ROOL ROM branding

I think it would be good to have special ROOL branding for RISC OS ROMS released by ROOL.

Currently the Iyonix name and logo appears on the startup banner and the Iyonix ‘jellybean’ is used as the switcher on the iconbar. These will look out of place and will be missleading on a BeagleBoard or a RPCEmu setup. Also, even on my Iyonix, I never really liked the jellybean. ;)

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

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

It uses the same font for “RISC OS OPEN” and the text below as the web site (Tahoma). I didn’t do a reflection on the ROOL cog, although the web site has one.

The big 3D cog was made quickly from the outline in the Drawfile available from the ROOL “Press material” page, in the documents section. (Well not that quickly, because Blender has a bad interface and I’d never used it before, but it can be done very quickly.)

The box with RISC OS version number and CTL copyright was just made up, cos I wasn’t sure exactly what would be needed. I guess that text would be drawn at the time of display, and not part of the image, hence the use of Homerton there.

For the iconbar switcher icon, I think a green 3D cog looks best, like I put on the above mockup, but smaller.

The point I’m generally driving at is I think it would look better if ROOL’s ROMs look like they are published by ROOL. Especially if we get new users with stuff like free emulator ROMs and ROMs for beagleboard and netbooks. Maybe the startup banner should have the ROOL web site URL, so people can see it and find this site.

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

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

If that doesn’t load, try refreshing. (My site blocks hot linking.)

Refreshing doesn’t work here. What did work was opening a new tab and manually copying & pasting the URL.

First impression: It looks gorgeous. Well done.

Following Jame’s advice by copying and pasting the link into a new tab, I saw your mockup.

I really do like the 3d cog. Very nice indeed. I personally don’t like the multi-coloured cog icon, but that’s just my own personal taste I suppose.

I agree with you though. It would be best to re-brand the ROMs. Perhaps a wider scale project could be started to co-ordinate a more system wide re-brand. i.e. A new ‘default’ system theme using the new Wimp Manager that James and co worked on recently.

It would make yet another differentiator against ROL’s version.

I included the multi-coloured cog because it’s ROOL’s logo, and my intention was to make a startup banner for ROOL ROMS.

I wanted to use the standard green RISC OS cog as a main feature, because that’s what best symbolises the OS nowadays, but I really don’t like the 2D one. (I think it looks a bit bland.) So I made a 3D version using the outline of the ROOL logo as as base. I think it has a clear enough RISC OS association.

For general window furniture, I’d ask Chris Wraight. His Steel theme has a nice clean look. I’m using his window furanture sprites on my desktop here:

http://www.smoothartist.com/riscos/screen.png

I definitely think it’s time RISC OS dropped the stone and paper background textures because texturing everything like that looks very dated. For file type icons, I think RISC OS 5 already has a nice set.

It may be a nice time to think about changing some of the default behavioural stuff too. For example, the iconise button on windows is seldom much use when you iconise to the pinboard, because if you have loads of windows open, you’ll never see the pinboard and if you don’t there’s not much call for iconising windows anyway. It works well when you iconise to the iconbar though, because that pops to the front when you move the pointer to the bottom of the screen. Also, that behaviour is a bit more like users from other OSes will expect.

Anyway, this has moved away from what I wanted to ask. What is ROOL’s opinion on rebranding the startup banner and iconbar taskmanager icon to replace the Iyonix heraldry? :)

I’ve been thinking for some time that we needed different branding, at least for non-Iyonix builds. I was even planning to ask for suggestions on these forums, but you’ve beaten me to it!

Having said that, I think we’re going to have to run the issue past Castle for a definitive answer.

I’ve been thinking for some time that we needed different branding, at least for non-Iyonix builds. I was even planning to ask for suggestions on these forums, but you’ve beaten me to it!

Heh, OK. :)

Having said that, I think we’re going to have to run the issue past Castle for a definitive answer.

Does anyone at Castle read this forum?

Michael: I think your cog graphic is really excellent, and the startup banner a huge improvement. My only query would be with the OS version box in the bottom left. As you say, this is just a mockup, but I think it would be better to match the background colour and font, in order to make a cleaner layout. But great stuff – looks really nice.

I am hoping to release another update to my desktop theme next week, which has been designed to work with Fred Graute’s updated Wimp in 5.14. If people generally like it, I’d be more than happy to work it up into a comprehensive replacement ‘look’ for the OS. It all depends on what people want (and Castle agree to).

Does anyone at Castle read this forum?

Possibly, although it’s not super likely they would post here. We’ve already dropped them an email about this so watch this space…

I am hoping to release another update to my desktop theme next week, which has been designed to work with Fred Graute’s updated Wimp in 5.14.

Nice I look forward to it. Did you ever do anymore work on that OS X metalic-like theme?

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

OK, great! Thanks Steve & Ben. :)

Chris: Yep, the reason for the OS version bit being in Homerton, because I expected that area would be left blank, and the text would be drawn by the Font Manager / WIMP or whatever when the startup splashscreen is displayed.

Otherwise you’d have to update the sprite every time you want to roll a new ROM release, with the new version number, and I guess there’s already enough to do when releasing a ROM. :)

The font for the other text “A fast and easily customised…” can easily be change to Homerton though. Anyway, maybe I’d do something a bit different. It all really depends on what Castle allow and what ROOL want. :)

I’m looking forward to the theme update, btw. I currently use your ToolSprites with:

WimpVisualFlags -WindowOutlineColour &292929 WimpVisualFlags -FontBlending

The only reason I use the FontBlending option is that the text on window titlebars is antialiased to beige for active windows and the active titlebar sprite is blue. Turning on font blending for the desktop does slow things down a bit though.

Is there any way to alter the flat colour for active titlebars, so without blending, I could make it antialias to the right blueish background colour? I’m not sure if that’s currently possible. Is Fred still developing the WIMP?

The only reason I use the FontBlending option is that the text on window titlebars is antialiased to beige for active windows and the active titlebar sprite is blue.

If I remember correctly there’s no need to specify -FontBlending as the Wimp will turn font blending on when it starts to execute WimpVisualFlags. In fact, there no code attached to -FontBlending, only -NoFontBlending is acted upon.

Is Fred still developing the WIMP?

Not at the moment by I’m hoping to do some more work soon (also to Filer and Pinboard).

Fred, great to hear you will be doing some more work on the Wimp and Pinboard and Filer in the future.

I have an idea for an improvement to RISC OS that touches on all three areas of your work: It is the ability for filer windows to open as child windows within one main window within the desktop. This main window can be moved, iconized etc… They net effect of this would be grouping of filer windows within RISC OS.

This would allow a user to position filer windows anywhere they want within the main window (as per the desktop now) but can quickly move them all out of the way if need be.

I only really need to have the filer windows open when loading and saving files, so this method would allow a me to unclutter the desktop very easily. Basically it would free up the desktop when the I’m working.

Maybe the way I use RISC OS is different to everyone else, but I know I would find it useful.

I’m just throwing this idea ‘out there’, to see what other users think of the idea. I think it would be useful. Sort of like a more advanced Windows Explorer really.

Thats all folks!

A new ‘default’ system theme using the new Wimp Manager that James and co worked on recently.

Modesty requires that I point out that I’ve contributed no code to the Wimp Manager (indeed I can only just about build the thing) and only a small amount of Basic to the Theme Manager

Is Fred still developing the WIMP?

Not at the moment by I’m hoping to do some more work soon (also to Filer and Pinboard).

I’ve done a small amount of work on the Filer, adding the -NoShift option to *Filer_Run (mainly for Alarm’s benefit), and tweaking the macros that generate the syntax error messages . This hasn’t been sent in to ROOL yet, would you like to synchronize this into your sources Fred?

I have an idea for an improvement to RISC OS that touches on all three areas of your work: It is the ability for filer windows to open as child windows within one main window within the desktop. This main window can be moved, iconized etc… They net effect of this would be grouping of filer windows within RISC OS.

One idea I’ve considered is to have a tabbed window manager. So a bit like a web browser, above the title bar you have a series of tabs, one for each window in the set. Clicking on a tab will iconise the currently visible window (or move it miles offscreen), and open the window corresponding to the tab.

The idea being you’d have several of these window stacks onscreen. So you could have a Zap window stack – rather than having the screen plastered with Zap windows you have one stack with one visible at once, and an easy ability to flick between all the Zap windows. Maybe new windows opened would be inherited by the same stack as the parent (or maybe not, or more complex inheritance rules). Each stack can mix windows from different applications. There would be simple drag-and-drop of tabs between stacks, and onto the desktop (where they’d become unstacked single windows). Windows could be easily dragged to join a stack (or via a menu over the titlebar, perhaps).

This could all be done by a third-party app with careful calls to Wimp_OpenWindow, so there’s not actually any need for OS support.

Sadly I’ve not got around to actually writing any code for it…

Fred wrote:

Not at the moment by I’m hoping to do some more work soon (also to Filer and Pinboard).

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

If I wanted to hide all the Filer windows at once I’d want a “Pin All” option, minimise the whole lot to 1 group icon on the iconbar (like addtinydir) or to the pinboard. Didn’t everyone give up on MDI interfaces years ago?

Having the window manager support tabs would be interesting, but how would the UI work? Possibly a “tab” titlebar icon that you could drag onto another title bar to group them? This would then add a tab above the title bar, kind of like BeOS, which could be used to switch, drag the tab order, or drag off the tab bar to change back into a normal window.

For tabs, I was originally thinking of abusing one of the existing icons with an Adjust-drag, perhaps put-to-back or iconise. But this was before the Wimp sources were available. So an extra ‘tab’ titlebar icon to drag would be much better.

I hadn’t seen BeOS’ tabs-instead-of-titlebars – thanks. I don’t think they can have multiple tabs for each window, so it’s not quite the same. Also, I don’t think this works on a non-raise-on-click system, because often in RISC OS you can’t see the whole titlebar so you can click on just the right end of it to bring the window to the front.

In my scheme, the tab bar would be in addition to the titlebar… a bit like a little ‘tool’ window floating above whichever child tab window happened to be open at the current time.

Then, as you say, you can drag around the tabs on the bar, drag to other tab bars (I think dragging into their child windows would be the same as dragging to the parent tab bar), or drag elsewhere to turn into a normal window at that location. Perhaps also iconised windows could be dragged onto tab bars to add them to that bar.

The problem with tabs taking up screen real-estate caused Apple to implement an alternative mechanism in the Safari 4 beta. The solution takes a bit of getting used to but works quite well and sounds similar to the BeOS reference above – the tabs and title bar are the same thing.

• http://www.ace-on-tech.com/wp-content/uploads/2009/02/picture-6.jpg
• http://mike-pulsifer.org/images/safari4/topsites.png
• http://www.screenshots-archive.com/files/images/Safari_4.preview.png

The close icon on the left of the tab shuts that tab, or the whole window if there is only one tab left. The triangular icon at the right edge of the tab is dragged to change tab order or drag tabs between windows; as with just about anything draggable in MacOS, the tabs act as proxies to the pages they represent, so they can be dragged into other places too (e.g. e-mail clients or the Desktop to insert / save links to those pages). Clicking on any other part of a tab brings it to the front. Dragging any other part of a tab moves the whole window. New tabs are added with menus, keyboard shortcuts or the ”+” icon on the right – easily visible here:

• http://tinyurl.com/orsahu

Positioning the close icon to the left of the tab is important. As with most tab implementations, the size of tabs shrinks as the number of tabs increases, until eventually there are too many to rationally fit in the window width, so some kind of overflow marker is shown on the far right and a scrolling mechanism, menu mechanism or combination of both gets used to access the extra tabs. When closing the tabs later on, since the tab widths change, the right edge position of a tab continuously moves. This makes it frustrating to “chase” close icons if shutting a lot of tabs with the mouse. When the close icon is on the left, the leftmost tab will always have the icon in the same place, so closing multiple tabs with the mouse (provided you want to close leftmost items!) is easy.

In RTL languages this ordering should swap over, but since RISC OS has no proper support for right-to-left it’s not really an issue there.

Other features of the beta include a CoverFlow approach to visualising history and bookmarks and the “favourite sites” welcome page (which is an obvious rip-off of Opera 9’s Speed Dial). This kind of stuff shouldn’t be dismissed as just meaningless eye-candy – experimenting with different ways of visualising data can only be a good thing in the long run (just look at the neat approach taken by NetSurf for its branched visual history, as an example of another approach).

• http://davetheroyale.files.wordpress.com/2009/03/safari4_2_history.jpg
• http://tinyurl.com/onappt

I like how the tab system is done in the safari 4 beta it make’s sense to combine the title bar with the tabs to reduce the amount of space taken up on the screen. This approach would certainly get my vote for a change to the windowing system.

How are the changes that are put forward decided upon in the end?

Do the ROOL founders have the last say once something has been put passed castle?

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.

The Mac tabbing system looks interesting, but there’s one drawback when implemented on RISC OS.

On most other OSs, the titlebar has two functions. One is to tell you the name of the window, and the other is to allow you to move the window around. Neither of these need the whole width of the window, which is why OSX and BeOS have added another feature to this space.

On RISC OS it has a third: to bring the window to the front. Other OSs have raise-on-click – you can click on any part of the window, so the titlebar isn’t important for this.

What I’d worry about a tabbed system is that you have window stack A behind window stack B. You want to flip to window stack A, but you can only see a small portion of the tab/title bar. But if you click on the tab bar that’s showing, you’ll pop stack A to the front and switch to whichever tab you clicked on.

Here’s a typically cluttered RISC OS desktop:

http://www.virtualacorn.co.uk/screens/screen1.gif

Imagine if the Filer window containing Chars and SciCalc had three tabs, and we were looking at the leftmost tab 1. The piece of titlebar showing would belong to the rightmost tab 3. How do we bring this window to the front without also flicking to tab number 3? (Let’s assume for the sake of argument that the menu showing was instead another window so it didn’t disappear when you clicked)

A toolbox gadget is an interesting idea… I didn’t think of that. Would that be something developers would have to use for it to happen? I was assuming that a bit of Wimp filtering would suffice to apply it retrospectively to existing apps.

Theo wrote:

Imagine if the Filer window containing Chars and SciCalc had three tabs, and we were looking at the leftmost tab 1. The piece of titlebar showing would belong to the rightmost tab 3. How do we bring this window to the front without also flicking to tab number 3

A couple of options spring to mind -

1. Tab switching only happens if the window is already unobscured (fully visible) – obvious pitfalls with that though
2. Tab switching requires a double-click on the tab

Double clicking would work reasonably well. Do you think that would be obvious enough to users? There’s nothing else in the window management that requires double clicks.

Another issue is the drastic foreshortening of titles – programs like Zap put the whole pathname in the title, and that’s the only place you see it. If you’re editing several similar !RunImage files, for example, the path in the titlebar is the only thing that distinguishes them. So maybe you either want a way to pop the full titlebar to the front temporarily (how?) or an option to run with tabs not obscuring the titlebar.

Firefox is a useful way to play with a practical tab system. As you say, having the close icons line up when tabs are closed is much easier. FF3 puts the close on the right, and so when you close a tab halfway along the screen then the next close icon isn’t lined up.

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.

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

(Before anyone gets too carried away, I should probably mention I don’t have a whole lot of time to implement anything for the moment)