Aaaand the branch is merged!
But don't get too excited yet - the dock now shows the launcher not only if
it has any meaningful items, but if the D-bus interface is attached to the
launcher at all. Checks for badge and progressbar visibility are yet to be
implemented.
2013/3/20 Nishant George Agrw
https://code.launchpad.net/~ricotz/plank/launcherentry-items
The above link implements Plank's behaviour described in the following
bug:
https://bugs.launchpad.net/plank/+bug/1155790
Here are two videos showing the changes off:
http://youtu.be/G7TC9cdmuRE
http://youtu.be/y7_R6glKQhE
On Mon,
So what's the final consensus on the matter, at least for Luna? Going
ahead with the blueprint would mean:
a) Biting the bullet and finally removing explicit minimize. Minimize
will now be a technical detail transparent to the user. Close could
mean different things, whatever makes the most se
2013/3/17 Nishant George Agrwal
> On Sun, Mar 17, 2013 at 7:11 PM, Sergey Shnatsel Davidoff <
> ser...@elementaryos.org> wrote:
>
> So I believe it really depends on the app. If it has to be easier to
> access while it's running (e.g. Noise), it should display an icon in the
> dock.
>
>
> That st
On Sun, Mar 17, 2013 at 7:11 PM, Sergey Shnatsel Davidoff
wrote:
So I believe it really depends on the app. If it has to be easier to
access while it's running (e.g. Noise), it should display an icon in
the dock.
That still leaves the "not bound to a workspace" thing, which will need
patche
2013/3/17 Nishant Agrwal
> Has this been uploaded to the daily repos? I have been playing around with
> it, and it appears the batch and progress bar appear even when no window
> for the app is opened, but this only works for launchers that are already
> pinned in the dock. Apologies if I have sp
2013/3/16 Daniel Fore
> So, we should now have solved the problem of showing badges or
> progressbars when there are no windows open.
>
Only if the app is pinned to the dock. The other report still stands:
https://bugs.launchpad.net/plank/+bug/1155790
> So the remaining issue seems to be: If a
Has this been uploaded to the daily repos? I have been playing around
with it, and it appears the batch and progress bar appear even when no
window for the app is opened, but this only works for launchers that
are already pinned in the dock. Apologies if I have spoken too soon and
the update ha
Okay so it looks like Rico implemented one of those reports already.
That was fast! So, we should now have solved the problem of showing
badges or progressbars when there are no windows open.
So the remaining issue seems to be: If an app can be run in the
background, should it's icon be presen
> 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
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 h
On Fri, Mar 15, 2013 at 6:07 AM, Sergey Shnatsel Davidoff
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 h
Okay, good. Now having said that, you would prefer to have Noise
minimize if the music was playing instead of closing (from the UI
standpoint this would mean that the dock icon is still visible) simple
because the quick access to the icon would be needed to pause the music
or select a new song.
2013/3/15 Nishant Agrwal
> Shnatsel, assuming your blueprint implemented, would the following be a
> correct summation of your desired behaviour? I am assuming that none of the
> mentioned apps are pinned to the dock.
>
> - user logs in, and several daemons start up and check for events.
> - when
Shnatsel, assuming your blueprint implemented, would the following be a
correct summation of your desired behaviour? I am assuming that none of
the mentioned apps are pinned to the dock.
- user logs in, and several daemons start up and check for events.
- when the daemons detect an event of int
>
> 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 sh
Yea, I mean personally I have media keys on my keyboard, but I would assume
(though I'm not sure) that system media controls are going to be important
in the tablet workflow.
touché with indicators-never-launch-apps. But realistically they do launch
apps already :p I think more accurately, indicat
As a data point, I never use the sound indicator for anything besides
adjusting volume. I can't put my finger on why, and I've certainly tried;
however, I always find myself going back to the application to control the
application. Again, this is just my data point. :)
On Wed, Mar 13, 2013 at 10:
2013/3/13 Daniel Foré
> Yea except that you can already access it quickly through the sound
> indicator.
>
That requires more clicks and much higher precision of cursor navigation.
Fitts' law in action.
Besides, I doubt that opening music player through that indicator
sufficiently discoverable.
Yea except that you can already access it quickly through the sound indicator.
If you really want to access it quickly on the dock, you can just pin the app.
Best Regards,
Daniel Foré
El mar 13, 2013, a las 7:10 a.m., "Sergey \"Shnatsel\" Davidoff"
escribió:
> The reason I pushed for minimizi
Yes
Best Regards,
Daniel Foré
El mar 12, 2013, a las 10:54 p.m., Nishant Agrwal
escribió:
> Daniel, so if I understand you right, you are supportive of the hide/unhide
> behaviour as opposed to the current minimize solution?
>
> On Wed, Mar 13, 2013 at 2:13 AM, Daniel Foré wrote:
>> I grew
The reason I pushed for minimizing in Noise instead of closing to make its
icon remain in the dock so that it can be accessed easily as long as the
music keeps playing.
2013/3/13 Daniel Foré
> I grew with Nishant that Noise should in fact close its window rather than
> minimize it. Having it bou
Thank you Victor. That really solves things in my case. Still, I feel
this is something we should discuss, perhaps after the Luna cycle.
On Wed, Mar 13, 2013 at 12:24 PM, Victor
wrote:
FWIW...
$ sudo apt-get install dconf-tools
$ dconf write
/org/pantheon/noise/settings/minimize-while-playi
FWIW...
$ sudo apt-get install dconf-tools
$ dconf write /org/pantheon/noise/settings/minimize-while-playing-shells "['']"
On Tue, Mar 12, 2013 at 7:53 AM, Nishant Agrwal
wrote:
I was reading this page of the HIG:
http://elementaryos.org/docs/human-interface-guidelines/user-workflow/background-
Daniel, so if I understand you right, you are supportive of the
hide/unhide behaviour as opposed to the current minimize solution?
On Wed, Mar 13, 2013 at 2:13 AM, Daniel Foré
wrote:
I grew with Nishant that Noise should in fact close its window rather
than minimize it. Having it bound to a w
I grew with Nishant that Noise should in fact close its window rather than
minimize it. Having it bound to a workspace is definitely not what I expect to
happen.
But like Nishant, I don't interact with the music player window very often. In
fact, on my phone I use the system player controls and
It's just weird to me that closing Noise doesn't have the same result as
closing everything else. I understand what it's going for, I think I just
don't have the workflow it expects or something. Let's see what design team
says about your feedback.
On Tue, Mar 12, 2013 at 10:36 AM, Nishant Agrwal
Could you elaborate on why you didn't like it?
Here's my rationale for proposing the closing/hiding behaviour:
I think the way most people use music players is - start the player,
choose the song, and close the window. Basically, the player window's
only functionality is to allow choosing the
After using it a while, I decided I don't like this behavior.
On Tue, Mar 12, 2013 at 8:53 AM, Nishant Agrwal <
nishantagrwal12...@gmail.com> wrote:
> I was reading this page of the HIG:
>
> http://elementaryos.org/docs/human-interface-guidelines/user-workflow/background-tasks
>
> I couldn't hel
I was reading this page of the HIG:
http://elementaryos.org/docs/human-interface-guidelines/user-workflow/background-tasks
I couldn't help noticing that the page specifically mentions the
expected behaviour from a music player, yet Noise minimizing instead of
hiding the window completely. Just
30 matches
Mail list logo
