Applets? [was Re: Planning for GNOME 3.0]
[ Resend from a typo in the To: ] On Sun, 2009-04-19 at 23:26 +0200, Luca Ferretti wrote: > 2009/4/19 Emmanuele Bassi : > > On Sun, 2009-04-19 at 14:34 +0200, Sebastian Pölsterl wrote: > > > >> I think it would be a big mistake to omit applets in the new gnome desktop > >> evolution. > > > > why? > > > > > > Emmanuele, do you[1] or do not have a plan for "pluggable > applications" (formerly know as applets) for GNOME 3.0? > > I think that applets developers are legitimate to be worried about > their own efforts, the only reference in gnome-shell stuff is "Design > an applet/add-on system" in Open Design Question. And 1 year could be > a short time for porting. If there were thousands of interesting applets with complex user interfaces then a year might be a short time for porting. But that isn't the case - there are just a tiny handful of useful applets. The main open question for gnome-shell is not how to implement them. It's the user interface question. And when we look at the user interface question I think the label "applet" is a bit deceptive. We have all sort of different things that are applets, and their only commonality is that they go on the panel. The better approach is to start from the tasks and functionality Let me try to characterize the list of things in my "Add to Panel..." I'll start off with the small set of applets that I think are worth thinking about when designing Information Display === We have a few applets that display information to the user; the set of conceivable applets that do this is almost indefinitely extensible (look at available Google gadgets), but not within the scope of a 24-pixel panel. (Note that you have to click on 2 out of the three listed here to actually get the information.) Invest System Monitor Weather Monitor Specialized UI Enhancements === We also have a number of applets that add controls to the panel. Some of these are more useful than others, but they are generally genuinely useful to some set of people. Character Palette Dictionary Lookup Pilot Applet Sticky Notes Time Tracker Tomboy Notes And moving on to everything else: "Crack" === We have quite a few applets that either I don't know what they do or I'm embarrassed to know what they do. I have no trouble with this stuff existing, but it shouldn't be mixed in with useful stuff on a default install, and it's outside the scope of design. Brightness applet CPU Frequency Scaling Monitor Command Line Drawer Dwell Click Force Quit Inhibit Applet Pointer Capture Toys These are similar to "Crack" except that their operation could easily be explained to non-geeks. (if not their existence) Eyes Fish Parts of the Core UI Quite a few of the available "applets" just make up things that we expect always to be there. The user doesn't want to remove or add them. (Obviously not everything here is part of the default panel, because of design indecision.) Clock Keyboard Accessibility Status Keyboard Indicator Main Menu Menu Bar Notification Area Show Desktop Trash User Switcher Workspace Switcher Window List Window Selector Desktop design copouts == Then there are applets that are about making it marginally faster to do things that should be obvious and fast to do without an applet to do them. If these are useful, we've misdesigned. Connect to a Server... Disk Mounter Lock Screen Log Out... Run Application... Search for Files... Shutdown.. So, a large part of what we have just drops out - it's not relevant. An additional portion is best handled by something like Firefox extensions - it's great for advanced users if there is a big ecosystem of them out there. But they aren't something you design for and the programming API is probably just giving them free access to the Javascript internals of gnome-shell. This applies to the "Crack" the "Toys" and maybe even the "Specialized UI Enhancements". And then some portion remains, and that is where design question lies. Do we want an optional sidebar? Do we want some approach where an extra layer of widgets/gadgets flies in when triggered? Could customizable displays be integrated into our existing Overlay mode in some fashion? The last thing I'll mention here is that I don't think we should be overly concerned with porting and applet parity. If there was no system monitor applet in GNOME 3.0, life would go on. What we should be concerned about is creating the ecosystem where it's easy and fun to do interesting things. And when we do there will inevitably be 23 competing system monitor applets whether we like it or not. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
On Sun, 2009-04-19 at 22:54 -0400, Owen Taylor wrote: > [ Resend from a typo in the To: ] > > On Sun, 2009-04-19 at 23:26 +0200, Luca Ferretti wrote: > > 2009/4/19 Emmanuele Bassi : > > > On Sun, 2009-04-19 at 14:34 +0200, Sebastian Pölsterl wrote: > > > > > >> I think it would be a big mistake to omit applets in the new gnome > > >> desktop > > >> evolution. > > > > > > why? > > > > > > > > > > > Emmanuele, do you[1] or do not have a plan for "pluggable > > applications" (formerly know as applets) for GNOME 3.0? > > > > I think that applets developers are legitimate to be worried about > > their own efforts, the only reference in gnome-shell stuff is "Design > > an applet/add-on system" in Open Design Question. And 1 year could be > > a short time for porting. > > If there were thousands of interesting applets with complex user > interfaces then a year might be a short time for porting. But that isn't > the case - there are just a tiny handful of useful applets. > > The main open question for gnome-shell is not how to implement them. > It's the user interface question. And when we look at the user interface > question I think the label "applet" is a bit deceptive. We have all sort > of different things that are applets, and their only commonality is that > they go on the panel. The better approach is to start from the tasks and > functionality > > Let me try to characterize the list of things in my "Add to Panel..." > I'll start off with the small set of applets that I think are worth > thinking about when designing I would add "Application Controller" to this list. There are a number of applications that have either an applet or a notification area thing, enabling quick interactions. The difference between the two is an irrelevant technical distinctions. They bought might as well be called applets for this conversation. (I'm talking about Empathy, Pidgin, RhythmBox, and Banshee here. And probably quite a lot more.) Lots of us will go on about how it's a broken design and how applications shouldn't be doing that. But it's done because people find it useful, warts and all. So rather than declare it broken (which it is) and throw it away, we should try to come up with a way to solve the same problems in a non-broken way. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Hi! > (I'm talking about Empathy, Pidgin, RhythmBox, and Banshee > here. And probably quite a lot more.) Well, these are part of the notification area - they will mostly remain the way they are (so I think the RhythmBox and Banshee icons are completely useless). I think the point of applets is that they should be more than "just an icon", because the icon case is already quite well covered. Regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Owen Taylor schrieb: > [...] > > The last thing I'll mention here is that I don't think we should be > overly concerned with porting and applet parity. If there was no system > monitor applet in GNOME 3.0, life would go on. What we should be > concerned about is creating the ecosystem where it's easy and fun to do > interesting things. And when we do there will inevitably be 23 competing > system monitor applets whether we like it or not. > I totally agree. As long as there's an easy way to write applets, there will be lots of applets. Unfortunately, I currently can't see what this ecosystem might look like. - -- Greetings, Sebastian Pölsterl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknsaggACgkQ1ygZeJ3lLIdHYwCeJKpIyyE1Jdx+WXAkhmtQSshA 0I4AoIDSd/3ZErkPibYO/00oC3W91d5V =jU8B -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
On Sun, Apr 19, 2009 at 10:54:43PM -0400, Owen Taylor wrote: > "Crack" > === > > Brightness applet > Inhibit Applet There will be often differences in opionions. I, for one, use above two applets very often. First, because changing brightness keyboard shortcut require two hands on my laptop, but operating mouse only one. Second one, because I don't want my laptop suspending when I move it, and moving is easier with closed screen. And it's way faster to single click applet instead of diving into preferences menu or rightclicking on battery indicator and navigating from there. One man's crack is another's basic functionality. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
On Mon, 2009-04-20 at 16:23 +0200, Tomasz Torcz wrote: > On Sun, Apr 19, 2009 at 10:54:43PM -0400, Owen Taylor wrote: > > "Crack" > > === > > > > Brightness applet > > Inhibit Applet > > There will be often differences in opionions. I, for one, use above > two applets very often. First, because changing brightness keyboard > shortcut require two hands on my laptop, but operating mouse only one. > Second one, because I don't want my laptop suspending when I move it, > and moving is easier with closed screen. And it's way faster to single click > applet instead of diving into preferences menu or rightclicking on > battery indicator and navigating from there. > One man's crack is another's basic functionality. Note that "Crack" was in quotes. I think it's legitimate for advanced users to want to configure their desktop in ways that simply would make no sense to the majority of the population. I'd like to foster that and extend to things that aren't just adding 24-pixel high controls to the edge of the screen. But we shouldn't confuse advanced user crack with normal customization. Think about the inhibit applet from a design point of view. A common use case that comes up for "close lid without suspending" is: User wants to listen to music on their laptop with the lid closed. (perhaps on a plane) Is it conceivable that the answer we'd come up with for that is: Let's have an applet available in "Add to Panel" described as "Inhibit Applet: Allow user to inhibit automatic power saving" - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
On Mon, Apr 20, 2009 at 10:07 AM, Owen Taylor wrote: > On Mon, 2009-04-20 at 16:23 +0200, Tomasz Torcz wrote: >> On Sun, Apr 19, 2009 at 10:54:43PM -0400, Owen Taylor wrote: >> One man's crack is another's basic functionality. > > Note that "Crack" was in quotes. I think it's legitimate for advanced > users to want to configure their desktop in ways that simply would make > no sense to the majority of the population. Actually, one man's crack can still be another man's crack. Just because you find it useful (or legitimate, or "necessary") doesn't mean it's not still crack, not bad UI practice, and that you're not simply addicted. It just means you don't want to admit it. :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
2009/4/20 Owen Taylor : > The last thing I'll mention here is that I don't think we should be > overly concerned with porting and applet parity. If there was no system > monitor applet in GNOME 3.0, life would go on. What we should be > concerned about is creating the ecosystem where it's easy and fun to do > interesting things. And when we do there will inevitably be 23 competing > system monitor applets whether we like it or not. I like gnome-system-monitor a lot. It is on all gnome installations I use and it is the first thing I customize when installing a new computer. It's the best applet there is and if you disagree it's because you haven't given it a chance. :) It is the perfect tool for quickly detecting abnormal memory usage and monitoring cpu intensive batch jobs (such as compiles). Life does not go on and no gnome-system-monitor equivalent in 3.0 is deal breaker for me, personally. It is also the only system monitor applet, so why would 23 new ones pop up with the new system? Why wouldn't it be possible to port the good applets we have to 3.0? A lot of work has gone into them and just throwing them away seems wasteful to me. -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Hey Owen, > The main open question for gnome-shell is not how to implement them. > It's the user interface question. And when we look at the user interface > question I think the label "applet" is a bit deceptive. We have all sort > of different things that are applets, and their only commonality is that > they go on the panel. The better approach is to start from the tasks and > functionality Not really responding to this directly since, as usual, your analysis is very good. I think one of the most important cases against applets (as they are currently defined in GNOME) is that they are extremely detrimental to the Identity of the product or platform. Today, our entire desktop identity is defined by a configurable number of horizontal or vertical bars filled with any number (even duplicates) of random Things that may launch stuff, open menus, open dialogs, operate on windows, switch workspaces, and more! Boxes-o-crap as I lovingly (in the eulogistic sense) refer to them. Each time I see "Remove from panel" when I right click on the notification area or the menu system I weep and my mascara runs and god is it awful. Let's say that we are trying to define either a product or a product platform. I don't think it is possible to do this without some "brand" coherence. And it is arguably impossible to do this effectively with such an ad-hoc/individually-customized design identity. Even those of us in the developer community would have a difficult time identifying a GNOME desktop in 3-5 steps. Let's try this with Windows: "Start" or menu, (usually) bar at the bottom. This works from Windows Server products all the way to embedded Windows on smartphones. With OS X: Apple logo menu, menu bar at the top, (usually) a dock. Even though the iPhone doesn't have the same software identification experience it retains the platform design branding on the hardware and uses familiar themes in the software visual design. There is usually no doubt that it is an Apple platform. With Android: who knows... So, one of the many very exciting things about GNOME Shell is that for the first time we may have ability to really shape the user experience and form an identity for the GNOME platform. That said, I agree that it is very important to have a number of extension points. * At the platform level to shape a different user experience (usually for devices with different form-factors and goals). I would expect this to probably be only at build/integration time. * Something like a new status area where extensions behave in a very consistent and well-defined manner - the current notification area "applets" are neither * A "place" where the rules are more relaxed and fun things can happen - maybe a sidebar - maybe Vegas... As you mentioned the current applet design conflates these things. I think we can do a lot better. Better default experience, more consistency, more fun! Unity! We're doing something together here and it is about time we started looking like it. Jon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Applets in general are broken because they are no different in functionality from regular applications, or from each other (in terms of desklets vs panel applets vs. the notification area). Many applets are applets because they have very small, simple interfaces; too small to justify having big top-level windows, too big to sit entirely in the background. The big usability disaster this distinction creates is that the application menu goes from being The Way to run applications to being A Way to run applications; another bunch of them are run by right clicking on the panel and choosing to add an applet. Lots of applets act as launchers. For example, timerapplet[0]. The user clicks it, it opens a little dialog, the applet becomes a stylish countdown timer with a nice icon. This could have been done differently. Alternatively, timerapplet could be opened from Applications->Accessories, create a notification icon and be reasonably close to the HIG. The problem there is Accessories would become bloated with stuff like Wanda the fish, stock tickers, eyes and alarm clocks, and also timerapplet would be jumping from one corner of the screen (where it's a launcher) to another (where it's a "window"). Hence the panel applets; a dumping ground for accessories that don't quite deserve to take up 30 pixels of vertical space in the Applications menu but can go somewhere else we never expect the user to use. Instead, because timerapplet is too small and insignificant to consume menu space, it is opened with the panel every time the user logs in! (Wait, what?...) Similarly, all sorts of applications choose to hide within the notification area because they want to stay out of the user's way and window managers fail to provide the necessary functionality themselves. Thus, they take window management upon themselves and start playing with system trays. This should remind you, tenacious reader, of tabbed document interfaces, notification-daemon abuse (for fancy looking dialog boxes), anthropomorphic dogs and rabbity things. So here are some questions to answer: What is so vastly inferior about the application menu that necessitates "applet" software to provide another distinct list of less important applications? Why can't we have big and small applications in the same place? I do have a guess what could be done. Firstly, abolish applets as things which must be run differently from other applications; the user should not Ever see the word "applet" again. Enhance running applications and how they connect with application launchers and their windows; one of the things GNOME Shell seems to be doing. Maybe one way about this is to build on that part of the window manager where it's up to The User whether he wants to minimize a window, shade it or put it beside another on the right side of the screen. How about window management hotspots, such as a panel and a sidebar, each with unique properties for how they treat windows? The user places a window in one of those and, depending on whether it supports some fancy extensions, it becomes a docked window like any file in the panel or the desktop (eg: a window icon that when clicked opens into a full window again). Super awesomeness could extend that so the docked window gains desklety / applety functionality when supported. Basically, kill the distinction and leave it up to the user to say what he wants a window to do rather than have them making unpredictable guesses, and have the window - or whatever other object - do what it can to meet the user's commands. [0] http://timerapplet.sourceforge.net/ Thanks, sorry for the hugeness, Dylan McCall PS: I wrote this bit by bit over a couple /days/, so I'm sending this at risk of it being completely incomprehensible. Forgive me if that's the case. Mockup almost at the ready if it'll help. PPS: A nice process here is writing out key features of different parts of the desktop environment which implement window management. Lots of overlap, but also lots of examples for how existing infrastructure can be beefed up as an alternative, tidier solution. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
On Mon, Apr 20, 2009 at 6:10 PM, Dylan McCall wrote: > Similarly, all sorts of applications choose to hide within the > notification area because they want to stay out of the user's way and > window managers fail to provide the necessary functionality themselves. > Thus, they take window management upon themselves and start playing with > system trays. This should remind you, tenacious reader, of tabbed > document interfaces, notification-daemon abuse (for fancy looking dialog > boxes), anthropomorphic dogs and rabbity things. This one at least has been solved in Windows 7 by merging the QuickLaunch area with running applications. A dock would also solve this problem nicely. You'll notice OS X doesn't have a lot of "applets" on the menu bar. The only one I've seen a lot of people have is smcFanControl. -- Travis Watkins http://www.realistanew.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Le lundi 20 avril 2009 à 16:10 -0700, Dylan McCall a écrit : > I do have a guess what could be done. Firstly, abolish applets as things > which must be run differently from other applications; the user should > not Ever see the word "applet" again. Enhance running applications and > how they connect with application launchers and their windows; one of > the things GNOME Shell seems to be doing. > > Maybe one way about this is to build on that part of the window manager > where it's up to The User whether he wants to minimize a window, shade > it or put it beside another on the right side of the screen. How about > window management hotspots, such as a panel and a sidebar, each with > unique properties for how they treat windows? The user places a window > in one of those and, depending on whether it supports some fancy > extensions, it becomes a docked window like any file in the panel or the > desktop (eg: a window icon that when clicked opens into a full window > again). Super awesomeness could extend that so the docked window gains > desklety / applety functionality when supported. > Basically, kill the distinction and leave it up to the user to say what > he wants a window to do rather than have them making unpredictable > guesses, and have the window - or whatever other object - do what it can > to meet the user's commands. While I agree your proposal would be a great enhancement for most applications that abuse of the notification area (e.g. music players), I don't think that could fully replace applets. Applets like timerapplet or sticky notes are different from standard applications in the sense that you don't work with them as a full task, but only keep them in the background to be easily accessible, while you actually use them for a very short period. The point with them is that the ratio (time running)/(time use) is very low compared with e.g. a text processor. Thus, you need them not to take too much space on the screen, not even, as you suggested, stacked in a corner by the window manager. I'd argue that the best place to put them is on a separate layer à la dashboard (Apple), or directly on the desktop. This layer could be accessed with a button in the top panel, somewhere or in the overlay. Many "widgets" of this kind exist, see Screenlets, Superkaramba, or Google gadgets, or Plasmoids. A simple way of reintroducing applets in a "correct" way would be to support e.g. Screenlets in an overlay: replacements for Tomboy already exist in that framework, which is AFAIK compatible with other widget formats. At least, that's really how I consider we could get rid of the clutter on the main screen, which is distracting us with icons we don't need to be always visible. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Hi, possible solution, the golden one imho, could be to create new API for applets, while redefining term "applet". Applet could be equivalent to widgets in macos x, or plasmoids (horrible naming) in kde. Small self contained applications rendered either with gtk+ or some htmlview with javascript (gecko or webkit), without window decoration, etc. We could either lookup or create specification and API for these. New API should stay language neutral, C, python, ruby, javascript, ... For existing applets, there will be one written in new API, providing room for these "yet to rewritten" applets. They can decide to transform into icon in notification area, or transform to new applet platform, or do nothing :) (the bad case) For users, there could be the option to either display these new applets as floating windows, or they can be docked in sidebar. There also could be an algorithm for laying out applets while in sidebar: wider applets in vertical list, rectangular/portrait in line, drag&drop sorting. Some examples: * Banshee/Rhytmbox/... - they could display small player controls and line with now playing artist/title * Deskbar - should be reused and rewritten as primary search field for gnome-shell, no reason to reinvent the wheel here, or use tracker or gnome-do to query for items * Volume+DateTime+user session could merge into one applet or move into notification area * ...I can imagine many other applets to expand beyond it's current (very restricting) panel-like container On Mon, Apr 20, 2009 at 09:13, Johannes Schmid wrote: > Hi! > > > > (I'm talking about Empathy, Pidgin, RhythmBox, and Banshee > > here. And probably quite a lot more.) > > Well, these are part of the notification area - they will mostly remain > the way they are (so I think the RhythmBox and Banshee icons are > completely useless). I think the point of applets is that they should be > more than "just an icon", because the icon case is already quite well > covered. > > Regards, > Johannes > > ___ > gnome-shell-list mailing list > gnome-shell-l...@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-shell-list > > -- Best regards, Dušan Maliarik // cell: +420 722 810 140 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Milan Bouchet-Valat wrote: > While I agree your proposal would be a great enhancement for most > applications that abuse of the notification area (e.g. music players), I > don't think that could fully replace applets. Applets like timerapplet > or sticky notes are different from standard applications in the sense > that you don't work with them as a full task, but only keep them in the > background to be easily accessible, while you actually use them for a > very short period. > > The point with them is that the ratio (time running)/(time use) is very > low compared with e.g. a text processor. Thus, you need them not to take > too much space on the screen, not even, as you suggested, stacked in a > corner by the window manager. I'd argue that the best place to put them > is on a separate layer à la dashboard (Apple), or directly on the > desktop. This layer could be accessed with a button in the top panel, > somewhere or in the overlay. Many "widgets" of this kind exist, see > Screenlets, Superkaramba, or Google gadgets, or Plasmoids. A simple way > of reintroducing applets in a "correct" way would be to support e.g. > Screenlets in an overlay: replacements for Tomboy already exist in that > framework, which is AFAIK compatible with other widget formats. > > At least, that's really how I consider we could get rid of the clutter > on the main screen, which is distracting us with icons we don't need to > be always visible. I like the proposed solution that the panel launchers would somehow become a dock. e.g. for Tomboy or Hamster Applet, you have the icon launcher. If you click on it, the app is opened. If you click on it again, it's closed. That could be achieved with single-instance applications (libunique), for example (when you try to launch it again, the instance is closed). For many cases, I can imagine such a workflow would be fine. It wouldn't solve all of them though, for example you don't want system-monitor to be a launcher, but rather to see the system activity IRL. Another benefit of this is that a) your applet doesn't need to be started up on login, and b) you don't have it running everytime. Of course, you need it to be quick to start up. But if it doesn't for such small applications, it's a big fail IMHO. Best regards, Emilio signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
I've found that I really like the plasmoid approach from KDE4. Most of those things fit the description of "infrequently needed for short periods of time", or "crack". From my point of view (a user), I mainly want to be able to get to applets quickly. With the current small format of applets on the panel, getting any significant amount of info requires that I actually mouse-over or click many of them to see what's going on. Since I'm already context-switching my mind from what I was doing to whatever I'm about to do with the applet, I don't particularly mind if my current application disappears temporarily while I work with the "applet". With that in mind... What if we create a new class of window for applets with these characteristics: - Does not appear in the Window list - Does not appear in the alt-tab switcher - No window borders (they will draw their own content somehow) - The Window Manager will have a certain key event that will bring all of these class of windows to the foreground until that button is pressed again (or each applet could register its own) - These windows (or maybe their children?) can be configured to be on top of all windows permanently, maybe with a lowered opacity (so you can always see f.e. your CPU usage on the system monitor applet) - The windows can be positioned anywhere on the screen - Ability to toggle temporary visibility in order to inform of events (next song playing, network disconnected, etc.) (maybe a good way to do notifications in the future?) - Would be nice if each app could have a "collapsed" state to further minimize screen usage (for people with smaller screens) The goals of this design would be: - Quick access to any of these applications when you need them; already running, just a keypress to activate them / bring to foreground - Can display more information because they have a larger display area - Can be written into any applicable spec so other environments could implement these - No specific framework required to these applications, just create a certain type of window - No language constraints; anything that can make a graphical app can make one of these - Any app could have a "minimize as applet" state (media players would like this) which shows just the basic info about them in a small footprint I personally think that the current state of applets is a little limiting. I like the panel well enough, but I feel like applets could be displaying more information about their state if they just had a little more screen real estate to play with. Since many people have very large screens now, why not work on letting the applets take up more of it? - Martin On Tue, Apr 21, 2009 at 8:10 AM, Emilio Pozuelo Monfort wrote: > Milan Bouchet-Valat wrote: >> While I agree your proposal would be a great enhancement for most >> applications that abuse of the notification area (e.g. music players), I >> don't think that could fully replace applets. Applets like timerapplet >> or sticky notes are different from standard applications in the sense >> that you don't work with them as a full task, but only keep them in the >> background to be easily accessible, while you actually use them for a >> very short period. >> >> The point with them is that the ratio (time running)/(time use) is very >> low compared with e.g. a text processor. Thus, you need them not to take >> too much space on the screen, not even, as you suggested, stacked in a >> corner by the window manager. I'd argue that the best place to put them >> is on a separate layer à la dashboard (Apple), or directly on the >> desktop. This layer could be accessed with a button in the top panel, >> somewhere or in the overlay. Many "widgets" of this kind exist, see >> Screenlets, Superkaramba, or Google gadgets, or Plasmoids. A simple way >> of reintroducing applets in a "correct" way would be to support e.g. >> Screenlets in an overlay: replacements for Tomboy already exist in that >> framework, which is AFAIK compatible with other widget formats. >> >> At least, that's really how I consider we could get rid of the clutter >> on the main screen, which is distracting us with icons we don't need to >> be always visible. > > I like the proposed solution that the panel launchers would somehow become a > dock. > > e.g. for Tomboy or Hamster Applet, you have the icon launcher. If you click on > it, the app is opened. If you click on it again, it's closed. That could be > achieved with single-instance applications (libunique), for example (when you > try to launch it again, the instance is closed). For many cases, I can imagine > such a workflow would be fine. It wouldn't solve all of them though, for > example > you don't want system-monitor to be a launcher, but rather to see the system > activity IRL. > > Another benefit of this is that a) your applet doesn't need to be started up > on > login, and b) you don't have it running everytime. Of course, you need it to > be > quick to start up. But if it doesn't for
Re: Applets? [was Re: Planning for GNOME 3.0]
Just to throw my hat into the ring, I thought I'd link to some previous discussion on applets. http://davyd.livejournal.com/118545.html http://mail.gnome.org/archives/desktop-devel-list/2004-September/msg00241.html http://mail.gnome.org/archives/desktop-devel-list/2004-September/msg00384.html -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
I'm new to this (having just joined the gnome-shell-list, but I quite like this suggestion, with one possible addition. I was wondering whether all of them could be on a circular strip (think zoetrope http://en.wikipedia.org/wiki/Zoetrope) which could easily be rotated so that you can choose and manipulate them as required. A circular arrangement would allow you to see all the applets at one time (bar those on the left and right at any particular time), and pick them easily. Note: IANAL or an interface designer... -Mike. > What if we create a new class of window for applets with these > characteristics: > - Does not appear in the Window list > - Does not appear in the alt-tab switcher > - No window borders (they will draw their own content somehow) > - The Window Manager will have a certain key event that will bring all > of these class of windows to the foreground until that button is > pressed again (or each applet could register its own) > - These windows (or maybe their children?) can be configured to be on > top of all windows permanently, maybe with a lowered opacity (so you > can always see f.e. your CPU usage on the system monitor applet) > - The windows can be positioned anywhere on the screen > - Ability to toggle temporary visibility in order to inform of events > (next song playing, network disconnected, etc.) (maybe a good way to > do notifications in the future?) > - Would be nice if each app could have a "collapsed" state to further > minimize screen usage (for people with smaller screens) > > The goals of this design would be: > - Quick access to any of these applications when you need them; > already running, just a keypress to activate them / bring to > foreground > - Can display more information because they have a larger display area > - Can be written into any applicable spec so other environments could > implement these > - No specific framework required to these applications, just create a > certain type of window > - No language constraints; anything that can make a graphical app can > make one of these > - Any app could have a "minimize as applet" state (media players would > like this) which shows just the basic info about them in a small > footprint > > I personally think that the current state of applets is a little > limiting. I like the panel well enough, but I feel like applets could > be displaying more information about their state if they just had a > little more screen real estate to play with. Since many people have > very large screens now, why not work on letting the applets take up > more of it? > > - Martin > > > On Tue, Apr 21, 2009 at 8:10 AM, Emilio Pozuelo Monfort > wrote: > > Milan Bouchet-Valat wrote: > >> While I agree your proposal would be a great enhancement for most > >> applications that abuse of the notification area (e.g. music players), I > >> don't think that could fully replace applets. Applets like timerapplet > >> or sticky notes are different from standard applications in the sense > >> that you don't work with them as a full task, but only keep them in the > >> background to be easily accessible, while you actually use them for a > >> very short period. > >> > >> The point with them is that the ratio (time running)/(time use) is very > >> low compared with e.g. a text processor. Thus, you need them not to take > >> too much space on the screen, not even, as you suggested, stacked in a > >> corner by the window manager. I'd argue that the best place to put them > >> is on a separate layer à la dashboard (Apple), or directly on the > >> desktop. This layer could be accessed with a button in the top panel, > >> somewhere or in the overlay. Many "widgets" of this kind exist, see > >> Screenlets, Superkaramba, or Google gadgets, or Plasmoids. A simple way > >> of reintroducing applets in a "correct" way would be to support e.g. > >> Screenlets in an overlay: replacements for Tomboy already exist in that > >> framework, which is AFAIK compatible with other widget formats. > >> > >> At least, that's really how I consider we could get rid of the clutter > >> on the main screen, which is distracting us with icons we don't need to > >> be always visible. > > > > I like the proposed solution that the panel launchers would somehow become > > a dock. > > > > e.g. for Tomboy or Hamster Applet, you have the icon launcher. If you click > > on > > it, the app is opened. If you click on it again, it's closed. That could be > > achieved with single-instance applications (libunique), for example (when > > you > > try to launch it again, the instance is closed). For many cases, I can > > imagine > > such a workflow would be fine. It wouldn't solve all of them though, for > > example > > you don't want system-monitor to be a launcher, but rather to see the system > > activity IRL. > > > > Another benefit of this is that a) your applet doesn't need to be started > > up on > > login, and b) you don't have it running everytime. Of course, you need it
Re: Applets? [was Re: Planning for GNOME 3.0]
On 21 Apr 2009, at 04:34, Travis Watkins wrote: This one at least has been solved in Windows 7 by merging the QuickLaunch area with running applications. A dock would also solve this problem nicely. You'll notice OS X doesn't have a lot of "applets" on the menu bar. The only one I've seen a lot of people have is smcFanControl. You'd be surprised. I currently have 15, 11 of which are standard OS X "applets" (but not all of which are turned on by default, admittedly). On the plus side, the good thing about OS X menu extras (as they're properly called) is that they're all generally of a uniform size and appearance (they fit into a square, and they're monochrome)-- the 15 I have still take up less than half the width of my menu bar. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:calum.ben...@sun.comOpenSolaris Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Hi Calum, On Thu, Apr 30, 2009 at 6:53 PM, Calum Benson wrote: > > On 21 Apr 2009, at 04:34, Travis Watkins wrote: > >> This one at least has been solved in Windows 7 by merging the >> QuickLaunch area with running applications. A dock would also solve >> this problem nicely. You'll notice OS X doesn't have a lot of >> "applets" on the menu bar. The only one I've seen a lot of people have >> is smcFanControl. > > You'd be surprised. I currently have 15, 11 of which are standard OS X > "applets" (but not all of which are turned on by default, admittedly). > > On the plus side, the good thing about OS X menu extras (as they're properly > called) is that they're all generally of a uniform size and appearance (they > fit into a square, and they're monochrome)-- the 15 I have still take up > less than half the width of my menu bar. Out of curiousity, do they all act like menus? Also guessing that you don't have the google notifier since that one isn't monochrome (I wish it was)... Jon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
On 1 May 2009, at 00:00, William Jon McCann wrote: On the plus side, the good thing about OS X menu extras (as they're properly called) is that they're all generally of a uniform size and appearance (they fit into a square, and they're monochrome)-- the 15 I have still take up less than half the width of my menu bar. Out of curiousity, do they all act like menus? Also guessing that you don't have the google notifier since that one isn't monochrome (I wish it was)... Yes, they do all act like menus, except arguably the standard OS X volume control and Spotlight icon, which both somewhat stretch the usual definition of a "menu". (But not out of all recognition.) Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:calum.ben...@sun.comOpenSolaris Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
What I would die is two things that stem from the same concept: A low operation mode that would be sent through a term signal so that the application knows it only has to perform basic operations. Like Rhytmbox only playing music and giving status updates, basically suspending there graphical user interface. For most application this would result in the same reaction as with Ctrl-Z, even possible sending Suspend to application that don't support some dbus service. This would eliminate polling and lot's of other stuff that minimized application should not do. This could also be used for applets. This would happen when application are minimized. And a suspended to disk mode which would pack the memory data to disk to be restored the next time the users clicks on the icon. This would be menu option in the minimized application, "Put application to sleep". This is a killer feature for any user of firefox that has to do short memory intensive operations. I basically do killall firefox now. Regards, Olafur Arason On Tue, Apr 21, 2009 at 1:25 PM, Martin Meyer wrote: > I've found that I really like the plasmoid approach from KDE4. Most of > those things fit the description of "infrequently needed for short > periods of time", or "crack". From my point of view (a user), I mainly > want to be able to get to applets quickly. With the current small > format of applets on the panel, getting any significant amount of info > requires that I actually mouse-over or click many of them to see > what's going on. Since I'm already context-switching my mind from what > I was doing to whatever I'm about to do with the applet, I don't > particularly mind if my current application disappears temporarily > while I work with the "applet". With that in mind... > > What if we create a new class of window for applets with these > characteristics: > - Does not appear in the Window list > - Does not appear in the alt-tab switcher > - No window borders (they will draw their own content somehow) > - The Window Manager will have a certain key event that will bring all > of these class of windows to the foreground until that button is > pressed again (or each applet could register its own) > - These windows (or maybe their children?) can be configured to be on > top of all windows permanently, maybe with a lowered opacity (so you > can always see f.e. your CPU usage on the system monitor applet) > - The windows can be positioned anywhere on the screen > - Ability to toggle temporary visibility in order to inform of events > (next song playing, network disconnected, etc.) (maybe a good way to > do notifications in the future?) > - Would be nice if each app could have a "collapsed" state to further > minimize screen usage (for people with smaller screens) > > The goals of this design would be: > - Quick access to any of these applications when you need them; > already running, just a keypress to activate them / bring to > foreground > - Can display more information because they have a larger display area > - Can be written into any applicable spec so other environments could > implement these > - No specific framework required to these applications, just create a > certain type of window > - No language constraints; anything that can make a graphical app can > make one of these > - Any app could have a "minimize as applet" state (media players would > like this) which shows just the basic info about them in a small > footprint > > I personally think that the current state of applets is a little > limiting. I like the panel well enough, but I feel like applets could > be displaying more information about their state if they just had a > little more screen real estate to play with. Since many people have > very large screens now, why not work on letting the applets take up > more of it? > > - Martin > > > On Tue, Apr 21, 2009 at 8:10 AM, Emilio Pozuelo Monfort > wrote: >> Milan Bouchet-Valat wrote: >>> While I agree your proposal would be a great enhancement for most >>> applications that abuse of the notification area (e.g. music players), I >>> don't think that could fully replace applets. Applets like timerapplet >>> or sticky notes are different from standard applications in the sense >>> that you don't work with them as a full task, but only keep them in the >>> background to be easily accessible, while you actually use them for a >>> very short period. >>> >>> The point with them is that the ratio (time running)/(time use) is very >>> low compared with e.g. a text processor. Thus, you need them not to take >>> too much space on the screen, not even, as you suggested, stacked in a >>> corner by the window manager. I'd argue that the best place to put them >>> is on a separate layer à la dashboard (Apple), or directly on the >>> desktop. This layer could be accessed with a button in the top panel, >>> somewhere or in the overlay. Many "widgets" of this kind exist, see >>> Screenlets, Superkaramba, or Google gadgets, or Plasmoids. A si
Re: Applets? [was Re: Planning for GNOME 3.0]
I think it would be worth fleshing out some existing parts of the design, like the application menu and launchers, before delving in to gizmos as a separate component. In the end, if the rest is done to cover the appropriate jobs, they may not be necessary. One really dumb thing with gnome-panel applets today is that, in a lot of ways, we're arbitrarily categorizing these applications differently (because they're small) and putting them in a horrible menu that can't be accessed through primary interactions. Instead of being in, say, Applications›Finances, to get a cute stock ticker that's always available you need to right click the panel, choose "Add to Panel…" and search, and then position the applet somewhere. It's really totally arbitrary! Lots of smartphone OSs solve this with things like badges attached to application launchers. That approach alone seems to work very well. Gnome-shell, meanwhile, has a lot of pixels to play with ;) Thanks, Dylan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
