1
0
Fork 0
Commit graph

9 commits

Author SHA1 Message Date
ehofman
0c61e0dae1 Make it optional whether a dialog can be dragged or not. 2005-05-02 12:14:12 +00:00
ehofman
3f6536fee6 Allow for recolloring the dialogs. 2005-04-13 11:39:53 +00:00
ehofman
4b116a1196 Melchior FRANZ:
The dialog handling has been written at a time when only one dialog was
shown at the same time, and dialogs were shallow -- with only children, but
no grand-children. This makes finding a draggable spot on modern, dialogs
with nested objects quite a challenge. The patches fixes this, and other things:

- check full object tree on button press, not only the outmost layer;
  and don't give up just because we are in *something* (which could well be
  something harmless, like a group); only ignore a few, sensible objects
  (we don't want to drag after a click on a button or into an input field)

- don't lose dialogs as easily when dragging too fast (it does still happen
  if one manages to enter an editable field while dragging, but this is
  a plib problem and I don't feel like fixing that now  :-)

- don't "live"-update input fields while they are in edit mode

- remove some "if (foo) delete foo;" redundancy
2005-03-24 13:41:43 +00:00
andy
bc22a50cde Fix the slider to request a non-zero length, and make its width a
little larger.

The text widget can now be meaningfully associated with a property; in
PUI, it's "value" isn't the same thing as its label, but we can hack
things to treat them symmetrically.

Commit an experimental "live" property that can be set on widgets to
cause them to update their values every frame.  This works great for
text widgets, as above.  Note that this synchronization is input-only:
no support is provided (or needed -- the GUI only changes when the
user does something) for writing those properties out every frame.
2004-05-14 17:16:35 +00:00
andy
09d4176e96 GUI windows are now draggable. This missing feature has annoyed me
for a while, it turned out to be pretty easy to implement.  Also, the
property picker is now non-modal, I presume the modality wasn't an
intentional feature.
2004-05-03 00:40:50 +00:00
curt
2119db35c3 This is step "1" of probably "many" in the process of separating out the
scene management code and organizing it within simgear.  My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies.  Then it will be free to move over into the simgear package.

- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
  in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
  related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
  state (all the globals-> stuff, the flightgear property tree, etc.)  SimGear
  code can't depend on it so that data has to be passed as parameters to the
  functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
  effect throughout the FlightGear code.
2003-05-06 23:46:24 +00:00
david
d819c42184 Remove another deprecated command, and fix things up so that dialogs
reload properly on a reinit.
2003-01-21 15:44:21 +00:00
david
4dc28f11f4 Add more documentation comments.
Fix memory leaks (PUI doesn't make copies of lists, so we have to make
our own copies and keep pointers to them).

Adjust for new method names in NewGUI.

Move the GUIInfo struct into the cxx file so that it's not part of the
public interface.
2003-01-20 16:01:54 +00:00
david
6632b2d8c2 Unbundle dialog-box support from the top-level GUI manager, to
simplify maintenance.
2003-01-18 15:16:34 +00:00