Drag and drop to reorder tabs

[soegaard]

A feature request: implement reordering of tabs via drag and drop.

[rfindler]

This probably belongs on the racket/gui repo; I think that DrRacket would just inherit the behavior of the underlying tab:panel%

[spdegabrielle]

Is tab-panel% in https://github.com/racket/gui/blob/master/gui-lib/mred/private/mrpanel.rkt the correct class?

[mflatt]

Yes, along with https://github.com/racket/gui/blob/master/gui-lib/mred/private/wx/gtk/tab-panel.rkt https://github.com/racket/gui/blob/master/gui-lib/mred/private/wx/win32/tab-panel.rkt https://github.com/racket/gui/blob/master/gui-lib/mred/private/wx/cocoa/tab-panel.rkt

[Lazerbeak12345]

Okay, I've got a proposal for how this API could work. I've been mulling over it for a week, and cross-comparing it to how other gui apis work, so I'm pretty confidant in how it looks, but, of course, I'd love feedback.

Ok, so first things first, we would add 'draggable as an option in style:

(new tab-panel%
    ...
    [style '(draggable)])

This would add inherent backwards compatibility with how it is now.

Second, there would be one of these two ways of getting the event (honestly, I don't know which would be better, but I prefer the way number 1 looks):

1. We add a new argument "drag-callback" that accepts arguments (such as a pair of integers [source, target] if its in the same tab widget, or else [source-tab-panel, target-tab-panel]).
2. We have an event that we expect to be augmented that's pretty much the same as above.

I'd like to make note, though. When I was brainstorming this, I didn't even think about tab-panel to tab-panel drags until really late, so I'm not confidant in that part. Perhaps it could still only be two numbers, but the third arg is the source panel? I don't know.

[Lazerbeak12345]

The signature for that last bit would be (-> exact-nonnegative-integer? (or/c -1 exact-nonnegative-integer?) (is-a/c? tab-panel%)) void?)

[Lazerbeak12345]

Ah. Wrong repo. My bad. Let me put this in the right one...

[rfindler]

@Lazerbeak12345 probably a good next step is to look at the libraries that are used to implement the current tab panel and see what functionality they offer, see if there is a common set of it, and then design the racket-level api around that.

[Lazerbeak12345]

Yeah... good idea. If I can I do want to give a pr for this a try, but I'd only be able to test the gtk stuff, so I simply won't write code I can't test. :)

[Lazerbeak12345]

Though, that actually does bring up an interesting problem: what if the api I end up pr-ing is only convenient to write back-end for on gtk (as I won't be able to do win32 or cocoa stuff)? I take it that would be looked over in the review, @rfindler ?

[samth]

I think @rfindler's suggestion is that you should look at what the mac and windows APIs for tabs provide (as in the documentation) and then try to design the API around that.

[rfindler]

Yes, exactly (but in the case of the mac, it is a third party library that we use, not the OS proper).

[rfindler]

There has been some progress here:

https://github.com/racket/gui/commit/04461edcf41c7bf7b8661f8708cec27ea7183b0d

https://github.com/racket/drracket/commit/3102a8c7affc288e0bd3ec82568ffad56e6c3ec6

[soegaard]

I think this works in recent versions of DrRacket.

Time to close?