Re: [Flightgear-devel] Property Picker
Mally writes: > I'm going to complain, mainly because I'm intrigued as to what the > 7th-century Insular Latin version would be like: Frightening (classicists need to be monitored closely in case they go into shock). I recommend Aldhelm's De Virginitate as a starting point; unfortunately, I cannot find an online version, but your local monastic library may have a copy. > Rather than a description attribute, if you have description as a > child element, then the description can have its own language > attribute. The default value for the language attribute can be > chauvenistic English, and the multilingual stuff can optionally be > done by using additional description elements with a specific > language attribute, e.g. . One advantage of the XML representation is its conceptual simplicity. Every element except for the root PropertyList container represents exactly one property, and every attribute represents metadata for the property associated with its element. I've added some simple support for aliasing and inclusion, but I'd be reluctant to do anything else. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Picker
> > An other idea could be to add a description to every property. So the > > user can figure out what each of those are good for when browsing the > > tree. And when we would change our command line options to be property > > entries we cuold automatically create the --help option which will > > allways stay up to date. > > I think that's a great idea. There are two reasonable choices: > > 1. Allow a "description" attribute for each property in the XML >markup. It could contain only plain text in a single language, but >would be trivially easy to access. > > 2. Allow a "url" attribute for each property in the XML, pointing to a >Web page (or part of a Web page) describing the property. The HTTP >server could handle L10N through content negotiation, and we could >make the documentation as elaborate as we want; however, it would >be hard to stick the docs into the property picker. > > I'm going to recommend #1, even though it supports only English > documentation. We can always add something more elaborate later, but > a navel-gazing, chauvenistic, English-only system that everyone uses > is better than an idealized, multilingual system that no one does. If > anyone complains, I'll consider doing the whole thing in 7th-century > Insular Latin instead. I'm going to complain, mainly because I'm intrigued as to what the 7th-century Insular Latin version would be like: Rather than a description attribute, if you have description as a child element, then the description can have its own language attribute. The default value for the language attribute can be chauvenistic English, and the multilingual stuff can optionally be done by using additional description elements with a specific language attribute, e.g. . As for all the other information which could be added to the property tree, but which is not required at run time, then that could be stripped out of a runtime copy of the tree if performance was an issue. Mally ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Picker
Christian Mayer writes: > > - is readable? (already implemented) > > - is writable? (already implemented) > > - is archivable? (already implemented) > > - data type (already implemented) > > - list of allowed values > > Wouldn't a check for that slow the properties down? Or would it only be > used when you enter data externally? It depends on the constraint. We'd want to design it to minimize overhead where a constraint is not in use (i.e. a single boolean or null-pointer check); where a constraint is necessary, we probably currently enforce it in C++-code somewhere, so it won't make much of a difference. Note that four of the five above are already implemented. > An other idea could be to add a description to every property. So the > user can figure out what each of those are good for when browsing the > tree. And when we would change our command line options to be property > entries we cuold automatically create the --help option which will > allways stay up to date. I think that's a great idea. There are two reasonable choices: 1. Allow a "description" attribute for each property in the XML markup. It could contain only plain text in a single language, but would be trivially easy to access. 2. Allow a "url" attribute for each property in the XML, pointing to a Web page (or part of a Web page) describing the property. The HTTP server could handle L10N through content negotiation, and we could make the documentation as elaborate as we want; however, it would be hard to stick the docs into the property picker. I'm going to recommend #1, even though it supports only English documentation. We can always add something more elaborate later, but a navel-gazing, chauvenistic, English-only system that everyone uses is better than an idealized, multilingual system that no one does. If anyone complains, I'll consider doing the whole thing in 7th-century Insular Latin instead. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Picker
David Megginson wrote: > > All Properties > -- > > - is readable? (already implemented) > - is writable? (already implemented) > - is archivable? (already implemented) > - data type (already implemented) > - list of allowed values Wouldn't a check for that slow the properties down? Or would it only be used when you enter data externally? > In addition, since the number of properties in the core tree will be > very small (probably less than 1,000), we could add optional debugging > information. That would be great. An other idea could be to add a description to every property. So the user can figure out what each of those are good for when browsing the tree. And when we would change our command line options to be property entries we cuold automatically create the --help option which will allways stay up to date. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Property Picker
Jim Wilson writes: > "Ranges" and "Value lists" would be good. I was thinking of > enforcing rules defined in xml in the prop_picker, but it sounds > like your saying that should be in the property manager code. > Which makes sense. It'd be good to have a error return code(s) > from the property manager so that prop_picker (and the other > interfaces) could display a message to the user. If the property manager could enforce basic constraints, it could eliminate a lot of C++ code. What are some reasonable facets for a property? Here's what I've thought of, going from general to specific: All Properties -- - is readable? (already implemented) - is writable? (already implemented) - is archivable? (already implemented) - data type (already implemented) - list of allowed values Numeric Properties -- - minimum value - maximum value - wrap past minimum? - wrap past maximum? Real-Number Properties -- - step/granularity Right now, I can define /controls/throttle as a readable, writable, archivable double-precision floating-point value, and all of that information is available to the property picker. With some relatively minor changes, I could also specify that the property's minimum value is -1.0, its maximum value is 1.0, and that it should freeze rather than wrapping at the minimum and maximum -- the property manager could enforce all that. In addition, since the number of properties in the core tree will be very small (probably less than 1,000), we could add optional debugging information. For example, as a compile-time or runtime option, we could track the number of reads, writes, and ties (for weeding out unused properties, typos, etc.), and could even through an exception (as a crude breakpoint) when certain values are assigned to certain properties. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Property Picker
This is what asking about earlier, then we got into the discussion about xml menus (which I'm still thinking about working on, but have been spending what little time I have available right now learning Ac3d enough to build a 3D panel--figuring along the way I'll eventually learn how the panel code works). "Ranges" and "Value lists" would be good. I was thinking of enforcing rules defined in xml in the prop_picker, but it sounds like your saying that should be in the property manager code. Which makes sense. It'd be good to have a error return code(s) from the property manager so that prop_picker (and the other interfaces) could display a message to the user. Best, Jim David Megginson <[EMAIL PROTECTED]> said: > Norman Vine writes: > > > >I encourage everyone who > > >hasn't done so already to try it out. I'd also be interested in > > >hearing what enhancements to the property manager (such as > > >constraints) would be useful for the property picker's future > > >development. > > > > One thing we could use are the dimensions and the x and y size > > of the property picker exposed as properties so that one could > > easily position it where desired. > > > > I can do this by making the dialog 'draggable' but this requires > > a substantial hack to PUI internals and I think the properties > > interface should be good enough for starters. > > Great idea (and Curt's, too), but I was actually asking what I should > do with the SimGear property manager rather than what Jim should do > with the GUI property picker. For example, we could add some kind of > simple schema support, with constraints and enumerated lists of > allowed values, so that the property picker can keep users from > picking bad values. > > Right now, it's possible to tell if a property has a numeric value, so > we could provide arrows for raising or lowering it. That's a (very > small) start. > > > All the best, > > > David > > -- > David Megginson > [EMAIL PROTECTED] > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Picker
Semi-static: click on the . (current directory dot) file entry and it refreshes. Best, Jim "Curtis L. Olson" <[EMAIL PROTECTED]> said: > David Megginson writes: > > Jim Wilson's new property picker is great -- I encourage everyone who > > hasn't done so already to try it out. I'd also be interested in > > hearing what enhancements to the property manager (such as > > constraints) would be useful for the property picker's future > > development. > > One thing that would be cool to add to the property picker would be > live updates ... right now the info that is displayed is static and > probably the state of the variable at the time the window was created. > > Regards, > > Curt. > -- > Curtis Olson Intelligent Vehicles Lab FlightGear Project > Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] > Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Property Picker
Norman Vine <[EMAIL PROTECTED]> said: > > One thing we could use are the dimensions and the x and y size > of the property picker exposed as properties so that one could > easily position it where desired. > That would be easy enough. Almost getting back to the xml gui idea. For the time being maybe a gui.xml should be started that has the dialog dimensions and position, with an eye on eventually doing the whole enchilada? > I can do this by making the dialog 'draggable' but this requires > a substantial hack to PUI internals and I think the properties > interface should be good enough for starters. > Yikes! Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Property Picker
Norman Vine writes: > >I encourage everyone who > >hasn't done so already to try it out. I'd also be interested in > >hearing what enhancements to the property manager (such as > >constraints) would be useful for the property picker's future > >development. > > One thing we could use are the dimensions and the x and y size > of the property picker exposed as properties so that one could > easily position it where desired. > > I can do this by making the dialog 'draggable' but this requires > a substantial hack to PUI internals and I think the properties > interface should be good enough for starters. Great idea (and Curt's, too), but I was actually asking what I should do with the SimGear property manager rather than what Jim should do with the GUI property picker. For example, we could add some kind of simple schema support, with constraints and enumerated lists of allowed values, so that the property picker can keep users from picking bad values. Right now, it's possible to tell if a property has a numeric value, so we could provide arrows for raising or lowering it. That's a (very small) start. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Property Picker
David Megginson writes: > >Jim Wilson's new property picker is great -- Indeed ! >I encourage everyone who >hasn't done so already to try it out. I'd also be interested in >hearing what enhancements to the property manager (such as >constraints) would be useful for the property picker's future >development. One thing we could use are the dimensions and the x and y size of the property picker exposed as properties so that one could easily position it where desired. I can do this by making the dialog 'draggable' but this requires a substantial hack to PUI internals and I think the properties interface should be good enough for starters. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Picker
David Megginson writes: > Jim Wilson's new property picker is great -- I encourage everyone who > hasn't done so already to try it out. I'd also be interested in > hearing what enhancements to the property manager (such as > constraints) would be useful for the property picker's future > development. One thing that would be cool to add to the property picker would be live updates ... right now the info that is displayed is static and probably the state of the variable at the time the window was created. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Property Picker
Jim Wilson's new property picker is great -- I encourage everyone who hasn't done so already to try it out. I'd also be interested in hearing what enhancements to the property manager (such as constraints) would be useful for the property picker's future development. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
