Re: [Flightgear-devel] Gui - updating gui state dynamically
* James Turner -- 6/12/2009 11:05 AM: I guess there is no chance of switching to osgWidgets in the near future? I've not looked at how mature that code is or isn't yet. No. This may take another year, or two. AFAIK, osgWidgets is still nothing more than colored, clickable rectangles with labels and input fields -- basic building blocks for a GUI. But there's nothing like a scrollable list, comboboxes, 3D-widget effects, etc. Looks like we'd have to take over osgWidgets development to get it into a usable state. Switching now would be a big step backwards, and I see no reason for that. PLIB's pui works reasonably well, and it's not like it'll suddenly stop working. We can still put it in our CVS if we want to get rid of the PLIB dependency already. But there are still other things that we depend on, anyway (js handling, networking). m. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gui - updating gui state dynamically
* James Turner -- 6/8/2009 10:52 AM: On 6 Jun 2009, at 08:46, Melchior FRANZ wrote: I'll [...] try to keep PLIB'isms away as far as possible. Actually, I'll reorganize the code a bit so that possible later transitions to osgWidgets or other toolkits are even easier. And I intend to make all widget properties live, so that one can, for instance, change the x component (and optionally re-layout the dialog), and see the widget move. It'll be nice to have live color changes and to see the total weight text in the payload dialog turn red on overload etc. I also hit problems trying to have PLIB notify the gui code (and hence, Nasal script) when a text field lost focus - which is a useful point to be able to 'commit' the contents and update other UI state dynamically. Aren't bindings triggered then? Well, maybe not in all cases. I'll look into that. One request, if possible, for the pop-up menus - it would be great to be able to associate a hash with them, OK, sounds like a good idea. Actually, if PLIB made it possible, the nicest thing would be a 'menu about to open' script hook for the menus - which could then update the contents directly. That's something available in many widget systems, but again I suspect it might be tricky with PLIB. The trickiness isn't so much the problem. It's more the question how much time we still want to invest in PLIB. But I see no problems submitting necessary changes to PLIB. Actually, I've sort-of become PLIB's gui maintainer already, anyway. ;-) m. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gui - updating gui state dynamically
* James Turner -- 6/8/2009 10:56 AM: Another, related question: is it possible to hide and show UI element / groups dynamically? You can manipulate (add/remove/change) anything in a dialog before it's opened by embedded Nasal. You could have an XML dialog file with only a nasalopen block, and let that create the whole dialog. At the moment you'd have to close and re-open the dialog to add widgets, though. I checked over the dialog code, and I don't see a standard 'visible' or 'hidden' property (looking at FGDialog::makeObject), but perhaps there is some other way to achieve this? There's a visible property per widget group, which defaults to true. You can let the nasal part toggle that, in which case the widget won't be considered at all (including in the layouting). But toggling the property later won't have an effect. m. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gui - updating gui state dynamically
On 12 Jun 2009, at 09:54, Melchior FRANZ wrote: And I intend to make all widget properties live, so that one can, for instance, change the x component (and optionally re-layout the dialog), and see the widget move. It'll be nice to have live color changes and to see the total weight text in the payload dialog turn red on overload etc. That would be a very useful feature yes ! I also hit problems trying to have PLIB notify the gui code (and hence, Nasal script) when a text field lost focus - which is a useful point to be able to 'commit' the contents and update other UI state dynamically. Aren't bindings triggered then? Well, maybe not in all cases. I'll look into that. I looked at it, and it seemed not, in this specific case, but I'm inexperienced with the code - I'm reading the existing dialogs, copying-pasting and trying to understand what I see (plus looking at dialogs.cxx sometimes for backgound). Maybe this already works and I just need to be shown an example. Actually, if PLIB made it possible, the nicest thing would be a 'menu about to open' script hook for the menus - which could then update the contents directly. That's something available in many widget systems, but again I suspect it might be tricky with PLIB. The trickiness isn't so much the problem. It's more the question how much time we still want to invest in PLIB. But I see no problems submitting necessary changes to PLIB. Actually, I've sort-of become PLIB's gui maintainer already, anyway. ;-) Yeah, that last is very much a 'nice thing'. I'll let you decide how to balance spending time on the PLIB GUI, since you know it better than me (or anyone else, it sounds like). I guess there is no chance of switching to osgWidgets in the near future? I've not looked at how mature that code is or isn't yet. James -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gui - updating gui state dynamically
On 12 Jun 2009, at 10:04, Melchior FRANZ wrote: I checked over the dialog code, and I don't see a standard 'visible' or 'hidden' property (looking at FGDialog::makeObject), but perhaps there is some other way to achieve this? There's a visible property per widget group, which defaults to true. You can let the nasal part toggle that, in which case the widget won't be considered at all (including in the layouting). But toggling the property later won't have an effect. Ah, which is the part I want. There's various uses I have in mind for this, but the key one is to adjust which (of a group) of buttons are shown based on the some other dynamic state. I guess for now I can simply show all the buttons, and disable / ignore the ones that don't make sense in each situation. It would also let me implement something like tabs, but I think I'd be better using child-dialogs for such features, at the moment. James -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gui - updating gui state dynamically
On 5 Jun 2009, at 19:52, James Turner wrote: I want this for the route-manager dialog, but I can imagine similar concepts being useful in the other places in the GUI - for example the 'position on ground' dialog could have the runway and parking position fields replaced with menus, avoiding having to guess the correct values. Another, related question: is it possible to hide and show UI element / groups dynamically? In once case I'd like to change which buttons are shown in a dialog, based on the property values, and in another I'd like to change what is displayed in a particular area, i.e show one of two different groups, again based on a property value. I checked over the dialog code, and I don't see a standard 'visible' or 'hidden' property (looking at FGDialog::makeObject), but perhaps there is some other way to achieve this? James -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gui - updating gui state dynamically
* Melchior FRANZ -- Friday 05 June 2009: With some code in dialog.cxx live updates of lists could be implemented, too. Recent changes made that easier than before. This would really be the best approach. It could then also be used to live-enable/disable (grey out) widgets, or to change their color while the dialog is open, etc. I'll work on that in the near future and try to keep PLIB'isms away as far as possible. (Can't do it in the next few days, and I'd really also like to know first in which direction the property (mis)develops.) m. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gui - updating gui state dynamically
I've started something similar, (I think) , with help from others, with the ATC2. I use the nasal airportinfo(id) to get airport and runway info.The ATC2 uses 2d panel text , but should be able to do the same in a dialog . A listener would be able to run a routine whenever the ICAO code changed ... ... Im on lunch break , so dont have time for more details :) Cheers On Fri, Jun 5, 2009 at 11:52 AM, James Turner zakal...@mac.com wrote: (getting back into some route-manager / GPS hacking, after a busy few months) Can anyone (with more experience of the GUI code and Nasal) suggest how close I can get to a GUI like the one I've mocked-up below: the idea being you enter an ICAO code, and when a valid code is entered, the runways menu gets populated (defaulting to the active runway for the airport, that's the one marked with an asterix) and we also update the airport text field to show full name. Here's what I think this needs, but perhaps I'm wrong: - the ability to populate a menu (of runways, in this case, but it could be anything) dynamically from a script / dialog-action - presumably from a Nasal array of strings, or a hash. - a way to run a dialog-action every time a text input field (for the airport ICAO code) receives a key-press, so I can keep trying to look up the airport and then populate the runways menu. I want this for the route-manager dialog, but I can imagine similar concepts being useful in the other places in the GUI - for example the 'position on ground' dialog could have the runway and parking position fields replaced with menus, avoiding having to guess the correct values. Regards, James -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gui - updating gui state dynamically
* James Turner -- Friday 05 June 2009:
Can anyone (with more experience of the GUI code and Nasal) suggest
how close I can get to a GUI like the one I've mocked-up below:
There are currently two ways:
- make the popup an extra dialog; See the dialog that's shown in Model
View in the lower left corner of the screen if you click on the model
name. It's defined in $FG_ROOT/gui/dialogs/model-view{,-select}.xml,
of which the latter is the popup.
- just fill the combobox values appropriately, and redraw the whole
dialog. That's problematic, though, if it interferes with user input,
because it happens while a user types into an input or something.
You have to read out the dialog x/y coordinations and to redraw the
dialog on the same place. The dialog dimension should better not
change in the new dialog.
With some code in dialog.cxx live updates of lists could be implemented,
too. Recent changes made that easier than before. I haven't done
anything of that sort yet, because we were discussing a switche from
plib to osgWidget, and more plib specific code didn't seem a good
thing at the moment, even though that switch isn't imminent.
I'd probably go with the first solution.
m.
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
