Weird coincidence! You discovered this at the same time as I did. That definitely inspired me, and was pretty similar to some other stuff I was trying to figure out, so I am working on such an applet right now. It is going surprisingly well, spare the bouncy animation stuff, though I did rearrange the goals a little bit. What I like here is that this gives functionality that I am jealous of MacOS for, which is that windows and processes are treated separately and this separation is made clear (and useful) to the user. MacOS, however, does that with the shared menu bar, which is something I otherwise consider quite ugly. With this behaviour, we can have closing windows and quitting processes become different motions, and we can move towards a user interface where a window usually resembles a document and a program is just what provides that window. (Programs should not pretend to be windows). This behaviour of top-level window = document (thus the window does not tab multiple documents!!) is very useful for window management, as we can see with Fluxbox's tabbing ability. That blabber makes little sense technically, since programs are not at all tethered to windows but simply choose (very often compared to MacOS programs) to close when their main windows close, but it makes a big difference for user interface.
By "going quite well", I mean that I finally figured out Bonobo, sort of duplicated the window list applet, fell in love with Monodevelop 0.16 (which works well with C!), and I am digging in to ways of finding running processes that matter to the user. (That they ran, and that actually has a reason to make itself known). It's not very far along in final product terms, but it definitely looks more possible than people assume! There are ways to get an icon for a running process (though I hope we can get the launcher icon; the system monitor seems to give the Python icon for programs launched using Python, which is a pain), it is easy to find out what window belongs to what process, and the rest is a piece of cake! (In terms of impossible puzzles, that is, there appear to be none remaining). Instead of replacing the notification area, I want this to present a new functionality that enhances the notification area's purpose. According to the GNOME HIG, the notification area should only have notifications -- notifications being notable messages, for example that the user has mail or that there are updates waiting to be installed. However, it is just as commonly used for permanent notifications, letting the user know that an application is running such as Liferea. It is often treated as an alternative to the window list. That is dumb, but right now it is the only choice if an application wants to not have windows at times yet remain accessible to the user. Going back to the Mac, this is easy! Since processes are not usually expected to exit when their windows close, anything that keeps running but wants to stay out of the way can just let its window be closed, but keep going in the background. Click on its launcher and a window pops up instantly (instead of waiting for the program to load). I am not a fan of doing that to launchers, though; users do not expect to look to the launchers (which "launch" things) for what processes are running, and there is another flaw: A program can't (or should not) change the functionality of those launchers to, say, pop up a certain context menu. Here, we have the window list! The user knows quite well to look there for what is running, which is good. However, as I said, he doesn't like looking at the notification area for what is running, since that is redundant (which leads to confusion). Listing processes, grouped with windows, gives us that important Quit button for the program (among other process-wide actions, perhaps), offers windowless access for programs like Liferea, Tomboy or Rhythmbox, is a good way to create a new program window without having to use the menu again, and looks really snappy. So, what I am building to follow this idea is essentially a window list grouped by processes. It will allow some customization by those processes, so for example Tomboy's entry there can work the same way as it does in the notification area, and running processes will be visible across all workspaces. (Since the virtual desktops only apply to windows). One hitch that I am sure you guys can help with is aesthetics. I have been doing a lot of mockups in Glade and with a little test program. I want this to look like the existing window list, and the best way to do that seems to be this way: http://img84.imageshack.us/img84/2454/screenshotmainpyoq9.png However, those 3 divisions you see have to be individually clickable! If that acts as just one button, it will be very confusing. Is there a nice way to have a GTK button assembled in multiple parts like that? (If that isn't possible, what is a safe way to draw a button-like graphic without creating a GTK button?). Another thing I thought of was tabs containing borderless buttons within, for the different groups in the application list, but the problem with those is that people do not really expect tabs be like that. The most natural is to have 3 buttons (with varying styles), but that way has looked quite ugly every way I have tried it. I guess this is really just decoration, so how does one create decorations that follow the current theme? There, that's my rambling on the topic. Bye, -Dylan McCall PS: I'm Mr. Picklesworth in that forum. On 10/11/07, Jared Moore <[EMAIL PROTECTED]> wrote: > > > Hi guys, > > I'd like to point out this spiffy idea: > > Concept demo: > http://users.tpg.com.au/adsltimu/task-system-launcher.html > > Discussion: > http://ubuntuforums.org/showthread.php?t=320315 > > Jared > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list >
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
