Re: [Ayatana] "fileless" paradigm (was: File menu)
On Thu, 2010-11-11 at 23:25 +0100, fain182 wrote: > 2010/11/11 frederik.nn...@gmail.com : > > here imo, especially considering the "fileless" paradigm we are > trying to > > introduce into userland. > What is it? can i find it in a document? > ( BTW defining something by negation, puzzles me I would be careful with how you introduce a file-less paradigm. In order to do so you'll need a cast-iron items and collections system with all sorts of concept access systems like tagging, event access and cross linking with user items. In Ubuntu we have no developers working on these systems, and I didn't see enough UDS time devoted to solving any of those problems either. Even android and iphone's systems which are a thousand times stronger than Ubuntu's are too weak to support real file-less paradigms. I remain very unconvinced that we are in any shape to offer this feature and I fear that people are looking at a dream before they can see the path that leads us there. Until we spend time adding in all the required features, removal of file access will equate with removal of functionality which will cripple workflows and destroy rich data access for many use cases. 2 cents. Martin, ___ 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] "fileless" paradigm (was: File menu)
2010/11/11 frederik.nn...@gmail.com : > here imo, especially considering the "fileless" paradigm we are trying to > introduce into userland. What is it? can i find it in a document? ( BTW defining something by negation, puzzles me ) -- pietro ___ 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] hearphones indicator?
On Thu, 2010-11-11 at 20:11 +0100, dani wrote: > https://wiki.ubuntu.com/Artwork/Incoming/Maverick/heardphones% > 20indicator%20%28daniel%20planas%29 The headphone icon replacing the speaker, if headphones are plugged in and other output muted because of that, looks like a good idea. > PD: i write on maverick incoming because natty isn't open yet. You mean there is no Artwork/Incoming/Natty. That's because none of the few people who took care of that for previous cycles did this time. Personally, I won't do it, as collecting stuff there wasn't of much use in the Maverick cycle. Mid to long term, we need something better than the wiki to manage assets (screenshots, sketches, mockups, videos ...). You could move your stuff over to https://wiki.ubuntu.com/Ayatana seeing how you post here and not in ubuntu-art, but that's a bit of a mess, too :} I feel bad about this wiki situation, but I had to give up on organizing /Ayatana and /Artwork, as it eats too much time and returns so little. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ 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] hearphones indicator?
https://wiki.ubuntu.com/Artwork/Incoming/Maverick/heardphones%20indicator%20%28daniel%20planas%29 PD: sorry for the bad link > -- > daniel planas.a > www.lightgraphite.com > > ___ 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] hearphones indicator?
today ubuntu indicators probably replace the old notification area, and this is great!!. But we must to do it indicators more intelligent. We must ensure that it can do anything humans need. One of the shortcomings i can find is that heardphones not indicates. i create some mockups of how it could fix, hope you like them. https://wiki.ubuntu.com/Artwork/Incoming/Maverick/heardphones% 20indicator%20%28daniel%20planas%29 PD: i write on maverick incoming because natty isn't open yet. -- daniel planas.a www.lightgraphite.com ___ 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] Sound Menu
and yeah.. the speaker icons to the left and to the right of the volume slider should receive visual focus on hover, according to how i understand consistency in the careful treatment of threefold horizontal control elements in Sound Menu.. What do you think? Some sort of indication that the volume slider is active would be good, yes. There is already a bug against IDO for this -> https://bugs.launchpad.net/ido/+bug/524541 ___ 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] Sound Menu
On 11/11/10 12:21, frederik.nn...@gmail.com wrote: > and yeah.. the speaker icons to the left and to the right of the > volume slider should receive visual focus on hover, according to how i > understand consistency in the careful treatment of threefold > horizontal control elements in Sound Menu.. What do you think? Some sort of indication that the volume slider is active would be good, yes. signature.asc Description: OpenPGP digital signature ___ 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 menu
On Wed, Nov 10, 2010 at 13:20, Matthew Paul Thomas wrote: > > Arian van Gend wrote on 09/11/10 12:16: > > > > Besides, the File menu has been overloaded with actions that have > > nothing to do with files anyway, and should therefore at least be > > cleaned up. > > As a menu title, "File" is not a noun. It's a verb, just like "Edit", > "View", "Go", "Insert", and "Format" are. > I agree. At least that's what makes sense. Unfortunately the capitalization doesn't support this interpretation in the mist of ambiguity.. Not only translators but also users ( English, French, German, Lithuanian, Russian) and most programmers i ever spoke to (in German) misinterpret the word for naturally being meant as a noun. (to) file makes more sense in interpretation, then again i don't see how this menu deserves to have this sort of a pole position in many non-office apps, while the more important features of these respective apps are hidden in a fourth, fifth or even sixth menu, way behind File, Edit, View. I think consistency is important in the first menu, the second, third and fourth menu should be context driven / per app. Some apps e.g. don't need an Edit menu, some don't need a View menu, most don't need a "Go" menu etc.. only browsers and document readers need a "Bookmarks" menu. I have a lot of stuff to say about the Edit and View menus, but i think its better to focus the File menu as well as possible in here. Cracking that nut will solve a lot of design problems to me. (to) file something makes sense for editable office documents, rather less for movies, single audiofiles etc. In case of non editable none office documents (perhaps someone can correct me a little here), "file" would suffice as a button which offers only "save as". For an editable document: *save *save as *close (i.e. close application) *open (recent, [Pinned Item1, Pinned Item2]) *print even if so, i would still prefer calling the menu by what it actually encompasses: either "Document" or [document type], i.e. "Song", "Movie", "Image", "Animation" or "Design".. File or (to) file wouldn't be so helpful titles here imo, especially considering the "fileless" paradigm we are trying to introduce into userland. The great thing i like most about testing Indicator Appmenu is that sometimes all i get for a menu is "File", nothing more. This gives me a glimpse at how lean and simple application menus could become one day, of course with a more meaningful title then! Best example remains Calculator, with its "Calculator" menu instead of "File". This is a noun and it makes sense. ___ 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] Sound Menu
and yeah.. the speaker icons to the left and to the right of the volume slider should receive visual focus on hover, according to how i understand consistency in the careful treatment of threefold horizontal control elements in Sound Menu.. What do you think? On Thu, Nov 11, 2010 at 13:18, frederik.nn...@gmail.com < frederik.nn...@gmail.com> wrote: > Thanks Conor, > > On Wed, Nov 10, 2010 at 17:12, Conor Curran wrote: > >> Hey folks, >> >> >> It might be specced, but it's not implemented. I didn't find a bug for >> that yet, so here's a new one: >> "no visible focus on horizontal controls" >> https://bugs.launchpad.net/indicator-sound/+bug/673185 >> >> the keyboard controls don't work for me, yet, i guess that's still in >> the making, is it? >> >> >> Conor is the right person to ask on this! >> >> Yes the keyboard handling and hover behaviour of the play/skip button has >> yes to be implemented. >> I did make an attempt late in the Maverick cycle to get this done but was >> unhappy with results. >> I do hope to get this into Natty for Alpha1 (3 weeks!) >> > > looking forward to an even better experience .. yeah! > > Since this is about horizontal control elements, how about using the same > concept for the "Output Volume Item", too? > The spec says (about the volume to zero button): > > A borderless, mouseover-less button that sets the volume to zero (as >> distinct from muting it). The icon for the button should >> be audio-volume-low-zero(in the default theme, a speaker with no sound >> waves). > > > Does this mean that the entire "Output Volume Item" will receive visible > focus on hover? > Spec says the following about the entire row: > > The item should highlight when navigated to, or on mouseover, just as >> normal menu items do, but the item should not be activatable (clicking it or >> pressing Enter should not close the menu) > > > Semantically correct would be to light up the "Output Volume to Zero" item > briefly upon CTRL+LEFT, equivalently the same for CTRL+RIGHT, if i'm not > completely mistaken.. And of course to highlight only the fader at first > when the "Output Volume Item" is navigated to. > > My shot at this is that the Spec needs to be updated for consistency in > this little place.. > Thoughts? > ___ 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] Sound Menu
Thanks Conor, On Wed, Nov 10, 2010 at 17:12, Conor Curran wrote: > Hey folks, > > > It might be specced, but it's not implemented. I didn't find a bug for > that yet, so here's a new one: > "no visible focus on horizontal controls" > https://bugs.launchpad.net/indicator-sound/+bug/673185 > > the keyboard controls don't work for me, yet, i guess that's still in the > making, is it? > > > Conor is the right person to ask on this! > > Yes the keyboard handling and hover behaviour of the play/skip button has > yes to be implemented. > I did make an attempt late in the Maverick cycle to get this done but was > unhappy with results. > I do hope to get this into Natty for Alpha1 (3 weeks!) > looking forward to an even better experience .. yeah! Since this is about horizontal control elements, how about using the same concept for the "Output Volume Item", too? The spec says (about the volume to zero button): A borderless, mouseover-less button that sets the volume to zero (as > distinct from muting it). The icon for the button should > be audio-volume-low-zero(in the default theme, a speaker with no sound > waves). Does this mean that the entire "Output Volume Item" will receive visible focus on hover? Spec says the following about the entire row: The item should highlight when navigated to, or on mouseover, just as normal > menu items do, but the item should not be activatable (clicking it or > pressing Enter should not close the menu) Semantically correct would be to light up the "Output Volume to Zero" item briefly upon CTRL+LEFT, equivalently the same for CTRL+RIGHT, if i'm not completely mistaken.. And of course to highlight only the fader at first when the "Output Volume Item" is navigated to. My shot at this is that the Spec needs to be updated for consistency in this little place.. Thoughts? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
