search

pbfy0 / visvis

Automatically exported from code.google.com/p/visvis
Other
0 stars 0 forks source link

Backend for the GTK toolkit #7

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
GTK is one of the mayor GUI toolkits, so it would be nice to have a backend
for it. Since GTK is not very popular on Windows, I have no experience with
it yet.

Any volunteers?

Original issue reported on code.google.com by almar.klein@gmail.com on 21 Mar 2010 at 11:34

GoogleCodeExporter commented 9 years ago 
Here's the beginning of a GTK backend.  It works from IPython and it can run 
all of the examples.  I'm sure it has many things to be fixed; the ones I'm 
aware of are:

- Figure._GetPosition and Figure._SetPosition don't do anything with the x and 
y coordinates.  This is because I didn't know what these coordinates were 
supposed to be measuring.  The widget relative to its parent?  The widget 
relative to its window?  The widget relative to the screen?  The window 
relative to the screen?  This doesn't seem to impair any functionality (and I'm 
a bit puzzled as to why the Figure would need to know any of those things).

- Calling DrawNow from newFigure() causes the GTK thread to hang within 
IPython, though it works fine in a script.  I replaced it with a direct call of 
the drawing function, which seems to be enough to get textures working.  But 
I'd like to understand why DrawNow doesn't work in this case.

- I don't really understand what's going on with the App class.  Compounding 
the issue, GTK doesn't have an object representing the application (at least to 
my knowledge), so I faked it by using the gtk module as the object returned by 
_GetNativeApp.  (At least I know it's a singleton.)  This whole class can 
probably be improved.

- The WX and QT4 backends seem to have timers in their _widgets.  My 
understanding is that events.processVisvisEvents handles events for all 
figures, so this struck me as odd.  I put the timer in App instead, starting it 
in _GetNativeApp.  But this requires this function to be called when embedding 
the figure, which makes me think maybe the timer should be started on module 
load.  What am I missing that suggests it's better for each _widget to have a 
timer?

- How does App know when to stop its main loop?  I couldn't figure out the 
logic from the other backends, so what I did was have the Figure class call 
App.Quit when the last figure is closed.  App.Quit will stop the main loop only 
if App previously started it.  Thus, scripts end when the last figure is 
closed, but IPython doesn't.  Since the other backends don't do this, I'm 
assuming there's a better way.

I have a few other questions and comments related to developing the backend.  
What's the best way to get them to you - this issue? a new issue? email?  Is 
there a mailing list?

Thanks,
Robert

Original comment by rschr...@gmail.com on 6 Feb 2011 at 3:42

Attachments:

GoogleCodeExporter commented 9 years ago 
Another potential bug:

- The other backends took a parent widget as an argument in Figure.__init__.  I 
didn't grasp why; maybe it's something to do with those backends.  GTK doesn't 
require this, so I didn't bother.  But maybe Figure should accept this argument 
just for consistency among backends.

Original comment by rschr...@gmail.com on 6 Feb 2011 at 3:49

GoogleCodeExporter commented 9 years ago 
> I have a few other questions and comments related to developing the backend.  
What's the best way to get them to you - this issue? a new issue? email?  Is 
there a mailing list?

There is a discussion group. I moved the discussion to there. 
see http://groups.google.com/group/visvis/browse_thread/thread/3ced28106bf440e8

You can also e-mail me for specific questions.

*Marking this issue as started.

Original comment by almar.klein@gmail.com on 9 Feb 2011 at 3:31

GoogleCodeExporter commented 9 years ago

Original comment by almar.klein@gmail.com on 24 Feb 2011 at 11:56