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] Functions to textures?
Actually, the code that creates the texture is in scene/util/StateAttributeFactory.cxx, but you would have to do something similar to the noise texture code in TextureBuilder to access your texture from a texture. It would be nice if the Effects framework had a way to load arbitrary textures and make them available to effects. These days you aren't limited to 8 bit texture components. There is a rich set of data formats for textures: 32 bit floats, 16 bit floats, exotic combinations of different length floats per RGB component... I don't know if there is a better way to create your texture offline than write C++ code in simgear. OSG will read a TIFF file with 32bits per component as a floating point texture... assuming you can create such a thing. Thanks for the explanations and locations. After some experiments, it seems the way to do this is to implement the noise function directly as GLSL code in the fragment shader. This has a whole bunch of advantages: 1) Creating a 4-component noise vector corresponding to what is in the texture beats the texture lookup call by (very roughly) ~20% on my system 2) Unlike a noise texture, noise generated on the fly never has tiling artefacts, so there is no need to superimpose nearby wavelengths in the first place, saving between a third and half of the total use of noise 3) Unlike texture lookup, the noise function can be evaluated just when needed, even inside a non-uniform conditional,i.e. for instance respecting a distance cut which makes a lot of sense for LOD, again that saves a lot of un-needed work (and 4), I can write it in a completely intuitive way by passing a wavelength in and getting a number between 0 and 1 out, so there's no need to do any re-scaling and mental arithmetics). So, that just means I have to change a few numbers everywhere... * Thorsten -- 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] commit 75087095b132ec7a42e14000c7c8b3b09147d720
Le 22/07/2012 14:58, Mathias Fröhlich a écrit : The mentioned commit breaks scenegraph picking. For reference take the c172 door handle that opens the dor but never closes it anymore. Well, except you click at the position where the untransformed door handle would be. Quite annoying when you want to work on panels pick animations :-) While taking the time to fix that or find a solution so FG got the best from the optimisations, could it be possible to have some guide line to revert on our local git only the necessary commits, so we can continue the work on the instruments and use the other latest developments ? Alexis (xiii) -- 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] commit 75087095b132ec7a42e14000c7c8b3b09147d720
Alexis Bory wrote: While taking the time to fix that or find a solution so FG got the best from the optimisations, could it be possible to have some guide line to revert on our local git only the necessary commits, so we can continue the work on the instruments and use the other latest developments ? Alexis (xiii) Sure, what about this: git checkout -b revert-tim-change git revert 75087095b132ec Now you work on the revert-tim-change branch until the fix is committed. Then you just switch back to next and delete the revert branch. Cheers Chris -- 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
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] socket communication
Thank you very much everyone! I've been reading all your advice, I made this
program that sends data to FlightGear and my protocol.
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include stdio.h
#include string.h
#include stdlib.h
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include unistd.h
/// CLIENT
int main(int argc, char *argv[])
{
printf(This is the client program\n);
int sockfd;
char data[1000];
int len, heading;
struct sockaddr_in address;
int result;
int rc = 1;
//Create socket for client.
sockfd = socket(PF_INET, SOCK_STREAM, 0);
if (sockfd == -1) {
perror(Socket create failed.\n) ;
return -1 ;
}
//Name the socket as agreed with server.
address.sin_family = AF_INET;
address.sin_addr.s_addr = inet_addr(127.0.0.1);
address.sin_port = htons(7734);
len = sizeof(address);
result = connect(sockfd, (struct sockaddr *)address, len);
if(result == -1){
perror(Error has occurred);
exit(-1);
}
heading=0;
printf(%d ,heading);
while (heading 360 rc !=-1) {
heading += 20;
sprintf(data,%d\n,heading);
usleep(10);
//Read and write via sockfd
rc = write(sockfd,data, strlen(data));
printf(%s,data);
}
close(sockfd);
exit(0);
}
?xml version=1.0?
PropertyList
generic
input
line_separatortab/line_separator
chunk
nameheading bug/name
typeint/type
node/autopilot/settings/heading-bug-deg/node
relativefalse/relative
min1/min
max360/max
wraptrue/wrap
/chunk
/input
/generic
/PropertyList
:)
2012/6/25 Geoff McLane ubu...@geoffair.info
Hi Sanny,
If you want to communicate via sockets,
and 'get' or 'set' properties then this is the
page -
http://wiki.flightgear.org/Telnet_usage
But to expand that a little
1. server - Need to run fgfs with a command -
--telnet=port
This connects fgfs to localhost:port, but the read/write
is only POLLED a few times a second, forget the exact
default hertz, but it is very SLOW in relative terms...
The full generic 'telnet' command is -
--telnet=foo,bar,POLLRATE,foo,PORT,bar
The 'foo' and 'bar' can be anything, and are ignored.
If you want the interface polled at your current frame
rate, then the POLLRATE used should be greater than
your frame rate...
I usually use 100, but that does NOT mean it is polled
faster than your frame rate ;=)) but at least AT your
frame rate...
2. client - a tcp client to connect to the PORT
Below I give a working examples in perl, but it should be
easy to translate that to C/C++, or any other language
of your choice...
You have to get to 'know' the hundreds of properties
that can be read, and set. Use fgfs MENU Debug -
Browse Internal Properties to see all what is
available...
Of course setting some property will have
no effect if over-written by some other control,
input, like setting the elevators, and then moving
the joystick, or up-arrow key...
And some properties are 'tied' to others, which can
effect what happens, and you need to have some awareness
of what is returned - a string, double, bool, etc...
Lots of fun in learning ;=))
And if thought suitable, maybe the below perl
tested example could be added to the wiki...
HTH.
Regards,
Geoff.
fg-telnet.pl
#!/usr/bin/perl
use strict;
use warnings;
use IO::Socket;
use Term::ReadKey; # for ReadMode
# run fgfs with TELNET enabled
# --telnet=foo,bar,100,foo,,bar
# otions
my $send_run_exit = 0; # if you want fgfs to shut down
my ($FGFS_IO); # Telnet IO handle
my $PORT = ;
my $HOST = 'localhost'; # or IP address
my $TIMEOUT = 3;
# some properties
my $get_Altitude = /position/altitude-ft;
my $get_Altitude_AGL = /position/altitude-agl-ft;
my $get_Latitude_deg = /position/latitude-deg;
my $get_Longitude_deg = /position/longitude-deg;
my $get_Track = /orientation/track-magnetic-deg;
my $nav_stg = /instrumentation/nav/frequencies/selected-mhz;
# Did not show - maybe the wrong property...
#my $hdg_bug_stg = /autopilot/settings/heading-bug-deg;
my $hdg_bug_stg = /instrumentation/heading-indicator/heading-bug-deg;
my @warnings = ();
sub prt($) { print shift; }
sub prtw($) {
my $msg = shift;
push(@warnings,$msg);
prt($msg);
}
# ### FG TELNET CREATION and IO ###
# ==
sub fgfs_connect($$$) {
my ($host,$port,$timeout) = @_;
my $socket;
STDOUT-autoflush(1);
prt(Connect $host, $port, timeout $timeout secs );
while ($timeout--) {
if ($socket = IO::Socket::INET-new(
Proto = 'tcp',
PeerAddr = $host,
PeerPort = $port)) {
prt( done.\n);
$socket-autoflush(1);
sleep 1;
return $socket;
}
prt(.);
