Sooo....

what do I need to do in order that it will not break when compiled, but so that I'm also satisfied with the behavior of the uncompiled script? Mainly the uncompiled script must be able to be run in any directory, from any directory, whether called as a command or as an argument to murgaLua.

Eventually I would like that to work even from a link/shortcut, but it's something I've never done in Lua, and I think it might be an OS-dependent issue.

By the way, how does viewing/editing of code work in this package if it's compiled?

Everything works fine in the binary, edit or view code, activating widgets, the works.

Finding the files from the binary on other systems is a mystery to me.
On Mac I'm keeping everything in a bundle and the Applescript solves the problem
of passing the right directory inside of that bundle to the binary.

dofile fails on arg[0]

There needs to be some test for arg, and if its nil then ...I'm not sure
how you'd find the script, does lua have any kind of "last file loaded"
global hanging around?

I thought I figured it out the other day but thats much less than a perfect solution.
I'm stumped, but happy its working well.

I'll take a look at this tomorrow night ... Don't forget that the compiler is the first beta, so if there are issues (and there are), I just have to fix them :-)

I was playing around with Vector Linux last night, and bumped into an application called gtk-demo. This application is virtually identical in its purpose, but the design of its interface is quite different. Gtk-demo is cleaner and simpler in both behavior and code, and I'm seriously considering a redesign. It would make the code much smaller and easier to follow, less prone to bugs, and provide a more friendly experience to the enduser. In fact, I'm quite certain that this will be a smart move.

The interface of gtk-demo is split into two sections: a selection browser on the left, and two tabs on the right. The tabs are "Info" (same as my "notes"), and "Source". When a widget name is selected in the browser, that Lua file and its associated text are loaded into the tabs. Double-clicking the widget name displays the widget in a new window rather than a nested window (which has given me more than a few headaches). This simple UI change would remove the need to mess with changing titlebar names, toggling menu items, exporting variables, limiting widget dimensions, watching out for clobbering or missed variables, and a number of other issues that I've had to pay close attention to. Most importantly the code for the individual widgets will not need to be tailored specifically for use in this package...any MurgaLua script that works on its own can simply be dropped into the data directory as-is.

This design won't be fully implemented, though. I'd much rather just have a button to launch the demo rather than deal with testing for single or double clicks. But it amazes me when I think about how much simpler it will be to manage the code with this design, and will be less annoying to the user with fewer clicks to do.

So, it will be a little while before Beta 3 is released, but it will likely be smaller and less buggy.

It still won't account for the arg issue, though. I will still need to know exactly where the data files are.

Of course, there are some issues I hadn't realized.

* The images directory still needs to be found by some of the demos, so I needed to set that variable from the murgaLua commandline. I don't think there's any way around that short of embedding all images, which would limit the flexibility of demos.
* The progress widget needed to be incorporated into the main interface, but that wasn't a big problem.
* There are some cosmetic issues that need to be worked out...resizing and intrusive scrollbars in particular
* Some of the "features" in the previous version will probably be dropped, such as coloring and styling the interface. These will be included as demos. I'll probably still include font scaling for the sake of readability.
* I had to remove or replace some variable names in practically all of the demos, and resize most of the windows for visual appeal =op

Overall I like the way the new interface works. The main script is about half the size and much less complex. Code viewing and editing is now done in a single field. Demos are run and saved from whatever code is in that field, so it doesn't need to access the file more than once. Info files (for existing widgets) that are added while the application is running can be viewed without restarting (just a dev issue that was annoying me). I'm hoping to do something similar for the demo files themselves, but that will be a bit harder. Code and Info are loaded simultaneously, so accessing either is just a matter of clicking a tab rather than reloading one or the other. The Lua manual is now loaded (on demand, to save precious resources) in a tab rather than a separate window. Eventually it will be much easier to control via keyboard than the old menu system ever could be.

EDIT: the disappearing window was a stupid user error =o)

This post was last modified: 02-06-2008 04:16 AM by mikshaw.

I briefly tested the new design in Windows, and one major part doesn't work yet.

Finding the murgaLua executable (for 0.5.5 support) works fine, so I was happy about that part:

But the command that is supposed to pass the images directory to the individual demos doesn't work:

It gives an error concerning an unexpected symbol. I'm thinking it's either the escapes or the nested quotes.

EDIT: Next time I'm going to try this to see if it's better:

This post was last modified: 02-13-2008 05:28 AM by mikshaw.

After some changes to that according to feedback from Juergen, I've made a change that will hopefully work in Windows, but it hasn't yet been tested. It does work in Linux, and I assume OSX as well, so I've posted beta 3 hoping that it can easily be fixed if it doesn't work in Windows.

http://www.murga-projects.com/forum/atta...php?aid=35

Awesome!
Works great!
I think those buttons at the base need to get moved though.
Whats the x%(n of nn) box in the corner?

Have we figured out how to display styled text?
Syntax styling on those scripts would be fantastic.
I suppose displaying html like the lua manual does the trick.

If its not already in your documentation, notes, and scripts,
you may want to begin adding a version number.

It will be useful to see whats new, and maybe see if something
has been removed before the current version of murgaLua, and
provide a pointer to the new style of doing things.
The file and timer stuff comes to mind.

Another thing might be to run "Snippets" as a separate but
nearly identical program with an "add" button.
Looks like it could be a handy tool, I have such a program,
but its not handy for murgaLua.

Why are you worried about 0.5.5 compatibility?

1.0 will compare to 0.5.5 as 0.5.5 compares
to John linking Lua and Fltk together for the first time.

Push forward.

Next step an IDE with compiler and GUI editor, yeah?
You have the makings for it right here in this reference gizmo!

I've been meaning to post a thread to get that started, but
seriously had to wait and see what you would pull off here.
Now to figure it all out.

Bravo!

This post was last modified: 02-28-2008 12:44 PM by iGame3D.

I had them originally at the top, but it seemed bulky-looking. Being a keyboard-focused user, I sometimes have trouble balancing the visual with the easily-clickable. I'm open to any suggestions you have.

It's an example of Fl_Progress(), displaying the number of demo scripts that have been viewed. It was originally a separate widget, but the design change made it necessarily part of the main script. I was thinking about moving into a tab, but the main screen was visually unbalanced without it.
Is it literally displaying "x%(n of nn)"? That would not be good.

I started to mess with formatting the snippets page with html, but after twenty minutes I realized that it will be a pain to make updates to it. Syntax highlighting is definitely on my want-to-do list, but every time I look through the Fl_Text_Editor docs I start to get dizzy =o)

It's there, at the top of the readme. My versioning system is very basic. Each release in incremented by 1 unless a very tiny yet very vital fix is needed.

I like those ideas. The Changelog is there, but it is not accessible through the gui and isn't terribly explicit. User-added snippets is brilliant, although it is not likely to be implemented right away.

I care about backward compatibility in general, as long as it is reasonable to do so. Version 0.5.5 was a pretty big change, so support for prior versions would be more work than it's worth. When it gets to the point where 0.5.5 support is an annoyance I'll likely drop it. Until then, support for it has been only a tiny issue. Also, I am positive that 0.5.5 is still circulating on fairly recent live CDs, so it's still in use (I still have a DSL system with version 0.5.5 installed on 2 machines). Finally, I believe intentionally including code to support older versions is an educational example in itself.

I'm also pretty sure 1.0 is still quite a while away. This demo package will evolve as time goes on, and will eventually also reach a 1.0 stage and be quite different than when I started.

Several times I have thought about the possibility of doing something in murgaLua based on the behavior of fluid but with a vtcl philosophy; in other words, a tool written in murgaLua that generates pure murgaLua code. However, thinking about the possibility is as far as I've ever gotten. That would be a big project and I'm not sure I'm the one to start it at this time.

Hey

AWESOME ...

but

Doesn't work on Windows ... You get a :

This is because the final "\" in the images path escapes the quotes in the DOS command ...

To fix modify the code as follows (or something similar, as I just knocked this up quickly)

Cheers
John de Murga