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:
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
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
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
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
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
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,
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
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
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
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
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
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
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.
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
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
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
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
--
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
19 matches
Mail list logo
