!tabby - a tabbed container app

Thanks for finding that Bernard, it crashes everything on RPCEmu as well, I’ll look into it ASAP.

Hey Gavin
In my !Diderot application there is an obey file to open the text file on the name of which we clicked.
It uses StrongEd’s Messages commands to open with this editor:
message StrongED_OpenDoc <ProjFileEdit>
Question: Is there an equivalent mechanism to open the file for !StrongED directly in !Tabby?

Bernard, I have uploaded a new version which hopefully fixes both issues.

Jean-Michel – I want to keep !tabby as agnostic as possible about the tasks owning the windows as possible, but it should be possible to make !tabby listen for a user message telling it to capture a particular window. The way I envision this would be to specify the window to capture by giving the window handle in the message to !tabby (perhaps just the window at the top of the window stack), and then have a * command that finds the window handle of a specified window . David Ruck’s WindOpen looks very useful for this sort of thing.

I was just about to offer to support that in WindOpen, but then remembered it’s assembler and needs rewriting in C first, which I should be doing around 2300 (the year that is).

I was just about to offer to support that in WindOpen, but then remembered it’s assembler and needs rewriting in C first, which I should be doing around 2300 (the year that is).

Nah, you need to do it before 2248…

Jean-Michel I’ve uploaded a new version to github and my website that listens for a WIMP user message (0×5FFFFF for now, hopefully that isn’t used for anything at the moment – I tried to register the task name, but didn’t get a reply, so when I try again, I’ll request a message ID as well), that will cause it to capture the window at the top of the window stack. I’ve also bodged a module together (based on the demo) that provides a * command *tabbyCapture that sends the message (in the tarfile on my website, the module is hidden in the !tabby directory as it is isn’t a finished feature).

I was hoping this could be used to make an obey file that opens windows (using WindOpen) and then capture it, but the problem seems to be that, even using wimptask, the window hasn’t actually opened before the message is sent. Not sure that is fixable. It does mean that another task can ask !tabby to capture windows. It wouldn’t be difficult to extend it to give the window handle and specify which !tabby instance should capture the window.

The Wimp message is a good idea, and should definitely allow for the window handle to be passed, along with any other settings that Tabby may offer.

The star command I am not so sure about. Any Wimp task can always send a message, but I’m doubtful as to when the star command would be useful. (Partly because I’ve never used WindOpen so I’m not sure what that’s capable of.)

If you’re wanting to be able to capture a load of windows automatically, it might be good if you can tell Tabby to always capture windows from particular tasks (where the window titles match a regular expression, perhaps). To implement that you may just be able to keep an eye on the window stack during null polls, or you may want to look into a Wimp filter in your module which can do the capturing by sending the Wimp message to Tabby when matching windows are first opened.

Thanks! The WIMP filter looks very useful, especially for the IDE, I will certainly investigate that.

The idea for the star command was so that an obey file could be used to set up a project in !tabby, but also to see if I could automate regression tests so that I could use WimpOpen to open windows and move them about, but it would also need some other facilities (such as being able to click on a particular icon). I might work on that a bit more, but the trouble seems to be that the WIMP events don’t happen until the obey script finishes. I’d not done a great deal of GUI programming before and my testing evidently isn’t very good!

!tabby currently uses timer events for most things because I was concerned about the expense of monitoring the active window more intensively than necessary, but perhaps I should try monitoring them in null events and see if it makes a real difference. It might simplify the code a bit.

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

StrongED 4.69f11 works correctly with Tabby, 4.70a13 does not. Oddly enough this is because 4.69f11 has one bug more. :-)

There was an obvious, but harmless, bug in 4.69f11 dating back to Guttorm’s last release. This bug was fixed in 4.70 but it exposed another bug that was far less obvious.

The exposed bug went unnoticed until Tabby came along and proved to be an inadvertent test case for it. The bug will be fixed in 4.69f12 and 4.70a14 releases.

a new version to github and my website that listens for a WIMP user message (0×5FFFFF for now,

Had a quick play with this. The format of the message isn’t documented so I used a message block with just the message number and no further payload.

With this, Tabby seems to always grab the top window. This is a problem as StrongED has panes that are above the main window. Tabby, rightly, ignores panes so nothing happens.

By designing a keyboard shortcut that turns the panes off and moves the window to the front first, I was able to send a StrongED window to Tabby. Made a second shortcut to turn the panes back on and it works quite nicely.

It needs more polish of course but it shows that an editor can get Tabby to capture a window by sending a message. :-)

Gavin, what’s the format for the *commands? It seems *tm1 takes an integer as argument (window handle?) and *tm2 a filename. Being able to send the window handle of the main StrongED window should make things easier.

Hi tm1 and tm2 are just the dummy commands from the demo program, they don’t actually do anything (I wrote a couple of modules in assembler about 20 years ago, but I’d never written one in C, so I started by hacking the demo about). I only got as far as adding the command to capture the window at the top of the stack yesterday, as proof of concept. At the moment, !tabby just responds to receiving the message, and ignores the rest of the block. I was thinking of requesting a single message ID when I try and re-register !tabby (and a file type for project files), and then have the first element of the payload being an action code. I’m working on another project today, but if I get it finished, I’ll have a go at implementing a message that captures a window given it’s window handle (and perhaps the !tabby instance to do the capturing).

Hi Fred, I’ve updated the message passing system and uploaded the code to GitHub (I’ll upload it to my website tomorrow). There are two new files, tabby.h and tabby.c, which will contain the message passing API for !tabby. I’ve made a function for sending the message:

/*******************************************************************************

Function    : tabby_sendCaptureMsg

Parameters  : wimp_t - handle of !tabby task
              int    - your reference.
              wimp_w - handle of window to capture
              int    - index of tab bar (starting at zero) 

Returns     : void

Description : Send a user message to !tabby to request that it captures the
              window specified by it's handle.  The second argument is a
              reference (not currently used).  The fourth specifies
              which tab bar should capture the window.  The tab bar index
              starts at zero, rather than one.  If the index is invalid, the
              window will be captured by the first tab bar; if no tab bar yet
              exists, one will be created.  If the window handle is zero,
              !tabby will attempt to capture the window at the top of the
              window stack (not yet implemented).  

*******************************************************************************/

void tabby_sendCaptureMsg(wimp_t task, int ref, wimp_w handle, int index);

The payload of the message is a reason code (0×00), followed by the window handle and the index of the tab bar, but hopefully this is abstracted well enough by the function in case the format needs to change later.

I’ve also updated the module so that it now only has the single star command

*tabbyCapture <handle> <index>

Hi Gavin and Fred
I will test this new version…
My main use of !Tabby is with StrongEd, very good tools.
Occasionally, using the search or function list, StrongEd ​​opens a second window of the same file.
This second file is not in !Tabby, if you close it you close the file and the one opened in !Tabby…

The bug will be fixed in 4.69f12

when ?

Hi,
I tested the latest version, no problem if you know the handle of the window you just opened.
I used a small program in Basic that I borrowed… from Fred Graute that I found on the forum

With some modifications I added it to !Diderot which I also had to adapt, it works just by clicking on the text file to open. (Note if you press ctrl at the same time as the click, the file normally opens in its own window.
Thanks to Gavin and Fred.

Tabby v 1.1.0
If I tab a NetSurf window, its horizontal scroll becomes small and restricted.
If I then tab an OvationPro window its full extent can be seen and scrolled whether portrait or landscape, and the Netsurf window becomes a bit wider but still restricted.
I I then tab a NetSurf window of ROOL’s site, I get the full width.
How is Tabby’s horizontal extent/scrolling so different in these various cases? It seems like the first window to be tabbed is restricted more than subsequent ones?
Oh, and the green button now goes straight to red though it turns amber and accepts a new tab if offered a window!
By the way, I really like this desktop widget and hope to see it fully fledged in due course.

Thanks Bernard, I’ll add those to the set of programs I use to test !tabby with.

!tabby doesn’t control the scrolling of the captured windows (except for storing their scroll bar positions while they are hidden). It only intercepts the adjust size icon. It tries to keep the windows the same size when switching between tabs (as otherwise it gets a bit distracting), but if the window refuses to change to the new size, then it readjusts to the size the window is willing to adopt, so a lot of it is down to what the task owning the window is willing to do.

I must be the only user of my program!Diderot: -(
Too bad it works very well et !Tabby allows better use of the desktop.

DDE + makefiles + StrongED + Tabby + Diderot = winner :-)

I must be the only user of my program!

No you are not, I am pretty sure there are at very least two users ;)

DDE + makefiles + StrongED + Tabby + Diderot = winner :-)

I would add also:

GCC + Makefiels + StrongED + Tabby + Diderot = winner

Now we just need Fred to help to disable StrongED indentation and I have a nice RISC OS IDE :)

I just don’t seem to be able to disable StrongED auto indentation and it’s really annoying because it does a really weird indentation :(

Thanks Paolo, users are welcome.

GCC + Makefiles + StrongED + Tabby + Diderot = winner

I forgot it especially since there is a makefile for GCC.
Another omission is !Reporter, indispensable tool…
Sorry if I forgot an app.
I’m going to update !Diderot on my site for the second user:-), I adopted !Tabby nice tool for an IDE.

Now we just need Fred to help to disable StrongED indentation and I have a nice RISC OS IDE :)

What version of !StrongEd are you using?

What version of !StrongEd are you using?

4.69f11

I think it’s the latest stable? Unless I have got lost with the updates as usual with RISC OS stuff… XD

I’m going to update !Diderot on my site for the second user:-)

Thanks, I have heard the 2nd user really appreciate that! :)

Version for !Tabby available here

Notes:
For !Diderot to work with !Tabby, this application must be launched.
!Tabby is not in this archive, see on this forum.
Thank you for testing and comments are welcome.

Hi Fred, I’ve updated the message passing system

Thanks Gavin. That’s made things a bit easier. I now have a nice toolbar icon to send StrongED windows to Tabby. Like Jean-Michel I needed a bit of external code to send the actual message but that’s fine.

Using the TabbyCapture command would have been even easier as it can be done entirely from StrongED but it doesn’t work reliably. It seems the module sends message &5FFFFF directly from the command handler.

However the command handler is called in SVC mode and not as a Wimp task. This means the message will be sent in the context of the current foreground task. If this happens to be a Wimp task then it works, if it’s a non-Wimp task then it fails.

The first of these two BASIC proglets doesn’t work (just a debug message is being output). The second one does work and shows the message to come from “ViewToTabby” even though it simply calls the *-command.

OSCLI("Do TabbyCapture <StrongED$Tmp_WorkView> 0")

END

SYS "Wimp_Initialise",400,&4B534154,"ViewToTabby",0

OSCLI("Do TabbyCapture <StrongED$Tmp_WorkView> 0")

SYS "Wimp_CloseDown"

END

You’ll need to alter the module so it uses a Wimp task to send the message, then it should work reliably.

@Jean-Michel

The bug will be fixed in 4.69f12

when ?

Not sure yet. The code’s done but there are some decisions to be made concerning modes and clipboard support.

DDE + makefiles + StrongED + Tabby + Diderot = winner :-)

You probably want DigDirSED in there too to be able to search through all files in the same directory as the current one directly from StrongED.

@Paolo

I just don’t seem to be able to disable StrongED auto indentation and it’s really annoying because it does a really weird indentation

Which mode?

Auto-indent is tied to the Return key. To change it you’ll need to edit the ModeFile for the affected mode and change the functions assigned to the Return key.

And, yes, 4.69f11 is the latest stable release.