!tabby - a tabbed container app

!tabby is a tabbed container app that allows you to manage a number of windows belonging to other tasks under a single tab bar. It was designed to alleviate my major annoyance when programming on RiscOS, which is having the desktop cluttered by lots and lots of !SrcEdit windows. It can probably be used for other things as well.

To use it, load !tabby onto the tab bar, each time you click on the icon, a new tab bar will appear. To load a window onto the tab bar, click the green LED icon, the LED will turn red indicating that it is waiting for a window to capture. Drag the window over the tab bar, when !tabby has identified the window, the LED will turn yellow, indicating that it is about to capture the window and give you time to stop dragging. One second later, the window will be captured and the LED will turn back to green again. The rest of the operation should be fairly intuitive.

It still has some rough edges and some additional functionality I’d like to implement, such as being able to re-order the tabs, but hopefully it is at the stage where it may be vaguely useful.

!tabby is available here: http://theoval.cmp.uea.ac.uk/riscos/index.shtml#tabby

The GITHub repository is here: https://github.com/usr-bin-gcc/Tabby (for those that are interested)

and there is a demo video here: https://youtu.be/OVhzGKLAxj4

Many thanks to Stuart Swales and everybody else who has given help and advice with this!

I have just given this a very quick try. It looks very useful. I often require having several editor windows open, perhaps iconising some, or using several virtual desktops to try and ‘manage’ them. This ‘tabbing’ of windows and instantly switching between them could be a game-changer. Thanks very much for the progress so far – I look forward to seeing further development.

The video is very good: I couldn’t tell what you meant from your description, but it all makes sense now.

It’s extraordinary and very clever.

I think I’m too used to managing hordes of windows to be likely to use it myself. When I’m using Windows or Linux I often dislike the way it’s hard to open things side by side, and despite being multi-tasking Windows does seem to expect applications to use the whole screen, whereas RISC OS gives you a desktop you can organise yourself.

With !Tabby, I can see that you can get the best of both worlds. Very impressive!

Dragging to reorder tabs, or to move windows from one tab to another, or to drag a window so that it becomes independent again would be great. I’m sure you’ve got those ideas planned, but thank you for releasing at this stage, as it’s already useful.

What others have said. Brilliant. Give that cat a gold collar.

or to drag a window so that it becomes independent again

Just click on the little cross in the tab title – the window becomes detached 8)

Gavin excellent work! :)

Very useful indeed and finally we have a way to control the number of windows that can get a little crazy on RISC OS.

Thanks a lot!

Another tab-related release! This looks useful, thanks.

A couple of minor bug reports:

I’ve got a window inside Tabby, and I drag the resize icon to the bottom of the screen. I would expect the window to grow upwards, instead it allows me to drag the icon off the screen.

The resize icon gets plotted in the wrong place sometimes.

The windows that I’ve attached to Tabby get left behind on the screen (not inside the Tabby window) when I switch tabs. Clicking on that window’s tab brings it back under control. Actually this seems to only happen with StrongEd windows.

I’ll use it for a while and see if I can provide more detail.

Very clever tool that I’m certainly going to use – especially when file dragging between the tabs will be implemented. Would it be possible at all to move a file from one tabbed (filer) window to another tabbed window, by shift-dragging it from the open window and drop it on the tab of another window? If so, I would love to see that implemented.

Thanks. That looks like it might tidy my desktop up!
It might be mentioning in the YouTube text RISC OS.

It looks interesting, but it is not for me.

StrongED provides ListOfWindows with various operations, including Hide. I usually stack SE windows, anyway.

For other windows I iconise to the Iconbar, or sometimes use AddTinyDir. What will Pinboard2 offer?

Thanks everybody for the constructive comments, especially the ideas for new features and the bug reports!

Matthew: I like the idea of dragging a tab to detach it from the bar, for one thing it would mean that the tabs could be shorter and there would be room for more of them. The only problem would be differentiating it from the dragging to change the order of tabs, perhaps Paul’s suggestion of shift-drag might work.

Rik, many thanks for the testing! The drag to the bottom of the screen issue is probably the thing I should work on next. There are probably other RiscOS behaviours that I have forgotten since the 90s ;o) I’ve downloaded !StrongEd and I think the problem there may be due to the horizontal scroll bar appearing and disappearing as the width of the window is changed. I was going to limit !tabby to programs with both scroll bars, but if !StrongEd doesn’t do that, I’ll have to accommodate that (as this was originally a proof-of-concept for the IDE that I am working on that is designed to wrap itself around whatever editor the user prefers, and !StrongEd is popular). It is definitely a program that I need to use in testing.

I’ve been thinking of refactoring my IDE to use Toolbox rather than RiscOSLIB and use the Tab and Treeview gadgets, which look very handy.

Paul, I think I initially misunderstood your question. Yes, you can use !tabby with filer windows and shift-drag seems to work. Unfortunately the way filer windows resize means they don’t work that nicely with !tabby at the moment, as it tries to keep the active window the same size (as far as possible) when you switch tabs, and filer windows have strong views about what size they want to be. I’ll have a think about how to make it work better. !tabby just hides the title bar of the captured window behind the tab bar, so it isn’t doing anything particularly clever, and the captured window should behave as it normally does. The only mildly sneaky think !tabby does is to have a small window that sits over the adjust size icon to intercept attempts to resize the captured window. That seemed to be the best way to make sure the size of the tab bar is adjusted smoothly when the captured window changes size.

Chris, good point, I’ll update the text.

I’ve been thinking of refactoring my IDE to use Toolbox rather than RiscOSLIB and use the Tab and Treeview gadgets, which look very handy.

My memory of how the WIMP+Toolbox works is a little hazy, but Tabs may not be ideal for your needs. Tabs embeds named Toolbox Window objects in its own Window, these nested windows have to be specified in the Resource file. There’s no API to add new tabs at run time.

I suppose you could have a fixed number of tabs that started empty, then when you drag a (different task’s) window to the empty tab, your application embeds that Wimp window inside the Toolbox window object that is embedded in the Tab. That’s a lot of levels of nested windows, I have no idea whether it’s a good idea or not!

Thanks for the info Rik, I think it may be well worth it just for the TreeView gadget, but it would be good if my tabs were consistent in appearance and behaviour with the Toolbox Tabs.

The only problem would be differentiating it from the dragging to change the order of tabs, perhaps Paul’s suggestion of shift-drag might work.

This wouldn’t be necessary, would it? If the destination of the drag is the tab bar, it’s a re-order; if it’s another window, it’s a de-tab. That’s how other platforms generally do it (try Chrome or Firefox, for example), so users would be familiar with it as a concept.

Changing the order of the tabs seemed fairly straight forward to implement by making the parent box for Wimp_DragBox horizontal and have the initial box capture the tab being moved, but if the drag can be out of the bar I’d probably have to animate the tab some other way (as I’d still want it to move purely horizontally until the pointer got too far from the bar)? The difficulty was more from a programming perspective than a user one. It is definitely a good feature to add though, and a good learning experience for me to work out how to implement it.

Actually this seems to only happen with StrongEd windows.

Tabby hides all its windows except for the one on the selected tab. When you switch to a different tab Tabby requests the associated window to open (unhiding it) behind Tabby’s window. StrongED didn’t handle this correctly, only unhiding to top of stack worked as intended. I’ve fixed this and now StrongED windows work okay with Tabby.

The automatic adding/removing of the horizontal scrollbar may be a problem. If it is, the scrollbar can be configured to be permanently on (or off).

While testing I found a couple of issues:

• If a tabbed window has input focus then quitting the editor often crashes Tabby.
   
• Trying to add a WinEd window always (at least for me) results in Tabby crashing.

Hopefully this is of use. Anyway, thanks for Tabby it’s an interesting concept.

Thanks Fred for updating StrongED, I will be using the same approach for my IDE and it is very important that works with StrongEd!

Many thanks for the bug reports. I think I have worked out the problem with the first issue, and hopefully fixed it. It crashes when there are two or more windows that are owned by the editor that quits, and !tabby was deleting the second window and then trying to make the preceding one the active window, which may also be one that no longer exists. I’ve changed it now so that it deletes all of the affected windows and then looks for a valid window to make the active one. Sorry for releasing !tabby with such an obvious bug! I’ll upload a new version when I have tested it some more.

For the second bug, it seems to be fine if it is a blank (unsaved) template, but not if it is a saved one, which suggests it may a problem reading the window title.

I think I need to find some method of automated testing. David Ruck’s WindOpen module looks like it has most of what I need except the ability to click a particular icon on a window.

Bonjour,
Thank for !Tabby, I am testing it with my !Diderot application and !StrongEd.
Nice.

Rik Griffin’s treeview and tab modules are a good thing for those who want to use the ToolBox.
This is what allows programmers on other platforms to build applications, welcome to future candidates for RISC OS.

Thanks Jean-Michel, do let me know if you find any (more) bugs!

I’ve hopefully fixed the problem with WinED (and possibly any parent window that has an icon), although adjusting the size of the WinEd window is not correct, I’ll look into that next. I’ve pushed it up to GIThub and make it available from my website when I get to the office tomorrow.

StrongED didn’t handle this correctly, only unhiding to top of stack worked as intended. I’ve fixed this and now StrongED windows work okay with Tabby.

Is this in an update in StrongED 4.69f11 or 4.70a13?

!tabby just hides the title bar of the captured window behind the tab bar, so it isn’t doing anything particularly clever, and the captured window should behave as it normally does.

Couldn’t Tabby’s title bar reflect the title bar of the currently displayed window: one needs both the name of any file being edited and the * that indicates it’s not yet saved.

Another suggestion might be to be able to drag a list of path.file names to Tabby’s icon bar icon or have a list set up in Choices so that resuming work on a multi-file project is quicker than manually going through the traffic light sequence several times.

It should do that already, I think I must have commented it out while debugging. I’ll fix it and upload a new version tomorrow.

That’s a good idea! I need to work out how to do something similar for the IDE I am working on, so I may as well prototype it in !tabby.

Just found that in v.1.0.3 clicking Menu in an unpopulated Tabby window causes mayhem under:
ARMX6 OS 5.29 (03-Nov-2020)
Pi400 OS 5.29 (18-Jul-2021)