Gtk v0.1.0 refactoring updates

[vtjnash]

This updates the Winston Gtk backend code to work against Gtk v0.1.0 (previous code worked against v0.0.0) and it provides a port of the canvas3d demo to Gtk.

[JeffBezanson]

Thanks for doing this. We might even decide to make Gtk the default. But, making a copy of a whole bunch of code is not going to work (only a few lines of it are even different). canvas3d will eventually be integrated into winston, and we can't keep updating 2 files as we work on it.

[JeffBezanson]

Also, while I'm not sure I'd push for identical GUI APIs implemented with both Tk and Gtk as alternate backends, it shouldn't be necessary to use things like GDK_BUTTON1_MASK. There should be backend-neutral, simple ways to do simple things (like Window).

[vtjnash]

I realized that too Jeff (both the file copying, and the button constants issues). I could also point out that the only changes I needed to make were to code where you were still breaking the abstraction and assigning / calling functions directly to members of the Tk types. I was delaying this pull request because of these issues, but realized that I may not have much time to make updates in the next few weeks, so figured I can at least make this much available.

I was hoping we can discuss this in realtime (perhaps the upcoming IRC sprint). I think they can have nearly identical GUI API's (except for layout).

[JeffBezanson]

Yes, let's do that. It'd be nice to settle on high-level APIs at least for the simple stuff.

In this case, assigning to e.g. win.mouse.button1press is my API for handling mouse events in Tk.jl. It's not Tk-specific and could probably be sanely provided for any toolkit. Breaking the abstraction would mean something like doing direct tcl calls with tcl_eval. But I'm certainly open to changing it. What I was thinking is that you might want to have dedicated mouse handler objects, and be able to switch which one a window is using.

[vtjnash]

bump. Can this be merged now?

[JeffBezanson]

Yes, if the changes to canvas3d.jl are removed. Having code that checks everywhere whether we are using tk or gtk is insane. The development of that code will be all but stopped by having to do everything twice.

We might use GTK as a backend, but we aren't going to use its API, which is designed for C. Notice how my part of the Tk bindings (Tk/src/tkwidget.jl) does not really expose the Tk API. For example you don't write "bind <ButtonPress-1>". And I provided width(win), whereas the new part provides winfo(win, "width"), etc.

[JeffBezanson]

I'm starting a related discussion here: JuliaGraphics/Tk.jl#35

[vtjnash]

@JeffBezanson bump.
The remaining changes are due to a difference in the way Tk and Gtk preferred to handle drawing.
In Gtk, I have that redraw -> draw & reveal
In Tk, You have that draw -> reveal
This change was in order to solve the issue with Tk where calls to draw may happen before the context was ready, or may not be reflected on the screen. Redraw check those conditions first and may delay the subsequent calls until after they are ready. It is not strictly necessary, but may be more efficient?

[JeffBezanson]

Ok, that's fair. We should sync up the meanings of these. My win.redraw is badly named, since it's really used as a hook to call when the window is resized. I also agree with you that draw should not call reveal. draw should just perform drawing operations onto a GC.

I propose the following:

• rename win.redraw to win.configure, which will only be called by the toolkit, when something like resize happens to a window
• by convention draw() just draws
• the mouse handler should call draw and reveal

I will make these changes in Tk.jl and Winston/src/tk.jl, and you can make them in canvas3d.jl, then I will merge this.

[vtjnash]

I use redraw in the same way, but I think the name is correct. I propose the following:

• keep win.redraw and have it performing your custom draw code
• by convention draw() just draws (calling reveal would be redundant)
• the mouse handler should call redraw()
• redraw() queues up a request to draw and then calls win.redraw then reveal, as soon as practical.

optional:

• redraw could take a second parameter "immediate" suggesting whether the window should be refreshed immediately, or when the event system is idle (this is a Gtk feature and I don't know how well it maps to other systems)

[JeffBezanson]

If we have win.redraw, it should only draw; the problem is that often extra operations need to be performed when the window is resized (such as configure(Canvas3D)), and these should not be done when only redrawing is needed.

[vtjnash]

Ah, OK. That is something quite different. If we want to say that the user is responsible for not calling draw() until after the configure callback is called, (as I think we have now) that is seems fine. It's just a question of whether we want to have immediate drawing (buffered), or callback (immediate) drawing available.

[JeffBezanson]

My thinking is based on the fact that only the toolkit knows when the window resizes and so must push that info to you, but only you know when something has changed that requires a redraw. I don't believe the gui toolkit ever needs to request an application-level redraw (i.e. rerendering geometry), since it can refresh screen areas out of its backing store.

[vtjnash]

Yes, the callback style is only advantageous if we want to allow unbuffered (high-speed?) writes.

[JeffBezanson]

I don't consider unbuffered drawing useful at all, but we could still support it by providing a way to tell the window to store a snapshot in its backing store at an appropriate time.

[vtjnash]

I seems that nearly all graphics libraries are written to provide this. But I agree that that speed (and perhaps more importantly, memory) of modern computers has probably made it mostly unnecessary.

• rename win.redraw to win.configure, which will only be called by the toolkit, when something like resize happens to a window

Yes, lets do this. It is much more clear.

• by convention draw() just draws
• the mouse handler should call draw and reveal

I'm not sure this distinction is meaningful, when both the drawing code and the mouse handlers are provided by the user. It probably makes the most sense for draw to end with a call to reveal. I think it is enough to say that the user may call draw on the backing store anytime after the configure callback has been fired (and must do so in the configure callback at minimum).

[JeffBezanson]

Ok. It's not terrible for the draw method for a whole canvas to call reveal, but in general reveal is not a drawing operation but a window-level one. Without reveal, draw(gc,Canvas3D) requires only a graphics context, but with it, it requires a window as well.

[vtjnash]

ok, that makes sense. on the other hand, only the drawing code would know if the call to reveal is necessary (or if only a part has been updated). are you just figuring that is an unnecessary optimization?

[JeffBezanson]

Yes, I consider that an unnecessary optimization. There also might be other ways to get it, such as returning a bounding box of the changed region, so higher level code can aggregate and act on them.

You also might be drawing many things, and it would clearly be wrong for all of them to call reveal.