Murga-Projects Forums
MurgaLua full release - Printable Version

+- Murga-Projects Forums (http://www.murga-projects.com/forum)
+-- Forum: Project Forums (/forumdisplay.php?fid=1)
+--- Forum: MurgaLua - General (/forumdisplay.php?fid=2)
+--- Thread: MurgaLua full release (/showthread.php?tid=271)


MurgaLua full release - JohnMurga - 01-29-2008 12:32 AM

Hi,

Version 0.6.0 stays as it is, but I won't be making a full release of it, as I have already got a little ahead of myself.

So the next is 0.6.5 ...

I am aiming for end of this week or some time next week ... My better half is out of the country for a while so I should be able to give this the time it deserves.

After the API changes I made with the 0.5 series people seemed to think I'd be doing this regularly ... That is not the case, I did it because there was a big gap, and I was taken by surprise by the success of murgaLua. Either way, 0.6.0 is 100% backward compatible with 0.5.5, and I expect all future releases to be, so there is no good reason not to start using any version you like ...

What I have done or am intending to do :
  • Fixed a couple of minor regressions. DONE
  • read_image implemented and made stable on all platforms (!!) DONE
    Allows you to capture any part of a window as an RGB image.
  • RGB image has a new NON-Fltk method (save as PNG). DONE
    I do not intend to support the saving of anything other than PNG's.
  • Off screen FLTK api.
    Abstract this in a way that can be used from murgaLua
  • Tiled image API - Allows you extract an array of images from one image (as tiles).
  • Animation control.
  • Table (grid) control.
  • Documentation.
If anyone wants to help they can do by submitting suggestions, tutorials, screen shots of your apps, or helping with documentation.

For the 0.7.0 series I'll be doing a lot of time consuming development, so anyone wanting a stable environment should stick with 0.6.5 as opposed to waiting... I'd be wanting to implement :
  • Size improvements.
  • Better FLUID integration.
  • C/Invoke type functionality.
  • Sound (where available).
  • Native 64 bit builds.
  • And much more !! ;-)
And it'll take a LONG time to do all this ...

Dropped from the list are :
  • Serial port support (this really should be a 3rd party module).
    Which I am happy to build if someone sends it to me
Let me know what you think.

Cheers
JohnM


RE: MurgaLua full release - Juergen - 01-29-2008 01:53 AM

JohnMurga Wrote:
Hi,

Version 0.6.0 stays as it is, but I won't be making a full release of it, as I have already got a little ahead of myself.

There is still a small problem with readline under Linux. (It just doesn't work ;-(

JohnMurga Wrote:
What I have done or am intending to do :
  • Fixed a couple of minor regressions. DONE
  • read_image implemented and made stable on all platforms (!!) DONE
    Allows you to capture any part of a window as an RGB image.
  • RGB image has a new NON-Fltk method (save as PNG). DONE
    I do not intend to support the saving of anything other than PNG's.

PNG as the only format to save images is O.K.
But what I would really like to see is the ability to load PNG's also from a binary string and not only from a file. This would allow it to have PNG icons embedded in the script, which can save about 60% against XPM's.

JohnMurga Wrote:
  • Off screen FLTK api.
    Abstract this in a way that can be used from murgaLua
  • Tiled image API - Allows you extract an array of images from one image (as tiles).
  • Animation control.
  • Table (grid) control.
  • Documentation.
If anyone wants to help they can do by submitting suggestions, tutorials, screen shots of your apps, or helping with documentation.


Another feature which might be worth considering, is a simple gzip and gunzip binding, since murgaLua already links to libz (PNG).

Juergen


RE: MurgaLua full release - iGame3D - 01-29-2008 03:31 AM

Is there a new version of murgaLua.html?

Time to SVN?
This SF project could be renamed: murgaLuaDocs or whatever.

We could update documentation and scripts as needed.

Looking forward to that PNG export.


RE: MurgaLua full release - JohnMurga - 01-29-2008 08:47 AM

Juergen Wrote:
There is still a small problem with readline under Linux. (It just doesn't work ;-(

Fixed in current dev build, was a linking problem.

Thanks for letting me know, I checked it out.

Juergen Wrote:
PNG as the only format to save images is O.K.
But what I would really like to see is the ability to load PNG's also from a binary string and not only from a file. This would allow it to have PNG icons embedded in the script, which can save about 60% against XPM's.

The functions in 0.6.0 make that possible now for any picture :-)

Only the PNGs would be in RGB form ...

But point taken ... I was thinking such a feature would be nice for JPG and PNG.

Juergen Wrote:
Another feature which might be worth considering, is a simple gzip and gunzip binding, since murgaLua already links to libz (PNG).

OK, it's on the list.

Cheers
JohnM


RE: MurgaLua full release - JohnMurga - 02-11-2008 10:02 AM

APOLOGIES !

If anyone was waiting for the new release they'll be disappointed ...

I had a couple of problems and lost a little work, and by the time I got back on track it's got a little late :-(

Anyway, here is a progress report ...
  • Tidied up a lot of code :-)
  • More build tweaks
  • Fixed a few more areas of the FLTK bindings, specially FL_Browser
    Can now use Fl_Browser as a grid/table, and data() works propperly
  • The offscreen API is done, but it's been a REAL pain, it isn't 100% perfect, and I haven't written tests yet.
  • Juergen's hex "C" code methods replaces my slower Lua code.
  • gzip and zlib integration (Juergen's suggestion).

I'll be making a cross platform build tomorrow I hope, and it'll be denominated 0.6.4 ... But it still won't be a full build as there is no way I'll get to update all the documentation, etc.

Cheers
JohnM


RE: MurgaLua full release - Juergen - 02-11-2008 10:41 AM

JohnMurga Wrote:
I'll be making a cross platform build tomorrow I hope, and it'll be denominated 0.6.4 ... But it still won't be a full build as there is no way I'll get to update all the documentation, etc.

Cheers
JohnM


If you are at it, here are a few few points (if they aren't corrected already):

The Fl_Menu_:menu() method doesn't work. I guess you are checking for an argument. The menu() should gives back the pointer to the first menu_item, which should be trivially to implement as it is the same as :find_item(first_item)

When you provide a callback function for a menu item, self in the callback function points to the menu_item and not to the menu which it should. This way there is no way to get the associated menu. The way fltk defines this is to provide a pointer to Fl_Menu_ and and the associated item can then retrieved via item=menu->mvalue().

I don't think user_data works. Or is there something special to pay attention to?

Juergen


RE: MurgaLua full release - JohnMurga - 02-11-2008 11:09 AM

Juergen Wrote:
The Fl_Menu_:menu() method doesn't work. I guess you are checking for an argument. The menu() should gives back the pointer to the first menu_item, which should be trivially to implement as it is the same as :find_item(first_item)

Nothing to fix :-)

That wouldn't be very useful in murgaLua, so I deviate from FLTK ...

Take a look at menuExample.lua ...

Fl_Menu_:menu(0) is what you'd want I guess.

Juergen Wrote:
When you provide a callback function for a menu item, self in the callback function points to the menu_item and not to the menu which it should. This way there is no way to get the associated menu. The way fltk defines this is to provide a pointer to Fl_Menu_ and and the associated item can then retrieved via item=menu->mvalue().

Again, I chose to deviate here ...

I thought it was simpler to get the menu item directly.

As it is MenuItems would always have to be a little different in murgaLua.
I will of course document these deviations ...
(There are more like timers, off-screen drawing, etc).

Juergen Wrote:
I don't think user_data works. Or is there something special to pay attention to?

Nope, you just set it on the widget or menu item, and then you get it.

If you remember the old menu example used it to store the function to call (a rather nasty hack).

Cheers
JohnM


RE: MurgaLua full release - Juergen - 02-11-2008 11:30 AM

JohnMurga Wrote:

Juergen Wrote:
The Fl_Menu_:menu() method doesn't work. I guess you are checking for an argument. The menu() should gives back the pointer to the first menu_item, which should be trivially to implement as it is the same as :find_item(first_item)

Nothing to fix :-)

That wouldn't be very useful in murgaLua, so I deviate from FLTK ...

Take a look at menuExample.lua ...

Fl_Menu_:menu(0) is what you'd want I guess.

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.

JohnMurga Wrote:

Juergen Wrote:
When you provide a callback function for a menu item, self in the callback function points to the menu_item and not to the menu which it should. This way there is no way to get the associated menu. The way fltk defines this is to provide a pointer to Fl_Menu_ and and the associated item can then retrieved via item=menu->mvalue().

Again, I chose to deviate here ...

I thought it was simpler to get the menu item directly.

As it is MenuItems would always have to be a little different in murgaLua.
I will of course document these deviations ...
(There are more like timers, off-screen drawing, etc).

If you could care to tell me, how to access the methods of the menu (redraw it for example) from within the callback. I don't see a way to do that. I can always access the item methods with self:mvalue():item_method() but I can't see a way to access the menu methods without using a special callback for every item or doing nasty tricks.

JohnMurga Wrote:

Juergen Wrote:
I don't think user_data works. Or is there something special to pay attention to?

Nope, you just set it on the widget or menu item, and then you get it.

If you remember the old menu example used it to store the function to call (a rather nasty hack).

Cheers
JohnM


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

Juergen


RE: MurgaLua full release - JohnMurga - 02-12-2008 09:47 AM

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.

Juergen Wrote:
If you could care to tell me, how to access the methods of the menu (redraw it for example) from within the callback. I don't see a way to do that. I can always access the item methods with self:mvalue():item_method() but I can't see a way to access the menu methods without using a special callback for every item or doing nasty tricks.


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.

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.

Cheers
John de Murga


RE: MurgaLua full release - JohnMurga - 02-12-2008 09:54 AM

JohnMurga Wrote:
  • The offscreen API is done, but it's been a REAL pain, it isn't 100% perfect, and I haven't written tests yet.

I'll be making a cross platform build tomorrow I hope, and it'll be denominated 0.6.4 ... But it still won't be a full build as there is no way I'll get to update all the documentation, etc.


Well, the offscreen API in FLTK is a REAL HACK, and getting it to work is pain ... I finally got it working, but the implementation is nasty, and sucks big time (likely to break with new versions of FLTK).

I'd like to yank it, but I invested a lot time ... And it does work well, so I'll keep it :-)

I also upgraded to Lua 5.1.3 ... I am now hoping for a test build this week with some documentation, but as normal my promises should be taken with a pinch of salt.

Cheers
JohnM


RE: MurgaLua full release - JohnMurga - 02-13-2008 10:16 AM

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


RE: MurgaLua full release - Juergen - 02-13-2008 12:29 PM

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


RE: MurgaLua full release - JohnMurga - 02-14-2008 11:46 PM

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


RE: MurgaLua full release - Juergen - 02-18-2008 08:55 AM

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.