Murga-Projects Forums

Full Version: [WIP] MurgaLua Reference Tool
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

Quote:
a list of relevant links are on one side of the page and the content that it links to pops up on the other side of the page.

That sounds like frames, which I have grown to dislike greatly, or as you said CSS. If it does export HTML it will likely be css-enabled (although not css-dependent), since css is another thing that I have been studying and playing with over the last several months and I find it an easy way to beautify and organize the content of a group of pages.

My HTML at one time was targeted toward making whatever I could to appear unique and blingy...flash, javascript, lots of graphics, complex frames...but over time I began to head in the opposite direction, aiming for simplicity in all things. Most of the time I prefer plain text, with only a small taste of graphics (small in size and subtle in appearance). The ultimate HTML goal for me is that everything should be standards compliant, fast loading, and viewable in as many browsers as possible (which especially means no client-side scripting or plugins). So the CSS would enhance the experience slightly for those browsers that support it, but would not suffer from loss of content or ugly layout for those that don't.

Small update:

I'm continuing to work on the project at least a few minutes every day, so it is progressing. With each new piece, though, I'm finding new things that I have to learn (or relearn in a different way from Lua-FLTK) so progress has been slow. Also ran into a snag which required a rewrite of the widget-loading mechanism, but that was something I had been expecting to do since near the beginning.

The original "a few weeks" might turn into "a month or so" or maybe longer, so from this point on I'm not going to even hint at a time for release until it's ready for testing and feedback.

Current features include editing script samples and previewing the edits, saving samples (edited or not) to new files, changing scheme and font size (of loaded text files only, at least for now), and quick access to FLTK and Lua manuals and a page of miscellaneous code snippets. That's not a lot, but as I said I want to keep it simple. Still less than 30 widgets have been implemented, but that number will continue to grow.

The preview/save functions need more work. For now all changes are lost even if you do something as simple as checking out the readme while editing. This is a low priority, though.
Even if I can't include it I would LOVE to see what you have so far :-)

Cheers
JohnM
Well, just keep in mind that some parts of this package ARE BROKEN AND INCOMPLETE.
I've removed the docs directory to minimize the file size for now. They add something in the area of 700k to the compressed archive.

Also note that I plan to change the license to something OSI approved, and that I made an assumption about what iGame3D's name is =o)

That said, here it is in its most recent state
[removed]

mikshaw Wrote:
Also note that I plan to change the license to something OSI approved, and that I made an assumption about what iGame3D's name is =o)


eh?

Ok its looking good.
After a widget is previewed and a second widget is chosen it exits the window without any message. murgaLua continues running, and no error goes to console.

Quote:
After a widget is previewed and a second widget is chosen it exits the window without any message. murgaLua continues running, and no error goes to console.

Thanks for the heads up. It doesn't do that for me, though. Maybe it's a particular widget?

Everything I tested so far, and I've been picking them randomly.
Is there anything in the code that tells the window to close or hide?
No, but I imagine there could be without too much trouble. I think I should probably rethink the way the preview is done...maybe even use a new instance of murgaLua for it.

Here's the way it currently works:
Each widget file is a semi-complete script, without the window creation and fltk:Fl:run().
When the widget is called, the previous widget (if it exists) is removed.
A new child window is created and the widget file is added within that window with dofile().
This process causes everything in the widget file to become a part of the main window.
The preview is done by creating a new script in ram with the contents of the text window, which is run with assert(loadstring(tempscript))(). This might be the problem, since I don't fully understand assert or loadstring. It might be better to simply create a new external window for the preview, which I think could be more easily controlled.

So far I haven't done anything with it since the last post, so I'm just speculating.
The way it currently shows things in the main window is kind of cool, but perhaps it would be better to create a new or semi-newish "Example" window, while still being able to look at documentation and the script etc in the main window.

Its worth a shot.
Don't think you need any hiders or closers, except to demonstrate that kind of call...and in that case you will certainly need a new window or poof there goes the sample.

Its impressive, I was kind of heading down the same pay with my console gizmo, which I'll try to hack your widget demo into eventually.
I think you're right. It would probably also solve the problem of losing edits. That's the method I used with the Lua-FLTK version, and it seemed to work fine. I just have this thing about trying to keep away from having multiple windows within the same application (the Gimp interface, for example, is rather annoying to me)
Pages: 1 2 3 4 5 6 7 8 9 10 11
Reference URL's