Re: Gnome shell suggestions after a bit of usage

[Florian Max <florian muellner gmail com>]

2011/7/9 Aurélien Naldi <aurelien naldi gmail com>

"normal" running aps are expected to appear in the dock. Background ones can either be here or somewhere else, I would prefere somewhere else, but indeed being in the dock also makes sense. The downside for me is that it may make the dock harder to use as it shows many icons. Beside this, I don't mind. Similar comment applies fot the other parts (alt-tab and overview)

I agree that "real" background apps shouldn't show up in the dash (shell-speak for dock) or the app switcher - those are services with little or no UI (think of the OSD popups of gnome-settings-daemon or the battery notifications of gnome-power-manager).
But this is about a not clearly defined set of applications, which provide both an "application mode" (i.e. showing an application window) and a "service mode" (i.e. "hiding" in a tray icon). For instance, there have been requests to add a status icon to Evolution. The requests were rejected, so Evolution is not a "background application" according to the definition above, though some people would like to think of it as one. Or consider a more provocative example: Image I'm using Firefox to download an ISO image. While I wait for the download to finish, I switch to the music player to organize my collection - now, which application is the "background application"?

So, two questions:
1. Should we support the concept of "background applications"?
  This is a good question - many reasons for status icons are not
  really an issue with gnome-shell. If a window is covered by other
  windows or on another workspace, it is effectively invisible - just
  like the terminal while I use the browser, I know some people (Hi Jasper!)
  get anxious just *knowing* that a "background application" has open
  windows somewhere, but given that the same applies for non-active
  non-"background" windows which don't produce any anxiety, I'm not
  sure whether we are considering an actual problem or just a habit.

2. If yes, do we want a generic mechanism?
  Right now, both status icons and indicators are implemented by applications,
  so it's entirely up to application authors to decide whether an application
  is a "background" application or not. But as pointed out above, sometimes
  there is disagreement between a user's expectation and the developers' view
  (Evolution) or an application which is generally not considered a "background"
  application can still be used to perform a lengthy non-interactive task "in the
  background" (Firefox). So, if the concept itself is deemed useful, would it make
  sense to implement it as a generic mechanism to leave the definition to users
  rather than developers?
 

I thought the notifications were better suited for the status than for the actions. So can they provide more than just one action like the indicators do?

Yes. Note that notification actions are represented by buttons (either text or icon), so in practice the number of actions is limited (of course you *can* add 20 buttons to a popup, but it'll look like crap).

 

Fair enough. But it is also a political one: it has been a supported feature for a while. I would be glad to see a better how, but a willingly rejecting this kind of things would need strong arguments, much more than "it was discussed on IRC" :-)

I don't think "we used to have this" makes a very strong argument. We used to support iconification (similar to minimization, but "hidden" windows are represented
by an icon on the desktop rather than an entry in the window list). Or "drawer" applets in the panel, which could contain other applets - including more nested drawers. Sometimes stuff was a bad idea in the first place, sometimes stuff is superseded by better stuff, sometimes stuff just stops making sense when the environment changes. I'm not sure any of this applies to "background" applications, but we shouldn't be afraid to consider it, just because it is a change to the status quo.

And yes, "it was discussed on IRC" is an important part of the process ... (ideally the outcome of such a discussion is a mockup, then a bug report is opened to implement it, a patch is attached, reviewed and landed, then people start ranting :-)


Florian