Tabs enhancements

[spdegabrielle]

Is there a particular aspect of the current tabs you don't find 'proper'?

The current tabs can’t be dragged, re-arranged, docked and undocked from the tabs bar.

Nb: the goal of this request would be to add this functionality to DrRacket

[rfindler]

The tabs are implemented as a separate control in racket/gui and, at least on mac os, I believe they do support that dragging (inside the C library). That support isn't available at the racket/gui layer (in the form of callbacks that would inform drracket that something had changed). So the first step here is probably sorting out how to turn that functionality on (this will be platform-specific work).

[spdegabrielle]

yes, I'm guessing this would need to be implemented for gtk, win32(? or is it DWM?) and macOS (nswindowtab?). I'm out of my depth here, but I'll use this issue to do a bit of initial research to see if I can do anything.

-- My Notes: platform specific code https://github.com/racket/gui/tree/master/gui-lib/mred/private/wx

Windows https://docs.microsoft.com/en-gb/windows/win32/dwm/desktop-window-manager-overviews https://docs.microsoft.com/en-us/windows/win32/controls/create-a-tab-control-in-the-main-window

GTK https://developer.gnome.org/gtk3/stable/GtkNotebook.html https://developer.gnome.org/gtk3/stable/

macOS https://developer.apple.com/documentation/appkit/nswindow#topics https://developer.apple.com/documentation/appkit/nswindowtab NB: this appears to be different/unrelated to NSTabView control https://developer.apple.com/documentation/appkit/nstabview https://github.com/racket/gui/blob/master/gui-lib/mred/private/wx/cocoa/tab-panel.rkt NB explicitly disabled by https://github.com/racket/gui/commit/0fbbf759d3f244458378a639f653971fdff76668 adding (tellv NSWindow setAllowsAutomaticWindowTabbing: #:type _BOOL #f) to gui-lib/mred/private/wx/cocoa/frame.rkt (fix for issue #racket/drracket/issues/377 )

[mflatt]

For Mac OS, it's currently MMTabBarView instead of NSTabView or NSWindow tabs.

[Lazerbeak12345]

Sorry about that thing in https://github.com/racket/drracket/issues/124 ... saw that the issue was specific to the API parts I had brainstormed and didn't realize it was on the wrong repo....

Anyway, here's basically what I put there:

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.

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

[Lazerbeak12345]

So after some research, I have a working idea in my head of how to implement tab dragging in a way that should be easily written for all three platforms.

But there's a catch. Win32 doesn't natively support dragging tabs. (I think .Net might. I haven't looked, but this comment also has another reason that we could make a push for .Net. On the other hand, we have a lot of code already in place that would let us use GTK on windows, and I'm 100% sure that everything, save some text fields, is dark-mode compatible and working on linux, at least.)

GTK 2 and up supports dragging tabs, and it's a pretty sleek api too, so it won't be hard to implement.

The two cocoa libraries we are using both support dragging tabs, but we might run into minor problems as we had to override some of that functionality given by the api used on newer systems (MMTabBarView on newer, PSMTabBarControl on older or 32 bit systems).

That's all for now. Hope you don't mind my slow pace as this is just hobby work for me!

[Lazerbeak12345]

Oh, quick question: In my pull request that will only implement the actual behavior on GTK (as I can't test the other two), what would be the best way to signal a developer that that feature hasn't been implemented for their underlying GUI platform? Would I raise an error? If so, what error would be best? Should I even bother, in case someone else swoops in with an implementation before the code is released in a new version?

[samth]

I think rather than merging it with only some platforms supported, we'd try to complete the platform support based on your work before merging. So if you just implement the GTK code that seems good.

[Lazerbeak12345]

for the record, dragging has been live since racket 8, as has closing. (noted in the release notes of 8.1 - though 8.1 also now includes the types in typed/racket so I'd see this as really released at that point anyway.)

[Lazerbeak12345]

I noticed one of the original reasons why this issue was opened was so tabs can be docked and undocked. Is this not a feature that PLT plans on adding to Racket/GUI?

[mflatt]

That's a good point. We can reopen the issue, although I'm not aware of any specific plans to add that feature.