elementary-dev-community team mailing list archive

[Daniel Foré <daniel@xxxxxxxxxxxxxxxx>]

Okay, so as far as I can tell, the deciding issue is about showing the dock icon?

Is there no way to both a. Have the window closed and b. show it's icon in the dock while c. Not having the app pinned?

It seems like a hack to open the window and then immediately minimize it. But I agree that having the icon available (when it makes sense) is a good thing. 

Even if this this is not currently programically possible, don't we have the means to make it so? Either through libplank or libunity or a combination of the two?

We already know that Canonical has this use case as well (with update manager). So I don't think they'd be opposed to a proper solution. 

Let's not try to derail discussion about what is a "real" service or what the HIG may or may not recommend about architecture. Lets try to keep to what exactly the problem we're having is and how we can solve that problem most cleanly. 

Best Regards,
Daniel Foré

El mar 15, 2013, a las 9:56 a.m., Victor <victoreduardm@xxxxxxxxx> escribió:

> 
> 
> On Fri, Mar 15, 2013 at 6:07 AM, Sergey Shnatsel Davidoff <sergey@xxxxxxxxxxxxxxxx> wrote:
>>> The big question is, "should background apps minimize or close their window?"
>> 
>> AFAIK it's a purely technical issue that's ultimately up to Gala devs, so I can't see the point of writing it down to the HIG or discussing it here. 
>> 
>> IMO the UX-related question is "when should background apps show their icon in the dock, and if should they do that at all?". 
>> 
>> It seemed to me that Noise should be easily accessible from the dock while it plays music, so that the user can pause playback or switch to the next track easily, regardless of the presence of media keys, which are still uncommon around here. Also, turns out many people don't discover media keys even when they are present - keyboards have so many keys...
>> 
>> This is why I pushed for minimizing Noise during playback when running in Pantheon. I also pushed for making it exhibit shell-native behavior, e.g. hide the window instead of minimizing it when running in Unity, but I'm not sure if that was implemented.
> 
> That was fully implemented. Noise minimizes its window instead of hiding it in Pantheon and GNOME Shell, and simply hides the window for the rest of shells. It uses the following GSettings key to decide for which shells it should minimize the window: /org/pantheon/noise/settings/minimize-while-playing-shells (See my other comment).
> 
>>  
>>> I'm inclined to think that close is the cleaner solution here when we're talking about making closing workspaces on Gala work properly, making "opening" (re-opening technically) these apps work as expected, etc. Think about it this way: How many apps does a user maybe want to be running in the background on start-up 24/7? Here's a few background apps I know that I have running on my Phone:
>>> 
>>> Twitter
>>> Facebook
>>> Email
>>> Messages
>>> ESPN (gotta know when Barça is playing)
>>> Music
>>> Calls
>>> Mint (I get alerts if I go over-budget)
>>> Fitocracy
>>> 
>>> Does it make sense to have all these windows minimized to my 1st workspace every time I log in since they all (in at least some way) need to be running in order to work properly? I just don't think that makes sense from a window management perspective.
>> 
>> I'll reply with a quote from the very same HIG page:
>> 
>>> If the app performs repeat background tasks (such as checking for new mail), the background tasks should be handled by a separate daemon.
>> 
>> All the apps from your list except Music perform some background tasks repeatedly, so they fall into this "background daemon" category. More specifically, they wait for some event and notify you when it happens. Of course it's counter-productive to make them all clutter the dock at all times. 
>> 
>> However, showing a dock badge with the number of action items in the app is an important means of notifying the user about the event because this way the dock provides a persistent overview of remaining action items. Dock badges are complementary to showing a notification but they're also important because the user is not always willing to react to a notification immediately and notification backlogs are far too cluttered to be useful.
>> 
>> The way I see it, these "background daemons" should only display an icon in the dock when the daemon has some new action items. Although the definition of "new" is a bit vague here - looking at how some people never get the unread mail count in their inbox to zero, I doubt it's a good idea to show an email client inon in the dock with the badge "243" all the time. Maybe it's better to only show the icon when the number of unread threads increases or display the number of unread emails since you last checked the inbox instead of the actual count of unread threads. But this is a topic for another discussion.
>> 
>> And regarding that quote, I have a bone to pick:
>> 
>>> If the app performs repeat background tasks (such as checking for new mail), the background tasks should be handled by a separate daemon.
>> 
>> Not only the Human Interface Guidelines advice on the matters of software architecture, they also provide no rationale for doing so. It's as ridiculous as an interior designer writing "and by the way, only build houses on this type of foundation" in a book on interior design. I mean, what can interior designers possibly know about foundations? And why do they even care?
> 
> Couldn't agree more. Sometimes you only need to hide the window from the world. Otherwise, for big apps like music players, the users would have to wait for the entire UI to be created again fetching information from the daemon (or somewhere else) in order to resume working. This is not ideal, considering you only save a couple of megabytes of memory used by the UI, and everybody hates startup times; this would only bring unresponsiveness. This type of information doesn't belong to the HIG.
> 
>> 
>> -- 
>> Sergey "Shnatsel" Davidoff
>> OS architect @ elementary