Home > Graphics > Editorial: Desktop Functionality I’d Like to See Editorial: Desktop Functionality I’d Like to See Eugenia Loli 2004-02-28 Graphics 21 Comments “Windowing environments are in their third decade, and they still do little more than open and close. There’s no reason windows can’t be more sophisticated”, Daryl Blakeslee writes on NewsForge. About The Author Eugenia Loli Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker. Follow me on Twitter @EugeniaLoli 21 Comments 2004-02-28 9:34 am > Even worse are non-X applications run in X that tell me > nothing: they quietly die without any messages whatsoever. > Every Unix application has an exit code, so why can’t it > notify me, or not, based on the code? Doesn’t KDE 3.2 do this? 2004-02-28 10:08 am Correct me if I’m wrong, but this article seems to say that it would be nice to somehow make it easier to keep the desktop tidy, and mentions a few possible ways of achieving that. A laudable objective (no sarcasm intended). My desk (the one the computer sits on) is always very messy. Strangely enough I don’t seems to have a problem with it. I know where everything is. The same goes for the computer’s desktop system (although for some reason it’s not so messy…). As a software engineer, I try to design software that covers all bases, but how do I write DE systems that cover all the possible ways a person will work? Just to illustrate what I am talking about: 1) Every person has their own way of doing things 2) Every program uses the screens real estate slightly differently 3) Every person and piece of software form a unique expression on the screen that is NOT constant with time (it changes with the persons mood) 4) No. I cannot assume anything about the way a person works because if I do, someone will break it (and it’s NOT their fault, it’s mine). 5) The list goes on… KDE and Gnome are the bare beninnings of managing complexity on the desktop, and look at their code bloat. I certainly don’t want more code to add extra features. I’d rather have more and different tools to choose from rather than more and different features. Who wants MORE features in Microsoft Office? Thanks, Yohn 2004-02-28 10:28 am … would be the ability to scroll through active programs in the same window. I know some WM do that, but I would like to have it as a “native” feature in KDE or XFCE… 2004-02-28 11:23 am I think XFCE4 already does this… at least it did for me just now when I tested it. Maybe it is a setting? I personally agree with his statment about desktop icons. While I prefer graphical file managers, I have no use for having them taking up huge gobs of memory when they’re unused most of the time (Nautilus is horrible in this respect, thankfully you can turn the display desktop off, although I imagine more than a few people would be more happy if this option was in the gnome control panel somewhere). As for desktop art… well, that’s a personal preference, that’s well addressed by current software. Every desktop environment I know of allows simple backgrounds, and there’s more than enough programs floating around that simply display and scale an image. As for scaling each program – there’s a simple reason that vector graphics haven’t made much of an impact outside of selected areas until recently – CPU power. Simply put, vector graphics sacrifice CPU power for ease of scaling at the end use point, and bandwidth. To create a vector image requires many calculations to turn it into a bitmap that graphics card can understand. Of course, if/when a standard arose for properly handling desktop type graphics (things like fonts, icons, and so on) in hardware, this would no longer be the case. Personally, while I’m happy to see the hardware vector graphics handling, I’ll probably use it to speed up my current desktop (XFCE4, after getting fed up with GNOME’s bloat) rather than slow down the bloated ones. 2004-02-28 11:28 am Damn, should have got this in the previous post. KDE and Gnome are the bare beninnings of managing complexity on the desktop, and look at their code bloat. I certainly don’t want more code to add extra features. I’d rather have more and different tools to choose from rather than more and different features. Who wants MORE features in Microsoft Office? I agree. This is one of the reasons I can’t stand KDE (I can’t stand GNOME either, but for different reasons), while things seem to run faster, The user interface is horribly bloated. There’s simply too many buttons, and controls on the average window. I guess this is good for a certain class of users (My parents are big KDE fans) who like the shallow and wide approache to interfaces, but annoys people (most geeky/technically minded people I imagine) who like the deep and and narrow/tree type interface. Of course, this is personal preference all over again, which is why we have KDE and GNOME and XFCE and Fluxbox and ICEWM and Windows and Mac OSX and… 2004-02-28 11:51 am Uhmm this guy doesn’t know that exposé on MacOS X do that. And that Longhorn will do that too… and probably some other OS in the meantime. The only environment were can’t do that for now is X. Maybe in the future? And I agree with those of you who said that KDE are too bloated with button and possibilities… It’s becoming harder and harder to change his desktop to something we like without being flooded by silly possibilities. Look at the MacOS X desktop or the Windows desktop… only some minor thing can be change, and most people are happy! 2004-02-28 1:17 pm Pity Longhorn isn’t actually out yet… I agree, X is i icky. It works, but it’s being stretched to things the orginal designers clearly never thought of. It is a testement to the orginal designers that it has lasted so well, but it’s time is nearly over… Fortunatly, y-windows looks like a very worthwhile replacement. I’m fairly certain that it will handle the base technology requirements of the article poster easily. Everything else is just individual features (the compressed window example). 2004-02-28 5:00 pm Nah, X is not icky, the ideas behind it are perfect for expandability and ect and nothing prevents it from handling any thing said in the article. =] The big problem with y-windows is that is that is it’s use of builtin widgets… 2004-02-28 5:52 pm > The only environment were can’t do that for now is X. Maybe in the future? It would be easy to implement with freedesktop.org’s X server’s XDamage extension. (I could be horribly wrong too since I don’t really know much about exposé… The only current issue prohibiting implementing it under X11 is to get snapshots of the windows, isn’t it?) 2004-02-28 6:51 pm Almost every idea in this article is terrible for a majority of users. Scaling windows is incredibly expensive and requires a fundamentally vector based graphics model to do it properly. Vector scaling, makes it incredibly hard to read documents below a 75% ratio. Sure, if we use a complex vector based widget it is possible to not scale text, but then you get the scoll bars back. Turning quick access buttons on the window frame into menus defeats the purpose of quick access buttons. Imagine if, instead of window buttons, you HAD to use the right click menu to access all window management functionality – and on top of that this person wants MULTIPLE menus for subtle changes in functionality for the existing menus. Attatching the taskbar widget to active windows means that either A)the taskbar has to scale to the size of small windows or B)the taskbar jumps across the screen full size covering up my important other windows. While reducing the amount of mouse movement in the abstract, it actually makes taskbar access slower by eliminating the advantage of the screen border, and making the taskbar of variable size eliminating predictability. Hard to implement, and totally useless to 99% of the population. At best, this is a case of “if you want it implement it yourself.” 2004-02-28 8:01 pm Actually, a task bar that is properly placed, that is, along the edge of the screen, can be accessed faster than anything attached to a window. Why? Fittz’s (or whatever his name) law. While you have to move your mouse further to reach the bottom of the screen, you actually have to do very little aiming, since the mouse can’t go past the edge of the screen. Because of this aiming for the edges of the screen takes less time than aiming for any other part of the screen. 2004-02-28 8:04 pm IIRC the XDamage is so that the entire window does not have to be redrawn or something along that line… AFAIK implementing that would require a the creation of a entirely new extension to handle window scaling… /me personally thinks window scaling is a lame idea It may be useful if you have a uber high res monitor and a obscenely large monitor it may be occasionally useful… but I doubt I would still even use it then… The only time I it is really useful is when viewing images or video… which that can all ready be done by the current set of extentions… 2004-02-28 10:12 pm Nah, X is not icky, the ideas behind it are perfect for expandability and ect and nothing prevents it from handling any thing said in the article. =] The big problem with y-windows is that is that is it’s use of builtin widgets I think we have to agree to disagree on this one. I think built in widgets is a good idea. If you leave the theme propogation up to the display unit, the server (in the X sense) sets the theme and behaviour for all widget. It also lets you send vector instructions, which coupled with a half decent font library, should present no problems for scalable content – provided it’s done properly. Things like webpages could be a bit tricky though. The primary reason I think X is ‘icky’ is that it was designed mostly back in the day when the displays were capable of little more than pushing graphics off the network on to a screen. Now-adays, when my mp3 player has more ram than some (non-X) servers used to have, it would be wise to change to take advantage of new technology. 2004-02-29 8:32 am Actually, its not XDamage that you want, but Composite. Composite lets you redirect all drawing in a window to its own pixmap. A composite manager runs and forms the desktop by drawing those pixmaps on the root window. A composite manager could easily draw the pixmap scaled instead of blitting it directly. All the code to do this is already in the FD.O X server. It’d be maybe a one line change in xcompmgr, not counting the code to scale the pixmap 2004-02-29 12:00 pm As for scaling each program – there’s a simple reason that vector graphics haven’t made much of an impact outside of selected areas until recently – CPU power. Simply put, vector graphics sacrifice CPU power for ease of scaling at the end use point, and bandwidth. To create a vector image requires many calculations to turn it into a bitmap that graphics card can understand. What about drawing the whole lot to a backbuffer and use OpenGL to scale the window? Afaik MacOS X does or did (they changed their technique somewhere) this with Quartz Extreme. They’d draw every window as a texture and put that texture on a 3d square in their 3d “scene”, the desktop. It’s no purely vector graphics, but allows for the scaling. 2004-02-29 4:26 pm It does not matter when it was designed… it is still a very good and extendable design. 2004-02-29 7:10 pm Longhorn has a lot of those features like zooming and shrinking. 2004-02-29 8:31 pm It does not matter when it was designed… it is still a very good and extendable design. X is a very good design. That doesn’t alter the fact that it was meant for running on dumb terminals with little processing power beyond that required to blit graphics on to the screen. Y-Windows and other X replacements are designed to take advantage of new and faster hardware. Why is this a bad thing? SpookyET – The word is will. See comment last page. Longhorn isn’t out yet. 2004-03-01 12:50 am Actually, a task bar that is properly placed, that is, along the edge of the screen, can be accessed faster than anything attached to a window. Why? Fittz’s (or whatever his name) law. While you have to move your mouse further to reach the bottom of the screen, you actually have to do very little aiming, since the mouse can’t go past the edge of the screen. Because of this aiming for the edges of the screen takes less time than aiming for any other part of the screen. This is only true if a) your taskbar is a single “row of items” high and b) said “items” *also* stretch all the way to the edge of the screen. As soon as you’ve got a taskbar more than one row high, or items that aren’t really on the edge of the screen, the speed advantage disappears. 2004-03-01 3:44 pm Plain old RatPoison will do most of the things the author wants. 2004-03-01 3:48 pm I have extensive experience with the newest Longhorn Beta and have yet to find any features comparable to Expose or even multiple desktops, just the old hide desktop button. Longhorn seems to be only a slight XP upgrade. Their “new” file system is a fraud. I too believe that the future of X is at freedesktop.org.