elementary-dev-community team mailing list archive
-
elementary-dev-community team
-
Mailing list archive
-
Message #02122
Re: Background apps discussion
Not everyone checks the list every day; for example, I'm on vacation this
week and haven't had the time to sit down and flesh this out. Let's keep
this discussion open a bit longer than two days. ;)
On Mar 24, 2013 10:01 AM, "Sergey "Shnatsel" Davidoff" <
sergey@xxxxxxxxxxxxxxxx> wrote:
> Any objections on this? It's about time to voice them.
>
> If not, this should be added to the relevant HIG article,
> http://elementaryos.org/docs/human-interface-guidelines/user-workflow/background-tasks
>
> 2013/3/22 Nishant George Agrwal <nishantagrwal12993@xxxxxxxxx>
>
>> Okay, so the thread about Noise not complying to the HIG turned into
>> quite a general discussion about the HIG and background application
>> behaviour so I am creating this new thread with a better title to continue
>> it. Here's a link to the old thread:
>> https://lists.launchpad.net/elementary-dev-community/msg02046.html
>>
>> Summing up, we need to think about proper ways to create and deal with
>> background applications, i.e, applications that don't require interaction
>> with the user for most or a big part of the time they are running, like
>> mail clients, IM clients, music players, microblogging apps, etc.
>> Typically, these apps don't fit well into any one task the user is
>> performing, so it often doesn't make sense for these applications to be
>> bound to a particular workspace either.
>>
>> To this end, applications are to intelligently handle closing the window
>> to do whatever best suits the situation. The following could be guidelines
>> to what the app must do (this deals with the user-facing elements, not the
>> implementation)
>>
>> "If you'd check a specific application frequently but not in reaction to
>> notifications it raises (e.g. group chat, even if you weren't pinged
>> directly) or if it has to be accessible as quickly as possible while it's
>> running (e.g. music player, to pause music), the app should display an icon
>> in the dock while it's running.
>> If the app is primarily brought up in reaction to a notification and if
>> the state of the app doesn't significantly affect its usage frequency (e.g.
>> microblogging client - if the user tweets often they'd pin it to dock
>> anyway), it should display an icon in the dock only when there are
>> unattended action items (e.g. new messages) along with the action item
>> count in the dock badge."
>>
>> As far as implementation goes, this branch was recently merged into
>> plank, which enables preliminary support for batches and progress bars
>> without the need for an open window.
>> https://code.launchpad.net/~ricotz/plank/launcherentry-items
>> For hiding the window while keeping the dock icon visible, one solution
>> would be to make better use of minimize. The following blueprint would need
>> to be implemented:
>> https://blueprints.launchpad.net/gala/+spec/minimized-as-closed
>>
>> That's all folks.
>>
>>
>> --
>> Mailing list: https://launchpad.net/~elementary-dev-community
>> Post to : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Sergey "Shnatsel" Davidoff
> OS architect @ elementary
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help : https://help.launchpad.net/ListHelp
>
>
Follow ups
References