News : The level of daily SPAM has reached insane proportions, all registrations are now manual. I ask you to send me an e-mail (john (at) murga (dot) org), to confirm that you want me to create an account for you.


Post Reply  Post Thread 
Pages (2): « First < Previous 1 [2] Last »
Initial build of version 0.6.0
Author Message
JohnMurga
Administrator
*******


Posts: 381
Group: Administrators
Joined: Apr 2007
Status: Offline
Reputation: 2
Post: #11
RE: Initial build of version 0.6.0

mikshaw Wrote:
I'm here =o)
Unfortunately, I have piles of snow to clear out today, so won't get a chance to look at it much until later. But I definitely wanted to see how the pixmap embedding works, and I gotta say THANK YOU very much for this!
It doesn't work exactly as I thought it would, but I figured it out after a few segfaults =o)
Important thing to note is that it doesn't accept the comments that you would typically see in an XPM file, including the initial /* XPM */

Glad you liked it :-)

It's totally based on how FLTK structures things internally, for Pixmaps you'll get an idea of what this by looking at the rotation demo...
I add some additional attributes for convenience, but that's about it.

One of the many things I have to document.

mikshaw Wrote:
I'm really looking forward to seeing how user data works.

The menu example has a sampler ...

Basically you can set the user data for any control or menu item, this is particularly useful if you have a group or menu, where many items got to the same callback ... This allows you add a function or information to influence the routing (for the menu example I make it possible to associate a function to each item, and that could even be the same function with different parameters).

Not that I explained it very well, and I fell short on the example :-(

mikshaw Wrote:
I also got the same error message on Linux (DSL 4) as xleitex did on XP when opening murgaLua with no argument.

Now that is weird ... I fixed the problem on Windows, but if it's happening on Linux then it's for a different reason.

I'm on it :-)

Cheers
JohnM

01-20-2008 03:16 AM
Visit this user's website Find all posts by this user Quote this message in a reply
Juergen
Member
***


Posts: 81
Group: Registered
Joined: May 2007
Status: Offline
Reputation: 0
Post: #12
RE: Initial build of version 0.6.0

There are still a few problems:

- The version string says still version 0.5.5.

- The error that has been already reported appears also under Linux, when the murgaLua command invocation doesn't contain any slashes and the shell has to locate the binary in one of the PATH directories. But I guess it is the same bug that has already been reported under Windows and might therefore already be fixed.

- There are still a few collisions with reserved keywords. For example: Fl_Group has a "end" method which can't be called. A rename to "End" would be a good idea.

- The user_data("function_name()") method looks like a really big ugly hack. Is it so hard to support something like:

myItem=menuBar:find_item("Some menu item/&item2")
myItem:callback(myItemCallback)

and also menuBar:add("&First menu item/First item",fltk.FL_CTRL + string.byte("f"),myItemCallback)

I'm pretty sure there is some way, to do it without using a function which takes a string with the name of the callback function as an argument.

Juergen

01-20-2008 04:11 AM
Find all posts by this user Quote this message in a reply
JohnMurga
Administrator
*******


Posts: 381
Group: Administrators
Joined: Apr 2007
Status: Offline
Reputation: 2
Post: #13
RE: Initial build of version 0.6.0

Juergen Wrote:
- The version string says still version 0.5.5.

That was stated in the release notes.

Juergen Wrote:
- The error that has been already reported appears also under Linux, when the murgaLua command invocation doesn't contain any slashes and the shell has to locate the binary in one of the PATH directories. But I guess it is the same bug that has already been reported under Windows and might therefore already be fixed.

Nope, the windows bug is slightly different ...

This one requires a different fix ... Which I haven't done yet.

Juergen Wrote:
- There are still a few collisions with reserved keywords. For example: Fl_Group has a "end" method which can't be called. A rename to "End" would be a good idea.

If you can tell me the other ones I'll be happy to address this.

Juergen Wrote:
- The user_data("function_name()") method looks like a really big ugly hack.

It is purely a way to do things a little better right now thanks to the user_data() support.

Not the only hack in there :-)

I don't think it's that big and ugly compared to the current menu handling (which leaves a lot to be desired).

Juergen Wrote:
Is it so hard to support something like:

myItem=menuBar:find_item("Some menu item/&item2")
myItem:callback(myItemCallback)

and also menuBar:add("&First menu item/First item",fltk.FL_CTRL + string.byte("f"),myItemCallback)

Not that hard, but I haven't got round to it yet as i needed the user_data for some other stuff too ... And callbacks are a pain, so it hasn't been a priority (but I've added it to the list).

Juergen Wrote:
I'm pretty sure there is some way, to do it without using a function which takes a string with the name of the callback function as an argument.

For now that is actually the best solution, until I get round to enhancing the API as you have pointed out :-)

Thanks for the thorough testing !

Cheers
JohnM

01-20-2008 04:54 AM
Visit this user's website Find all posts by this user Quote this message in a reply
mikshaw
Senior Member
****


Posts: 522
Group: Registered
Joined: Apr 2007
Status: Offline
Reputation: 5
Post: #14
RE: Initial build of version 0.6.0

Quote:
Basically you can set the user data for any control or menu item, this is particularly useful if you have a group or menu, where many items got to the same callback ... This allows you add a function or information to influence the routing

I've used tooltip() in the past as a replacement for this, but tooltips are not always appropriate for some situations, and I can't say for sure whether you can apply them to individual menu items.

01-20-2008 05:45 AM
Find all posts by this user Quote this message in a reply
JohnMurga
Administrator
*******


Posts: 381
Group: Administrators
Joined: Apr 2007
Status: Offline
Reputation: 2
Post: #15
RE: Initial build of version 0.6.0

OK, fixed the other bug now ... All related to the compiler core.

I am going to see what I can do about Juergen's menu concerns ... Later :-)

01-20-2008 06:48 AM
Visit this user's website Find all posts by this user Quote this message in a reply
mikshaw
Senior Member
****


Posts: 522
Group: Registered
Joined: Apr 2007
Status: Offline
Reputation: 5
Post: #16
RE: Initial build of version 0.6.0

Messing around with the menu example, I made a couple of changes that cut down the size a little, although it might not be as easy to read. Mainly I just like to see how small I can make things.

Code:
testItem=menuBar:find_item("Second menu item/&First item");
testItem:user_data("testFunction()")

is replaced by

Code:
menuBar:find_item("Second menu item/&First item"):user_data("testFunction()")

and the callback (just the part that runs testFunction) is

Code:
menuBar:callback(
function(w)
local s=w:mvalue():user_data()
if s then assert(loadstring(s))() end
end
)


I don't know if io.flush is still needed? Actually I don't know if I should be using it in other scripts too.

It didn't look at first as though this was any simpler than making a bunch of elseif statements in a single callback, but it seems that this is the next best thing to assigning callbacks directly to menu items.

It still seems like there should be a simpler way than loadstring, since the string is already static and in memory, but since you plan to eventually attack the callback this will be fine.

01-20-2008 08:34 AM
Find all posts by this user Quote this message in a reply
Pages (2): « First < Previous 1 [2] Last »
Post Reply  Post Thread 

View a Printable Version
Send this Thread to a Friend
Subscribe to this Thread | Add Thread to Favorites

Forum Jump: