Murga-Projects Forums

Full Version: MurgaLua full release
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
OK ...

First the bad news :

No build tonight, and what's more I have been called away to London, so there is not going to be until Sunday at the earliest (when I get back). I am taking my laptop, so I expect I'll get time to do some stuff.

Then the good news :

Menu items now have a "menu()" method that points to their parent menu ... This allows you to do things like change a menu from a menu item callback (Juergen will be happy).

user_data(), data() and other methods only worked properly with strings ... I have completely re-written them so that you can use/associate any lua variable (or table), this needs a lot of testing, but so far I'm pretty happy :-)

I have made some other binding improvements and have a couple of nice surprises in store I think.

Cheers
JohnM

JohnMurga Wrote:

Juergen Wrote:
Yes it is ;-)
I overlooked that. Although there is a small misunderstanding.
menu:find_item(first_item) and menu:menu(0) is exactly the same, but for the latter you don't have to know what the first item is. If you check if there are 0 arguments supplied to the menu() function and then execute the same code that menu(0) does, it would be nearer to the fltk documentation.


Yes ... And ... No ...

The FLTK version would return a pointer that you could increment to get the next item. I cannot sensibly reproduce that in Lua, so I rather just have a slightly different method.

I think there is still a misunderstanding. I was talking purely about syntax not semantics!
As long as there is no complete documentation for MurgaLua, users have to refer to the fltk documentation. Therefore it isn't a good idea to unnecessarily differ from the FLTK behavior, especially when it is such a small difference.

The expected behavior can be restored if you do the following change:

Code:
int lua_call1_Fl_Menu___menu(lua_State * __S__)
{
   int nparam = lua_gettop(__S__);
   int __ERROR__ = 0;
-  if (nparam < 1) goto error;
+  if (nparam < 1) lua_pushnumber(__S__,0);
   {
      class Fl_Menu_ * __self__;
    
     __self__ = ( class Fl_Menu_ * )lua_to_Fl_Menu_(__S__, 1, &__ERROR__);


Which is a trivial change.

Also the userdata with the metatable isn't that different from the C++ behavior. If you want, you can add the __add meta method to get the increment behavior.


JohnMurga Wrote:
Right now ... You cannot ... In normal use the only instance I can see you wanting a reference to the menu would be if you want to change it from a menu item ... If so, there are several ways for you to hold a reference to the menu (I'll knock up and example).

I do not like the way FLTK handles it, as menu items are second class citizens (being low level structs). In murgaLua it's different, although I'll address your usage pattern and find a way to get it to make sense.

In some applications there are more then one menu. There may be multiple menu bars (sometimes there are multiple windows, like a small text editor for example), there could be multiple menu buttons or context menus. They can of course share the menu_item class/structure. For some functionality it is necessary to change the menu or access the parent widget or window.

The Fl_Menu_Item class is nothing more than a helper class to manipulate the Fl_Menu_Item structure. There is no functionality in the Fl_Menu_Item methods (except for do_callback) that you couldn't get by directly manipulating the Menu_Item structure. They are purely for convenience and compatibility. There are also the add, replace and methods in Fl_Menu_ that can be used to manipulate the menu.

Therefore the Menu_Item callback is just the same as the Menu callback but finer grained. It doesn't really make sense to provide a pointer to the menu_item to the callback.


JohnMurga Wrote:

Juergen Wrote:
Is there an example somewhere that doesn't throw an error message or a segmentation fault?


The previous menu example worked, although you (rightly) complained about it :-)

I'll code some more, although what I'd REALLY like to see are examples that DO cause error messages or segfaults, as that way I can either address the bug or explain what's wrong with the example.


I always get segmentation faults or a message that Lua can't index a nil value.

I didn't look into the code, but when I saw the double quotes in the original example it looked like you are compiling a binary chunk and calling it later.

I have an alternative suggestion. A few weeks ago I did a small user_data replacement implementation in pure Lua:

Code:
Fl_Button.udata={}


Fl_Button.user_data_old=Fl_Button.user_data

function Fl_Button:user_data(...)
local arg={...}
if #arg<1 then return self.udata[self]
   else self.udata[self]=arg[1]
end
end


It is simple, works with all values (also functions or tables). I guess it isn't hard to do it in C++ with some metatable magic and hide the table somewhere.

Juergen

Juergen Wrote:
Which is a trivial change.

Also the userdata with the metatable isn't that different from the C++ behavior. If you want, you can add the __add meta method to get the increment behavior.

I have no desire to change the syntax to be more like C++, and to me it makes NO SENSE ... As it happens when testing my latest user_data stuff I have also found it would result in additional LUA UserData chunk creation.

I don't want the lua code to behave like if it was C++, that is not the point.

Juergen Wrote:
In some applications there are more then one menu. There may be multiple menu bars (sometimes there are multiple windows, like a small text editor for example), there could be multiple menu buttons or context menus. They can of course share the menu_item class/structure. For some functionality it is necessary to change the menu or access the parent widget or window.

If you had a chance to read my other post you'd see that I'm putting functionality in place to support that usage pattern ... As I know it'll come up :-)

Juergen Wrote:
Therefore the Menu_Item callback is just the same as the Menu callback but finer grained. It doesn't really make sense to provide a pointer to the menu_item to the callback.

As part of the finer level of granularity I believe it does make sense :-)

But I have to give you a way to get hold of the parent menu (which I have done).

Juergen Wrote:
I have an alternative suggestion. A few weeks ago I did a small user_data replacement implementation in pure Lua:
It is simple, works with all values (also functions or tables). I guess it isn't hard to do it in C++ with some metatable magic and hide the table somewhere.

Again, if you had looked at my other post you would have seen that I have implemented something quite similar ... And as I said the reason for this is that I wanted people to be able to associate tables and anything else they be able to do normally from Lua.

I get your points, but I am not afraid of deviating from FLTK where it makes sense, and where (in my mind) it makes things simpler.

And far as the documentation ... The first step is for me to document the differences, and the second is for me to document everything :-)

Just out curiosity, what are you using murgaLua for ?

Cheers
JohnM

Hi John,

I haven't read your message since I wrote mine quite a few hours before. Unfortunately I got occupied somewhere else before I could post it and when I got back I just pressed the post reply button before I turned off the computer. (it was a little bit late/early ;-)

JohnMurga Wrote:

Juergen Wrote:
Also the userdata with the metatable isn't that different from the C++ behavior. If you want, you can add the __add meta method to get the increment behavior.

I have no desire to change the syntax to be more like C++, and to me it makes NO SENSE ... As it happens when testing my latest user_data stuff I have also found it would result in additional LUA UserData chunk creation.

I don't want the lua code to behave like if it was C++, that is not the point.

First: This was just a btw. addition to the above text and wasn't meant to be taken to seriously. I'm not even completely sure, if the functionality is really necessary.

JohnMurga Wrote:

Juergen Wrote:
I have an alternative suggestion. A few weeks ago I did a small user_data replacement implementation in pure Lua:
It is simple, works with all values (also functions or tables). I guess it isn't hard to do it in C++ with some metatable magic and hide the table somewhere.

Again, if you had looked at my other post you would have seen that I have implemented something quite similar ... And as I said the reason for this is that I wanted people to be able to associate tables and anything else they be able to do normally from Lua.

No I hadn't looked at your post. It was just a suggestion to use a table or something to store the value. The original example with the user_data("callback_function()") looked like there was some compiling involved (because the brackets had to be supplied).

Btw. Did you implement both behavior ( function my_callback(self, my_user_data) and my_user_data=self:user_data())?

JohnMurga Wrote:
Just out curiosity, what are you using murgaLua for ?

Besides from a few smaller scripts I did, I'm still evaluating it for a bigger project. It will be for a Linux development environment inside a virtualized Linux on Windows. The functionality I want to implement is something like downloading a image, creating virtual partitions, resizing partitions (with the fs), setting up the network (host guest), ...

There are still a few open questions, like calling external VB scripts or using luacom for some functionality or writing custom bindings for some functionality or using luawin or writing the code in C/C++ and make a lua module. I also haven't decided, if I want to use the socket support or libcurl or bundle a curl or wget binary and call it.

Juergen

BTW.: I did a small script and wanted to embed mplayer in a fltk window. Unfortunately the fl_xid and fl_find functions are not implemented. This shouldn't add any significant overhead (in size) and would be a cool addition.

I also did some tests and noticed that the methods to control the fltk event loop (like Fl.add_idle(), ...) are missing. If I want to have none blocking network IO, I think it would make sense to call copas.step() inside the fltk event loop. Or maybe alternatively put it in its own thread.

Pages: 1 2
Reference URL's