Re: [Ayatana] File transfer dialog behaviour

2010-05-11 Thread Alex Launi
This is actually addressed in a Gnome summer of code project for this
summer[0].
If that project turns out, this discussion should to go to the desktop-devel
list and it packaged into main.

Until there's a product there's not much to do except observe, and maybe
contribute.

For now maybe we should (as a project) watch that project, and help give
suggestions and patches along to way to serve our agenda, and help upstream.

[0]
http://home.in.tum.de/~sickert/archives/2010/05/09/introducing_my_gsoc_project/index.html

-- 
-- Alex Launi
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


[Ayatana] Sound Menu

2010-05-11 Thread Tyler Brainerd
Looking at the mockups for the new SoundMenu
design,
which looks great, my one concern is for consistency. Right now, with all
the new applets, we have a myriad of inconsistent behavior, and this will
only worsen as we make things more complicated. For instance, in the mockups
and in current use, we have toggles that, in some cases, add a left hand
margin check mark, such as with the play button in rhythmbox applet, and in
others, it changes the text, like in the current sound applet. I say get rid
of the check mark, and make it change between play/pause, but looking at the
mockups, this will only get worse. Can we please discuss specific ruling
functions in these applets so we don't have a full on widget on the panel?
Currently, we only have Vertical layered controls. Each vertical row
contains one function, and ought to be indicated in consistent ways (i.e.,
the triangles for running programs, the dots for status, the check for
play/pause, sometimes the icon changes...) and I think its going to mess up
that consistency with adding horizontal functions as well. part of the
reason these applets are great is the ability to use pretty fast keyboard
shortcuts to control things, and being the literally every single one so far
has only vertical, lets not add the horizontal (i'm referring specifically
to the next and previous buttons on either side of the play button).

After the rows, we really need to get the indications cleaned up. Lets make
some firm decisions about what means 'This program is open!' what means
'this feature is on/off' and what doesn't, in all the menus. The mockups
show no check marks, thats good. Get rid of all of them, unless actual
indicating is needed (like the status selector).
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] File transfer dialog behaviour

2010-05-11 Thread Jonathan Blackhall
On Tue, May 11, 2010 at 5:37 PM, Jarlath Reidy  wrote:
> If this is the wrong forum to bring this up, apologies in advance:
>
> I'm wondering if the current form of the file-transfer dialog is up for
> discussion. I wanted to dismiss this dialog (see attachment). I was fairly
> certain that the red X to the right would abort the copy operation, so I
> didn't click that.
>
> But what about the red x on the top left of the window? It could cancel the
> operation. Then I thought 'when I close nautilus, it doesn't delete all my
> files. It just dismisses that view of my filesystem.' - so it probably just
> closes the window without effecting the operation.
>
> Then I thought 'But this is an operation dialog, not a passive window
> interpreting a view of the system.'
>
> I clicked it anyway, and sure enough - I was safe. Could this dialog be
> improved? A file transfer is a more delicate operation than say, Rhythmbox
> playing music and some reassurance from the interface would have made the
> experience far more comfortable before taking the plunge and clicking on
> that. I can live with my music stopping, but I don't want to restart a large
> transfer.
>
> I know, I could have minimized it. But I guessed from the panel indicator
> that I had a better option, which we do. Should it be publicised a bit more?


I think this is actually similar to the issue I emailed about
yesterday.  Although you say that this situation is different from
Rhythmbox, it's only apparently different in the sense that it's
easier to test what will happen when you're not afraid of the
consequences.

I'm more and more intrigued by the idea of using Windicators (such as
maybe an "eye icon") as a means of "hiding" a window (where
applicable) but continuing the current operation from background
process and being accessible by an indicator applet, such as the file
transfer applet as you're suggesting.  Of course a "show" option for
the window should also be accessible from the indicator applet, such
as is present in the Rhythmbox applet currently.

Jonathan

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


[Ayatana] Combo Indicator Applets

2010-05-11 Thread Jonathan Blackhall
With the announcement of the Sound Indicator, I see that the functions
of the current Rhythmbox IA and Banshee IA will essentially be
available via this new Sound IA.  Will the Rhythmbox and Banshee IA's
be removed when this is in effect?  Otherwise I feel like there will
be a lot of overlap in function between these individual applets and
the sound applet.

Jonathan

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] File transfer dialog behaviour

2010-05-11 Thread Conscious User

> I'm more and more intrigued by the idea of using Windicators (such as
> maybe an "eye icon") as a means of "hiding" a window (where
> applicable) but continuing the current operation from background
> process and being accessible by an indicator applet, such as the file
> transfer applet as you're suggesting.  Of course a "show" option for
> the window should also be accessible from the indicator applet, such
> as is present in the Rhythmbox applet currently.

I like that. The "eye" symbol is quite intuitive and has been
traditionally been used that way in layer-based graphic editors.



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] File transfer dialog behaviour

2010-05-11 Thread Luke Morton
On Wed, 2010-05-12 at 08:13 +0200, Conscious User wrote:
> I like that. The "eye" symbol is quite intuitive and has been
> traditionally been used that way in layer-based graphic editors.

I'd avoid using an eye for the same reasons the GNOME HIG recommends
against them:
http://library.gnome.org/devel/hig-book/stable/icons-design.html.en

Luke.


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Combo Indicator Applets

2010-05-11 Thread Conscious User

Le mardi 11 mai 2010 à 22:31 -0500, Jonathan Blackhall a écrit :
> With the announcement of the Sound Indicator, I see that the functions
> of the current Rhythmbox IA and Banshee IA will essentially be
> available via this new Sound IA.  Will the Rhythmbox and Banshee IA's
> be removed when this is in effect?  Otherwise I feel like there will
> be a lot of overlap in function between these individual applets and
> the sound applet.

That's not necessarily a bad thing in the short term. Regardless of
how awesome you are convinced you new idea are, I think it's
important to make a smooth transition and, at least for a while,
allow easy reversal to old behavior to avoid (quoting Martin Owens)
fanning the flames of resistance to change.

For example, I personally believe that the fact that AppIndicators
gracefully degrade to the notification area was a major step in
the long and winding road of making them universally used upstream.

On the opposite side, aggressively patching Empathy and not doing
any kind of graceful degradation when the messaging menu is not
present (and/or notify-osd is uninstalled in favor of the old
notification-daemon) was a major step in irritating some Empathy
users *and* developers and making sure they never care about
trying the messaging menu, notify-osd or even Ubuntu again.

So I vote for keeping the IA's and making them optional. Actually,
they are *already* optional, so no real work needed.

Ayatana developers should keep in mind that some people will be
upgrading from systems *without the indicator-applet*, and not
caring about those people is not good PR:

http://blogs.gnome.org/xclaesse/2010/04/01/ubuntu-lucid-indicate/
https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/552543



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp