Well you can’t have it both ways :-) – if it isn’t obvious to users (and it might not be) then another mechanism, e.g. option 1 above, would have to be used.

You could turn it around and have a keyboard modifier which causes the window to be brought to the front without the tab being selected. This is perhaps more “RISC OS-like”; the default behaviour is workable and reasonably intuitive but not always what you want (e.g. inadvertent tab selection), so add a modifier for more advanced users (e.g. Shift+Click => bring to front without selection). Make sure !Help tells people about it.

programs like Zap put the whole pathname in the title, and that’s the only place you see it

This may be a good example of an application where tabs-in-titlebar does not make as much sense. Conventional tabs, showing a leafame only, might be one route (the containing window still shows the full pathname). A drawer approach, again from Mac OS, is a mechanism that might be used. MDI is another, discarding tabs in favour of a collect/tile approach. Or show the pathname somewhere else! Help-style tooltips shown when hovering over a tab could give the extra information (speech-bubble style, hovering above the tab if the window is far enough away from the top of the screen, or hovering below it if the window is near the screen’s bottom edge). A status bar could be used to show the extra information. There are hundred different approaches and the way to choose from many of them may be dependent upon the application at hand.

At least by right-aligning the title string, the leafname part would be shown; the tab minimum size might be set manually or automatically “somehow” to make sure at least that was visible. In Safari’s tabs-in-titlebar, the currently selected tab is also made wider than all the others, so more information can be seen.

A more integrated solution in Mac OS is implemented through “proxy icons”. Any window representing a file shows the leafname and file icon in its title bar. This icon is actually a proxy for the document itself. Right-clicking (or MENU-click for RISC OS) opens a menu where each menu entry represents initially the file at hand, then its container directory, then the level below that, etc.; it even works for web sites by stripping back the path until you’re left with just the host. The services are provided by the window manager so applications require almost no coding effort to support it. IIRC something like !Director and maybe !TreeMenu offered this as a hack – some modifier click on title bars caused the code to extract the pathname details and show the menu. That would of course fail if you didn’t show the full pathname anymore; but if the window manager offered the feature instead, it might not matter so much (and besides, a right-aligned title text approach may allow the best of both worlds).

I’m not that keen on FF3 scrolling behaviour…

It’s a bit clumsy. Safari uses a pop-up menu instead. A standard RISC OS pop-up menu icon could show to the right of the tab bar, so your right hand toolset would presumably contain the optional toggle size icon, menu icon, ”+” (add tab) icon then tab data. The menu may as well always be present and could offer submenus for tabs to let you close them, switch to them, pop them out into another window etc. etc. so that mouse dragging and clicking within the tabs would not be needed.

Safari suffers when you switch to a tab which is “out of view” (off to the right) via the menu; the tab bar doesn’t scroll, so none of the visible tabs are selected. The user knows what’s going on because they consciously selected a tab from the pop-up menu, but it’s still pretty lame (e.g. how can you now close the tab, or drag it to another window?). If tabs were to re-order, it could be confusing. I reckon there may be no choice but to implement some kind of scrolling approach, but I’m not sure how it would work smoothly, especially in a title bar context.

Maybe having a favicon-style small application icon on the bar to help identify tabs is useful?

Favicons in most cases would be pointless because the icons would all be the same (e.g. Filer; I suppose StrongEd et al could use a document filetype icon but it’d be text most of the time; only a web browser would be likely to benefit and then not much). A reasonable approach might be to provide a SWI call / other interface which lets an application specify additional decorations (e.g. in the form of pointers to an icon block, or even a window description) and indicate their alignment relative to other tab data.

Ben wrote:

I think the logical way to implement such a tab system would be as a new Toolbox Gadget type, utilising furniture windows that overlap the window’s title bar. That would also have the advantage of working on Wimps back to the old nested Wimp and therefore work on all versions of RISC OS from 3.10 onwards, including ROL’s fork of the OS - making it all the more likely to be embraced by application developers.

All good points, but it would break titlebar-based extensions like !Director and other window enumeration mechanisms wouldn’t treat the windows as separate, when you may (or may not, confusingly!) want them to.

If these were actually genuinely separate windows, just collected and managed together “as one” by some magic flag or SWI or whatever, then a lot of the existing window management tools and desktop extensions may behave more sensibly. If we were to choose an implementation that breaks significant numbers of such utilities then we ought to make sure that something roughly as good (or even better!) is implemented within the OS directly, so that the non-functioning extension is no longer required anyway.

Just in case it is unknown here, there is a Tabs toolbox module already, http://homepage.ntlworld.com/rik.griffin/gadgets.html . This allows tabbing between toolbox windows.

Tank

All good points, but it would break titlebar-based extensions like !Director and other window enumeration mechanisms wouldn’t treat the windows as separate, when you may (or may not, confusingly!) want them to.

Would it? When I said “furniture windows” I was meaning that special category of child windows that overlap their parent’s window furniture. Anything that merely enumerates the top-level window stack wouldn’t see these at all.

Presumably some of them operate by filtering clicks on the title bar. If you obscure the title bar with something else, those clicks never happen.

ou could turn it around and have a keyboard modifier which causes the window to be brought to the front without the tab being selected. This is perhaps more “RISC OS-like”; the default behaviour is workable and reasonably intuitive but not always what you want (e.g. inadvertent tab selection), so add a modifier for more advanced users (e.g. Shift+Click => bring to front without selection). Make sure !Help tells people about it.

That’s a good idea. That would work. It might also be nice for the extra buttons on 4/5/6 button mice to do Shift-click/Ctrl-click so you don’t have to use the keyboard if you don’t want (fitting into the paradigm as a bit like Adjust – does the same operation but in a slightly different way).

1. Windows are real windows, with real titlebars. They will operate just fine if you peel them from the tab stack
2. Tabbing is handled by some outside tab manager. The application doesn’t (need to) know that its window is part of a tab stack. The window itself doesn’t operate any different. Maybe the Wimp doesn’t know anything about the tabs either.
3. Windows from different applications can be mixed in the same tab stack
4. Windows retain their individual sizing so you can pin, say, a spreadsheet and a calculator together. That may feel a bit odd but it’s better than expanding the calculator to full screen width.

I was aiming for user-defined stacks. So you can pin, say, your spreadsheet, your calculator and your accounts file together. And then in another stack you can pin your HTML editor, your FTP client and your web browser.

Some Director-style popup menus for tab control would be very useful – that’s how I manage most of my windows at the moment. It would be necessary for those to be tab-aware.

Presumably some of them operate by filtering clicks on the title bar. If you obscure the title bar with something else, those clicks never happen.

But clicks/drags on the window furniture don’t generate Mouse_Click events, so there’s nothing to install a filter on. All that the application (or by extension anyone that installs a filter on it) ever sees is Open_Window_Request events, and there’s no way those between ones caused by clicks or drags on the titlebar from clicks/drags on the adjust-size icon, or the scroll bars, or the fact that the user has just changed screen mode.

Well Director seems to manage it. Click Menu over the Close icon and you get a different menu from that if you click Menu over the titlebar. I’m not sure how it does it, but the source is available.

[has a look]

Looks like it sits on MouseV, and filters clicks. On each click it calls Wimp_GetPointerInfo to read the icon number (or an error, if you’re not in the desktop). Then it can discriminate between window furniture.

I’m not that keen on FF3 scrolling behaviour… it’s a bit clumsy with lots of tabs, but I can’t think of any way to do it better. It is scrollable with a mouse wheel, which is nice, but only if the tab bar has focus.

For completeness, note the KDE mouse wheel behaviour – scrolling in a window will give it focus (and scroll it if possible), but doesn’t bring the window to the top.

For completeness, note the KDE mouse wheel behaviour – scrolling in a window will give it focus (and scroll it if possible), but doesn’t bring the window to the top.

On RISC OS, the scrollwheel scrolls whatever is under the pointer, without giving it focus and without bringing it to the front. At least, that’s what happens on RISC OS 5 here, and it happens on my VRPC Adjust, although I might have had to configure that behaviour on ROL OS.

I think it’s the least invasive and most functional way of doing things.

I think it’s the least invasive and most functional way of doing things.

To us die-hard RISC OS users, that may well be true. And I’m not arguing advocacy of any particular method, just pointing out the larger picture given the context of tab scrolling which was mentioned. What’s important to realise is what Andrew H. noted earlier – in RISC OS, you explicitly need to click on the title to bring the window to the front (although many, including me, use the MoveWin module, which lets you ctrl-shift-click to drag a window around or bring it to the front). In KDE, and most elsewhere by default, just clicking on a window brings it to the front.

Probably the RISC OS way to new users is a bit strange (although arguably much more consistent when considered with the right click variations). And RISC OS 6 et al does have a ridiculous amount of Window Manager configurability. Of course, I’m not fan of endless configuration options, but having people attempt these features is a good way to get them familiar with the system, and to consider all the matters in a practical context.

As a final note, “non-nativised” (to make up a term) ports like Firefox, are a particularly good way to break RISC OS UI consistency, even if it’s just for scrolling and such. Any such discussion should take such things into account.

We’ve already dropped them an email about this so watch this space…

Was there any response from Castle?

There’s nothing on the subject in the Castle non-commercial licence .

I haven’t review this in a while, and I’d like to note some problems with it (IANAL) especially in light of things I recently mentioned. The context I’ve quoted is very selective, so read the entirety

1.2.3 ”... distributed … at no charge…”.

Well yes. Clearly the intent here is that the product not be sold – section 2.4 is much clearer about this and 1.2.3 doesn’t say anything useful that 2.4 doesn’t – but it doesn’t exactly mention who should be charged. For example, it definitely costs to hosts the source. As a more meaningful interpretation, it could mean that contributors could be banned from receiving donations for their efforts.

2.2 “You may not impose .. RISC OS .. any restrictions other than those set out [here]”

Not very helpful. The implication of this is that all of “RISC OS” (whatever the definition of that is) all falls under the CTL licence, which is clearly not true. The paragraph should simply mention “Derivative works”, of which this licence has a much better grasp of than ROL have demonstrated publically recently.

On an incidental note, I would still like to see a categorization of who owns what when it comes to “RISC OS”. The ROOL sources are an excellent start for that (because they are already split in the source code directories and most files contain an explicit copyright), but is not very convenient for causal browsing.

1.2.3 ”… distributed … at no charge…”.

Well yes. Clearly the intent here is that the product not be sold – section 2.4 is much clearer about this and 1.2.3 doesn’t say anything useful that 2.4 doesn’t – but it doesn’t exactly mention who should [not] be charged. For example, it definitely costs to hosts the source.

I assume you meant to insert the “not” where I have done for you. IANAL either, but I think you’d need to read 1.2.3 in a rather twisted way to interpret as a demand that you don’t incur costs upon yourself during the process of distributing the software.

In my opinion, it means that once you have distributed RISC OS or a derivative work, you must give any third party at least the option to receive a copy of the same at no cost to the recipient.

I know this may sound at odds with ROOL’s practice of selling CDs containing sources and binaries at shows, but we do also publish all the same data via our website and we try to remind show visitors that they do have the option of downloading the same thing for free.

It’s true that hosting the source code incurs costs, but by acting as a central hosting point, ROOL only incurs these costs once, and can also pool the funding from those who feel that they can best contribute to the project via financial contributions. We also happen to feel that it’s in RISC OS’s best interests to avoid any further forking of the source tree, and this works well with the idea of a central host. But the licence is worded to give everyone the confidence that were ROOL to cease operating that somebody else could take over our role.

I would also disagree that 1.2.3 doesn’t expand upon 2.4. 2.4 only applies to hardware: for example, by itself, it wouldn’t prevent someone from uploading a RISC OS module to a shareware website that requires payment before you can download it.

As a more meaningful interpretation, it could mean that contributors could be banned from receiving donations for their efforts.

I wouldn’t interpret it that way. Most of the conditions do not apply until you distribute a derivative work. A bit like the GPL, you can charge as much as you want until that point for the effort you’re putting in. But unlike the GPL you can’t then choose to whom you distribute your derivative version, and you’re also obliged to make it available for free (with GPL, market forces usually achieve the same thing).

2.2 “You may not impose .. RISC OS .. any restrictions other than those set out [here]”

Not very helpful. The implication of this is that all of “RISC OS” (whatever the definition of that is) all falls under the CTL licence, which is clearly not true. The paragraph should simply mention “Derivative works”, of which this licence has a much better grasp of than ROL have demonstrated publically recently.

Well, “RISC OS” is defined at the top of the licence, although it is a somewhat circular definition. Arguably, you could pull out revisions of one or more modules where copyright is purely owned by Castle and distribute that as-is, and it would count as “RISC OS” and not a derivative work, so I think the words “RISC OS” do need to be there.

On an incidental note, I would still like to see a categorization of who owns what when it comes to “RISC OS”. The ROOL sources are an excellent start for that (because they are already split in the source code directories and most files contain an explicit copyright), but is not very convenient for causal browsing.

Producing a list of who owns what would be a long and complicated task – and for the most part not very useful. What matters is that Castle either owns the code (and therefore gets to choose how it is distributed) or has acquired the right to distribute the code from the copyright holder.

To expand on this, all the BSD-licenced code in the Internet stack, the USB stack, the nVidia driver and so on is still owned by the original authors, but the authors have chosen to licence it to anyone under the (relatively unrestrictive) terms of the BSD licence. Any changes to those files made by people under the employ of Acorn/Castle/etc are owned by Castle.

There is a small amount of GPL code in the source tree, which also remains owned by the copyright holder(s). However this is only used in build tools or in debug libraries. Because of licensing conflicts between the GPL and Castle licences, it is important to note that nobody is permitted to distribute debug builds of any RISC OS components that use these libraries. (Note that you can build and use them yourself without incurring this conflict, you just can’t distribute them further.)

Software written by ARM and ANT is supplied under other licence terms currently incompatible with the shared source licence, which is why certain modules are currently supplied in binary form – we are working on renegotiating these. The Squash module is a bit of a sticking point, since we can’t contact Jon Thackray, the copyright holder of part of the code – most likely we’ll eventually need someone to do a cleanroom reimplementation of the affected files, probably based upon the public domain Unix “compress” utility source.

There are a number of other licences scattered through the source tree (although there shouldn’t be any within the “castle” directory of the repository). ROOL has been checking them as we went through the slow process of auditing the code for release. We’re happy they’re all compatible with the shared source licence – if you want to use them under different conditions, you’ll just have to audit it yourself.

Ownership of any code in the published source tree marked as copyright Acorn Computers Ltd, Element 14 Ltd, Pace Micro Technology plc, Tematic Ltd or (dons flameproof jacket) RISCOS Ltd is, to the best of my knowledge, now transferred to Castle.

Any contributions that individuals have contributed to ROOL remain the copyright of those individuals. However, by passing those contributions to ROOL (or anyone else), they are implicitly indicating that they are granting Castle the right to use and distribute those contributions effectively as though they were a part of RISC OS.

Is that enough information? This really is a very tedious subject.

Is that enough information? This really is a very tedious subject.

For now, yes. It may be tedious to you (understandably), but I’m not sure it’s been laid out like this to date in a public forum. I wouldn’t continue to press the matter if I didn’t think it was important – i.e, ROL’s claims of ownership, or the wider issue of what can and cannot be more widely used under certain circumstances. For example, replacement of certain RISC OS elements (as Graham Shaw has done) and how that might impact matters.

I’m hoping someone else might take this detail even further, but probably the number of people who find this interesting or who have the right background is small.

ROL’s claims of ownership

...are just that – claims. Nothing more. They have no meaning and really don’t deserve further debate IMHO.

Cool. What sort of changes do you have in mind? :)

Below is a list of things I intend to look at although I doubt I’ll be implementing all of it, certainly in the short term. If anyone has any favourites do let me know, it might help prioritise things. Also, if anyone is interested in working on any of these (alone or with me) then please get in touch.

Filer

• Keyboard support. The two main questions here are how close do we want to follow ROL and has anyone done any work on this yet (it was mentioned a while ago)?

• Display Filer object in columns rather than rows. I’ve done some work on this when last I worked on the Filer and have got code to do this but it’s very much hardwired ATM and needs (a lot?) more work to be usable and configurable.

• Allow Filer objects to be sorted in reverse order. Haven’t looked at this in detail but it seems to be using OS_Heapsort with custom comparison routines. So it may be as simple as switching over the inputs, or not of course.

• Make doubleclick-and-hold configurable. It should be possible to turn doubleclick-and-hold on/off and the time the second click needs to be held down for should be configurable.

Pinboard

• Doing a ‘Select all’ on the Pinboard when there are lots of icons (>100) is quite slow. The reason for this might be that the Pinboard does a SWI Wimp_SetIconState on each icon causing lots of small redraw rectangles to be created.

  It might be better to simply calculate the area that needs to redrawn. IIRC the Wimp will squash redraw rectangles that are completely overlapped by another rectangle (can anyone confirm this) so that might be a lot faster.

  Better still would be if SWI Wimp_SetIconState was extended such that you could update the flags without generating a redraw. So, that’s something else to think about.

• Currently the Pinboard maintains two icon lists, one for pinned Filer objects and another for iconised windows. It seems that some work has already been done towards this but the actual merge has yet to be done. It would clean-up the source quite a bit and simplify it in places as well but it’d be a considerable amount of work.

Wimp

• Add icon border shading so that buttons can be tied in with a theme. I’ve already got a hardwired version, all that needs to be done, is to work out an algorithm to allow this to be done dynamically. The configuration will probably follow ROL’s way, not ideal but compatibility is paramount IMO.

• Look into the recaching of tool icons. At the moment the Wimp seems to be recaching much more often then it needs to. Simply selecting icons on the Pinboard cause the tool icons to be recached. As far as I can see this only needs to be done when there is a change to the display, mode change, palette change, etc.

Hi Fred!

That all sounds really good. I’d love to see icon border shading – I’d definitely extend the Theme Manager scripting to cope with that, and it would be the final element needed to produce truly comprehensive skinning.

Filer keyboard shortcuts would also be great. I’ve no experience with ROL’s implementation, but I think compatibility is generally the way to go: I’d guess that several RISC OS enthusiasts may well want to use a Select/Adjust machine as well as an RO5 box, so keeping things consistent would be good (unless the ROL implementation is seen as being deficient).

Enjoying the new StrongED, by the way!

Agreed with the comments from Chris – for keyboard shortcuts in the Filer, we should use the same ones as ROL or it would drive people mad if they have both an Iyonix and a RiscPC/A9home running ROL RISC OS!

I’ve not played much with the ROL keyboard shortcuts in the filer. I hope you can use cursor keys to move a highlight around, run, copy or move the selected objects, some key to to select/deselct – that kind of thing… if that’s not implemented in the ROL version, I’d say it’d be a big plus doing it in the ROOL filer as that’s the type of thing I usually want to do but can’t with QuickFiler.

Another trivial (I hope) Filer change I’d love is in the “Create directory” menu; I’d love to be able to create “foo.bah.wibble” and the whole directory structure gets created if it’s not there (similar to mkdir -p).

I’ve no experience with ROL’s implementation, but I think compatibility is generally the way to go:

I don’t have any experience with ROL’s implementation either but I agree with you on the importance of compatibility. (If someone could send the list of keys that ROL’s Filer supports that’d be a great help.)

Another trivial (I hope) Filer change I’d love is in the “Create directory” menu; I’d love to be able to create “foo.bah.wibble” and the whole directory structure gets created if it’s not there (similar to mkdir -p).

I’ve had a quick look at this and it’s not quite as trivial as hoped. It works if you enter a full path but not if you enter a partial path. The reason is that the code assumes that if it’s not a singular leafname (ie no dots) then it must be a full path. Your suggestion makes that assumption invalid so we need a new way of working out if a full path has been entered.

Here’s a screenshot showing a directory viewer with files arranged in columns and in reverse sort order. Still a long way to go before it’s all neat and tidy but it’s a start.

Great, I always wanted the filer to arrange items in columns. Especially in ‘full info’ and ‘small icons’ views. :)

I made a really quick mockup for a new start up screen:

http://wii.smoothartist.com/riscos/mockup.png

[snip]

Also, I’m not sure if ROOL are allowed by Castle to change the branding. Any thoughts?

Did Castle ever reply?

I hope they did – a smart new splash screen would be nice. I like your initial design. If you’d like to collaborate on producing a finished version, I’d be happy to help.

Sure that would be great.

At the moment, I’m really just waiting to see what CTL say.