Re: [Flightgear-devel] Switching from PUI to osgWidget
On 30 Jul 2012, at 13:31, Thomas Geymayer wrote:
I have now pushed some updates to my branch. It is now possible to
create windows (texture rectangles) with just using the property tree
and place a canvas texture onto it.
Mouse events are passed to the active window (=the window the cursor is
hovering over, or for dragging the window where the drag gesture
started) and can be handled from Nasal or anything else that has access
to the property tree.
I'm going to let Stefan think about the GUI side, and I'll look at 2D panels,
since I've realised from the list below that the overlap is very large!
I'm not sure the focus policy you describe above is always going to work, but
it will certainly be sufficient for now.
Currently I'm copying all values to the property tree. The following
properties are set on the canvas of the active window:
mouse/x
mouse/y
mouse/dx
mouse/dy
mouse/button
mouse/state
mouse/mod
mouse/scroll
mouse/event
I don't know if it would give as any advantages to have some global
mouse states because the values are only valid for one single window
(coordinates are relative to window origin).
Hmm, I was hoping we'd be able to register callbacks on specific widgets (or
panel nodes in my case) - do you have a Nasal layer on top of these properties
to forward semantic events ('left button press', 'scroll up', 'double-click')
to Canvas elements?
- Window Stacking:
New windows always appear on top of older windows. It would be nice
to have the possibility to change stacking order (either reorder
the windows or use z-buffer with different z-values)
The window manager could eg. listen on a special signal property on
each window (eg. /sim/gui/canvas/window[i]/raise) which moves the
according window to the top of the current window stack.
I'd prefer window reordering because it would make checking for a
window at a given position very ease, because we'd just have to
check for the first match in revers stacking order (from topmost to
lowest window).
Have either of you thought about implementing the menubar? Which in PUI is a
series of popup-windows, just wondering if the 'window manager' needs to be
aware of such windows in terms of z-ordering.
- (Canvas Element) Clipping:
Already mentioned. At least rectangular regions are needed.
(eg. group/clip-min[0..1], group/clip-max[0..1])
I need this for the 2D panels, will look at it.
- (Canvas Element) Picking:
Forward mouse events to canvas elements (trigger onhover, onclick,
etc.)
The canvas could listen for creation of the signal properties and
then add the according region to a list of monitored regions. If
the cursor is in one of the regions the property is signaled.
Ah ok - can you explain more how you see this working? I'd imagined passing a
Nasal function as a callback into the element:
element.setHoverCallback( fun = { } )
element.setClickCallback
element.setWheelCallback
and so on...
- Use images inside Canvas:
We need a new element type to also display images and other textures
(eg. also the texture of another canvas) inside a canvas. Not
everything can easily be represented using just vector graphics, so
images will also be needed.
Right, the 2D panels are just textures. I will also add a 'scale 9' (aka CSS
border image) element since my impression is this would be very useful in
styling GUI elements.
- Keyboard input:
I haven't thought too much about it and also haven't done anything,
but we will definitely need access to keyboard events :)
Panels don't need this, so I will ignore it for now :)
- Own ideas:
Come up with a new idea or something that I have already mentioned
somewhere else :)
One thing I want to fix for 2D panels, the GUI and 3D picking is cursor
feedback. So if a 3D model or 2D 'knob' is clickable, we can show a hand-cursor
and a tooltip on hover. This would be a *huge* usability win for people
learning new cockpits, besides the GUI. Unfortunately OSG cursor support is
somewhat limited.
The current window manager registers itself to the main viewer and
subscribes on osgGA events, so the canvas has no dependencies on the old
system.
Fantastic
What do you think about the current way of handling mouse events? It's
also just passing x/y and some more values to the property tree, but we
need to forward the values somehow.
Also I had to create a new event class (which uses most of the osgGA
types) because the coordinates of the mouse where passed in the range
[-1,1] which would make handling a bit more complicated...
Personally I'd like an event class exposed to Nasal (I can do that part, lots
of experience with it now!), which is available in the callback functions I
suggested above: so in a hover / wheel / click callback, one has an 'event'
object with:
event.button (button that triggered the
Re: [Flightgear-devel] Switching from PUI to osgWidget
Am 2012-07-31 10:00, schrieb James Turner:
Currently I'm copying all values to the property tree. The following
properties are set on the canvas of the active window:
mouse/x
mouse/y
mouse/dx
mouse/dy
mouse/button
mouse/state
mouse/mod
mouse/scroll
mouse/event
I don't know if it would give as any advantages to have some global
mouse states because the values are only valid for one single window
(coordinates are relative to window origin).
Hmm, I was hoping we'd be able to register callbacks on specific widgets (or
panel nodes in my case) - do you have a Nasal layer on top of these
properties to forward semantic events ('left button press', 'scroll up',
'double-click') to Canvas elements?
mouse/event contains the type of event (its a
osgGA::GUIEventAdapter::EventType) and is always updated last, so it is
enough to just register a callback on mouse/event and read all the other
properties.
The advantage of just using properties is that you can easily create
mouse events from different sources, even from Nasal (eg. to control the
cursor inside a MFD also with keys or the joystick one would just need
to write to the according properties and to the canvas it looks just
like any other mouse event).
- Window Stacking:
New windows always appear on top of older windows. It would be nice
to have the possibility to change stacking order (either reorder
the windows or use z-buffer with different z-values)
The window manager could eg. listen on a special signal property on
each window (eg. /sim/gui/canvas/window[i]/raise) which moves the
according window to the top of the current window stack.
I'd prefer window reordering because it would make checking for a
window at a given position very ease, because we'd just have to
check for the first match in revers stacking order (from topmost to
lowest window).
Have either of you thought about implementing the menubar? Which in PUI is a
series of popup-windows, just wondering if the 'window manager' needs to be
aware of such windows in terms of z-ordering.
- (Canvas Element) Picking:
Forward mouse events to canvas elements (trigger onhover, onclick,
etc.)
The canvas could listen for creation of the signal properties and
then add the according region to a list of monitored regions. If
the cursor is in one of the regions the property is signaled.
Ah ok - can you explain more how you see this working? I'd imagined passing
a Nasal function as a callback into the element:
element.setHoverCallback( fun = { } )
element.setClickCallback
element.setWheelCallback
and so on...
I was thinking exactly the same. the setXxxCallback functions would just
add a listener to mouse/event, and upon change read all values into a
hash and call the registered function.
- Use images inside Canvas:
We need a new element type to also display images and other textures
(eg. also the texture of another canvas) inside a canvas. Not
everything can easily be represented using just vector graphics, so
images will also be needed.
Right, the 2D panels are just textures. I will also add a 'scale 9' (aka CSS
border image) element since my impression is this would be very useful in
styling GUI elements.
Sounds useful. Maybe we can do also an element which supports this for
vector images (eg. for buttons, inputboxes, etc.)
One thing I want to fix for 2D panels, the GUI and 3D picking is cursor
feedback. So if a 3D model or 2D 'knob' is clickable, we can show a
hand-cursor and a tooltip on hover. This would be a *huge* usability win for
people learning new cockpits, besides the GUI. Unfortunately OSG cursor
support is somewhat limited.
With osgGA handling mouse over events is now also possible. So for
canvas elements adding tooltips is very easy. For 3D picking we would
need to forward the mouse intersection to Nasal. This will also be
needed for interacting with canvases placed on 3D surfaces.
Personally I'd like an event class exposed to Nasal (I can do that part, lots
of experience with it now!), which is available in the callback functions I
suggested above: so in a hover / wheel / click callback, one has an 'event'
object with:
event.button (button that triggered the event)
event.type (press / release / click / double-click)
event.time (maybe...)
event.buttons (state of all the mouse buttons)
event.modifiers
event.x, event.y
event.globalX, event.globalY? (do we need these?)
And this can potentially have some helper functions to transform X/Y
coordinates or even find the lat/lon of the scene location...
Looks like a good idea (relative changes would also be useful eg. for
dragging). The question is only if we need to expose this class from C++
or if it is enough to build it in Nasal.
Tom
--
Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org
Re: [Flightgear-devel] Switching from PUI to osgWidget
Am 2012-07-31 10:00, schrieb James Turner: Have either of you thought about implementing the menubar? Which in PUI is a series of popup-windows, just wondering if the 'window manager' needs to be aware of such windows in terms of z-ordering. If you open a window it will be placed on top of all other windows, if you exit a menu with the mouse it normally closes, so it should work. Maybe we should create different categories/priorities (just a numeric value) of windows where one window can only raise to the top inside a category. Am 2012-07-31 15:30, schrieb Thomas Geymayer: Personally I'd like an event class exposed to Nasal (I can do that part, lots of experience with it now!), which is available in the callback functions I suggested above: so in a hover / wheel / click callback, one has an 'event' object with: event.button (button that triggered the event) event.type (press / release / click / double-click) event.time (maybe...) event.buttons (state of all the mouse buttons) event.modifiers event.x, event.y event.globalX, event.globalY? (do we need these?) And this can potentially have some helper functions to transform X/Y coordinates or even find the lat/lon of the scene location... Looks like a good idea (relative changes would also be useful eg. for dragging). The question is only if we need to expose this class from C++ or if it is enough to build it in Nasal. The more I think about it the less I'm convinced about a Nasal-only event class. There can occur many problems with (accidentally) setting the mouse values in the wrong order, or how to get the mouse values inside every affected element without copying to much properties around and also thread synchronisation (if it is used) will get complicated. How do you want to register callbacks if a custom class should be passed as argument? Is it possible to set the value of a property node to a custom class? Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 31 Jul 2012, at 15:50, Thomas Geymayer wrote: Maybe we should create different categories/priorities (just a numeric value) of windows where one window can only raise to the top inside a category. Right, that's a pretty standard system in window ordering. The more I think about it the less I'm convinced about a Nasal-only event class. There can occur many problems with (accidentally) setting the mouse values in the wrong order, or how to get the mouse values inside every affected element without copying to much properties around and also thread synchronisation (if it is used) will get complicated. Right. In general since we have no way to change several properties atomically, relying on very complex property listeners often comes down to knowing which order the C++ code makes changes - the Autopilot and Environment systems have the issue to some degree I think. How do you want to register callbacks if a custom class should be passed as argument? Is it possible to set the value of a property node to a custom class? I was assuming I'd create a Nasal ghost for Canvas::Element, and another for osgGA::Event, or a Canvas::Event if we need an explicit class. Then we need some global Nasal C functions to map from a Canvas property node to the Nasal ghost (i.e finding the underlying C++ canvas::Element). All of the above is only a few lines of code and I've been doing it for FGPositioned recently - it's pretty easy. Once that's done we define the 'addXYZCVallback' methods in C++, and have them capture an naFunctionRef for the callbacks - again I've already done this and it works nicely. When the C++ element receives an event it can check its registered callback list, wrap the event in a ghost and run whichever callbacks apply. If you want me to prototype some code for this, I am happy to do so! James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
Am 2012-07-31 18:49, schrieb James Turner:
I was assuming I'd create a Nasal ghost for Canvas::Element, and another for
osgGA::Event, or a Canvas::Event if we need an explicit class. Then we need
some global Nasal C functions to map from a Canvas property node to the Nasal
ghost (i.e finding the underlying C++ canvas::Element).
What shall the ghost for the canvas::Element do? I think it would be
enough to have a set(event)handler(path, event_type/mask, cb) and
remove(event)handler function which work similar to the property
listener functions:
sethandler('/canvas/texture[2]/group[3]', 'click', func(event) {
print('click at ' ~ event.x ~ '|' ~ event.y);
});
or
sethandler('/canvas/texture[2]/group[3]', 'mouse', func(event) {
print('mouse event ' ~ event.type ~ ' at ' ~ event.x ~ '|' ~ event.y);
});
I'm not really sure if we need to differentiate between different mouse
events already at C++ level or if just passing every mouse event is
sufficient.
Finding the acording canvas::Element is really easy as the first part of
the path can directly be compared to the canvas base path (see
canvas_mgr.cxx and property_based_mgr.cxx) and access the required
canvas by it's index (only possible with canvases) and afterwards
recursively checking for element name and index.
Can Nasal ghosts also be used with an inheritance hierarchy? Eg. having
an event base class and mouse, keybord, etc. events. Events may have
something in common, but eg. for mouse and keyboard most of the data
will be different.
All of the above is only a few lines of code and I've been doing it for
FGPositioned recently - it's pretty easy. Once that's done we define the
'addXYZCVallback' methods in C++, and have them capture an naFunctionRef for
the callbacks - again I've already done this and it works nicely. When the
C++ element receives an event it can check its registered callback list, wrap
the event in a ghost and run whichever callbacks apply.
If you want me to prototype some code for this, I am happy to do so!
Would be great :)
Tom
--
Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org
Student of Computer Science @ Graz University of Technology
--- Austria
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
Sorry for responding this late, I've been on a horrible internet connection. 2012/7/26 Thomas Geymayer tom...@gmail.com: 2012/7/26 James Turner zakal...@mac.com: Okay, I wasn't clear from the Wiki page what the final idea was. As you say, so long as we're going through show-dialog it should be fine. My feeling is we still want a C++ hook around creating individual widgets, so we have the option the create custom widgets in C++, but it's not a difficult thing to change internally. You can always create widgets from C++ by adding canvas elements through the property tree, but I think a fully scripted GUI is the most flexible and powerfull approach. Do you have any usecase where you wan't to create a widget in C++? Hmm, I wonder if having a C++ base class for widgets in the canvas will simplify picking and mouse-over. To avoid such details to the basic canvas item. I'm currently thinking of adding a property to each element which allows enabling picking for this element. If the element is a group it receives picking events from all children otherwise only its own. We should also keep in mind that the Canvas won't be used only for the GUI but also eg. for MFDs which may have a touch interface where not necessarily widgets are used... Sounds like a fine plan to me, I was just wondering how you're planning to expose the events: - Copy values into properties - Expose the event class to nasal I'd vote for the first option... This would result in quite a lot of properties though, for all the possible states. I've been thinking about this, would it make sense to have a default mouse event handler, which exposes all global mouse state to some properties in (for example) /sim/mice/mouse[0]? That way, only a few mouse event values would need to be set as canvas properties. Regards, Tom On a different note: window management. I've seen that in Tom's private branch, he has started on a window class (albeit, it is just a skeleton currently). I think we indeed want a c++ window manager, which is basically just a dumb visible thing that renders a texture. That way, the canvas code only has to render stuff to a texture and expose that, which is a nice abstraction point. So, given all that, where can I jump in to help? I must admit that I'm primarily interested in C++ development, rather than writing nasal ;( Thanks, Stefan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 30 Jul 2012, at 11:39, stefan riemens wrote: On a different note: window management. I've seen that in Tom's private branch, he has started on a window class (albeit, it is just a skeleton currently). I think we indeed want a c++ window manager, which is basically just a dumb visible thing that renders a texture. That way, the canvas code only has to render stuff to a texture and expose that, which is a nice abstraction point. Agreed - I was planning to dive into adapting the window on Tom's branch, with a C++ host for a canvas. Note that the canvas currently assumes render-to-texture, but for the GUI I'm not sure that's actually desirable - simply a separate camera per GUI window may be sufficient. Since the camera already arranges everything beneath the RTT camera this should be fairly minor change, if it's desirable. (Saves some memory, makes re-sizing GUI windows a little easier, might make clipping or other state management less efficient in the main GUI camera ... but probably not) So, given all that, where can I jump in to help? I must admit that I'm primarily interested in C++ development, rather than writing nasal ;( Same here :) I need to spend some time on Mac release engineering, so I'm happy for you to work with Tom on 'window manager' - I'd suggest starting with the current GUICamera code, and especially the osgWidget base class. In particular my goal is to be able to kill off fg_os.hxx in the near future, i.e to have all events being passed into the canvas as osgGA types, not the old GLUT interface of raw x/y floats. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
I have now pushed some updates to my branch. It is now possible to create windows (texture rectangles) with just using the property tree and place a canvas texture onto it. Mouse events are passed to the active window (=the window the cursor is hovering over, or for dragging the window where the drag gesture started) and can be handled from Nasal or anything else that has access to the property tree. Am 2012-07-30 12:39, schrieb stefan riemens: Sounds like a fine plan to me, I was just wondering how you're planning to expose the events: - Copy values into properties - Expose the event class to nasal I'd vote for the first option... This would result in quite a lot of properties though, for all the possible states. I've been thinking about this, would it make sense to have a default mouse event handler, which exposes all global mouse state to some properties in (for example) /sim/mice/mouse[0]? That way, only a few mouse event values would need to be set as canvas properties. Currently I'm copying all values to the property tree. The following properties are set on the canvas of the active window: mouse/x mouse/y mouse/dx mouse/dy mouse/button mouse/state mouse/mod mouse/scroll mouse/event I don't know if it would give as any advantages to have some global mouse states because the values are only valid for one single window (coordinates are relative to window origin). On a different note: window management. I've seen that in Tom's private branch, he has started on a window class (albeit, it is just a skeleton currently). I think we indeed want a c++ window manager, which is basically just a dumb visible thing that renders a texture. That way, the canvas code only has to render stuff to a texture and expose that, which is a nice abstraction point. The Window manager just creates plain rectangles and forwards mouse events. It also allows to modify window position and window size through the property tree. So, given all that, where can I jump in to help? I must admit that I'm primarily interested in C++ development, rather than writing nasal ;( Currently missing: - Window Stacking: New windows always appear on top of older windows. It would be nice to have the possibility to change stacking order (either reorder the windows or use z-buffer with different z-values) The window manager could eg. listen on a special signal property on each window (eg. /sim/gui/canvas/window[i]/raise) which moves the according window to the top of the current window stack. I'd prefer window reordering because it would make checking for a window at a given position very ease, because we'd just have to check for the first match in revers stacking order (from topmost to lowest window). - (Canvas Element) Clipping: Already mentioned. At least rectangular regions are needed. (eg. group/clip-min[0..1], group/clip-max[0..1]) - (Canvas Element) Picking: Forward mouse events to canvas elements (trigger onhover, onclick, etc.) The canvas could listen for creation of the signal properties and then add the according region to a list of monitored regions. If the cursor is in one of the regions the property is signaled. - Use images inside Canvas: We need a new element type to also display images and other textures (eg. also the texture of another canvas) inside a canvas. Not everything can easily be represented using just vector graphics, so images will also be needed. - Keyboard input: I haven't thought too much about it and also haven't done anything, but we will definitely need access to keyboard events :) - Support multiple views/windows: Currently the GUI can only be placed inside one view/window (see Docs/README.multiscreen) but it would be nice to be able to move windows between views. - Own ideas: Come up with a new idea or something that I have already mentioned somewhere else :) Am 2012-07-30 12:48, schrieb James Turner: Note that the canvas currently assumes render-to-texture, but for the GUI I'm not sure that's actually desirable - simply a separate camera per GUI window may be sufficient. Since the camera already arranges everything beneath the RTT camera this should be fairly minor change, if it's desirable. It should probably event be enough to use just one single camera for all windows. The big advantage we gain with render-to-texture is that by using a larger texture we can get better anti-aliasing. For rendering paths the stencil buffer is used so we only have pixel resolution which can be seen at non horizontal or vertical lines or curves. We could also use lazy rendering to only update the GUI texture if something changes. Normally dialogs should be pretty much static... I need to spend some time on Mac release engineering, so I'm happy for you to work with Tom on 'window manager' - I'd suggest starting with the current GUICamera code, and especially the
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 25 Jul 2012, at 17:27, Thomas Geymayer tom...@gmail.com wrote: We could for example just add some more parseXXX functions (like parsesvg) which parse a dialog/hud/whathever file and create a canvas from it. So we would just have to modify eg. the show-dialog command to create a canvas and call the parser. We need to keep the existing way of specifying GUI files via XML - it's a nice, declarative way of building the dialogs. Switching to an imperative system would be a step backwards. I do like the idea of a gui/widget/widgetname.nas structure so we can easily create a factory function and hack / add widgets. Have you thought where the layout logic will work in this scheme? Right now it's all in C++, and a layout manager might make sense for the canvas in general (think about laying out text or elements on an MFD or EICAS), possibly even in C++, but again you maybe already have a solution. - Clipping: For different reasons we will need to be able to clip some elements to certain regions. It should work with specifying either a clipping rectangle or by using a path. OpenVG seems to have support for it, although I haven't looked into it too deep. We also need to ensure that it also works with text. Right, clipping is needed for 2D panel support too. We need to consider this one carefully since it's needed for various GUI widgets as well, and there's a few different implementation strategies. Stencil planes are one option, I'm unsure about the performance of 'real' GL clipping on modern hardware. - Geographic Mapping: It's very experimental, missing different projection modes (eg. vertical projection) and especially the Nasal API feels very hackish. I have some knowledge of this from doing the MapWidget and NavDisplay, happy to take a look. - Picking: For mouse handling some kind of picking would be nice. As already mentioned, at least bounding box intersections will be needed. Picking is surely needed already for building widgets, unless you mean something more detailed? Like obtaining the X/Y position inside a widget? In general I think the event handling will evolve once PUI is not involved at all (see next point) - Improve PUI to allow eg. receiving mouse over events. I had a look at the wiki and the major thing is we need to switch away from the CanvasWidget approach you're using now - I.e we need a C++ dialog implementation that wraps a canvas and has /no/ PUI dependency at all. (As you already started discussing) Actually that code is going to look quite similar to the osgWidget base class :) That will get rid of the legacy (GLUT based) mouse event API that PUI uses, and mean we can support any mouse event supported by osgGA and osgViewer - mouse wheel, buttons and mouse-over. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 26 Jul 2012, at 11:09, Thomas Geymayer tom...@gmail.com wrote: I didn't meant to replace the existing way, but instead only changing the implementation to use the Canvas system in Nasal space. Just mapping the existing dialog-show command to a Nasal function which creates a window and parses a GUI xml file. This wouldn't change anything on how dialogs are specified and shown. Okay, I wasn't clear from the Wiki page what the final idea was. As you say, so long as we're going through show-dialog it should be fine. My feeling is we still want a C++ hook around creating individual widgets, so we have the option the create custom widgets in C++, but it's not a difficult thing to change internally. I think the best place would be doing it with Nasal, as there is already all the information needed available. C++ doesn't know anything about widgets... Hmm, I wonder if having a C++ base class for widgets in the canvas will simplify picking and mouse-over. To avoid such details to the basic canvas item. We will need to support clipping using the stencil buffer in any case, as it allows arbitrary shapes to be used. We need to check if OpenGL clipping planes are faster - if it's the case we should use them for rectangular clipping regions. Right, in practice rectangular clipping is what's need 90% of the time so I'd rather optimise for that case, whether that means stencils, GL scissors clip or clip planes. I have some knowledge of this from doing the MapWidget and NavDisplay, happy to take a look. You will probably find some parts you already know :) Basically I wanted to loosely follow the ideas from ARINC 661. Right the NavDisplay is really an ARINC 661 display - it takes a list of symbols, a list of items and combines then using a projection to create a final display. The only additional code is to deal with special things that can't easily be described by a simply symbol, especially the flight-plan/route path. I had a look at the wiki and the major thing is we need to switch away from the CanvasWidget approach you're using now - I.e we need a C++ dialog implementation that wraps a canvas and has /no/ PUI dependency at all. (As you already started discussing) Actually that code is going to look quite similar to the osgWidget base class :) Maybe we can use some ideas from it :) Basically we only need to pass mouse/keyboard events and handle dragging/resizing and input focus/stacking order of multiple dialogs. This is certainly where things need to start, then. I'd hope dragging and resizing can be mostly handled by the Nasal layer, the C++ only needs to keep the window and canvas texture in sync when a resize happens. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 26 Jul 2012, at 11:28, James Turner zakal...@mac.com wrote: Maybe we can use some ideas from it :) Basically we only need to pass mouse/keyboard events and handle dragging/resizing and input focus/stacking order of multiple dialogs. This is certainly where things need to start, then. I'd hope dragging and resizing can be mostly handled by the Nasal layer, the C++ only needs to keep the window and canvas texture in sync when a resize happens. Just been reviewing the CanvasWidget (and related code) on your branch, and there's definitely scope to fix some long-standing API issues. You should consider the way osgWidget gets events from osgGA as the 'correct' way. We want to be passing osgGA events around, not raw x,y values, and pretty much all of fg_os.hxx dates from support GLUT and OSG in a single codebase - which forces us to use a very crude API. If we use the real OSG events we get lots of information about button index, event type and modifier state all encapsulated in a clean way. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
2012/7/26 James Turner zakal...@mac.com: Okay, I wasn't clear from the Wiki page what the final idea was. As you say, so long as we're going through show-dialog it should be fine. My feeling is we still want a C++ hook around creating individual widgets, so we have the option the create custom widgets in C++, but it's not a difficult thing to change internally. You can always create widgets from C++ by adding canvas elements through the property tree, but I think a fully scripted GUI is the most flexible and powerfull approach. Do you have any usecase where you wan't to create a widget in C++? Hmm, I wonder if having a C++ base class for widgets in the canvas will simplify picking and mouse-over. To avoid such details to the basic canvas item. I'm currently thinking of adding a property to each element which allows enabling picking for this element. If the element is a group it receives picking events from all children otherwise only its own. We should also keep in mind that the Canvas won't be used only for the GUI but also eg. for MFDs which may have a touch interface where not necessarily widgets are used... Regards, Tom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
Just to illustrate what I mean actually ... Current situation: http://maptest.fgx.ch/screens/current-screen.png New GUI with separated menus/dialogs, viewer in a separate window: http://maptest.fgx.ch/screens/one-screen.png Or new GUI with two screens setting, where one screen is the view only: http://maptest.fgx.ch/screens/two-screen.png Regards Yves Am 25.07.12 01:42, schrieb ys: Hi Thomas, Hi James This looks promising in a technical/coding perspective of having this and that common GUI feature available also for flightgear. But for me personally one of the big problems of the FlightGear GUI is that it is inside the only and one main window. There is no possibility to have a separate window to not cover the main content, the scenery and the cockpit? This would make the GUI much more practical. I would really like to run flightgear with one window view and other windows for the program (options). This will improve the usability of all the menus, dialogs etc. a lot in my opinion. Cheers, Yves Am 25.07.2012 um 00:11 schrieb Thomas Geymayer tom...@gmail.com: Am 2012-07-24 19:35, schrieb James Turner: Thomas, one issue I can guess at (though PLIB is also really bad at it, and osgWidget is not much better!) - text selection. Do you think you'd be able to handle a blinking insertion point and a standard draggable text selection area in this approach? Obviously it might need some additional C++ helpers but that's okay since text-editing is a pretty specialised behaviour. Yes :) http://youtu.be/CIS8UyuJLgM I have just added some property change listeners to get the position of the next character at a given position. The highlighting happens only from Nasal. What is currently missing is the possibility to also change the color of the selected text and to actually get the selected text, but this shouldn't be too hard to implement. One goal of mine for the GUI is to get platform native copy-and-paste working, BTW ;) This has already been on my wish/todo list :P Obviously Thomas knows the Canvas code since he created it [...] Currently documentation is not too detailed, but looking at the different demos and maybe also the Nasal API and source code should help. If not, don't hesitate to ask :) Regards, Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 25 Jul 2012, at 00:42, ys wrote: This looks promising in a technical/coding perspective of having this and that common GUI feature available also for flightgear. But for me personally one of the big problems of the FlightGear GUI is that it is inside the only and one main window. There is no possibility to have a separate window to not cover the main content, the scenery and the cockpit? This would make the GUI much more practical. I would really like to run flightgear with one window view and other windows for the program (options). This will improve the usability of all the menus, dialogs etc. a lot in my opinion. This is an orthogonal issue - it can be solved by using multiple osg windows to contain whatever GUI solution we go with - canvas, osgWidget or PUI-port. Or to put it another way - the actual hard part is running the widgets in the main OpenGL window - which *is* a requirement for full-screen apps and multi-monitor setups. (Some people have claimed otherwise, but I believe we need the option of 'in-window' UI for many cases). So, this is a desirable feature, but doesn't dictate the choice of GUI technology. And can be done as a separate step from replacing PLIB. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 24 Jul 2012, at 23:11, Thomas Geymayer wrote: Do you think you'd be able to handle a blinking insertion point and a standard draggable text selection area in this approach? Obviously it might need some additional C++ helpers but that's okay since text-editing is a pretty specialised behaviour. Yes :) http://youtu.be/CIS8UyuJLgM I have just added some property change listeners to get the position of the next character at a given position. The highlighting happens only from Nasal. What is currently missing is the possibility to also change the color of the selected text and to actually get the selected text, but this shouldn't be too hard to implement. Videos convince me very easily! I think we need a bit of discussion about the architecture for this approach, especially to define a widget abstraction (maybe C++, maybe nasal) so dialog authors can't break widget functionality unintentionally, but aside from that I can't see many potential problems; Nasal can already process the GUI files since they're property lists. (I'm imagining a C++ factory function that takes a property node and builds a widget - this would be exposed via a Nasal API - and even if it called back to a Nasal definition for each widget type, would still allow us to build custom widgets using the C++ canvas API if required) The map-widget, route-manager waypoint list and airport-list widgets would need some porting, but that's all pretty valuable anyway - especially for the map-widget. As you say once it's done it would be re-usable for in-cockpit displays which is all good. Since I created the Map-widget I've added a whole bunch of Nasal APIs to query the navDB so that part of the map-widget is doable without C++ now too. Oh, and we need the option to keep the native menu-bar on Mac of course ;) James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
HB-GRAL wrote: New GUI with separated menus/dialogs, viewer in a separate window: http://maptest.fgx.ch/screens/one-screen.png Someone please buy me a display *that* wide so I can still afford using space lateral to the viewer for the menu ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
Hey Martin, you can get mine and I take (all) yours when FlightGear keeps that all in one window approach for the next ten years. But maybe the width is not that exact, I didn't measure my screen size for this 5 sec. scribble, sorry for that. Just wanted to keep file size small and clipped height for all the ML readers with 640 x 480 and modem connection. Cheers, Yves Am 25.07.2012 um 12:17 schrieb Martin Spott martin.sp...@mgras.net: HB-GRAL wrote: New GUI with separated menus/dialogs, viewer in a separate window: http://maptest.fgx.ch/screens/one-screen.png Someone please buy me a display *that* wide so I can still afford using space lateral to the viewer for the menu ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
Hi Thomas, This is very convincing! Congratulations, that looks really neat. Having seen this, I think we'd better go with the canvas approach. It would require quite a lot of code to get osgWidget to produce that... Stefan 2012/7/25 Thomas Geymayer tom...@gmail.com: Am 2012-07-24 19:35, schrieb James Turner: Thomas, one issue I can guess at (though PLIB is also really bad at it, and osgWidget is not much better!) - text selection. Do you think you'd be able to handle a blinking insertion point and a standard draggable text selection area in this approach? Obviously it might need some additional C++ helpers but that's okay since text-editing is a pretty specialised behaviour. Yes :) http://youtu.be/CIS8UyuJLgM I have just added some property change listeners to get the position of the next character at a given position. The highlighting happens only from Nasal. What is currently missing is the possibility to also change the color of the selected text and to actually get the selected text, but this shouldn't be too hard to implement. One goal of mine for the GUI is to get platform native copy-and-paste working, BTW ;) This has already been on my wish/todo list :P Obviously Thomas knows the Canvas code since he created it [...] Currently documentation is not too detailed, but looking at the different demos and maybe also the Nasal API and source code should help. If not, don't hesitate to ask :) Regards, Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 25 Jul 2012, at 11:42, stefan riemens wrote: This is very convincing! Congratulations, that looks really neat. Having seen this, I think we'd better go with the canvas approach. It would require quite a lot of code to get osgWidget to produce that... Indeed! Thomas, can we have a discussion about a sensible roadmap for this, and what parts myself or Stefan could help with? I'm aware you've made some progress on this locally (based on some wiki pages), but apparently not discussing it here - could you summarise how you see this working so Stefan and I can review it? In particular I'm interested to see what aspects of XML - building canvas elements are common between 2D panels, the GUI dialogs and HUD code. I'm also anxious that the 'front-end' XML and Nasal stays clean, i.e we have sufficient abstraction when creating dialogs and UI that we can vary the widget implementations without breaking existing dialogs. (This is effectively theming / styling) James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 25 Jul 2012, at 11:42, stefan riemens wrote: This is very convincing! Congratulations, that looks really neat. Having seen this, I think we'd better go with the canvas approach. It would require quite a lot of code to get osgWidget to produce that... Okay, I think Stefan and I are convinced :) Thomas, I have the impression you've been working on this stuff for a while, could you please summarise how you see it developing so Stefan and I can see where we might help. I'm pretty concerned to keep the Nasal code sufficiently structured that we vary the widget implementation without updating the dialogs. In particular, I'm concerned that we don't end up with inline Nasal dialog XML which depends on the widget implementation internals, simply because that's convenient in Nasal. (for example, the current dialog XML files don't know anything about 'mouse-handling', they work exclusively in bindings, and that's a good separation of UI events from semantic behaviours) I'd also like to see / understand how we manage XML / property-list file processing in a nice way, to support the various formats we want to create canvas elements from - GUI dialogs, 2D panels and HUDs. So, yes, if you could explain your plan here, and where people could help, that would be useful. Regards, James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
James Turner wrote: Or to put it another way - the actual hard part is running the widgets in the main OpenGL window - which *is* a requirement for full-screen apps and multi-monitor setups. (Some people have claimed otherwise, but I believe we need the option of 'in-window' UI for many cases). I object - at last I can't envision a case where running the UI inside a separate window in front of a (full-screen) viewer is inferior to an in-window UI. All supported window systems provide the required information on screen/window-geometry or -placement to position a separate UI-window wherever you like. For the die-hards just think of a menu bar positioned in front of the upper left corner of the viewer-screen or -window having just very thin borders. From my perspective that's a pretty appealing approach because running the UI outside the viewer and probably/hopefully outside the main program could lead to a consistent management-/ control-interface in FlightGear. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
ys wrote: Am 25.07.2012 um 12:17 schrieb Martin Spott martin.sp...@mgras.net: HB-GRAL wrote: New GUI with separated menus/dialogs, viewer in a separate window: http://maptest.fgx.ch/screens/one-screen.png Someone please buy me a display *that* wide so I can still afford using space lateral to the viewer for the menu ;-) Hey Martin, you can get mine and I take (all) yours when FlightGear keeps that all in one window approach for the next ten years. The above has been a joke. I did *not* express my support for the current all in one window approach, but there are more options than just the two all in one window and lateral to the viewer :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On Wed, Jul 25, 2012 at 1:43 PM, Martin Spott martin.sp...@mgras.net wrote: James Turner wrote: Or to put it another way - the actual hard part is running the widgets in the main OpenGL window - which *is* a requirement for full-screen apps and multi-monitor setups. (Some people have claimed otherwise, but I believe we need the option of 'in-window' UI for many cases). I object - at last I can't envision a case where running the UI inside a separate window in front of a (full-screen) viewer is inferior to an in-window UI. All supported window systems provide the required information on screen/window-geometry or -placement to position a separate UI-window wherever you like. One avoids OpenGL rendering to more than one window if possible because graphics context switches are expensive. I have no idea if this would affect normal FG usage. Portions of the OpenGL window buffer that are obscured by other windows are not guaranteed to be rendered correctly or at all, and in most implementations are not. This is less of an issue in newer OpenGL versions that support frame buffer objects and can do multi-pass rendering in an off screen buffer. For the die-hards just think of a menu bar positioned in front of the upper left corner of the viewer-screen or -window having just very thin borders. From my perspective that's a pretty appealing approach because running the UI outside the viewer and probably/hopefully outside the main program could lead to a consistent management-/ control-interface in FlightGear. A system menu bar is a slightly different. By definition it is not obscuring the main rendering window, and it is not updated unless the user interacts with it. It might be possible to simulate the same thing in FG with a menu bar in a separate window, but it would be very complicated to manage updating those windows differently from the main simulation window. I agree that separate user interface windows would be nice in several interesting use cases, but I don't think the default single-screen case is one of them. Tim Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 25 Jul 2012, at 12:38, James Turner wrote: Okay, I think Stefan and I are convinced :) Apologies for send 'the same email' twice, I'm on an erraitc connection and thought the first one had managed to not send, but also be deleted from my outbox, drafts /and/ sent mail folder. So I re-typed it, and then both turned up on the list! James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
2012/7/25 James Turner zakal...@mac.com: Thomas, I have the impression you've been working on this stuff for a while, could you please summarise how you see it developing so Stefan and I can see where we might help. I think it now slowly reaches a state where everything starts to stabilize. The API is really easy to use and most things should be already possible without any modification to the C++ code. Now we need to extend the API, create some helper functions/classes and have a look what is possible and what is still missing. I'm pretty concerned to keep the Nasal code sufficiently structured that we vary the widget implementation without updating the dialogs. In particular, I'm concerned that we don't end up with inline Nasal dialog XML which depends on the widget implementation internals, simply because that's convenient in Nasal. (for example, the current dialog XML files don't know anything about 'mouse-handling', they work exclusively in bindings, and that's a good separation of UI events from semantic behaviours) I have based the implementation on many ideas from different existing technologies and projects. The most important are the Javascript DOM API and some Javascript/SVG/drawing APIs (eg. jQuery SVG [1]). For mouse handling I like the idea of having event handlers (eg. click, drag, hover, etc.). So instead of just one property holding the events of the whole dialog/canvas I want to forward the event to the according element by using picking or maybe for a first step just bounding box checking with the current mouse position. It would still just set the three properties like before (button, x, y) but we could add an helper function which adds a listener to the button property and calls a function with all three parameters if the event was triggered. (I always want to keep the basic idea of only communicating via the property tree). I'd also like to see / understand how we manage XML / property-list file processing in a nice way, to support the various formats we want to create canvas elements from - GUI dialogs, 2D panels and HUDs. We could for example just add some more parseXXX functions (like parsesvg) which parse a dialog/hud/whathever file and create a canvas from it. So we would just have to modify eg. the show-dialog command to create a canvas and call the parser. So, yes, if you could explain your plan here, and where people could help, that would be useful. Missing things: - Documentation: Read, ask questions, extend. I haven't done too much documentation (apart from inline documentation) just due to the reason that the API is not completely stable yet. You could also try different use-cases and maybe find some examples where the API lacks some features. - Clipping: For different reasons we will need to be able to clip some elements to certain regions. It should work with specifying either a clipping rectangle or by using a path. OpenVG seems to have support for it, although I haven't looked into it too deep. We also need to ensure that it also works with text. - Geographic Mapping: It's very experimental, missing different projection modes (eg. vertical projection) and especially the Nasal API feels very hackish. - Picking: For mouse handling some kind of picking would be nice. As already mentioned, at least bounding box intersections will be needed. - Animations: I don't know if we should do animations just be using interpolator and settimer from Nasal or if we should implement some time-based animations directly in C++. At least we need some helper functions (eg. for blinking elements - cursor, fading, ...) - Improve PUI to allow eg. receiving mouse over events. - Improve the Nasal API: Add some helper functions for animating different glass cockpit displays (I have already some basic code, but it needs some generalization). - Implement some widgets in Nasal. - Check what is missing to implement the different hardcoded instruments. - Allow placing images inside the canvas. - Maybe support displaying shapefiles. - I also want to unify the canvas creation a bit, such that canvases can be moved seamless between the different placements (gui, model, hud, etc.). The normal model placement is great but the gui widget placement needs to be able to also use an already existing canvas. - Support copypaste: I'm working on the selection part, but have no clue yet on how to access the system clipboard. - Find more work I've currently forgotten about :) Please also have a look at the wiki [2]. There is already plenty of brainstorming outcome and also information about some current features. Regards, Tom [1] http://keith-wood.name/svg.html [2] http://wiki.flightgear.org/Canvas -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint
Re: [Flightgear-devel] Switching from PUI to osgWidget
Tim Moore wrote: On Wed, Jul 25, 2012 at 1:43 PM, Martin Spott martin.sp...@mgras.net wrote: James Turner wrote: Or to put it another way - the actual hard part is running the widgets in the main OpenGL window - which *is* a requirement for full-screen apps and multi-monitor setups. (Some people have claimed otherwise, but I believe we need the option of 'in-window' UI for many cases). I object - at last I can't envision a case where running the UI inside a separate window in front of a (full-screen) viewer is inferior to an in-window UI. All supported window systems provide the required information on screen/window-geometry or -placement to position a separate UI-window wherever you like. One avoids OpenGL rendering to more than one window if possible because graphics context switches are expensive. I can't resist the feeling that running the current PUI menu inside the main viewer isn't less expensive. From an empirical point of view I'd say that opening an xterm in front of a full-screen FG viewer has about the same impact as enabling the menubar. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
I have now added some more thoughts about the GUI implementation and support of the current xml files to the wiki: http://wiki.flightgear.org/Canvas_Widgets#Fully_Canvas_based_implementation_.28planned.29 Regards, Tom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
Hi all, Thanks for the feedback, and especially thanks to James for the offer! I think your request for POC code is very reasonable, so let me get back to you on that when I have some (although a combobox is already almost there, as it is basically just a menu with a changing header). Obviously, it will take a lot of time to implement all the needed widgets, but I don't think it will be necessary to create a complete osgWidget fork. From what I've seen it's pretty flexible (just lacking a lot of widgets ;). My hope is to be able to upstream most of the yet-to-be-made widgets. My hope is to keep at least the current gui xml format, which I think should be doable. Failing that, let's at least have the changes scriptable ;) I must admit I forgot to look at the nasal API, am going to take a closer look at that shortly. Regarding canvas, I think that that is definitively the way to go for stuff like the map widget, but to be honest I have my doubts whether it would be suitable for the entire gui. I must admit though, so far I've only read the documentation on the wiki, so I haven't played around with it yet. Regarding librocket, that would mean adding another dependency to FlightGear. I thought the consensus was that that is not something to be taken lightly. And then again, it would require updating all of the gui definitions. Stefan 2012/7/23 Jacob Burbach jmburb...@gmail.com: On Sun, Jul 22, 2012 at 6:42 PM, HB-GRAL flightg...@sablonier.ch wrote: Am 22.07.12 22:40, schrieb Thomas Geymayer: Hi Stefan, Am 2012-07-21 22:46, schrieb stefan riemens: It's obviously a long time wish to get rid of the PLIB dependency, and one of the main subsystems using it is the GUI. There are a couple of things lacking in possibilities with the current implementation: - Proper internationalisation. PUI doesn't support UTF-8, limiting i18n support tremendously. - Things like submenus - The code is pretty messy, by the looks of it mostly due to the oldness of PUI and its API Have you seen my ongoing efforts towards a unified 2D drawing system called Canvas (http://wiki.flightgear.org/Canvas). It basically allows drawing 2D shapes (with OpenVG) and text (using osgText::Text). As it uses osgText for textrendering, supporting UTF-8 is very easy. I just tried it and with changing a single line of code now also using UTF-8 is supported. Currently only drawing inside an existing (PUI) dialog is possible, but the idea is to slowly implement the current functionally in Nasal and get rid of the hardcoded PUI widgets. Only some code for mouse/keyboard interaction with Nasal will be needed. In contrary to using some hardcoded GUI system (PUI, osgWidget, etc.) this approach would give much more flexibility and also the means of modifying and creating new widgets without the need to touch any core code. With the Canvas system every type of widget would be possible, so that also things like submenus can be realized. Another advantage of the Canvas approach is that it is heavily using the property tree and therefore is already fully accessible from Nasal code and also configurable with the existing xml formats. Switching to another scripting language or adding support for a new one, I think would be far too much work and not worth the efforts. Regards, Tom I don’t know what is it worth to think about a GUI inside fgfs at all sometimes. When I look to what can be done i.e. with the FGx launcher, properties and now HLA/RTI I’m thinking about trying to skip the built-in GUI at all ;-) Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Might be worth having a look at http://librocket.com, looks to be a very powerful and well done gui system. Uses html/css based files for creating, laying out, and styling the gui...has some support for interfacing script engines (ie nasal), localization, etc. This is the route I'd probably go personally if I were to do this...or any game/sim/3d project needing a gui... -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 24 Jul 2012, at 13:22, stefan riemens wrote: Thanks for the feedback, and especially thanks to James for the offer! I think your request for POC code is very reasonable, so let me get back to you on that when I have some (although a combobox is already almost there, as it is basically just a menu with a changing header). Obviously, it will take a lot of time to implement all the needed widgets, but I don't think it will be necessary to create a complete osgWidget fork. From what I've seen it's pretty flexible (just lacking a lot of widgets ;). My hope is to be able to upstream most of the yet-to-be-made widgets. Okay - my personal feeling was it's flexible but some of the design choices make a few things harder than they need to be. Again, I've made slow progress on porting PUI, so if you have proof-of-concept stuff for some widgets already, you can convince me quite easily :) Oh, I remembered the other 'difficult' widget - the scrolling lists and (related) multi-line text. My feeling was that osgText was going to handle multi-line text fairly badly, and this might be an issue. We don't have many multi-line text widgets, but they're some useful ones - e.g. the Nasal console. My hope is to keep at least the current gui xml format, which I think should be doable. Failing that, let's at least have the changes scriptable ;) Keeping the current XML format is really a requirement - improving that format, especially handling of layouts, is another task, but there's too many existing dialogs to really break compatibility. I must admit I forgot to look at the nasal API, am going to take a closer look at that shortly. I don't think there's a major issue here - so long as you keep XML compatibility most of the current Nasal interaction with the GUI will work. There is great scope to make /better/ Nasal APIs for items such as combo-boxes and pickers, especially ICAO and radio frequency pickers, but that's all 'improving the GUI' work than can happen once we've ditched PLIB and have something hackable. Regarding canvas, I think that that is definitively the way to go for stuff like the map widget, but to be honest I have my doubts whether it would be suitable for the entire gui. I must admit though, so far I've only read the documentation on the wiki, so I haven't played around with it yet. Right, canvas makes more sense for the map-widget and replacing the old OpenGL calls in the HUD is my feeling; to build something compatible with the current GUI using the canvas might be possible, but is a lot of work. Regarding librocket, that would mean adding another dependency to FlightGear. I thought the consensus was that that is not something to be taken lightly. And then again, it would require updating all of the gui definitions. Agreed on all counts - of course it should be possible to support the current XML syntax using any toolkit, it just's a question of how hard it is. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
Am 2012-07-24 15:43, schrieb James Turner: Oh, I remembered the other 'difficult' widget - the scrolling lists and (related) multi-line text. My feeling was that osgText was going to handle multi-line text fairly badly, and this might be an issue. We don't have many multi-line text widgets, but they're some useful ones - e.g. the Nasal console. I have just experimented a bit with osgText and multi-line text. So far I didn't notice any problems. Regarding canvas, I think that that is definitively the way to go for stuff like the map widget, but to be honest I have my doubts whether it would be suitable for the entire gui. I must admit though, so far I've only read the documentation on the wiki, so I haven't played around with it yet. Right, canvas makes more sense for the map-widget and replacing the old OpenGL calls in the HUD is my feeling; to build something compatible with the current GUI using the canvas might be possible, but is a lot of work. But using the Canvas also for the GUI would give us the advantage of a unified rendering backend for any type of GUI/text rendering and also the ability to use the same widgets everywhere - eg. use them also inside aircrafts for CDU GUIs or other displays... I've done a quick proof of concept for a tabbed and scrollable widget (including some UTF-8 chars): http://youtu.be/1a6wtPVPWc4 https://gitorious.org/~tomprogs/fg/toms-fgdata/blobs/canvas/gui/dialogs/canvas-demo.xml Regards, Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 24 Jul 2012, at 16:45, Thomas Geymayer wrote: I have just experimented a bit with osgText and multi-line text. So far I didn't notice any problems. My concern was about calculating sane vertical heights allowing for line-wrap, but that appears to work, based on your demo below! But using the Canvas also for the GUI would give us the advantage of a unified rendering backend for any type of GUI/text rendering and also the ability to use the same widgets everywhere - eg. use them also inside aircrafts for CDU GUIs or other displays... I've done a quick proof of concept for a tabbed and scrollable widget (including some UTF-8 chars): That's quite a convincing demo :) Especially since we'd factor the createXYZ functions into a helper, or even C++, depending on how much customisability we're looking for. I'm even more convinced now that we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI. Thomas, one issue I can guess at (though PLIB is also really bad at it, and osgWidget is not much better!) - text selection. Do you think you'd be able to handle a blinking insertion point and a standard draggable text selection area in this approach? Obviously it might need some additional C++ helpers but that's okay since text-editing is a pretty specialised behaviour. One goal of mine for the GUI is to get platform native copy-and-paste working, BTW ;) Stefan, what's your opinion? Obviously Thomas knows the Canvas code since he created it - I've looked at the source but not used it properly (and probably no-one else has a chance to either, yet), but it has the advantage that it's already checked in, and offers a very lightweight solution potentially. (We could could allow aircraft dialogs to include custom widgets, although that might be unwise for other reasons) James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
Am 2012-07-24 19:35, schrieb James Turner: Thomas, one issue I can guess at (though PLIB is also really bad at it, and osgWidget is not much better!) - text selection. Do you think you'd be able to handle a blinking insertion point and a standard draggable text selection area in this approach? Obviously it might need some additional C++ helpers but that's okay since text-editing is a pretty specialised behaviour. Yes :) http://youtu.be/CIS8UyuJLgM I have just added some property change listeners to get the position of the next character at a given position. The highlighting happens only from Nasal. What is currently missing is the possibility to also change the color of the selected text and to actually get the selected text, but this shouldn't be too hard to implement. One goal of mine for the GUI is to get platform native copy-and-paste working, BTW ;) This has already been on my wish/todo list :P Obviously Thomas knows the Canvas code since he created it [...] Currently documentation is not too detailed, but looking at the different demos and maybe also the Nasal API and source code should help. If not, don't hesitate to ask :) Regards, Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
Hi Thomas, Hi James This looks promising in a technical/coding perspective of having this and that common GUI feature available also for flightgear. But for me personally one of the big problems of the FlightGear GUI is that it is inside the only and one main window. There is no possibility to have a separate window to not cover the main content, the scenery and the cockpit? This would make the GUI much more practical. I would really like to run flightgear with one window view and other windows for the program (options). This will improve the usability of all the menus, dialogs etc. a lot in my opinion. Cheers, Yves Am 25.07.2012 um 00:11 schrieb Thomas Geymayer tom...@gmail.com: Am 2012-07-24 19:35, schrieb James Turner: Thomas, one issue I can guess at (though PLIB is also really bad at it, and osgWidget is not much better!) - text selection. Do you think you'd be able to handle a blinking insertion point and a standard draggable text selection area in this approach? Obviously it might need some additional C++ helpers but that's okay since text-editing is a pretty specialised behaviour. Yes :) http://youtu.be/CIS8UyuJLgM I have just added some property change listeners to get the position of the next character at a given position. The highlighting happens only from Nasal. What is currently missing is the possibility to also change the color of the selected text and to actually get the selected text, but this shouldn't be too hard to implement. One goal of mine for the GUI is to get platform native copy-and-paste working, BTW ;) This has already been on my wish/todo list :P Obviously Thomas knows the Canvas code since he created it [...] Currently documentation is not too detailed, but looking at the different demos and maybe also the Nasal API and source code should help. If not, don't hesitate to ask :) Regards, Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 21 Jul 2012, at 21:46, stefan riemens wrote: Obviously, I think the best choice of these is to switch to osgWidget, and I'm willing to take that task upon me. I've made a clone on Gitorious, with a osgWidget MenuBar implementation. Its currently pretty quick and dirty, and looks absolutely horrible, but it (mostly) works. https://gitorious.org/~stefanriemens/fg/stefanriemens-flightgear Before pushing further with it, I'd like to hear other devs opinions on how to go forwards... I've got about 25% of option 1) done in a private branch. I believe 4) (using osgWidget) is not great because osgWidget is essentially unfinished, unmaintained and has no examples of the kind of widgets we actually need - sliders, combo boxes, dials and so on. The great advantage of porting PLIB is that the we already use its API, and it already implements all the widgets we need :) I did start using osgWidget, and realised to create scrollbars, combo-boxes and sliders that work, and then port all the dialog / menu code to use the new API, was a huge amount of work, and would require updating all the dialog XML definitions. I am hopeful (though not sure) that I can make approach 1) and keep all the existing generic and aircraft-specific dialog XML files looking 'okay' and working as intended. My assumption is to make osgWidget do what we need, you will *have* to fork it (although you may be able to upstream the changes if they are generic enough) and will spend a lot of time creating all the widgets we need. If you disagree, I am more than happy to help and collaborate, but I'd like to see proof-of-concept code, say, a combo-box and scrollbar before agreeing you can do it :) James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
