Murga-Projects Forums

Full Version: Visual Lua
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi!

To celebrate the upcoming, long-expected release of the next version of murgaLua, I came up with a new toy project:

Making an FLTK interface that would allow for creating Lua programs graphically.
I got this idea from different tools, like Matlab's Simulink, vistrails visualization workflows, etc etc.

I think it might be very useful for prototyping, for education (think explaining programming to kids), visualization of data for less programatic minded people etc.

The idea would be to have a set of blocks that would have in- and output ports that can be connected with lines. This would enable passing data from one block to another if run. Each block corresponds to a Lua function.

If anyone would want to join the effort, I could put up a git repo.

Now for the problems:
I'd want to separate of the logic from the GUI stuff, as to be able to port the same logic to other frontends (Why not put those blocks in a 3D space Wink). This would mean keeping all blocks, links, ... in tables. But I would need to be able to get the identity of a GUI block to associate it with the logic. A quick check however pointed out that the Fl:belowmouse() returns the correct widget, but each time packed in a new userdata object. Would it be possible to make murgaLua keep userdata objects associated with the generated widgets, as to be able to store and compare them in a list?
For now I was able to move boxes without needing the ID, just using the returned widget itself, and the FL boxtype, but as the project goes on, I will certainly need to be able to keep ID's (for example selecting multiple boxes, or using different box types for different kind of blocks, ...)

You can find the code I knocked up starting from the draggable box in the Widgets Demo attached.

Current pathetic features:
- multiple draggable boxes
- snap to (invisible) grid
Edit: New version adds:
- no initial jump when starting the drag

[attachment=81]

jpjacobs Wrote:
This would mean keeping all blocks, links, ... in tables. But I would need to be able to get the identity of a GUI block to associate it with the logic. A quick check however pointed out that the Fl:belowmouse() returns the correct widget, but each time packed in a new userdata object.

That is possible but I don't remember how and I am not at a PC right now.

I'll take a look and post the code.

Cheers
JohnM

Hey,

Subtle thing to do there ...

When you create the widget call user_data("your id/data/whatever") on it.

Then on the returned widget call user_data().

user_data() should work (if it doesn't it's a bug).

That is how the menu examples work.

Cheers
JohnM
Hey, thanks for the quick reply!

That indeed solves the issue of tracking the widgets Smile.

Now for another, bizarre problem: I made a function to add new blocks, and a button to add blocks, that calls that function as callback when pressed.

When used as standalone function it functions perfect (boxes show up as they should, get registered, etc etc), but when called as callback, the function runs, but the box does not show.
I did take into account that a callback gets passed its button as first argument, and compensated for that...

Any idea what's going wrong there?

Kind regards,

Jan-Pieter
So I've been testing around, and it seems that the newBlock function works fine when called before window:show() and stops working (ie, the generated blocks do not show) when called after window:show().

Am I just missing the point here, or is there a work around for this?

Kind regards,

Jan-Pieter
Yeah, this is a funny one ...

Basically a Window is a Group, and when you create the Window (but before the show) it is the default group.

However, in the callback it is not ... So just add "w:add(tmp)" before your "w:redraw()" and it should work.

Cheers
JohnM
Reference URL's