RapaGUI related improvements

Feature requests for future versions of Hollywood can be voiced here
Post Reply
User avatar
midwan
Posts: 74
Joined: Sun Jun 19, 2016 1:15 pm
Location: Sweden

RapaGUI related improvements

Post by midwan »

Now that the RapaGUI plugin is available, I think we have a great tool for multi-platform UI design.
I would like to suggest a few improvements which I believe would make things even better:
  • Integrate the XML GUI definition file(s) in the final executable, so they don't have to be supplied separately for distribution. Ideally they should be handled as an "internal resource", but perhaps that can be an option?
  • Allow more than one XML GUI definition file per application. If my understanding is correct, this is not possible at the moment since there can be only one Moai Application entry point, which depends on one XML file (please correct me if I'm wrong though). Having more than one XML file available would do wonders for more complex applications which may need multiple windows.
  • When the plugin is used (defined in the code), make the Moai classes a "first class citizen" so they can be accessed directly instead of by reflection. What I mean is that I would love to use <TextBoxId>.Text = "new text" (or at least Moai.<TextBoxId>.Text = "new text") instead of Moai.Set("TextboxId", "Text", "new text"). I expect this one would require some (significant?) work to be done, but IMHO it would make things so much better.
p-OS
Posts: 167
Joined: Mon Nov 01, 2010 11:56 pm

Re: RapaGUI related improvements

Post by p-OS »

RapaGUI (like MUIRoyale) gets the xml definiton as a String. The developer is free to choose the way in which he provides this string.
In my MUIRoyale projects I already used different approaches.
1. external gui.xml file loaded at runtime
2. external gui.xml linked with @FILE
3. xml String created dynamically at runtime, based on a select from a SQLite3 database.

Hollywood IMHO should not force a specific rule.

I wonder for which use separate MOAI App Objects would make sense?

AFAIK IDs of RapaGUI Objects are actually just numbers, not pointers to an object (resp table). Thus I doubt that kind of access is not possible. It's not like Java, where every variable has an explicit datatype. Hollywood, Lua and many other languages (REBOL...), that are interpreted and/or inspired by functional languages work different:
Variables themselves don't habe a type, they have a value, and this value has a type.

But you might want to try writing a wrapper, based on tables with included functions, that simulate the kind of access you suggested.

Seems you have an OOP languages background ? But even with OOP languages (which Lua isn't really) it nowadays is considered bad coding style to directly access object attributes. One should use setter/getter methods for this and keep the attributes themselves private.
User avatar
midwan
Posts: 74
Joined: Sun Jun 19, 2016 1:15 pm
Location: Sweden

Re: RapaGUI related improvements

Post by midwan »

Thank you for the clarification regarding the xml definition, I wasn't aware of these possibilities actually (should've done my homework I guess). Especially option 2 seems to be exactly what I'd like to have, so great news! :)

I agree that since these options exist, Hollywood should not enforce a specific one.

What I mean regarding separate xml definitions, was a scenario with a rather complex application consisting of multiple source files (.hws) and multiple windows for the GUI. As soon as you start to scale up, the model of having only one XML file defining the GUI elements becomes more and more difficult to manage.
Is there a way to have multiple xml definition files but only one Moai App entry point? If that's possible somehow, then this is a non-issue.

Hmm, I will look into the wrapper approach you mentioned, I just haven't seen the internals of Hollywood's plugins so much yet so it will take me a while...

You're right about my language background, nowadays I make my living by coding in C# and I have some experience with C/C++, Java and some scripting languages before that like ARexx. :) Of course you're right about the coding style, but I was just suggesting the possibility, not the best practice scenario.
p-OS
Posts: 167
Joined: Mon Nov 01, 2010 11:56 pm

Re: RapaGUI related improvements

Post by p-OS »

Code: Select all

@FILE 1, "myGUI.xml" 

....

moai.CreateAppI(ReadString(1,FileLength(1) ) ) 

You could use several strings and concatenate them before you call CreateApp. The first and last containg the xml header / footer.

RapaGUI also allows you to dynamcally add objects like windows at runtime. Have a look at the exampüle for function reference -> moai.CreatObject
User avatar
airsoftsoftwair
Posts: 5433
Joined: Fri Feb 12, 2010 2:33 pm
Location: Germany
Contact:

Re: RapaGUI related improvements

Post by airsoftsoftwair »

midwan wrote:[*] Allow more than one XML GUI definition file per application. If my understanding is correct, this is not possible at the moment since there can be only one Moai Application entry point, which depends on one XML file (please correct me if I'm wrong though). Having more than one XML file available would do wonders for more complex applications which may need multiple windows.
I don't see why one would want to create more than one application object. I think what you want to do is create new windows or dialogs at runtime. This is already possible. See the Dynamic1.hws example.
[*] When the plugin is used (defined in the code), make the Moai classes a "first class citizen" so they can be accessed directly instead of by reflection. What I mean is that I would love to use <TextBoxId>.Text = "new text" (or at least Moai.<TextBoxId>.Text = "new text") instead of Moai.Set("TextboxId", "Text", "new text"). I expect this one would require some (significant?) work to be done, but IMHO it would make things so much better.[/list]
This would require every RapaGUI ID to be made available as a script variable which would break the compatibility with existing scripts because there might be variables which share the name of a RapaGUI ID. So the only way would be to make this optionally available. Basically, I think it's a nice idea because it would speed up things by allowing you to leave out all the moai.Set() and moai.Get() calls. I've noted down your idea and I'll see if this can be added for a future version.
User avatar
midwan
Posts: 74
Joined: Sun Jun 19, 2016 1:15 pm
Location: Sweden

Re: RapaGUI related improvements

Post by midwan »

Thanks for considering this, it would be fantastic if it gets implemented in some way in the future! :)
User avatar
airsoftsoftwair
Posts: 5433
Joined: Fri Feb 12, 2010 2:33 pm
Location: Germany
Contact:

Re: RapaGUI related improvements

Post by airsoftsoftwair »

It probably wouldn't be very difficult to do because Lua offers techniques to implement such things but I need to evaluate how efficiently and economically this is handled internally.
Post Reply