Re: [Ayatana] Application Bucket(AppStasher)
On Mon, May 17, 2010 at 1:54 AM, Tyler Brainerd tylerbrain...@gmail.comwrote: what sort of programs need this space? On Sun, May 16, 2010 at 10:34 AM, Akshat Jain ssj6akshat1...@gmail.comwrote: With the coming of Notify-OSD and soon to come Windicators the only function of Notification area left is Minimize to Tray A.K.A T3(Trash The Toolbars),Which IMO is worst thing ever thought by mankind(note:Not the Minimize to Tray concept but putting the icons in Toolbars without my permission and cluttering the toolbar with it) but we still need somewhere to hide the apps,So why not replace it with something new and Innovative?And the Idea of an Application Bucket or App Stasher came to my mind. (Not needed on Unity as it has a Dock/Launcher) I imagine it to be an Applet residing in the panel when user clicks the Applet a drawer pops out and user can drag the application and stash it there,When the app needs indication a notify-osd bubble pops up(suggested by me) or the drawer button blinks and rapidly changes to the application's icon(suggested by Sense Hofstede). Now what needed is some feedback and some pretty mockups -- I am 13 year old and make a lot of typos. I am a non-native english speaker. I will never answer emails half-asleep again. I love Ubuntu. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp Applications which minimize to tray.They can still be hidden in Application Bucket to save space without cluttering the panel since they aren't notificative anymore as Notification work is handled by Notify-OSD and soon Windicators. -- I am 13 year old and make a lot of typos. I am a non-native english speaker. I will never answer emails half-asleep again. I love Ubuntu. ___ 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] Thoughts on quitting and window controls
This is a copy of a message I sent to ubuntu-devel-discuss last month. After Matthew Paul Thomas' post on the Canonical Design blog (http://design.canonical.com/2010/04/notification-area/), other users expressed similar sentiments. I was just curious if Ayatana members had any additional thoughts. I understand that many of you are also subscribers to ubuntu-devel-discuss, so I apologize if you're getting this message twice. I've also added some more thoughts after the break. - It's very confusing for me when I click the big 'X' in my window controls, only to find that the application I was attempting to close has since been minimized to my system tray (or notification area or its respective indicator applet or wherever it goes instead of quitting). Examples of programs with this behavior include Rhythmbox and Empathy in the default install. To me, the 'X' signifies closing and quitting the application. If I wanted to minimize it and keep it open, I would think to click the 'Minimize' button before clicking the 'X'. In fact, I'd argue that the only reason anyone thinks this is appropriate is because it's what's been done in the past. The reason I find this so frustrating is because in order for me to eXit an application, I have to go searching through menus (File-Quit) or know some fancy keyboard shortcuts (things that casual users never even think about). I can only assume that developers' theories behind this (which is definitely not a problem unique to Ubuntu) stem from them telling themselves that no one would actually want to Quit their application. What they *really* mean to do is close the window, but keep the application running silently. So I'll just save them the trouble of accidentally quitting by changing the function of that 'X' button. I just dislike the fact that it sends mixed signals. After all, if I click 'X' in Firefox or in gEdit or in a whole host of other applications, I'm quitting and completely closing it. Why must this be different in Rhythmbox? And also, when I install a new application, what is the 'X' going to do when I click it in this application? I'm not exactly sure what I'd propose to fix this problem. I really just think that the current way is broken. Maybe the function could be switched to the Minimize button, but that would likewise exhibit ambiguity, although I'd argue less so than the current incarnation. Maybe there should be a new window button, but that doesn't seem like a very elegant solution either. I thought about filing this as a bug, but then I thought it might be better to generate discussion amongst developers. What are your thoughts? Do you consider the current situation a problem? If so, what do you propose to fix it? Cheers, Jonathan - After some discussion on ubuntu-devel-discuss, I do understand that the 'X' means close the current window and it's up to the application to decide whether it makes sense to keep running in the notification area (or its indicator applet). It's definitely is nice to let something such as Rhythmbox or Empathy run without needing the window open. I outlined 2 of my biggest concerns later: The current behavior can cause a number of problems. As other users pointed out (and I have also experienced), sometimes you want to quit an application, such as Empathy or Gwibber, only later to find yourself still logged in, online, and maybe receiving messages. Another issue is with Rhythmbox. This is especially true for newer users. Let's say I just click the 'X' to quit, just like I do with Firefox or Calculator. I don't notice that the icon is still present in the Notification Area. It's not doing any particular harm there right now. However, then I shut down my computer and come back the next day. I open Rhythmbox, and it starts minimized to the Notification Area. I'm sitting there waiting patiently for it to open, but it never does. Now you could argue that this is a bug in Rhythmbox (and it has been reported), but my point is that it highlights an underlying problem of an application not quitting when the user wants it to. I guess I'd summarize my concern as: 1. It should be possible to completely quit an application by clicking a single button on the window controls. 2. When you're not completely quitting an application, that fact should be unambiguous to the user. 3. If an application is going to start solely in the Notification Area (or Indicator Applet) without opening a window, the user should know and expect that's going to happen and know where/how to open the application's window should they need to. After reading Mark's post yesterday (http://www.markshuttleworth.com/archives/333) I began to wonder whether this was a great opportunity for his Windicators. For example, something like the eye button seems like it would be an interesting way to hide a window, but still have the application accessible via its indicator applet. Cheers, Jonathan
[Ayatana] Move indicator-session to the left?
The reasoning behind the controversial button movement to the left was that starting/quitting would be on the left, and status would be on the right. Given that reasoning, for consistency sake shouldn't indicator-session go on the far left since it is for starting/quitting an entire session? _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2___ 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] GSoC '10 Idea : NotifyOSD improvements
Hey, all. I posted a GSoC project Idea on the ubuntu-soc list yesterday and I thought it'd be more appropriate if I run it down by developers in the Ayatana list. https://lists.ubuntu.com/archives/ubuntu-soc/2010-March/47.html Some of the things that this project could help solve : 1.) Make the OSD customizable * setting up persistence time * UI modifications over a basic structure * Font size/style ...other similar stuff we can decide upon. 2.) Most of the above things would be customized by an OSD Manager that could handle all those by a native GTK+ application. 3.) Implementing unresolved work in the Design Specs. A few design features that I have in mind (possibly conflicting from the specs in the wiki) : 1.) Stacking, that'd make the bubbles dock downwards as they are initiated and start to stack up as the bubble times finish away. 2.) A close button on the corner of the bubble as soon as a mouseover occurs (like Growl, instead of disappearing away) 3.) Some other ideas? It could either be a combination of new features and the proposed customizability improvements or just the latter. How feasible do you think it is? (possible additions/subtractions?) -- 4, 8, 15, 16, 23, 42 ___ 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] XDG Base Directory spec
-Original Message- From: Mark Shuttleworth [mailto:m...@ubuntu.com] Sent: Thursday, March 25, 2010 1:22 PM To: Krzysztof Klimonda Cc: ayatana@lists.launchpad.net; Waldo Bastian Subject: Re: [Ayatana] XDG Base Directory spec On 25/03/10 20:05, Krzysztof Klimonda wrote: On Thu, 2010-03-25 at 19:49 +, Mark Shuttleworth wrote: Also from Jo: In order to clean up, perhaps Canonical and Ubuntu would consider a much louder support for XDG Base Directory Specification? Many developers are hesitant to follow it, perhaps a strong leadership is required there as well? This seems like a real win, too. Looks like quite a few apps do support it. This sort of thing is useful for us to say is a requirement for main inclusion in the next LTS, to try an accelerate adoption. Hey, Thanks for rising this subject on the mailing list. I'd love to read some discussion about implementing this specifiation. Although I'm a big fan of the XDG Base Dir specification there are few ambiguities that should be resolved before we ask everyone to follow it The thing I have on my mind is described in the http://bugs.launchpad.net/bugs/466541 (most important is the 4th comment made by the Transmission developer). If XDG_DATA_HOME is supposed to be used just as the /usr/share/ is used then it is currently misused by applications and the whole specification is questionable (if people are following it only partially then it creates just as much confusion as if they weren't following it at all). If it's supposed to be a directory where developers are supposed to save all files that are not configuration but are important to the application then it also should be stated clearly. Thanks for the pointer. I commented on the bug that I don't understand the confusion. Have cc'd Waldo Bastian, the author of the spec, to ask if he can shed any light. It does seem like the guidance as to what goes into which directory could be clarified and examples provided, especially for tricky things. Maybe that would justify a 0.9 version of the spec :-) Waldo? Mark XDG Base Directory spec is intended for use by other specification. For example the XDG Menu specification and Autostart specification refer to the XDG Base Directory specification instead of reinventing their own filesystem locations / hierarchy. Cheers, Waldo ___ 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] XDG Base Directory spec
-Original Message- From: Krzysztof Klimonda [mailto:kklimo...@syntaxhighlighted.com] Sent: Thursday, March 25, 2010 1:35 PM To: Bastian, Waldo Cc: Mark Shuttleworth; ayatana@lists.launchpad.net; Waldo Bastian; Charles Kerr Subject: RE: [Ayatana] XDG Base Directory spec On Thu, 2010-03-25 at 13:30 -0700, Bastian, Waldo wrote: -Original Message- From: Mark Shuttleworth [mailto:m...@ubuntu.com] Sent: Thursday, March 25, 2010 1:22 PM To: Krzysztof Klimonda Cc: ayatana@lists.launchpad.net; Waldo Bastian Subject: Re: [Ayatana] XDG Base Directory spec On 25/03/10 20:05, Krzysztof Klimonda wrote: On Thu, 2010-03-25 at 19:49 +, Mark Shuttleworth wrote: Also from Jo: In order to clean up, perhaps Canonical and Ubuntu would consider a much louder support for XDG Base Directory Specification? Many developers are hesitant to follow it, perhaps a strong leadership is required there as well? This seems like a real win, too. Looks like quite a few apps do support it. This sort of thing is useful for us to say is a requirement for main inclusion in the next LTS, to try an accelerate adoption. Hey, Thanks for rising this subject on the mailing list. I'd love to read some discussion about implementing this specifiation. Although I'm a big fan of the XDG Base Dir specification there are few ambiguities that should be resolved before we ask everyone to follow it The thing I have on my mind is described in the http://bugs.launchpad.net/bugs/466541 (most important is the 4th comment made by the Transmission developer). If XDG_DATA_HOME is supposed to be used just as the /usr/share/ is used then it is currently misused by applications and the whole specification is questionable (if people are following it only partially then it creates just as much confusion as if they weren't following it at all). If it's supposed to be a directory where developers are supposed to save all files that are not configuration but are important to the application then it also should be stated clearly. Thanks for the pointer. I commented on the bug that I don't understand the confusion. Have cc'd Waldo Bastian, the author of the spec, to ask if he can shed any light. It does seem like the guidance as to what goes into which directory could be clarified and examples provided, especially for tricky things. Maybe that would justify a 0.9 version of the spec :-) Waldo? Mark XDG Base Directory spec is intended for use by other specification. For example the XDG Menu specification and Autostart specification refer to the XDG Base Directory specification instead of reinventing their own filesystem locations / hierarchy. Cheers, Waldo Hey, Thanks for your comment. Does it mean that there should be yet another specification for data saved by applications that do not fit into any of the base directories? If there is a reason to care where applications save all or part of their data (beyond the FHS), then one could write a spec that outlines where applications should put what and one could express those locations using the XDG Base Directory spec. One reason to care about file locations is if multiple independent applications need to be able to access the same information. Cheers, Waldo ___ 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] XDG Base Directory spec
On Thu, Mar 25, 2010 at 3:53 PM, Bastian, Waldo waldo.bast...@intel.com wrote: If there is a reason to care where applications save all or part of their data (beyond the FHS), then one could write a spec that outlines where applications should put what and one could express those locations using the XDG Base Directory spec. One reason to care about file locations is if multiple independent applications need to be able to access the same information. Cheers, Waldo There seems to be reasonable disagreement about how XDG models the FHS wrt XDG_DATA_HOME. I've had users suggest that Transmission save .torrent files to XDG_DATA_HOME, and Mark interpreted it as a place for data that the app writes during the users use of it, which is not data that the user explicitly saved somewhere (i.e. not data the user would open through File-Open). On the other hand, several people at the XDG mailing list assert that it mirrors /usr/share. For example Thomas Leonard wrote it should only be written to when installing software. The user should only have to backup CONFIG. and Mark McLoughlin wrote editors shouldn't be editing .desktop files by making a copy with the same file ID and putting them in ~/.local/share/applications. $XDG_DATA_HOME, AFAICT, is for application data, not user configuration files. To show a concrete problem with doing it this way, if you installed a vim package in your home directory, you'd expect the package to install vim.desktop in ~/.local/share/applications, overriding the user's changes. Neither interpretation is new, and both groups of people are well-reasoned, so perhaps the best solution would be to reduce ambiguity in the spec. That aside, FWIW I agree with the idea of Ubuntu getting behind a (clarified) XDG spec. cheers, Charles ___ 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] new list member
hello there i'm new to this list i just decided to write this introductory message, in case it works: my name is Nnaji, i'm currently testing lucid on about a dozen boxes and would like to hear/discuss the numerous usability issues at hand.. i came across this here while looking for where to subscribe: *Policy:* You must be a team member to subscribe to the team mailing list. what is it with this? ___ 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] XDG Base Directory spec
Please, also note that there is a conflict about thumbnails between XDG Base Directory spec and Thumbnail Managing Standard (1). Thumbnail Managing Standard defines a folder where thumbnails are stored and shared. A lot of applications make use of it : Nautilus, F-Spot, gThumb, GIMP... Obviously the is part of XDG_CACHE_HOME. (1) http://jens.triq.net/thumbnail-spec/ ___ 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] ApplicationIndicators design decision and its application to Rhythmbox
Hi all, I'd like to (strongly) vote against the change to Application indicators. Yes I have read https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators/ and even though the goal seem laudable, its (current) implementation is severely broken IMO. First, the implementation is broken because it heavily reduce usability in a lot of use cases. Take a simple use case: show Rhythmbox, do any rythmbox-specific action (like viewing the next songs) and hide the window. Previously, it was only a matter of two clicks on the same icon (ie very fast), now it's click, move mouse, click, mouve mouse, click. Secondly, it is currently way more inconsistent than before (how ironic given the stated goal of reducing inconsistencies). Currently, I have 6 applications in my notification area: xchat, liferea, pidgin, skype, NetworkManager and rhythmbox. They all behave the same *except* for rhythmbox: left-click = show/hide, right-click = menu with options. To that list, you can also add Tomboy, which also behaves the same even if it is an applet. How is the current situation more consistent than having rhythmbox use the same behavior as other applications as it does upstream? Thanks for reading, -- Gaëtan de Menten ___ 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] [GnomeShell] A task panel
Hi, I began a conversation on the taskbar subject on the GnomeShell milling list here: Frederik Nnaji suggest that I need to do the same here. So, here is the original message: Hi I am very confused by the task bar's death. It's very confusing my work. I change to an other application several times by minutes in order to build my mockups. I always need to go back to the overview to find the good one. Each time I go back I lose time trying to recognize the good application. Some of them have a look very close. And many Times I don't reminder from which desktop I come from. In my idea, the Overview is where your organize your work, and the fullscreen, the place where you work. Go back all the time ,It's very boring. It's give me headache too (really). In order to be constructive, I made a new little mockup here: http://nsa14.casimages.com/img/2010/05/16/100516085743593381.jpg I replace the existing calendar by a task panel. (I don't really understand the purpose of this solitary calendar.) The clock become an hotspot to get a quickly access. I add few separator in order to show the distribution between desktops I add also an access to desktop, I miss that too. Thanks for listening Kao ___ 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] Export/Import idea for Windicators
On Sun, May 16, 2010 at 6:09 PM, Frederik Nnaji frederik.nn...@gmail.com wrote: On Sun, May 16, 2010 at 14:26, Mark Shuttleworth m...@ubuntu.com wrote: For designing indicators, ask yourself: - what is the *status* I am conveying, and - what options are there to manipulate that status? If you don't have both, especially the status, don't use an indicator. Use a menu. this hammers down heavier than a 30page spec. Thanks for the clarification once again, SABDFL ;) In this case, what you are describing is really just part of the File menu. So leave it there. To be precise, Send-to, as David Siegel would probably say, please be unforgiving if am i completely wrong David?! ;) We mentioned open-with in connection with GNOME Do (ingenious) and FAYT already... I'd like me a FAYT Send-to.. dialog in Nautilus' right-click menu. Copy-to and Move-to don't consistenly offer all Places yet, which is also a shame.. i see only Home and Desktop.. How about moving a file to another person? Why does it always have to be IP, URI, folder or host? Sounds interesting :) It would be good to discuss how we could incorporate a protocol independent contact list into Unity, using the same interactions expressed i the Applications and Files places. David with a proper FAYT integration in Send-to, we could also integrate Folks [http://telepathy.freedesktop.org/wiki/Folks], a protocol independent contact list. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] Windicators
On Sun, May 16, 2010 at 1:31 PM, Mark Shuttleworth m...@ubuntu.com wrote: On 16/05/10 08:17, Akshat Jain wrote: On Mon, May 10, 2010 at 1:02 AM, Mark Shuttleworth m...@ubuntu.com wrote: On 09/05/10 07:45, akshat jain wrote: But what will happen to Windicators when I minimize windows You minimise them too. They are specifically status associated with that window - so you won't miss them. But wouldn't it be better that that the windicators show up in the window list? So I won't have to open a minimized window to just see the windicators.like I have an Image in my mind with with Compiz Live Preview like popups with Windicators instead of Window Previews. Interesting... yes, one could put a rendition of the Windicators on the windows in the Alt-TAB preview. Cool idea. David, could you make a note of that, please, in your window management file? Windicators would naturally appear in the alt-tab preview, as the preview is a complete representation of the window including content and window decorations. Are you thinking that we would make them larger or somehow emphasize them? David Mark ___ 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] Instant-messaging as an indicator menu
Nice mockup, Frederik -- keep playing with the idea, I think you could be on to something. David On Sun, May 16, 2010 at 4:02 AM, Frederik Nnaji frederik.nn...@gmail.com wrote: On Sat, May 15, 2010 at 23:43, Tyler Brainerd tylerbrain...@gmail.com wrote: I agree. Both gwibber and evolution suck hard, and the basic integration is still weak across the desktop. I have to keep a browser open pointed at my email pages anyway, because the messenging menu and evolution are inconsistent at best. I have to manually check twitter because gwibber never tells me about new posts properly. the whole thing is still messy and needs to actually integrate, not just come with panel launchers. On Sat, May 15, 2010 at 2:36 PM, Frederik Nnaji frederik.nn...@gmail.com wrote: The Social Desktop, nicely wrapped in a consistent and comfortable UI, will bring the Meercat into many a household! ;) here's the dirtiest mockup i ever made.. sorry @ SABDIZZLE, i hope this shot doesn't hurt your knightly eyes ;) *FAYT search field *removed the semantically undefined bubble from the indicator icon let's let the blasphemy on the Me Menu begin :D ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] Evolution
I wrote in length at OMG! Ubuntu about the current weakness of Evolution, but I figured I ought to bring it up here as well, specifically in a few areas concerning primarily Ayatana. There have been numerous bug reports about the crappy behavior of Evolution with the messenging applet, and we really seriously need to get these things fixed by 10.10. Specifically, Evolution behaves completely opposite form all the other apps in the applet, as it must have a window open to work, while the others all close to the applet. We can argue back and forth about which is the right way to do it, but we need to make them all the same now and we can argue about which way later. Consistency now and then we'll change them all as a whole. Secondly, because of the fact that it doesn't close to the applet, then when new messages show up, and you click it, nothing happens. If its on a different workspace, you don't move there, and it opens the main window rather then the message itself. Again, totally inconsistent and really obnoxious. When I get new messages in Empathy and I click the new message in the applet, then just that conversation opens, not my friends list. Evolution should follow suit. So true. It would be very great if these issues get addressed in 10.10. Please add support for Thunderbird, too. ___ 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] Intuitive
It's very nice to see some discussion about the way we discuss user experience! It's the kind of reflection we sorely need if we want the Ayatana list to become more effective. Thorsten, can you recommend any literature on this topic? Would you be interested in co-authoring a document that would help people understand how to structure productive conversations on this list? Just to throw in my $0.02, other words and phrases that should be discouraged are: * subjective (this is almost always used incorrectly) * IMHO (we need less humility, more bravado!) David On Sun, May 16, 2010 at 12:20 AM, Frederik Nnaji frederik.nn...@gmail.com wrote: Grüß Gott, Thorsten ;) 2010/5/14 Thorsten Wilms t...@freenet.de: This is totally unrealistic. Humans can't even walk or talk without learning. Some say the nipple would be the only intuitive interface. I've been told that not even breast feeding just works on first try ... you're a real entertainer ;) In all your disregard for the term, let me suggest you start seeing it as a romantic metaphor. I think we all benefit from this little excourse into official nomenclature, thanks ;) In future i will try not to use this word carelessly but still intuitively. Intuition is the fastest way someone can consciously make a correct decision. Since this is valid for humans, the AI guys will definitely pick up on this for machines also, now that we have Memristors and Virtual Swarm Intelligence out there.. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] GSoC '10 Idea : NotifyOSD improvements
On 15 March 2010 21:45, Akshay Gupta kital...@gmail.com wrote: Hey, all. I posted a GSoC project Idea on the ubuntu-soc list yesterday and I thought it'd be more appropriate if I run it down by developers in the Ayatana list. https://lists.ubuntu.com/archives/ubuntu-soc/2010-March/47.html Some of the things that this project could help solve : 1.) Make the OSD customizable * setting up persistence time * UI modifications over a basic structure * Font size/style ...other similar stuff we can decide upon. 2.) Most of the above things would be customized by an OSD Manager that could handle all those by a native GTK+ application. 3.) Implementing unresolved work in the Design Specs. A few design features that I have in mind (possibly conflicting from the specs in the wiki) : 1.) Stacking, that'd make the bubbles dock downwards as they are initiated and start to stack up as the bubble times finish away. 2.) A close button on the corner of the bubble as soon as a mouseover occurs (like Growl, instead of disappearing away) 3.) Some other ideas? How about the bubbles being more interactive. For example, the most common use of these bubbles is associated with the media players. But I find the need to be able to skip or pause songs when they are playing on shuffle. So, having play/pause, next, previous options on the bubbles would make it more useful. It could either be a combination of new features and the proposed customizability improvements or just the latter. How feasible do you think it is? (possible additions/subtractions?) -- 4, 8, 15, 16, 23, 42 ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] No application bucket needed
cringe If you are designing an interface, and suddenly you believe you need to add a bucket, this is a good sign that your initial design failed somewhere. I would encourage you to shelve the bucket and revisit your earlier assumptions. Shake things up a bit and ask yourself what could I do differently so that I don't need a 'bucket'? Challenge yourself to make a fundamental change to your design so the bucket isn't needed. As Mark pointed out, this additional entity is not needed, and the Launcher should not contain unnecessary parts! David On Sun, May 16, 2010 at 5:49 PM, Mark Shuttleworth m...@ubuntu.com wrote: My comments below are written from the perspective of Unity, because (a) that's what I'm running, and (b) that's where our design conversations can have the most immediate impact. On 16/05/10 15:30, Sense Hofstede wrote: An application bucket where you can dump applications you don't want to take space sounds like a neat idea. The applications could stay in there, even when they're running and have got the focus -- this could be indicated by placing the focus triangle at the bucket icon (the bucket icon is distinct from application by a different background colour or a border around its icon (what icon?)). The Unity Launcher shows running applications. If the app fits one of the Category Indicators, like the Messaging Menu or Sound Menu, it may also show as running there, with the same visualization (currently, a little triangle). I think it's reasonable to have apps which *don't* show in the Launcher, but are still running. I'd like to hear from MPT, cc'd, on the subject. I'm not sure if it's worth making that an explicit configuration option (those cost a knuckle at least, remember ;-)). I've seen spec's from MPT where that behavior is sometimes implicit (you close a music player window, and it keeps running in the background if a song was playing but not otherwise), but I'm a bit uncomfortable with that myself, because I'm not sure what the IM analogy would be. But I would object to a third catch-all place where windows might sometimes go, which is how I interpret your application bucket. The launcher is basically that bucket already, and Category Indicators should suffice for things which are running but which we consider more like services than applications; we don't need a third place as well. Mark ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] Tabs
On 16/05/10 21:19, Tyler Brainerd wrote: Ok. Thanks for the response. I'm assuming this means that instructions will be issued for patching all currently tabbed apps to use ctrl-tab? When you say instructions will be issued, you make me feel short on the benevolence front :-) What we'll do is demonstrate some great experiences when apps do express their tabs in a consistent fashion, and run a program working with multiple upstreams to help them get that for their users too. Mark 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] Windicators
On 17/05/10 09:50, David Siegel wrote: Windicators would naturally appear in the alt-tab preview, as the preview is a complete representation of the window including content and window decorations. Are you thinking that we would make them larger or somehow emphasize them? Yes, perhaps show them at 1:1 scale as emblems on the window previews, whatever the underlying window scale is for the reveal / alt-tab. Mark 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] Evolution
On 17/05/10 10:21, Stefan Reichel wrote: Secondly, because of the fact that it doesn't close to the applet, then when new messages show up, and you click it, nothing happens. If its on a different workspace, you don't move there, and it opens the main window rather then the message itself. Again, totally inconsistent and really obnoxious. When I get new messages in Empathy and I click the new message in the applet, then just that conversation opens, not my friends list. Evolution should follow suit. So true. It would be very great if these issues get addressed in 10.10. Please add support for Thunderbird, too. Yes, the behavior of the system-default mail client should be consistent with the system-default chat and twitter apps (they should all be able to run as services, displaying solely in the MM). And T-bird support would be fantastic, too. Anybody want to try and organise a developer project around both of those? Get out there and champion the idea, see if developers are willing to take it on? Mark 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] GSoC '10 Idea : NotifyOSD improvements
On 15/03/10 16:15, Akshay Gupta wrote: 1.) Make the OSD customizable * setting up persistence time * UI modifications over a basic structure * Font size/style ...other similar stuff we can decide upon. OK 2.) Most of the above things would be customized by an OSD Manager that could handle all those by a native GTK+ application. 3.) Implementing unresolved work in the Design Specs. A few design features that I have in mind (possibly conflicting from the specs in the wiki) : 1.) Stacking, that'd make the bubbles dock downwards as they are initiated and start to stack up as the bubble times finish away. Please, no. I would urge Mirco NOT to take patches that introduce that sort of behaviour. We are trying to build clean and tested codebases, and the more alternative pathways we support, the less maintainable it becomes. The design experience of Notify-OSD is what it is. Changing the style is one thing, changing the behaviour of the bubbles is another thing entirely. We are just NOT going to support simultaneous display, the design is queued and serialized. 2.) A close button on the corner of the bubble as soon as a mouseover occurs (like Growl, instead of disappearing away) Same. The design of Notify-OSD is specifically not clickable, and we would NOT accept patches to change that. Mark 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] GSoC '10 Idea : NotifyOSD improvements
On 17/05/10 10:43, Ashutosh Rishi Ranjan wrote: On 15 March 2010 21:45, Akshay Gupta kital...@gmail.com wrote: Hey, all. I posted a GSoC project Idea on the ubuntu-soc list yesterday and I thought it'd be more appropriate if I run it down by developers in the Ayatana list. https://lists.ubuntu.com/archives/ubuntu-soc/2010-March/47.html Some of the things that this project could help solve : 1.) Make the OSD customizable * setting up persistence time * UI modifications over a basic structure * Font size/style ...other similar stuff we can decide upon. 2.) Most of the above things would be customized by an OSD Manager that could handle all those by a native GTK+ application. 3.) Implementing unresolved work in the Design Specs. A few design features that I have in mind (possibly conflicting from the specs in the wiki) : 1.) Stacking, that'd make the bubbles dock downwards as they are initiated and start to stack up as the bubble times finish away. 2.) A close button on the corner of the bubble as soon as a mouseover occurs (like Growl, instead of disappearing away) 3.) Some other ideas? How about the bubbles being more interactive. For example, the most common use of these bubbles is associated with the media players. But I find the need to be able to skip or pause songs when they are playing on shuffle. So, having play/pause, next, previous options on the bubbles would make it more useful. No, that will be handled through the Sound Menu. Mark 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] GSoC '10 Idea : NotifyOSD improvements
On Mon, 2010-05-17 at 11:11 +0100, Mark Shuttleworth wrote: On 15/03/10 16:15, Akshay Gupta wrote: 1.) Make the OSD customizable * setting up persistence time * UI modifications over a basic structure * Font size/style ...other similar stuff we can decide upon. OK 2.) Most of the above things would be customized by an OSD Manager that could handle all those by a native GTK+ application. 3.) Implementing unresolved work in the Design Specs. A few design features that I have in mind (possibly conflicting from the specs in the wiki) : 1.) Stacking, that'd make the bubbles dock downwards as they are initiated and start to stack up as the bubble times finish away. Please, no. I would urge Mirco NOT to take patches that introduce that sort of behaviour. We are trying to build clean and tested codebases, and the more alternative pathways we support, the less maintainable it becomes. The design experience of Notify-OSD is what it is. Changing the style is one thing, changing the behaviour of the bubbles is another thing entirely. We are just NOT going to support simultaneous display, the design is queued and serialized. 2.) A close button on the corner of the bubble as soon as a mouseover occurs (like Growl, instead of disappearing away) Same. The design of Notify-OSD is specifically not clickable, and we would NOT accept patches to change that. Mark I completely agree with the no clicking and no moving around of notification bubbles. Looking at notify-osd in lucid it looks great as it is. Maybe make them a little more see through by default but other than that the behaviour is just right. --fagan ___ 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] No application bucket needed
More specifically, I'm interested in why people use minimize-to-tray instead of regular minimize. My suspicion is that it's easier to recall minimized windows by clicking on indicators than by clicking on the window list. If a window minimizes to tray instead of closing when the Close button is clicked, this just means that Close has become another Minimize button, and the tray has become another window list. Ugly! David On Mon, May 17, 2010 at 11:34 AM, David Siegel david.sie...@canonical.com wrote: We have a great metaphor that's familiar to users and already implemented: minimized windows! There's already a button on every single window dedicated to getting a window out of your way if you're not interested in the window but still want to retain it. Why aren't we using this? Why are we inventing more ways to minimize windows? There should be only one way to do it. If there's something currently flawed with how we're minimizing windows, let's fix it and make this highly visible feature useful. For starters, it's been suggested that minimized windows shouldn't appear when alt-tabbing. Do you use minimized windows? Why or why not? How do you use them? David On Mon, May 17, 2010 at 11:18 AM, Luke Benstead kaz...@gmail.com wrote: On 17 May 2010 10:52, David Siegel david.sie...@canonical.com wrote: cringe If you are designing an interface, and suddenly you believe you need to add a bucket, this is a good sign that your initial design failed somewhere. I would encourage you to shelve the bucket and revisit your earlier assumptions. Shake things up a bit and ask yourself what could I do differently so that I don't need a 'bucket'? Challenge yourself to make a fundamental change to your design so the bucket isn't needed. As I mentioned in another thread, the *bucket* would just be duplicating the window switcher, just like minimizing to tray does. Which are plasters over the fact that the window-switcher applet just doesn't deal well with many windows - so minimize to tray exists to free up space. Unity is on the right track with its dock, but is obviously tailored to netbooks, we could really do with something similar for the desktop (*cough* dockbarx *cough*) :) Anyway, ideally we'd have one place to look for application windows, at the moment we have two (window-switcher and notification area/indicator applet), potentially several if you factor in workspaces*. Luke. *P.S. I'd love it if whatever window-switcher replacement grouped windows by workspace, I'd then actually use them. ___ 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] ApplicationIndicators design decision and its application to Rhythmbox
Hi there, im not quite sure if i understand your use case, let me recite and translate to my understanding, if youre saying: now it's click, move mouse, click, mouve mouse, click. You mean: Click on Indicator to open it Move Mouse to Show Rhythmbox Click Show Rhythmbox Move Mouse to a Song or Button Click the designated target Did i get that right? Have you been reading about this https://wiki.ubuntu.com/SoundMenu ?? The plan is to get Rhythmbox show inline with the SoundApplet,maybe that`ll calm your concerns.. 2010/4/14 Gaetan de Menten gdemen...@gmail.com Hi all, I'd like to (strongly) vote against the change to Application indicators. Yes I have read https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators/ and even though the goal seem laudable, its (current) implementation is severely broken IMO. First, the implementation is broken because it heavily reduce usability in a lot of use cases. Take a simple use case: show Rhythmbox, do any rythmbox-specific action (like viewing the next songs) and hide the window. Previously, it was only a matter of two clicks on the same icon (ie very fast), now it's click, move mouse, click, mouve mouse, click. Secondly, it is currently way more inconsistent than before (how ironic given the stated goal of reducing inconsistencies). Currently, I have 6 applications in my notification area: xchat, liferea, pidgin, skype, NetworkManager and rhythmbox. They all behave the same *except* for rhythmbox: left-click = show/hide, right-click = menu with options. To that list, you can also add Tomboy, which also behaves the same even if it is an applet. How is the current situation more consistent than having rhythmbox use the same behavior as other applications as it does upstream? Thanks for reading, -- Gaëtan de Menten ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] No application bucket needed
On 17 May 2010 11:40, David Siegel david.sie...@canonical.com wrote: More specifically, I'm interested in why people use minimize-to-tray instead of regular minimize. My suspicion is that it's easier to recall minimized windows by clicking on indicators than by clicking on the window list. If a window minimizes to tray instead of closing when the Close button is clicked, this just means that Close has become another Minimize button, and the tray has become another window list. Ugly! Like I said, I believe it's simply down to lack of space. The default window-switcher is rubbish with many windows and truncates titles quite quickly. Using a dock that uses icons like dockbarx, (which groups by application and shows full window titles in the apps window list on hover), I can run my email client, music player etc. minimized and it doesn't get in my way. Without dockbarx and I start using minimize to tray for those apps because it clutters the window list. Most of the feedback from my other Ayatana thread Is it time to kill minimize to tray? seems to indicate other users agree. 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] No application bucket needed
On 17/05/10 11:40, David Siegel wrote: More specifically, I'm interested in why people use minimize-to-tray instead of regular minimize. My suspicion is that it's easier to recall minimized windows by clicking on indicators than by clicking on the window list. My assumption has been that people want to get the window OUT of the Alt-TAB list, and off the task bar. Mark 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] No application bucket needed
Also, window positions in the window list are apparently arbitrary and therefore undependable. Luke, thank you for the excellent description of your use case. David On Mon, May 17, 2010 at 11:55 AM, Luke Benstead kaz...@gmail.com wrote: On 17 May 2010 11:40, David Siegel david.sie...@canonical.com wrote: More specifically, I'm interested in why people use minimize-to-tray instead of regular minimize. My suspicion is that it's easier to recall minimized windows by clicking on indicators than by clicking on the window list. If a window minimizes to tray instead of closing when the Close button is clicked, this just means that Close has become another Minimize button, and the tray has become another window list. Ugly! Like I said, I believe it's simply down to lack of space. The default window-switcher is rubbish with many windows and truncates titles quite quickly. Using a dock that uses icons like dockbarx, (which groups by application and shows full window titles in the apps window list on hover), I can run my email client, music player etc. minimized and it doesn't get in my way. Without dockbarx and I start using minimize to tray for those apps because it clutters the window list. Most of the feedback from my other Ayatana thread Is it time to kill minimize to tray? seems to indicate other users agree. 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] No application bucket needed
On 17 May 2010 11:58, Mark Shuttleworth m...@ubuntu.com wrote: On 17/05/10 11:40, David Siegel wrote: More specifically, I'm interested in why people use minimize-to-tray instead of regular minimize. My suspicion is that it's easier to recall minimized windows by clicking on indicators than by clicking on the window list. My assumption has been that people want to get the window OUT of the Alt-TAB list, and off the task bar. Mark Alt-TAB list definitely, but I think people only want it off the task bar because of lack of space. DockbarX has a ppa[1] give it a try, replace your window-switcher applet and then don't use the minimize-to-tray functionality of the indicator applets/notification area. It's much more usable IMO. If DockbarX also removed minimized windows from the Alt+TAB list - it would be perfect :D Luke. [1] https://launchpad.net/~dockbar-main/+archive/ppa ___ 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] No application bucket needed
Luke, thank you for the excellent description of your use case. David No worries. The window-switcher and minimize-to-tray (I firmly believe the latter exists because of the former) is my #1 bug bear ;) 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] Evolution
On Sun, 2010-05-16 at 21:15 -0700, Tyler Brainerd wrote: get these things fixed by 10.10. Specifically, Evolution behaves completely opposite form all the other apps in the applet, as it must have a window open to work, while the others all close to the applet. +1. I occasionally miss critical stuff because of this. smime.p7s Description: S/MIME cryptographic 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] No application bucket needed
On 17/05/10 12:16, David Siegel wrote: Alright, sounds like we should definitely test removing minimized windows from alt-tab when they are minimized to the Launcher in Unity. This would break Alt-TAB for me, completely. I trust Alt-TAB to have *all* the windows, just in last-used order. So things I haven't gone to are way back in the list. I think closing the application window but allowing the app to continue to run, is appropriate (we have this for Pidgin and Empathy and Gwibber now, and it works). Mark 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
[Ayatana] Structure (was: Intuitive)
On Mon, 2010-05-17 at 10:29 +0100, David Siegel wrote: Thorsten, can you recommend any literature on this topic? Specifically about the vocabulary / on how to talk about UX? Not really. My own language might be shaped by: * Jeff Raskin: The Humane Interface * Alan Cooper: About face 2.0 * Donald A. Norman: The Design of Everyday Things plus various articles. Would you be interested in co-authoring a document that would help people understand how to structure productive conversations on this list? Perhaps. I would like to discuss how the wiki should be structured, first. Concepts touching aspects of window and file management used to land in the Artwork section of the wiki. I made an effort to keep them out of the Artwork/Incoming section of specific releases, as those should allow an overview of things that have at least the potential to be ready for the release. The result is pretty much a centralized instead of a distributed graveyard: https://wiki.ubuntu.com/Artwork/Incoming/Concepts I think in future all concepts that go beyond mere theming should be kept out of the Artwork section. Given there's no Design section, Ayatana seems to be the best fit, except if you want that label to stay exclusive to Canonical-backed projects. Of course it shouldn't be a continuation of that wasted effort, so we need the structure and guidance you have been speaking of, David. On the Ayatana main page, I'd like to see a brief intro and pointers to: * A system of goals/objectives. I think it should flow from the success of present and potential users, aided by a few assumptions we make (which have to be explicit). * A pragmatic introduction to UX design, how to talk about it included. * An outline of a process we will develop, follow and refine. * A list of Canonical projects * A list of community-led projects, work in progress The wiki itself does not speak well of our design and user experience sensibilities. Is anyone listening who would be interested in marrying Etherpad-like editing with a non-hierarchical wiki, perhaps using Lift/Scala, Nitrogen/Erlang or Seaside/Smalltalk? ;) -- 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] GSoC '10 Idea : NotifyOSD improvements
Am Montag, den 15.03.2010, 21:45 +0530 schrieb Akshay Gupta: I posted a GSoC project Idea on the ubuntu-soc list yesterday and I thought it'd be more appropriate if I run it down by developers in the Ayatana list. https://lists.ubuntu.com/archives/ubuntu-soc/2010-March/47.html Some of the things that this project could help solve : 1.) Make the OSD customizable * setting up persistence time I'd rather finish the time-out specs, than work around it like this. * UI modifications over a basic structure Not sure what you mean by this? * Font size/style You can change the font-size/-style already. notify-osd picks up the font from your system-wide settings. ...other similar stuff we can decide upon. 2.) Most of the above things would be customized by an OSD Manager that could handle all those by a native GTK+ application. I would not suggest that. Great care has been taken to avoid the need for a preferences UI for notifications. Completing the implementation would be of greater benefit, than taking this shortcut of a settings-UI. With these kind of UIs we get into the realm of undiscoverability again. We try to move away from this, not towards it. 3.) Implementing unresolved work in the Design Specs. I could help with that, e.g. the growing timer needed for getting all the time-outs stated in the spec could be used finally. I've implemented it already, but it still needs to be hooked up. Furthermore the expanding bubble for the append-case could be revisited. The needed animation-framework is in place. Numerous (unit-) test-programs of notify-osd trunk already demonstrate these features. There are some low-hanging fruits within the scope of fulfilling the spec. 1.) Stacking, that'd make the bubbles dock downwards as they are initiated and start to stack up as the bubble times finish away. 2.) A close button on the corner of the bubble as soon as a mouseover occurs (like Growl, instead of disappearing away) These two above mentioned items I'd rather see implemented in a fork than in notify-osd trunk itself. The reasons for notify-osd not exposing these kind of behaviours have been discussed to great lengths in the past on this list. I don't want to see this discussion reignite again. Best regards ... Mirco ___ 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] Sudoku: Let's try a heuristic usability evaluation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan-Christoph Borchardt wrote on 10/05/10 10:51: ... Thanks MPT for this game/task, had real fun doing it. Thanks Jan-Christoph, that's good feedback. Does anyone else want to have a go? - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvxP3sACgkQ6PUxNfU6ecom8ACfZMyEAq0YN01gxM8O+nNdiHXV A6QAniUuXC/e7xo+Wl/tDePfcJsd/WPE =FTae -END PGP 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] No application bucket needed
I think that minimise to tray was always about cleaning up the task bar (windows-switcher). There are long running apps that seldom require input and these should not clutter up the task bar. Pidgin, Rhythmbox solve this by closing the application window but continuing to run. The biggest culprit that does not do this for me is Evolution. I think a dock solves most of the other issues which is I am using DockbarX. One case it does not allow is a single quick click to go to the window you want as you can with windows-switcher. I think a hybrid approach may solve this. You could have all open apps displayed as a icon as current docks like dockbarx do except for the windows of the current foreground application, so if I am working in openoffice, all the openoffice windows will show expanded with the windows title but all other apps will show as just an icon. This way you could quickly switch between openoffice windows by clicking on the appropriate one but still have a less cluttered task bar. It is not perfect as I might be working on a document and the pictures in it so I might want openoffice and gimp windows visible. I agreed that alt-tab should work as it currently does, switching between all open windows. Raymond On Mon, 2010-05-17 at 12:32 +0100, Mark Shuttleworth wrote: On 17/05/10 12:16, David Siegel wrote: Alright, sounds like we should definitely test removing minimized windows from alt-tab when they are minimized to the Launcher in Unity. This would break Alt-TAB for me, completely. I trust Alt-TAB to have *all* the windows, just in last-used order. So things I haven't gone to are way back in the list. I think closing the application window but allowing the app to continue to run, is appropriate (we have this for Pidgin and Empathy and Gwibber now, and it works). Mark ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp signature.asc Description: This is a digitally signed message part ___ 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] Tabs
Haha. I guess what I'm getting at is theres plenty of apps (like Empathy) that have tabs available, but they work on different rules. Not to mention that some apps are on top, others on bottom, some are full featured tabs, some are content only and not tool bars and so have inconsistent appearance So the benevolence is assumed there already, I want some of the Dictating to give some set rules. :D On Mon, May 17, 2010 at 2:57 AM, Mark Shuttleworth m...@ubuntu.com wrote: On 16/05/10 21:19, Tyler Brainerd wrote: Ok. Thanks for the response. I'm assuming this means that instructions will be issued for patching all currently tabbed apps to use ctrl-tab? When you say instructions will be issued, you make me feel short on the benevolence front :-) What we'll do is demonstrate some great experiences when apps do express their tabs in a consistent fashion, and run a program working with multiple upstreams to help them get that for their users too. Mark ___ 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] Evolution
On Mon, May 17, 2010 at 3:01 AM, Mark Shuttleworth m...@ubuntu.com wrote: On 17/05/10 10:21, Stefan Reichel wrote: Secondly, because of the fact that it doesn't close to the applet, then when new messages show up, and you click it, nothing happens. If its on a different workspace, you don't move there, and it opens the main window rather then the message itself. Again, totally inconsistent and really obnoxious. When I get new messages in Empathy and I click the new message in the applet, then just that conversation opens, not my friends list. Evolution should follow suit. So true. It would be very great if these issues get addressed in 10.10. Please add support for Thunderbird, too. Yes, the behavior of the system-default mail client should be consistent with the system-default chat and twitter apps (they should all be able to run as services, displaying solely in the MM). And T-bird support would be fantastic, too. Anybody want to try and organise a developer project around both of those? Get out there and champion the idea, see if developers are willing to take it on? Mark How would one go about doing this? The evolution launchpad is downloads only, not bugs or blueprints. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] No application bucket needed
Fair enough. Alt-tab could still show minimized windows and preserve MRU ordering, but maybe do so in a way that naturally de-emphasizes minimized windows so they're easier to ignore? David On Mon, May 17, 2010 at 12:32 PM, Mark Shuttleworth m...@ubuntu.com wrote: On 17/05/10 12:16, David Siegel wrote: Alright, sounds like we should definitely test removing minimized windows from alt-tab when they are minimized to the Launcher in Unity. This would break Alt-TAB for me, completely. I trust Alt-TAB to have *all* the windows, just in last-used order. So things I haven't gone to are way back in the list. I think closing the application window but allowing the app to continue to run, is appropriate (we have this for Pidgin and Empathy and Gwibber now, and it works). Mark ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] No application bucket needed
On Mon, May 17, 2010 at 01:14, Mark Shuttleworth m...@ubuntu.com wrote: To me, it's not about time-to-load. It's about the fact that you want to know about new tweets even if you are not actively using Gwibber. If you are actively using it, you want the window. If not, you just want the notifications. Quite so, however I think the issue is having an effective and consistent UI for quickly switching back and forth between these two states. This is where the messaging menu falls quite a bit behind the old minimize-to-tray behavior: Switching states with the notification area requires a click and no inertia change to go from the active-inactive gesture to the inactive-active gesture. The messaging menu requires: For inactive-active: - Moving to the panel - Clicking the messaging menu - Moving to the correct entry - Clicking it For active-inactive: - Moving to the application's close button - Clicking This is both a more complicated process, but more importantly, a more inconsistent one, since the processes to show and hide the windows have virtually nothing in common. That said, I'm not sure if the application bucket is the right solution to this. This interaction is precisely how the task list works, however: - The notification area is nice because it's (hopefully) for commonly used applications - The notication area shows icons, which visually can be scanned much faster, and take up much less space on the panel than a text-based task-bar - The notification area typically has only one icon for the entire application, whereas each window in a multi-window application shows up in the task bar - The notification area icons show up regardless of what workspace you're on, whereas the task bar only shows the current workspace's tasks In a perfect world then, the task bar would provide a way for a window to be: - Sticky when minimized - Icon-only, without text - Favorited, so it shows up based on the above rules. That doesn't sound too complicated implementation-wise, but (for me) would make the behavior of these toggled applications much more consistent with the regular task-manager UI. -- Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =- ___ 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] Tabs
On Mon, May 17, 2010 at 7:05 AM, Tyler Brainerd tylerbrain...@gmail.com wrote: Haha. I guess what I'm getting at is theres plenty of apps (like Empathy) that have tabs available, but they work on different rules. Not to mention that some apps are on top, others on bottom, some are full featured tabs, some are content only and not tool bars and so have inconsistent appearance There is also some variety in what tabs feel like; what they mean, and how they relate to windows. Lots of apps (Empathy, Firefox, gedit) have tabs representing toplevel windows, to the extent they can be dragged / dropped to expand into new toplevel windows. Reinteract is a neat alternative case. The application lets you do math with Python and you get results in-line (plotting graphs, etc). It has Notebooks, which contain Worksheets. Each notebook is represented by a new window, and all the worksheets in a notebook appear as separate tabs in its window. It makes no mention of tabs in the surrounding chrome (there isn't a Tabs menu), and it is impossible to drag a tab to create a new window. This isn't a problem of any sort because they are a distinctly defined part of the user interface; they represent something in a concrete way and they don't conflict with top level windows. The tabs are just there. I think I have seen a few other apps like this, but Reinteract is the one I remember. I think it is a nice example of tabs done right, because it doesn't feel like they're just throwing tabs in for the sake of it. Not that ”tabs are like windows, but inside of them” is inherently tabs done wrong, but it _is_ a kludgey design as it is, and inconsistent with how tabs are used elsewhere. Right now both designs, even though they are completely different, go through the GTK Notebook widget. Maybe that could be reconsidered. A new widget that semantically and visually represents a separate document inside a toplevel window may be worth exploring. I think becoming consistent with tabs will be difficult when we have some applications (like Firefox) that treat tabs as features by themselves that the user needs to think about directly; and other applications (Reinteract, most configuration dialogs :/) where a tab - as in, that exact same GTK widget - represents a section, or some other unique and tactile thing where the important part is what it represents, not the tab itself. Dylan ___ 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] Menu complication
GNOME is currently putting new effort into getting Control Center into shape, as the Preferences and Administration menus will be deprecated in GNOME 3. UNE 10.10 will promote Control Center by placing it in the Launcher. David On Mon, May 17, 2010 at 4:03 PM, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Hey all, I looked recently at the system menu items and I have to say even I got confused. Theres just way too many menu items there and there is no real logical order to the items. Can we clean up the items or order them logically? Or can we start using Gnome Control Panel instead of having the menus for system preferences and admin? Gnome Control Panel is included by default but not shown in the menu. (This option would be more familiar to windows users) Ive attached two screenshots of my current menus. The preferences part is actually bigger than my screen. I think this issue really needs addressing for Maverick. --fagan ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] Menu complication
On Mon, 2010-05-17 at 16:28 +0100, David Siegel wrote: GNOME is currently putting new effort into getting Control Center into shape, as the Preferences and Administration menus will be deprecated in GNOME 3. UNE 10.10 will promote Control Center by placing it in the Launcher. David So David will this happen for Maverick or Maverick+1 for the desktop? On Mon, May 17, 2010 at 4:03 PM, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Hey all, I looked recently at the system menu items and I have to say even I got confused. Theres just way too many menu items there and there is no real logical order to the items. Can we clean up the items or order them logically? Or can we start using Gnome Control Panel instead of having the menus for system preferences and admin? Gnome Control Panel is included by default but not shown in the menu. (This option would be more familiar to windows users) Ive attached two screenshots of my current menus. The preferences part is actually bigger than my screen. I think this issue really needs addressing for Maverick. --fagan ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] Evolution
Start on the Evolution mailing lists? Mark 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] Windicators
the automatically-generated windicators (as window decorations) would be was to small in the preview to be of any real use to most users. Maybe either emlemized over the preview, or under the preview name? Perhaps the same could be done when zoomed out in gnome-shell/gnome 3. On May 17, 2010 5:59 AM, Mark Shuttleworth m...@ubuntu.com wrote: On 17/05/10 09:50, David Siegel wrote: Windicators would naturally appear in the alt-tab preview, ... Yes, perhaps show them at 1:1 scale as emblems on the window previews, whatever the underlying window scale is for the reveal / alt-tab. Mark ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] Menu complication
As far as I know, the Control Center we'll use in UNE 10.10 will be the current incarnation shipping in GNOME, not the GNOME 3 Control Center. I assume that like any other GNOME component, once the new Control Center is released upstream it will land in Ubuntu Desktop. That being said, I think it's unlikely that we will prematurely jettison the Preferences and Application menus and introduce Ubuntu users to the soon-to-be-replaced Control Center. Maybe Matthew Paul Thomas can say more about the new Control Center and when we can expect it in Ubuntu. David On Mon, May 17, 2010 at 5:06 PM, Shane Fagan shanepatrickfa...@ubuntu.com wrote: On Mon, 2010-05-17 at 16:28 +0100, David Siegel wrote: GNOME is currently putting new effort into getting Control Center into shape, as the Preferences and Administration menus will be deprecated in GNOME 3. UNE 10.10 will promote Control Center by placing it in the Launcher. David So David will this happen for Maverick or Maverick+1 for the desktop? On Mon, May 17, 2010 at 4:03 PM, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Hey all, I looked recently at the system menu items and I have to say even I got confused. Theres just way too many menu items there and there is no real logical order to the items. Can we clean up the items or order them logically? Or can we start using Gnome Control Panel instead of having the menus for system preferences and admin? Gnome Control Panel is included by default but not shown in the menu. (This option would be more familiar to windows users) Ive attached two screenshots of my current menus. The preferences part is actually bigger than my screen. I think this issue really needs addressing for Maverick. --fagan ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] Epiphany as a desktop-consistent web browser in Ubuntu
Midori. :) it's faster and lighter. On May 17, 2010, at 9:24 AM, Jeremy Nickurak jer...@nickurak.ca wrote: I'm curious to find out if many users on this list have been paying much attention to what epiphany-browser is doing in Lucid. Epiphany provides a web browser experience that's much more consistent with the rest of the gtk/gnome desktop environment. It has a few rough edges, but the 2.30.x branch has made some HUGE leaps in terms of usability and website compatability, via the webkit-gtk project. Epiphany also might yield better results than other browsers like Firefox and Chrome, which use relatively heavyweight custom toolkits and widgets. I get the impression that integrating Epiphany into newer ubuntu design goals (global menu, windicator, etc) would be substantially less work. As someone who's successfully switched to using epiphany for about 99% of my browsing, my experience can't help but ask if epiphany is the best route going forward. Is it getting much attention from Ayatana? -- Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] Epiphany as a desktop-consistent web browser in Ubuntu
On Mon, 2010-05-17 at 10:24 -0600, Jeremy Nickurak wrote: (...) Hey, Epiphany provides a web browser experience that's much more consistent with the rest of the gtk/gnome desktop environment. It has a few rough edges, but the 2.30.x branch has made some HUGE leaps in terms of usability and website compatability, via the webkit-gtk project. Although I agree that Epiphany is a better choice for a GNOME browser as it integrates well with the platform (for example using gnome-keyring for storing passwords) its rough edges make it hard to use it and there are few other things we should think about. My biggest issue with Epiphany is the way it handles tabs - they were the most important selling point of the Firefox, Google has done a lot of work on their implementation to make sure it's great but Epiphany uses a default toolkit tabs which simply do not cut it - I can open only 8 tabs on my laptop without them being hidden and useless button popping out. I can open 14 tabs on Firefox before I get those scrolling buttons (and I always access a list of all opened tab in a form of dropdown menu) and even more on Chromium. While I agree that unexperienced users don't really care about tabs, I must say that for all the others the ability to manage a lot of tabs is important. Another issue related to tabs and opening new window is that the url bar isn't focused - I have to press ctrl+l/F6 every time to start typing url. Both Firefox and Chromium provide way of installing 3rd-party plugins (or add-ons) for your browser directly from web pages. Epiphany also might yield better results than other browsers like Firefox and Chrome, which use relatively heavyweight custom toolkits and widgets. I get the impression that integrating Epiphany into newer ubuntu design goals (global menu, windicator, etc) would be substantially less work. Probably. It uses GTK+ and Firefox uses XUL so Epiphany does look like an easier target to at least implement global menu (it should just work). As someone who's successfully switched to using epiphany for about 99% of my browsing, my experience can't help but ask if epiphany is the best route going forward. Is it getting much attention from Ayatana? What about other 1%? :) I like Epiphany and I believe that Ubuntu needs a browser that is visually and technically integrated with the rest of the desktop. I don't believe that Epiphany is there yet, though. The cost of switching for many users would be just too big and the gain from switching isn't obvious for most of them. I think that working on getting Firefox (or even better Chromium) more integrated with GNOME may be an easier and safer route. Best Regards, -- Krzysztof Klimonda kklimo...@syntaxhighlighted.com signature.asc Description: This is a digitally signed message part ___ 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
On Thu, May 13, 2010 at 05:17, Mark Shuttleworth m...@ubuntu.com wrote: The apps should always degrade to older / alternative behaviours. It's a bug if they don't, and I'm sorry if the Empathy case was badly handled, we should patch things up with upstream :-) If the category indicator (sound indicator in this case) is not present, then AppIndicators or the SysTray (till 11.04 on Ubuntu) are available and should be used. Aha, I misunderstood. If the indicator applet isn't present, it's up to the application to provide a usable interface via some other method. I thought this meant that if the indicator applet wasn't present, the various indicators would show up via the notification-area, transparent fall-back style. You'd get a messaging menu, a rhythmbox indicator, a volume-control indicator, all in the notification tray. Any reason not to do it this way, technical or design-wise? It seems like that would be a good way to encourage upstream adoption in particular... desktops that don't want to go full-hog into the indicator desktop experience can wade in slowly: Here's a library that makes it easy to put stuff into the notification tray, with a consistent UI. Oh, and if you happen to have a more advanced implementation, it can do something cooler, but through precisely the same protocol! -- Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =- ___ 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] No application bucket needed
On 17/05/10 15:30, Sense Hofstede wrote: * most applications will already be there AND it is natural for the launcher to be filled with icons = it doesn't feel untidy when it's full and the presence of an application in the launcher doesn't We'll still have this issue in Unity, if apps that don't have a window open, but are still running and *could* have a window open, show up in the Launcher as well as in the category indicator. Mark 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] Window close button is not consistent
Hi there Dieki ;) On Mon, May 17, 2010 at 21:06, Dieki N dieki.ubu...@gmail.com wrote: Currently, the close button in the window decoration closes the window, and in most cases closes the application if the last window is closed. However, on applications such as Rhythmbox, Empathy, or Gwibber, it closes the last window, but leaves the application running. For these applications, not closing is a necessary part of their functionality, but it's pretty annoying for the user since the close button is not consistent. Does anyone else believe this to be a problem? yes, i agree, it definitely is a consistency problem! Some dialog types don't even deserve to have a close button if you ask me. If e.g. a confirmation dialog appears on the screen, containing [OK] and [CANCEL] as big fat buttons in it, i see no reason to keep a title bar on the window in fact. This problem is, as so many others, a problem of interaction design, not necessarily one of window decoration design. On the long run i would like a window to dismiss itself automatically when i *knows* it is not needed, and to return to the front quickly when i want it focused. Currently, no such system is in place, it has yet to be invented. Context aware preemption is another AI problem we need to attack carefully and with caution. ___ 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] Epiphany as a desktop-consistent web browser in Ubuntu
On Mon, 2010-05-17 at 11:15 -0700, Tyler Brainerd wrote: Aren't we after the application selection stage? Any change would have to be 10.10 +1 Well we are but id say if there was something important that was missed im sure the desktop team would want to talk about it. I mentioned Epiphany and Midori in the default app selection meeting but there is some serious issues with both Epiphany and Midori. The main issues with both of them is support, Epiphany supports third party plugins but they dont have nowhere near as many as Firefox and Chromium and Midori last time I checked has no such system. They all use webkit except Firefox but Chromium has some extra stuff in there like each tab running in separate processes. Although Epiphany is very well integrated in the desktop it still looks and feels bad to use and Chromium is very well integrated with the look and feel of Gnome desktop. Anyway all that being said this conversation should be happening on the desktop team mailing list. They would have a much better answer for you than I would and this is kinda out of spec for Ayatana. On May 17, 2010, at 11:04 AM, Jeremy Nickurak jer...@nickurak.ca wrote: You certainly point out a few of those rough edges :) I'd simply argue that they're relatively small. If epiphany was to be targetted as a default browser for 10.10 (for example), we'd find a lot more of these rough-edges, get more usability testing results, get more developer eyeballs and keyboards on it, and ultimately get a better web experience for everyone (IMO :) ) AFAIK, this is approximately the same argument that was made for pulseaudio, and (although it took several releases to get it to a good state) I think it's been a huge net win overall. On Mon, May 17, 2010 at 11:26, Krzysztof Klimonda kklimo...@syntaxhighlighted.com wrote: On Mon, 2010-05-17 at 10:24 -0600, Jeremy Nickurak wrote: (...) Hey, Epiphany provides a web browser experience that's much more consistent with the rest of the gtk/gnome desktop environment. It has a few rough edges, but the 2.30.x branch has made some HUGE leaps in terms of usability and website compatability, via the webkit-gtk project. Although I agree that Epiphany is a better choice for a GNOME browser as it integrates well with the platform (for example using gnome-keyring for storing passwords) its rough edges make it hard to use it and there are few other things we should think about. My biggest issue with Epiphany is the way it handles tabs - they were the most important selling point of the Firefox, Google has done a lot of work on their implementation to make sure it's great but Epiphany uses a default toolkit tabs which simply do not cut it - I can open only 8 tabs on my laptop without them being hidden and useless button popping out. I can open 14 tabs on Firefox before I get those scrolling buttons (and I always access a list of all opened tab in a form of dropdown menu) and even more on Chromium. While I agree that unexperienced users don't really care about tabs, I must say that for all the others the ability to manage a lot of tabs is important. Another issue related to tabs and opening new window is that the url bar isn't focused - I have to press ctrl+l/F6 every time to start typing url. Both Firefox and Chromium provide way of installing 3rd-party plugins (or add-ons) for your browser directly from web pages. Epiphany also might yield better results than other browsers like Firefox and Chrome, which use relatively heavyweight custom toolkits and widgets. I get the impression that integrating Epiphany into newer ubuntu design goals (global menu, windicator, etc) would be substantially less work. Probably. It uses GTK+ and Firefox uses XUL so Epiphany does look like an easier target to at least implement global menu (it should just work). As someone who's successfully switched to using epiphany for about 99% of my browsing, my experience can't help but ask if epiphany is the best route going forward. Is it getting much attention from Ayatana? What about other 1%? :) I like Epiphany and I believe that Ubuntu needs a browser that is visually and
Re: [Ayatana] Tabs
Hi Dylan On Mon, May 17, 2010 at 17:21, Dylan McCall dylanmcc...@gmail.com wrote: On Mon, May 17, 2010 at 7:05 AM, Tyler Brainerd tylerbrain...@gmail.com wrote: Haha. I guess what I'm getting at is theres plenty of apps (like Empathy) that have tabs available, but they work on different rules. Not to mention that some apps are on top, others on bottom, some are full featured tabs, some are content only and not tool bars and so have inconsistent appearance There is also some variety in what tabs feel like; what they mean, and how they relate to windows. Lots of apps (Empathy, Firefox, gedit) have tabs representing toplevel windows, to the extent they can be dragged / dropped to expand into new toplevel windows. Reinteract is a neat alternative case. The application lets you do math with Python and you get results in-line (plotting graphs, etc). It has Notebooks, which contain Worksheets. Each notebook is represented by a new window, and all the worksheets in a notebook appear as separate tabs in its window. It makes no mention of tabs in the surrounding chrome (there isn't a Tabs menu), and it is impossible to drag a tab to create a new window. This isn't a problem of any sort because they are a distinctly defined part of the user interface; they represent something in a concrete way and they don't conflict with top level windows. The tabs are just there. I think I have seen a few other apps like this, but Reinteract is the one I remember. I think it is a nice example of tabs done right, because it doesn't feel like they're just throwing tabs in for the sake of it. Not that ”tabs are like windows, but inside of them” is inherently tabs done wrong, but it _is_ a kludgey design as it is, and inconsistent with how tabs are used elsewhere. Right now both designs, even though they are completely different, go through the GTK Notebook widget. Maybe that could be reconsidered. A new widget that semantically and visually represents a separate document inside a toplevel window may be worth exploring. I think becoming consistent with tabs will be difficult when we have some applications (like Firefox) that treat tabs as features by themselves that the user needs to think about directly; and other applications (Reinteract, most configuration dialogs :/) where a tab - as in, that exact same GTK widget - represents a section, or some other unique and tactile thing where the important part is what it represents, not the tab itself. Being much of a layman, i can still follow most of what you formulate in here. This time i don't understand your point, for all the words you use to make it.. Dedicated GTK widget vs misused Notes widget sounds plausible to me, thanks. What's with tabs now? I see the discussion on how tabs can't be consistently cycled with [CTRL]+[TAB] in all apps.. But what do you mean exactly with your Reinteract example? Are you saying that e.g. Firefox should have a seperate, different sidebar for each tab that is open? Please apply your theory to how Firefox should rather handle tabs in your vision.. ___ 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
hi jeremy On Mon, May 17, 2010 at 19:57, Jeremy Nickurak jer...@nickurak.ca wrote: It seems like that would be a good way to encourage upstream adoption in particular... desktops that don't want to go full-hog into the indicator desktop experience can wade in slowly: Here's a library that makes it easy to put stuff into the notification tray, with a consistent UI. Oh, and if you happen to have a more advanced implementation, it can do something cooler, but through precisely the same protocol! i'm with you in what you are stating. About how fast upstream will move along: Consistency is the way to go. Notification area icons have never cared much about consistency, is my guess, that's why they came in all kinds of colors, shapes and visual incompatibilites with each other and the panel itself. Behaviour was also totally random on click, doubleclick or secondary click. To introduce a more advanced menu functionality is a step forward, and as long as nobody else codes something even half this advanced, i don't see how upstream will reject such valuable contribution to our common cause. Remember: as long as we are contributing to a project, we're part of it. If Ubuntu's contribution to GNOME is libindicator, let's make it worth everybody's while and give upstream not a reason to reject this major step forward. ___ 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] Thoughts on quitting and window controls
eck redundant wording, let me rephrase. Wouldn't it be easier to just remove the close button? ex. file transfer, click the cancel button to close. imo, minimize to system-tray wouldn't be necessary with an icon dockbar. Thus returning the close icon to its previous state of actually quiting the app. Of course if the minimize and close icon were separated it would make them more distinct. The system tray and menu could also be activated by hover (1 sec delay) instead of click, further reducing the mishap of clicking the wrong button. :p -no idea how well that would actually work tho... ___ 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
On Mon, 2010-05-17 at 11:57 -0600, Jeremy Nickurak wrote: On Thu, May 13, 2010 at 05:17, Mark Shuttleworth m...@ubuntu.com wrote: The apps should always degrade to older / alternative behaviours. It's a bug if they don't, and I'm sorry if the Empathy case was badly handled, we should patch things up with upstream :-) If the category indicator (sound indicator in this case) is not present, then AppIndicators or the SysTray (till 11.04 on Ubuntu) are available and should be used. I thought this meant that if the indicator applet wasn't present, the various indicators would show up via the notification-area, transparent fall-back style. You'd get a messaging menu, a rhythmbox indicator, a volume-control indicator, all in the notification tray. Any reason not to do it this way, technical or design-wise? It seems like that would be a good way to encourage upstream adoption in particular... desktops that don't want to go full-hog into the indicator desktop experience can wade in slowly: Here's a library that makes it easy to put stuff into the notification tray, with a consistent UI. Oh, and if you happen to have a more advanced implementation, it can do something cooler, but through precisely the same protocol! With Application Indicators we manage the fallback into the notification area by default, so application developers don't need to worry about that in most cases. They can change the behavior of that fallback if they wish. --Ted signature.asc Description: This is a digitally signed message part ___ 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
On Mon, May 17, 2010 at 15:31, Ted Gould t...@ubuntu.com wrote: With Application Indicators we manage the fallback into the notification area by default, so application developers don't need to worry about that in most cases. They can change the behavior of that fallback if they wish. What counts as an application indicator exactly? I removed indicator-applet and indicator-session applet from my panel, logged out, and logged in, and i didn't see anything extra show up in the notification area. My thinking is that I'd see the messaging menu icon and perhaps the volume indicator especially in the notification area, but that hasn't happened. Maybe you could give me a test case of something that's supposed to work with this behavior? -- Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =- ___ 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
On Mon, 2010-05-17 at 15:51 -0600, Jeremy Nickurak wrote: On Mon, May 17, 2010 at 15:31, Ted Gould t...@ubuntu.com wrote: With Application Indicators we manage the fallback into the notification area by default, so application developers don't need to worry about that in most cases. They can change the behavior of that fallback if they wish. What counts as an application indicator exactly? I removed indicator-applet and indicator-session applet from my panel, logged out, and logged in, and i didn't see anything extra show up in the notification area. My thinking is that I'd see the messaging menu icon and perhaps the volume indicator especially in the notification area, but that hasn't happened. Anything that's not a system indicator :) The library that handles this fallback is libappindicator. You can find any application using libappindicator like this: $ apt-cache rdepend libappindicator0 Probably the simplest case in Lucid is to look at the Rhythmbox application indicator or the GNOME Power Manager one. --Ted signature.asc Description: This is a digitally signed message part ___ 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] Thoughts on quitting and window controls
On Mon, May 17, 2010 at 23:19, David Hamm davidth...@gmail.com wrote: eck redundant wording, let me rephrase. Wouldn't it be easier to just remove the close button? ex. file transfer, click the cancel button to close. thank you. ___ 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] No application bucket needed
In the process of writing this, I realised the problem I have with applications closing to the tray is that it makes the consequences of closing windows inconsistent. * Closing the only window for a non-tray application causes the application to quit. * Closing the only window for a tray application does not cause the application to quit. * Most applications are not tray applications so their non-quitting behaviour is inconsistent with the majority. Consider: if you've just opened an application that you've never used before, what would you expect to happen if you closed its window? So I think the thing that causes usability problems is actually inconsistent exiting behaviour. If applications never exited when their last window was closed, this wouldn't be a problem. (Incidentally, I think this is the approach Mac OS X takes.) Of course, that doesn't solve the messy task-list, but a dock would. My original email: On Mon, 2010-05-17 at 15:56 -0600, Jeremy Nickurak wrote: On Mon, May 17, 2010 at 15:27, Frederik Nnaji frederik.nn...@gmail.com wrote: Isn't the ordinary user's mental concept of closing the window via a red X rather closely related with quitting? For me this is definitely the case. I close windows by clicking the x in the title bar, and if that's the only window open for that application, the application exists as well. Empathy breaks that model. And there have been a few times that I've closed the Empathy contacts window thinking I will go offline only to be caught out by its unexpected behaviour. Hitting close on one web browser window doesn't terminate the web-browser process, and the other windows associated with it. It does if its the only window. In the case of Empathy, I've (gradually, and begrudgingly) come around to the idea that the messaging menu *is* the application, and the Contact List window is just a dialog box that lets me interact with it. I'm starting to think the same about rhythmbox, but its UI is complicated enough that it's tricky. Evolution is another several steps of complexity above that. I get the concept--a line in the sand that separates services from applications. I just don't think of Empathy as a service. In my mind services are things I set-up and leave. I interact with Empathy (and Rhythmbox, Evolution, etc) frequently, so they not services. But what makes a service and what doesn't isn't well defined (not as far as I'm aware) which will lead different people to make different assumptions about which is which. ___ 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] Windicators
On Mon, May 17, 2010 at 11:59, Mark Shuttleworth m...@ubuntu.com wrote: On 17/05/10 09:50, David Siegel wrote: Windicators would naturally appear in the alt-tab preview, as the preview is a complete representation of the window including content and window decorations. Are you thinking that we would make them larger or somehow emphasize them? Yes, perhaps show them at 1:1 scale as emblems on the window previews, whatever the underlying window scale is for the reveal / alt-tab. wow. +1 ___ 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] Fwd: Proposal of new UI element for windows in Ubuntu: Esfera
Hi Owais ;) On Sat, Mar 27, 2010 at 19:11, Owais Lone loneow...@gmail.com wrote: I know this is off-topic but improving drag-n-drop caught my eye. Currently the windows get focus upon dragging. This makes it difficult to drag and drop in some situations. (Check the video.) This problem is about to celebrate it's zillionth anniversary soon. It turned me into an alcoholic for a while, as you can see from my lack of discipline in this Ubuntu Brainstorm here: http://brainstorm.ubuntu.com/idea/3490/ The problem's origin is upstream, see: https://bugzilla.gnome.org/show_bug.cgi?id=76672 That was 2002.. :P omg sweet jeezus If you read the description of this bug, you will read: *by definition, 'click' is 'press and release', so metacity's behaviour is out of order.* As you can see this bug is ancient and major. Fixing this by making Metacity *focus on release* would make a great improvement. Thanks for bringing this one up again, i started missing it already ;) Nnaji ___ 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] Tabs
Thanks a lot for the positive replies so far, i got a little scared actually cause i tend to over-do-good with my Ideas. . does it suggest that the initial invocation of the window switcher doesn't take it to the previous window yet, instead focuses the current window to cycle the tabs in it? Not necessarily, i guess that would actually lead away from the core usage of AltTab, which should remain fast Task Switching, i think if, for example, the Browser is already open with Tabs this should'nt serve as a standard replacement since the Tabs are already visible and easily accessible, if you only attempt to change to another Tab its highly unlikely somebody will use AltTab anyways. A lot of Windows don't even have Tabs in a way the Tabs Bar would provide them, like several Settings-Windows that would not need it and most Apps that simply don't use Tabs. So i started thinking how would it be an advantage over just Switching to the Window and selecting a Tab manually and came up with some things i figured would enhance the comfort of working on my Desktop by using something like this Mockup. -Hand and Mouse Movement (for Laptops and Desktop alike) The Mouse Mileage is reduced cause the distance between the Tabs and the Window is as small as one can imagine, actually you don't even have to move your Hand anywhere cause by using the MouseWheel ( or more likely Arrow Keys on a Laptop) you start, process and end in the exact same Position you most likely already have gotten used too. -Less Eye Movement Content Relocating Usually you'd AltTab, start searching for the right Tab (in case its not the one thats currently open) and open it, which will give you another hard transfer on the Eyes, with the Tabs in the Switcher the Windows will gracefully fade in while selecting the Tab and the AltTab will fade out too, much easier on the Eyes and less relocating of your ACTUAL Destination. Even if the Tabs would switch without any fading-effect its still more pleasant on the Eyes cause you're focused on the AltTab Interface. -Better Emphasis of your current Documents I just think its less Where is it? and more There it is! -A Nice Shortcut for Windicators Instead of checking the IndicatorApplet which Application demands Attention or has some Update, opening the App and searching the associated Tab, i just AltTab and click the pending/informing Windicator and it'll take me right to the Spot. it's insanely convoluted and I doubt there are many who walk this Earth who could have understood it. I take that as a compliment :D A similar design could be applied to expose`, which would be much easier accessed by most people, ex. hot-corner or a single key. True, at the end of the Day its nothing but a Window Switcher. Im just such an AltTabbing guy so a lot of this came from my personal taste as well as the earlier mentioned influences from Gnome-Shell, Firefox and of course this and several other mailing lists, just saying cause it would probably be impossible to credit everybody who influenced this. Best Regards, Joern ___ 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] Windicators
On Tue, May 18, 2010 at 01:47, Brandon Watkins bwa...@gmail.com wrote: Interesting idea but I am not sure I grasp the real usability application for it. What point exactly would seeing the application indicators large have? well, if you need to ask like that, check: http://www.markshuttleworth.com/archives/333 otherwise perhaps you misunderstood, or i misunderstood. it's 1:1 scale, meaning the windicators are shown in their usual size, even while their respective window is scaled down to what have you.. ___ 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] Killing Menu Bars
On Mon, 2010-05-17 at 18:47 -0700, Tyler Brainerd wrote: I know, I know, we just had an announcement about changing menu's over to global menu's for the UNE. But seriously, how necessary is 4 menus in the calculator application gcalctool? The only menu options that have anything to do with actual calculator options are under the view menu. The rest is silly and redundant. I just wrote a fairly long blog post on my blog here, along with mockups and what not: http://tjamesubuntu.blogspot.com/2010/05/re-thinking-desktop.html about how silly most apps menu's are. I'm hoping that we can maybe pool some resources on looking at what is and what isn't necessary in default applications in Ubuntu, although I'm not under any impression that this will be something to be put directly in default Ubuntu. However, I do think it is the sort of mod that can gain traction similar to Nautilus-Elementary if we can get applications repackaged with cleaned up and optimized menus. Cleaned up and optimised; sounds like a good idea. How would you do that for the gcalctool menus? (They seem pretty good to me.) General comments: (Pertaining to the removal of menus and replacement with toolbar menus as mentioned in your blog post.) 1. Menus provide access to functions that might be otherwise obscured, infrequently used or hard to access--especially for people who cannot use pointing devices. For example, I can tell that if I want to insert something into this email I can press Alt+I to get the insert menu, even though I've never used it before. If that menu were represented by an icon in a toolbar, how would I get to it without having to tab through the entire interface? 2. Menus provide a convenient reference list of keyboard accelerators. If that menu were represented by an icon in a toolbar, how would I get to it without having to tab through the entire interface? Take gcalctool for example. If it didn't have a menu, and you couldn't use your mouse, how would you switch to a different mode? Quit the application? Input an ASCII character? 3. A menu by itself takes up less space than a toolbar by itself Removing the menu in gcalctool in the same way that Nautilus-Elementary removes the menu would mean that we'd have to add a toolbar for the functions that have no-where else to go. (I don't think this is particularly important though.) None of these are absolute barriers to your idea, but they are things that need to be considered/resolved. ___ 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] Windicators
Somewhat contrived user story: suppose I have a whole bunch of applications open, and all of them have some sort of audio playing, and all of them have a volume level windicator. If one application starts playing some sound too loud, I can see -- while I'm alt-tabbing -- what the respective sound levels of all my applications are. If the windicators are only rendered nativly in the window, it will be too small to see or be useful. But, if the windicators are larger, then I can quickly see which window is too loud, switch to it, and fix it. I'm sure that there are much better examples of why enlarging windicators when windows are iconified is a good idea, but this was ay the top of my head ;) On May 17, 2010 9:52 PM, Frederik Nnaji frederik.nn...@gmail.com wrote: On Tue, May 18, 2010 at 01:47, Brandon Watkins bwa...@gmail.com wrote: Interesting idea but I ... well, if you need to ask like that, check: http://www.markshuttleworth.com/archives/333 otherwise perhaps you misunderstood, or i misunderstood. it's 1:1 scale, meaning the windicators are shown in their usual size, even while their respective window is scaled down to what have you.. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] Windicators
Fair point :D I was basing that on Shuttleworth's blog post about windicators, an example given was a volume indicator. Regardless, I feel like anything that is small, used to convey information to the user, and tied to a window should be made larger when the window is thumbnail-ized (better term, anyone?), otherwise it is no longer useful. On May 17, 2010 11:45 PM, Tyler Brainerd tylerbrain...@gmail.com wrote: It'll be a little easier to come up with user stories when we have some idea of what the windicators will actually be. :D It'd be nice to get a nice big set of basic ideas of what should and what shouldn't be in a windicator. On Mon, May 17, 2010 at 8:43 PM, Alex Schoof alex.sch...@gmail.com wrote: Somewhat contrived... ___ 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] Windicators
But still, your point stands, and I agree. Another example is when working with a large number of documents, getting a quick view to see if they are all saved/synced with UbuntuOne or DB before logging off for the day. On Mon, May 17, 2010 at 8:51 PM, Alex Schoof alex.sch...@gmail.com wrote: Fair point :D I was basing that on Shuttleworth's blog post about windicators, an example given was a volume indicator. Regardless, I feel like anything that is small, used to convey information to the user, and tied to a window should be made larger when the window is thumbnail-ized (better term, anyone?), otherwise it is no longer useful. On May 17, 2010 11:45 PM, Tyler Brainerd tylerbrain...@gmail.com wrote: It'll be a little easier to come up with user stories when we have some idea of what the windicators will actually be. :D It'd be nice to get a nice big set of basic ideas of what should and what shouldn't be in a windicator. On Mon, May 17, 2010 at 8:43 PM, Alex Schoof alex.sch...@gmail.com wrote: Somewhat contrived... ___ 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] Killing Menu Bars
On Mon, 2010-05-17 at 20:38 -0700, Tyler Brainerd wrote: Actually, I added a (extremely rough) mock up of what gcalc might look like. Basically, the most commonly used options ought to be (categorically) available the easiest. I agree, although determining what's most commonly used is easier said than done--it depends heavily on the user's habits and their particular needs. In a tool like a calculator that doesn't have a lot going on as far as options its pretty easy to put these on a row of mode or view buttons. everything else can be found in the 'gearbox' options menu. Roughly like so:Calculator_027.jpg How would I access that with my keyboard? This translates very well in simple apps, and with more work, could work well for more complex apps as well. With the keyboard shortcuts, particularly the insert command, ironically enough I'm using chromium, which does not allow for that command. The point of accessing the Insert menu (in Evolution) was to illustrate the discoverability of a feature without having to know its accelerator key ahead of time. Presumably we could still allow similar behavior for common key presses of that sort, I would expect items in the toolbar to have accelerators--especially in the absence of a menu. But how would I know what they were? And even if they were standardised (say the cog icon is in your example is accessible via Alt+S), how would I know what they were? and honestly some of it will be taken care of by a clean shearing of commands that are used for actual action (i.e., in a file browser relate to actual browsing instead of slightly less needed interface editing like reset view to defaults or history clearing) and menu items which do not directly relate to the task at hand. You lost me here. Are you making a case for well thought-out menus? If so then yes, I agree menus should be well thought-out. Again, Chrome is really a great example of giving context menus which are very dependent on the area clicked, and two very sparse clean menus, with all non-essential interface controls tucked away. Accessible in 3 or less clicks, but away. In addition, this would hopefully lower the levels of total overlap going on. None of the issues I raised pertain to clicking (using a pointing device). But you are right about the Chromium menus being well organised. And the use of context menus is good too. However, Chromium also highlights one of the issues I menioned: how do you open one of those menus without a mouse? I'll save you some frustration for the Customise and Control Chromium menu: it's Alt+F. I know that from trial and error--guessing key combinations until a menu popped up. I'm yet to figure out how to duplicate a tab. On Mon, May 17, 2010 at 8:15 PM, Luke Morton luke.mor...@internode.on.net wrote: On Mon, 2010-05-17 at 18:47 -0700, Tyler Brainerd wrote: I know, I know, we just had an announcement about changing menu's over to global menu's for the UNE. But seriously, how necessary is 4 menus in the calculator application gcalctool? The only menu options that have anything to do with actual calculator options are under the view menu. The rest is silly and redundant. I just wrote a fairly long blog post on my blog here, along with mockups and what not: http://tjamesubuntu.blogspot.com/2010/05/re-thinking-desktop.html about how silly most apps menu's are. I'm hoping that we can maybe pool some resources on looking at what is and what isn't necessary in default applications in Ubuntu, although I'm not under any impression that this will be something to be put directly in default Ubuntu. However, I do think it is the sort of mod that can gain traction similar to Nautilus-Elementary if we can get applications repackaged with cleaned up and optimized menus. Cleaned up and optimised; sounds like a good idea. How would you do that for the gcalctool menus? (They seem pretty good to me.) General comments: (Pertaining to the removal of menus and replacement with toolbar menus as mentioned in your blog post.) 1. Menus provide access to functions that might be otherwise obscured, infrequently used or hard to access--especially for people who cannot use pointing devices. For example, I can tell that if I want to insert something into this email I can press Alt+I to get the insert menu, even though I've never used it before. If that menu were represented by an icon in a toolbar, how would I get to it without having
Re: [Ayatana] Killing Menu Bars
BTW, using gcalc as the example again, tooltips give the available key shortcut. is this a good approach to discover-ability? On Mon, May 17, 2010 at 9:37 PM, Luke Morton luke.mor...@internode.on.netwrote: On Mon, 2010-05-17 at 20:38 -0700, Tyler Brainerd wrote: Actually, I added a (extremely rough) mock up of what gcalc might look like. Basically, the most commonly used options ought to be (categorically) available the easiest. I agree, although determining what's most commonly used is easier said than done--it depends heavily on the user's habits and their particular needs. In a tool like a calculator that doesn't have a lot going on as far as options its pretty easy to put these on a row of mode or view buttons. everything else can be found in the 'gearbox' options menu. Roughly like so:Calculator_027.jpg How would I access that with my keyboard? This translates very well in simple apps, and with more work, could work well for more complex apps as well. With the keyboard shortcuts, particularly the insert command, ironically enough I'm using chromium, which does not allow for that command. The point of accessing the Insert menu (in Evolution) was to illustrate the discoverability of a feature without having to know its accelerator key ahead of time. Presumably we could still allow similar behavior for common key presses of that sort, I would expect items in the toolbar to have accelerators--especially in the absence of a menu. But how would I know what they were? And even if they were standardised (say the cog icon is in your example is accessible via Alt+S), how would I know what they were? and honestly some of it will be taken care of by a clean shearing of commands that are used for actual action (i.e., in a file browser relate to actual browsing instead of slightly less needed interface editing like reset view to defaults or history clearing) and menu items which do not directly relate to the task at hand. You lost me here. Are you making a case for well thought-out menus? If so then yes, I agree menus should be well thought-out. Again, Chrome is really a great example of giving context menus which are very dependent on the area clicked, and two very sparse clean menus, with all non-essential interface controls tucked away. Accessible in 3 or less clicks, but away. In addition, this would hopefully lower the levels of total overlap going on. None of the issues I raised pertain to clicking (using a pointing device). But you are right about the Chromium menus being well organised. And the use of context menus is good too. However, Chromium also highlights one of the issues I menioned: how do you open one of those menus without a mouse? I'll save you some frustration for the Customise and Control Chromium menu: it's Alt+F. I know that from trial and error--guessing key combinations until a menu popped up. I'm yet to figure out how to duplicate a tab. On Mon, May 17, 2010 at 8:15 PM, Luke Morton luke.mor...@internode.on.net wrote: On Mon, 2010-05-17 at 18:47 -0700, Tyler Brainerd wrote: I know, I know, we just had an announcement about changing menu's over to global menu's for the UNE. But seriously, how necessary is 4 menus in the calculator application gcalctool? The only menu options that have anything to do with actual calculator options are under the view menu. The rest is silly and redundant. I just wrote a fairly long blog post on my blog here, along with mockups and what not: http://tjamesubuntu.blogspot.com/2010/05/re-thinking-desktop.html about how silly most apps menu's are. I'm hoping that we can maybe pool some resources on looking at what is and what isn't necessary in default applications in Ubuntu, although I'm not under any impression that this will be something to be put directly in default Ubuntu. However, I do think it is the sort of mod that can gain traction similar to Nautilus-Elementary if we can get applications repackaged with cleaned up and optimized menus. Cleaned up and optimised; sounds like a good idea. How would you do that for the gcalctool menus? (They seem pretty good to me.) General comments: (Pertaining to the removal of menus and replacement with toolbar menus as mentioned in your blog post.) 1. Menus provide access to functions that might be otherwise obscured, infrequently used or hard to access--especially for people who cannot use pointing devices. For example, I can tell that if I want to insert something
Re: [Ayatana] Killing Menu Bars
On Mon, 2010-05-17 at 21:50 -0700, Tyler Brainerd wrote: BTW, using gcalc as the example again, tooltips give the available key shortcut. is this a good approach to discover-ability? That could work. It would require a change to GTK+ to allow tooltips to show on focus. As an extension to that, if toolbuttons/toolmenus had groups with labels like in Mac OS X then the labels could have accelerators, and each toolbutton could have its own accelerator that shows as a tooltip. Again this would require changes to GTK+. On Mon, May 17, 2010 at 9:37 PM, Luke Morton luke.mor...@internode.on.net wrote: On Mon, 2010-05-17 at 20:38 -0700, Tyler Brainerd wrote: Actually, I added a (extremely rough) mock up of what gcalc might look like. Basically, the most commonly used options ought to be (categorically) available the easiest. I agree, although determining what's most commonly used is easier said than done--it depends heavily on the user's habits and their particular needs. In a tool like a calculator that doesn't have a lot going on as far as options its pretty easy to put these on a row of mode or view buttons. everything else can be found in the 'gearbox' options menu. Roughly like so:Calculator_027.jpg How would I access that with my keyboard? This translates very well in simple apps, and with more work, could work well for more complex apps as well. With the keyboard shortcuts, particularly the insert command, ironically enough I'm using chromium, which does not allow for that command. The point of accessing the Insert menu (in Evolution) was to illustrate the discoverability of a feature without having to know its accelerator key ahead of time. Presumably we could still allow similar behavior for common key presses of that sort, I would expect items in the toolbar to have accelerators--especially in the absence of a menu. But how would I know what they were? And even if they were standardised (say the cog icon is in your example is accessible via Alt+S), how would I know what they were? and honestly some of it will be taken care of by a clean shearing of commands that are used for actual action (i.e., in a file browser relate to actual browsing instead of slightly less needed interface editing like reset view to defaults or history clearing) and menu items which do not directly relate to the task at hand. You lost me here. Are you making a case for well thought-out menus? If so then yes, I agree menus should be well thought-out. Again, Chrome is really a great example of giving context menus which are very dependent on the area clicked, and two very sparse clean menus, with all non-essential interface controls tucked away. Accessible in 3 or less clicks, but away. In addition, this would hopefully lower the levels of total overlap going on. None of the issues I raised pertain to clicking (using a pointing device). But you are right about the Chromium menus being well organised. And the use of context menus is good too. However, Chromium also highlights one of the issues I menioned: how do you open one of those menus without a mouse? I'll save you some frustration for the Customise and Control Chromium menu: it's Alt+F. I know that from trial and error--guessing key combinations until a menu popped up. I'm yet to figure out how to duplicate a tab. On Mon, May 17, 2010 at 8:15 PM, Luke Morton luke.mor...@internode.on.net wrote: On Mon, 2010-05-17 at 18:47 -0700, Tyler Brainerd wrote: I know, I know, we just had an announcement about changing menu's over to global menu's for the UNE. But seriously, how necessary is 4 menus in the calculator application gcalctool? The only menu options that have anything to do with actual calculator options are under the view menu. The rest is silly and redundant. I just wrote a fairly
Re: [Ayatana] Killing Menu Bars
On Mon, 2010-05-17 at 21:48 -0700, Tyler Brainerd wrote: Ah. Well, you're making me work for things, thats for sure. Ha. It's what I do ;) On Mon, May 17, 2010 at 9:37 PM, Luke Morton luke.mor...@internode.on.net wrote: On Mon, 2010-05-17 at 20:38 -0700, Tyler Brainerd wrote: Actually, I added a (extremely rough) mock up of what gcalc might look like. Basically, the most commonly used options ought to be (categorically) available the easiest. I agree, although determining what's most commonly used is easier said than done--it depends heavily on the user's habits and their particular needs. Agreed. Thats why I started with the calculator here, and with the already partially simplified Nautilus-Elementary. In a tool like a calculator that doesn't have a lot going on as far as options its pretty easy to put these on a row of mode or view buttons. everything else can be found in the 'gearbox' options menu. Roughly like so:Calculator_027.jpg How would I access that with my keyboard? This translates very well in simple apps, and with more work, could work well for more complex apps as well. With the keyboard shortcuts, particularly the insert command, ironically enough I'm using chromium, which does not allow for that command. The point of accessing the Insert menu (in Evolution) was to illustrate the discoverability of a feature without having to know its accelerator key ahead of time. Presumably we could still allow similar behavior for common key presses of that sort, I would expect items in the toolbar to have accelerators--especially in the absence of a menu. But how would I know what they were? And even if they were standardised (say the cog icon is in your example is accessible via Alt+S), how would I know what they were? Pressing alt brings up hovering indicators perhaps? I don't disagree that these things ought to be discoverable, but honestly keyboard accessibility is nowhere near my strong suit, as I rarely use only the keyboard so I really don't know how to make it work and what doesn't. I think IE7 had something like that ... No wait, it was a hidden menu bar that became visible when holding Alt. I think IE now has a similar toolbutton/menu thing to Chromium, except it uses labels instead of icons, thereby allowing for discoverability and avoiding the issue of poor icon metaphors. and honestly some of it will be taken care of by a clean shearing of commands that are used for actual action (i.e., in a file browser relate to actual browsing instead of slightly less needed interface editing like reset view to defaults or history clearing) and menu items which do not directly relate to the task at hand. You lost me here. Are you making a case for well thought-out menus? If so then yes, I agree menus should be well thought-out. Um, yes. Well thought. :D. In the sense that chrome has what I can do to this page and what I can do to the whole browser as its two menus, then we would have whats pertinent to the actions I am currently doing and what customizations to the nature of the program are available Again, Chrome is really a great example of giving context menus which are very dependent on the area clicked, and two very sparse clean menus, with all non-essential interface controls tucked away. Accessible in 3 or less clicks, but away. In addition, this would hopefully lower the levels of total overlap going on. None of the issues I raised pertain to clicking (using a pointing device). But you are right about the Chromium menus being well organised. And the use of context menus is good too. Fair enough. :P However, Chromium also highlights one of the issues I menioned: how do you open one of those menus without a mouse? I'll save you some frustration for the Customise and Control Chromium menu: it's Alt+F. I know that from trial and error--guessing key combinations until a menu popped up. I'm yet to figure out how to duplicate a tab. You bring up good points, further illustrating to me that my idea as a whole is likely suitable as a modification, not as an attempt to alter vanilla
