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
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
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
2013/3/16 Daniel Fore dan...@elementaryos.org
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
2013/3/17 Nishant Agrwal nishantagrwal12...@gmail.com
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
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 still leaves the not bound to a workspace thing,
2013/3/17 Nishant George Agrwal nishantagrwal12...@gmail.com
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
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
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
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
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
2013/3/15 Nishant Agrwal nishantagrwal12...@gmail.com
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
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
On Fri, Mar 15, 2013 at 6:07 AM, Sergey Shnatsel Davidoff
ser...@elementaryos.org 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
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
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
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é dan...@elementaryos.org
I grew with Nishant that Noise should in fact close its window rather than
Yes
Best Regards,
Daniel Foré
El mar 12, 2013, a las 10:54 p.m., Nishant Agrwal
nishantagrwal12...@gmail.com 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,
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
ser...@elementaryos.org escribió:
The reason I
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
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 help
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
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
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é dan...@elementaryos.org
wrote:
I grew with Nishant that Noise should in fact close its window rather
than minimize
24 matches
Mail list logo
