Haiku Deskbar graphical update - see pictures

1

Morning / afternoon / evening.

It is no secret that eye-candy adds to the appeal of an Operating System (just ask Apple). Haiku has gorgeous scalable vector icons on the Desktop, but the Deskbar itself is still stuck in a 16x16 world. Considering that more and more people are getting exceptionally large monitors, its time Haiku Deskbar joins the 21st century, at least on the graphical eye-candy front.

I have written a proposal with several nice mock up pictures of a vector icon based Deskbar (the mockups are so hot, they should be rated 18+). Have a read, enjoy the screenshots, and please provide feedback so that we can make the best looking Operating System ever made.

http://www.users.on.net/zenja/haiku/Haiku_Deskbar_RFC.pdf

Please post feedback on the Haiku website forum (http://haiku-os.org/community/forum/haiku_deskbar_graphical_update_see_pictures)

2

Interesting…a first reaction:

I hope the greyness of the greyed out phase can be set by the user ‘from none to black’.

On Mac OSX, the ‘greyout’ turns quite dark, but that doesn’t really matter, because at the same moment the OS switches to a fundamentally different state.
This new state is all about displaying and nothing else, because the greyness disappears when you want to go from ‘using your eyes only’ to ‘starting some interaction with a mouse’ again.

In your example there are still clickable icons in the greyed out state, and they are still in a grid, just like in the Desktop icon arrangement underneath.

This makes it psychologically harder to accept the sudden greying out of a significant percentage of the user’s screen, compared to the Mac OSX situation.

Providing a ‘greyness-slider’ will then enable the user to set a value below his/her irritation level for this situation.

3

To be honest, I find the proposal too radical, and I don’t immediately see the big benefits.

  • I agree that the Deskbar should make use of scalable icons, they should adopt in size to the current system font. In fact, I believe the current system font size should be the only way to adjust the overall size of interface elements on Haiku.

  • I agree the usability of the Deskbar can be improved. I am using the Deskbar since 1998 and I am quite happy with it. But I am not using one feature of it enough, which is launching application from the Be menu. I believe the reason is that access is not quick enough for me. To address this, I would copy Ubuntu’s (or Gnome’s?) solution and make the application categories available at the top level. Ie, instead of having one Be menu with Applications, Prefernces etc. as sub menus, Applications and Preference itsself would be at the top level. I would put Applications in the screen corner, since it should be the most frequently used.

  • To address your concern about saving screen space, I am using an application called “DeskbAct” since a couple of years. It will raise the Deskbar to the top of the window stack after a very short timeout when you hit the screencorner with the mouse. It does the same for Workspaces if it is running. This works very well for me, much better than the autohide feature of the Windows taskbar. My girlfriend has turned that on (I never would), because her screen is quite small. The problem that renders this Windows feature totally useless is that the Taskbar quickly hides again when you leave it with the mouse accidentally. Which is very easy to do considering it is only a couple pixels high. Then I find myself repeatedly trying to click something in the Taskbar for two or three times becoming quickly frustrated. Back to Haiku: I would include such an autoraise feature like DeskbAct (default on) with Haiku.

To sum up, yes you make some valid points, but I would address them with small changes instead of a complete overhaul, since the Deskbar works so well for me as it is. I see some problems with it, but they don’t justify big changes from my point of view. At the same time, we can improve the Deskbar’s look of course to give it a fresher look. This can be done simply by tweaking the borders, using some gradients, having bigger icons according to font size and so on.

Best regards,
-Stephan

4

I have to agree with Stephan, they are radical, but I think something has to be done, and soon. I once used BeOS much for its beauty, today it looks old when I compare it to systems like Vista and OS X. Whatever happend to the Art group? There were some really nice suggestions there.

I think Haikus problem is that there are small group of people working active on the inner core of the system. It feels like that group doesn’t wan’t to change the look. They are happy with the old look that was so nice 1996, but 11 years later it’s obsolete. New icons are nice sure, but the rest? Buttons, Radiogroups, Scrollbars [Insert something from InterfaceKit]

Is it to early to change the look? Is that something that MUST happend after R1? If you want to attract new people, start to attract the old BeOS users out there, give us something new. And Stephan why dont you do something radical and redesign the whole look, everything you do, looks good (IMO). If you and some other artists togheter worked something out I bet the OS would gain a few more users.

“She looking good, for beauty we will pay” - Kraftwerk 1978
/Konrad

5

Yes I even made some mockups already. But believe me, there are more important areas right now. First things first. We also have to think about who we need to attract at which stage of development. Right now, it would help the project to attract more developers, and for that, the looks are not as important as a stable system and to deliver on some of our promises with regards to living up to R5.

Best regards,
-Stephan

6

Hmm, this is interesting. I’ve started playing with a prototype to see how demanding the graphics are.

I’ve created a simple function to draw a hardware overlay.

void BackgroundView :: DrawDarkOverlay()
{
rgb_color black = {0,0,0, 232};

SetDrawingMode(B_OP_ALPHA);
SetHighColor(black);
BRect aRect = Bounds();
FillRect(aRect);

}

It draws a nice transparent view. However, running Zeta on VMWare, and the drawing is almost instant. According to Eric Petit (the author of the VMWare video driver for BeOS), the only hardware acceleration the driver offers is “it only implements RECT_BLIT”. As I said, running on VMWare on a MacBookPro (1440x900), and the FillRect function is instant.

I tried the same code on real hardware with nVidia 7900GT video (the driver included with Zeta, which is the Rudolf / Euan driver), which has quite a bit of acceleration (the 2D desktop is very smooth, video overlays etc). The FillRect() function is much slower, so much slower that you can physically see the screen being filled from top to bottom. This is on a 1152x852 desktop, so its drawing even less pixels. Both boxes are running a dual core CPU (one is AMD, the other Intel).

The only logical conclusion that I can muster is that the nVidia driver doesn’t offer the only accelerated function the VMWare driver has, which is RECT_BLIT.

Should I ignore this setback for the time being? It’s really ironic that emulated Zeta runs faster than the real thing. Anyone care to comment?

7

Say… can you post more info/screenshots than a PDF? (Adobe Acrobat seems to consistently BSOD my comp every time I open a PDF.)

8

Would you mind sharing thoose mockups? Its a pretty easy task to change the look of a GUI, so by showing them it might attract new devs aswell. Just a thought.
/Konrad

9

Hi Zenja,

yes I can comment. Filling a rectangle with alpha blending is not accelerated on any BeOS/Haiku driver. Only solid rects are possibly accelerated. To fill a rect with transparency, the graphics buffer’s memory has to be read by the CPU, modified and written back. The reading part is exceptionally slow when the memory has to be accessed over the PCI bus. This is why it is so slow on real hardware, and fast enough in emulation. You will see the same speed like in emulation on systems with a shared memory architecture, where the graphics card uses normal system RAM for it’s frame buffer. That being said, I optimized our alpha blended FillRect routine and on the system I have tested it, it was even about 20% faster than the original R5 routine. At a later point in time, we could extend the accelerant API with more accelerated functions, but I am not in a position to do so now.

Best regards,
-Stephan

10

The icons definately needs better grouping. As it is now, all icons float on top of the darkened background, and have equal distances to sourrounding icons, both vertical and horisontal. This means that grouping are done by logic alone, not visual cues.

Taking a cue from the gestalt laws, you could group by having a background plate for each row, by decreasing the vertical distances between icons on the same row, by having some sort of connector between them, or do everything all at once.

11

Did you have a look at the ‘EndSession.BeOS’ application? It uses the same (or a similar) screen effect.

http://www.bebits.com/app/3906

12

Just what I needed, thanks…very useful !

To others:
Since ‘DeskbAct’ is not on BeBits (directly), here’s where it can be found:

http://ftp.bebits.com/pub/mirror/beware/misc/

13

I have been using BeOS since R4 and have become quite fond of the Deskbar and Tracker. I think these changes force the user to lose application information ( open windows ) while performing Deskbar operations ( launching a new application or performing preference change). The current Deskbar will allow me to keep track of open applications while performing these tasks.

It also will require far too much mouse movement. I vote to keep the Deskbar as it is.

14

Yeah, I think what’s often bumped into, is the fact that BeOS got it so exactly right that the ideal solution is already implemented, needing no change apart from some (slight) cosmetic touches here and there.

15

I think it’s good to see somebody thinking about eye candy in Haiku. I know the OS is about speed but there’s no denying the fact that the interface is definitely dated these days - it still looks good, but it does look old. I agree that a more attractive interface will be key to drawing in new users.

There’s no reason we can’t keep the original look and feel for BeOS purists though :slight_smile:

I quite the setup proposed - it looks like a good system to me

16

Since this thread started with such radical ideas, why not go on with this line…
My 2c:

-do we need taskbar? why not use task switcher, like one in Beryl (Compiz-Beryl or whatever it’s now). It uses screen edges and corners, which are mostly unused as triggers. Mouse has usually 3 buttons, but they all usually have a function already. So by using screen edges and corners we get 8 new ‘buttons’. One could use it by just moving the mouse to the corner/edge of the screen and get a result (like in Beryl) or by moving the mouse to the corner/edge of the screen AND clicking some mouse button so the edge/corner is like a function key (like in RunIt, http://www.onlythebestfreeware.com/program.asp?program_id=33).

-do we need ‘haiku’ menu? why not use desktop like in XFCE? and if desktop is covered? well we could use one or more screen edges/corners as a place where one could always click with primary mouse button and always get a ‘haiku’ menu. it’s VERY easy to throw mouse cursor to th closest screen edge and click. (btw. also used deskbact ;). deskbact is not needed when one could set in system preferences that if there’s free edges/corners we could activate ANY application with this, be it Workplaces or any other.

-clock and tray? well, which part is unused usually in application windows? window’s top border. usually there’s application’s name and after that it’s empty eg unused, one could use this space very well… or these 2 components could be attached to the ‘haiku’ menu witch is activated from edge/corner. or maybe as a replicant that just sits there on the top or bottom edge of the screen, ‘always-on-top’, small enough to just cover part of the statusbar (of any maximized application)…

-about windows’ borders - from the practical point of view i didn’t personally like too much of the ‘beos’ type of windows’ borders. they gave the system unique appearance but weren’t very useful. i think having the window’s top border as wide as window is a much more practical solution. and maybe having different function on window border buttons depending on the mouse button used to click them (like in xfce, fluxbox for restore-maximize)? why not use right click on ‘x’ to not close the application but instead minimize/iconify it? that way we save some more space and use what we got more efficiently.

  • on switching workplaces… well ‘workplaces’ was the best in its time compared to any os using multiple worplaces/virtual desktops and it could be still used but i think something new is needed. one way is using xfce approach and use third mouse button for menu or maybe even better - to invoke ‘workplaces’ on spot but i think the best way is using mouse scrollwheel to scroll through the desktops/workplaces like xfce or beryl. one could just throw the mouse cursor to the screen edge, scroll just a click forward or backward and get to the prev/next workplace. and maybe we could invoke full-screen ‘workplaces’ even from some corner or edge of the screen with mouse? or maybe one could have instead of desktop wallpaper a ‘workplaces’ application on the screen, under desktop icons? well, mayb not that…

  • why so minimalistic? well, more and more people are using laptops and with small screen sizes it’s not very uncommon that 30-40% of the screen space is taken up by some unneeded junk. and linux desktops are a good example (be it with kde or gnome or even xfce/gtk) of wasting space. even windows has more space for work than linux. beos was good example of economical use of screen space - no unused gray areas no useless buttons (‘exit’ button? - WHY, if i have ‘close’ button on the window’s edge?) and so on, but it could be improved… i think that the best workplace/desktop would be without any distractions like blinking lights, windows popping up here and there and so on, but until the computers can read our minds, we could make the best of what we got. and we got more than we usually use…

btw. these solution should be implemented as OPTIONS, not the ONLY way. it’s good to have flexibility and options. and maybe someone likes blinking lights… :wink:

all in all, what this mostly means (i think) is that the desktop should have more ‘component’ approach eg one could use different tools to achieve same or similar functionality. and these tools for desktop interaction could be developed by any enthusiastic programmer and added to the selection of already existing set of tools, so the interface can adapt and evolve. and anyone can make and love their OWN haiku. but it’s the same haiku underneath. so there will be no (more) interface wars on haiku like some linux desktops had and still have… and in the end, eyecandy without usability is nothing (but maybe a pretty screenshot) and ugly workspace… well that’s like going back to windows’95…

I like your Christ, I do not like your Christians. Your Christians are so unlike your Christ. 
Mahatma Gandhi
17

I hate to leave a negative comment, especially since I made a Deskbar proposal in RFC section around the same time as you posted this, but this proposal kinda hits directly to my pet peeves. This comment is not so much about your proposal, as it is about a certain deeply rooted bad idea that I hope Haiku avoids. This also applies to any Tracker improvements.

Big icons in grid layout idea comes from the earliest GUIs. It was okay then, because the few files and applications people had were stored on diskettes. It was obviously bad later, in e.g. Windows 3.1, when number of applications and files increased with hard drive space.

Big icons in grid layout may look nice, but they are usable only when looking at thumbnail pictures. Icons do help to find a target among others, but only when every target has an unique icon (icons for folders in any kind of a menu serve no purpose). Furthermore, icons rarely communicate anything about the purpose of their respective applications. Icons only help recognition, application name can help understanding. This is why the name of an applications is at least as important as its icon.

Icons in grid layout forces users to seek in two dimensions and focus their eyes on each item separately, which is slow. Wasted space between items also makes accessing items with a pointer slower. Seeking a specific item from a list layout is far more convenient and faster for eyes and for pointer. As much as it pains to admit, Microsoft actually came up with something good with Windows95 start menu when they chose to put items in list layouts and give equal representation to icons and names.

I’m not saying that there is no room for improvement in list based menus, such as Deskbar is now. I just believe that genuine improvements are more likely evolutionary than revolutionary. There is a lot of innovative things that can be done to improve menus that are list based.