Move rubberband code from ImageView to Gtk?

[timholy]

The rubberband selection code in ImageView could conceivably be added to Gtk/src/cairo.jl. Then it would be of greater use to Winston and other projects that might want to implement zooming.

Alternatively, we could have a GtkExtras. Finally, of course it could continue to live in its current location.

If interested, I'll prepare a PR.

[lobingera]

I'd recommend to keep library interfaces (like Gtk, cairo etc.) 'clean'.
Your code works on top of a library and is a first step into a new toolkit, so thinking about putting it into a package of its own might make some sense.

btw: Is there no support for rubberband selection in Gtk?

[vtjnash]

Realistically, the cairo.jl file is the only part that isn't just a simple ('clean') interface to the Gtk library. I would also like to expose the draw event for user code, which should greatly simplify the implementation of rubberbanding code -- and perhaps make it reasonable to include in base Gtk (providing additional Gtk-dependent packages is also reasonable, esp. as the internal API here starts to stabilize).

[timholy]

btw: Is there no support for rubberband selection in Gtk?

I can't find one. I even found a similar python file.

[timholy]

Now that Gtk has matured considerably, what are the thoughts about this? I now see at least two areas, rubberbanding and hit-testing for objects on a Canvas, that would likely be of common interest. Here, or in an extensions package?

[lobingera]

I still believe in modularization -> a lightweight (small, only interface to gtk+ and cairo) package.

Something like hit-testing of objects and arranging objects onto a canvas seems to sail under the name of scene graph. In the gnome world clutter is to be used for that, but some development of a GTK scene graph toolkit started:
http://www.bassi.io/articles/2014/07/29/guadec-2014-gsk/

Also i'm still wondering, why the click-and-hit internals of gtk are not accessible, are they?

[timholy]

There's no rubberband built into Gtk that I can find, but feel free to do your own search. You will quickly find several examples of people implementing this themselves.

Cairo has some built-in facility for hit-testing (see the second code-listing in http://cairographics.org/hittestpython/). It's not yet clear to me if Cairo offers all the facilities we'd need; for example what about closest point in a scatter plot? But my plan would be to look into exploiting it. No matter how you do this, it's a little tricky because you have to plan ahead for this when you first create the path.

[lobingera]

I was not clear enough:

Both hit-testing and rubberband doesn't exist in plain Gtk (and Gtk+). Cairo has some means to test pixel coordinates against the current path, but only the current path. Gtk should have some internals to do something like hit-testing for non rectangular widgets but there is no access. X11 (!) has support for non rectangular windows and could be used for that.

For my display/visualize project on pygtk, pycairo i use a dedicated click map (pixelmap) that is filled with an ID for the respective object that is drawn on screen. So, i paint a flower to the screen with cairo and an ID of 75 to the click-map in the background, also with cairo but something special on setting the color and you have to turn off antialiasing to have clear pixels etc... If i get a event.onpress with button=1 i use the event coordinates and look up in my click map what ID is there. Apart from the effort for drawing everything twice and the memory for the click map, this is efficient and fast.

As an alternative i was looking at a BSP-tree for having fast tests on coordinates, but that was beyond my reach to iteratively update the tree if you paint new things additionally on screen, OR if you change the zoom (pan is not an issue here).

I think the cleanest solution would be an internal geometric representation that can be searched for inside-near-outside tests.

However, on a click map you could (if you hit ID=empty) search the surrounding for the next non-empty ID...

But back to your original question; about putting it into Gtk.jl or having something external?

I'm still in favour of having library interfaces like Gtk.jl 'clean' so only having the interfacing code and additional functionality in a package on top.

[timholy]

I'm fine with putting this in a CanvasExtras.jl package.