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 fin
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
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
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
>>
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 cu
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 d
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 "visibl
Sorry for responding this late, I've been on a horrible internet connection.
2012/7/26 Thomas Geymayer :
> 2012/7/26 James Turner :
>> 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
2012/7/26 James Turner :
> 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
On 26 Jul 2012, at 11:28, James Turner 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 dr
On 26 Jul 2012, at 11:09, Thomas Geymayer 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
2012/7/26 James Turner :
>> 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 kee
On 25 Jul 2012, at 17:27, Thomas Geymayer 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 p
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
--
Tim Moore wrote:
> On Wed, Jul 25, 2012 at 1:43 PM, Martin Spott 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 hav
2012/7/25 James Turner :
> 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 reall
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-type
On Wed, Jul 25, 2012 at 1:43 PM, Martin Spott 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,
ys wrote:
> Am 25.07.2012 um 12:17 schrieb Martin Spott :
>> 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
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
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 discu
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 convi
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 :
> Am 2012-07-24 19:35, schrieb James Turner:
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 heigh
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 fri
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 special
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.
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:
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 t
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 approa
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 us
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,
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
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, i
On Sun, Jul 22, 2012 at 6:42 PM, HB-GRAL 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
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 cu
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 internationalisatio
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
> abso
38 matches
Mail list logo
