elementary-dev-community team mailing list archive
Mailing list archive
Re: Background apps discussion
Rico has completed implementation of the dock part - it's already
available in PPA - and Ubuntu One happens to support it!
is left to do, most of which sounds quite trivial and some items are
So, any objections on the design?
2013/3/30 Nishant Agrwal <nishantagrwal12993@xxxxxxxxx>:
> On Sun, Mar 24, 2013 at 11:33 PM, Cassidy James <cassidy@xxxxxxxxxxxxxxxx>
> 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,
>> 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:
>>> 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
>>> "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.
>>> 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:
>>> 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
> 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