Re: [Ayatana] Notification consistency
On Friday 11,September,2009 04:52 PM, David Barth wrote: > It is was not on the table for Karmic, that is, Mozilla had reservations > last year about the non-interactivity of n-osd notifications and I think > they prefer to see how the rest of the community reacts to our change > before reconsidering a switch. If they're having reservations about the non-interactivity of notify-osd, how about making the actions optional? For example, don't show actions for notify-osd users (where actions aren't supported), but show actions for notification-daemon users, much like most of the other applications are doing. > I think what we've shown for now 2 releases, is that the > non-interactivity of that kind of notification is well received, and > actually becomes a desirable feature for users. I do miss the notification interactivity sometimes, but I do think that the notification bubbles making themselves translucent when hovered upon is a godsend. The recent change which caused notification bubbles to not disappear if the cursor was already there before the notification appeared is very annoying, but that's a different story. > The standardization work that we did with other projects (on the xdg > list) should also help, along with the fact that now third-parties can > really rely on a server capability to adapt their behavior. > > Last Mozilla not only uses Growl on the Mac but they also research > similar notification mechanisms (http://www.toolness.com/wp/?p=463) so I > hope they will reconsider libnotify support in the future. AFAICS, libnotify appears to be the de-facto notification system on most if not all desktop environments, or at least the major GTK-based ones anyway, so if they're using Growl on Mac, I really don't see any reason for them to reinvent a notification system rather than just using libnotify for their notifications. -- Kind regards, Chow Loong Jin 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] Possible security risk with update-manager
On Tuesday 15,December,2009 10:58 PM, mac_v wrote: >[...] > With policykit we can set up the admin account to be granted access to > admin privileges without password-prompts [ex:mounting internal > drives] , similar can probably be done for updates. > > The present policy of asking for password isnt really very ideal for a > non-tech user. > The user just doesnt know or understand what the updates are for and > installs the updates blindly. Asking for password doesnt solve anything > here. > > For the users who know about the update they check and install the > update. Prompting the password isnt solving anything here either. > > So, prompting for passwords in the common user-scenarios isnt solving > anything. > So why are we prompting for passwords? How is the present behavior > helping or solving anything or ensuring better the security of the > system? I can't speak for anyone else here, but I am personally not comfortable at all with the idea of the ability to make system-wide changes without requiring my password. I believe it was mentioned earlier in this thread that in real life, people do walk away from their computers without locking their screens. In the event that I do walk away from my computer without locking my screen, I'd like the possible/probable damage of someone randomly clicking around minimized. > > Or are you asking , how we can confirm that the user using the admin > account is actually the admin and not a guest user? > > This is a scenario where the admin trusts the guest enough to use the > admin account and doesnt mind. I trust my guests to use my account with administrative privileges for short periods of time as long as privilege escalation still requires my password as it does now. But if it doesn't, I *DO* mind, and I don't believe I'm the only one who feels this way. > > Or if the user is concerned about guests installing the updates , they > could just remove the policykit rule and always be prompted for > passwords. In other words, you're proposing for passwordless privilege escalation by default, and I believe this is foolish. How far do you want to chip away at Ubuntu's security model before you are satisfied that it is usable enough? Usability and security have always been and will probably continue to always be at odds with each other. If we continue forsaking security for usability, we'll eventually have something akin to Windows in terms of security. If Ubuntu ever comes to this, I certainly hope I'm not around to see it. -- Kind regards, Chow Loong Jin 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 tooltip popups on appindicators
On Friday 19,March,2010 08:42 AM, Chris Johnston wrote: > Greetings; > > I have noticed that in Lucid, appindicators no longer have tooltip > popups. When on my laptop, running on battery, this adds two extra > steps for me to find out the status of my battery. I have to click on > the battery and then click off the battery to continue what I was > doing. To me, this is very inconvenient and a change that is not good. > I have filed a bug [1] against this, as I believe that adding two more > steps just to check the status of my battery is a regression in > Ubuntu. I would like to see some feedback on this decision, and > hopefully see this change back to the way it was. > > [1] > https://bugs.edge.launchpad.net/ubuntu/+source/indicator-application/+bug/541609 > The main bug is at https://bugs.edge.launchpad.net/indicator-application/+bug/527458 where I have written my response. Rather than having discussions all over the place, I think it is better to carry out all discussions there instead. Thanks for posting this to the list though, this issue deserves more attention than it is getting. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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 tooltip popups on appindicators
On Friday 19,March,2010 08:54 PM, Mark Shuttleworth wrote: > On 19/03/10 00:42, Chris Johnston wrote: >> I have noticed that in Lucid, appindicators no longer have tooltip >> popups. > > For the moment, there are no tooltips on app indicators or system > indicators. They have also been removed from window controls. Tooltips > here had historically been poorly written and inconsistently used, we've > removed them to see whether we can address the need for information > through crisper, clearer app indicator icons. > >> When on my laptop, running on battery, this adds two extra >> steps for me to find out the status of my battery. > > The indicator icon should show sufficient information. For batteries, > the specification is quite detailed in defining which device or battery > is represented (for example, in cases where you have a wireless mouse, > wireless keyboard and the laptop battery itself) and how it should be > represented. You should always know that you have at least a certain > amount of time, just by looking at the icon. > > Detailed information (hours and minutes of battery life per device) is > available by clicking on the indicator. And very detailed interactions > are supported, through the indicator, by bringing up the control panel > itself. When you explain it like that, it all seems well at first glance. But one use case, and one I frequently used, for gnome-power-manager's tooltip was to leave the cursor over it while performing other tasks that did not require the cursor to be shifted from its position. By doing that, one could have real-time (somewhat) estimates of the remaining time and percentage of remaining energy left in the battery, as the tooltip would update on its own. With a menu, you cannot do this, as the menu would grab keyboard focus. In fact, tooltips have been traditionally used to describe whatever is pointed to by the cursor. I would not consider gnome-power-manager's use of the tooltip as "poorly written" or "inconsistently used". I would be rather tempted to categorize the way application indicators use menus as misuse, rather than use, considering menus have been traditionally used for housing a series of clickable/activatable actions or a list of items to be chosen from, rather than for displaying status. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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 tooltip popups on appindicators
On Friday 19,March,2010 09:35 PM, Abhishek Dasgupta wrote: > There could be an option in the g-p-m dropdown to show the > time/percentage remaining by the side. That would solve the > accessibility and the tooltip problem. > > This would not cover all use cases, such as for Transmission data > rates. However, knowing the time remaining on a battery is a much more > frequently accessed action. By the side? What exactly do you mean? An applet that stays on top of all windows displaying the amount of time you have left? I don't think GNOME upstream would approve of such an approach, and I believe it would feel even more cluttered and messed up than the previous approach of using tooltips. Also, as you had mentioned, not all cases are covered by your suggestion, Transmission, Rhythmbox, and Banshee included. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] [Less is More] Nautilus Context menu
On Friday 26,March,2010 03:21 AM, Jorge O. Castro wrote: > Mark blogged[1] that we should communicate things that we feel need to > be trimmed back so I thought I would bring up the topic of the > Nautilus context-menu (aka. right click on the desktop/file). Over the > years I feel like this menu has been growing unchecked and now I feel > overwhelmed when I use it. Right now when I click on a file I get: > > [...] > Copy to > (and then my home and Desktop) > Move to > (and then my home and Desktop again) I actually haven't seen these two options before. How/Where did you find them? > [...] > Stretch Icon (does anyone really use this?) > Restore Icon (grayed out unless you've resized the icon) I have used this once, but have never bothered to for the past few years. I don't think it will be missed. Either way, these two items only appear for items on the desktop. Perhaps one might like to have a larger "Computer" or "Home" icon. > Send to... > Compress > Revert to Previous Version (I suspect this one is there because I have > deja-dup installed) These are menu options added by plugins. Perhaps we can collapse them into an "Extra Actions" submenu once they pass a certain limit, similar to how our bookmarks collapse into a Bookmarks submenu in the Places menu. > [...] > Right clicking on a folder has similar options, with the addition of > "Sharing Options" and now "Synchronize to Ubuntu One". When using > other software I get even more options added in here (crypto options, > dropbox, etc.). Some of the UI in these options is pretty weird. For > example in "Send to..." I can send a file to a bluetooth device (OBEX) > so the UI makes sense there but I can also send to "Removable disks > and shares" and then select "Blank CD ROM", which is and odd way to > write something to a CD. Likewise the "Sharing Options" and Ubuntu One > options should likely be integrated together into something nicer. Regarding the "Sharing Options" menu item, I have been thinking that it would be a good idea to do away with it completely, since there is a "Share" tab in the properties dialog which does exactly the same thing. In fact, it is actually the same widget pulled from the same .ui file, then added into either a standalone window or a property page. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] Fwd: Proposal of new UI element for windows in Ubuntu: Esfera
On Friday 26,March,2010 02:18 PM, Mark Shuttleworth wrote: > Hi folks > > Got this interesting proposal from Pablo, and thought it should be sent > to the list rather than handled in private correspondence. It reminds me > of something David Siegel was sketching out, also inspired by the > challenge of "how we can make the most of the new space". > > Pablo, if you're not subscribed to Ayatana, it's the best place to > sketch out a proposal like this. > > I appreciate both the detail in the proposal and the relaxed way it's > pitched! This is some really cool stuff, but one UI element doing everything, and especially because the appearance is just a blue circle, really does not seem intuitive. We would need a manual describing exactly how to use the control (akin to the proposal attached earlier), or it would be just a single (albeit powerful) UI element that nobody uses because they don't know what it is. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] Bluetooth: What do you use it for? (design research)
On Thursday 08,April,2010 10:08 PM, Matthew Paul Thomas wrote: > Hi everyone > > Since Ubuntu 9.04, one of the many things Canonical's Design team has > been working on is making panel elements more consistent. > > As part of that work, I am researching how people use Bluetooth, and in > particular, the Bluetooth menu in the Ubuntu panel. > > If you use Bluetooth with your computer, it would be very helpful if you > could reply -- preferably to me personally, to minimize noise for others > on this list -- with answers to these questions: > > 1. What kinds of Bluetooth device do you use with Ubuntu? 1. My bluetooth mouse 2. Connecting to my phone, either to transfer files, or as another input device (remote control) > > 2. Do you use the Bluetooth menu in the panel? If so, what for, and > how often? Whenever I need to transfer files to/from my phone, and for connecting to my mouse whenever it starts running out of battery and stops auto-associating. I also use it to check if my mouse has connected, if waving the mouse around doesn't work (sometimes needed if HAL has crashed on Karmic). This would be a few times a month. I also use it to setup new devices, but this is pretty rare, as setting up devices is a one-time thing. > > 3. Do you use Bluetooth devices with any OS other than Ubuntu? If so, > do you find it more or less convenient, and why? No. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] Indicators for showing progress
On Wednesday 14,April,2010 06:18 PM, Roth Robert wrote: > Hello! > > A new idea came into my mind regarding the indicators: we have many > applications that execute long-running operations... like when copying > large files or many files, the nautilus icon appears in the system tray > to indicate that some operations are in progress. In my opinion for > cases like this, we should have the possibility to show the progress of > an operation in an indicator applet menuitem. This could be useful for > file operations, cd/dvd writing, sending or receiving file via > bluetooth, downloading file from the internet, etc. > One possible solutions would be to add the functionality of menuitems > with progress bars to the appindicator library, and everyone would > implement menuitems with progressbar for their long-running operations, > or the other one, which I lik better would be to have a progress > indicator applet, which would contain information about all long-running > operations. This would be more efficient, because we could hide it when > there are no operations in progress, show it when there are operations > running. In most cases there are only a few long-running operations > running at once, so the menu shouldn't be cluttered. This would break a > bit the idea of getting information about applications only by clicking > their appindicator, but it would be helpful for many applications that > do not need appindicator, (like nautilus, cd-dvd burners, web browsers > downloading files). > > Please comment, tell me what's your opinion about this... I actually prefer Brasero's way (in Karmic) of showing progress, i.e. the icon itself shows progress in a way that can be estimated. For most things involving progress, I think I'd like to be able to check the progress without needing to click on anything. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] Middle-click on indicators
On Wednesday 14,April,2010 07:32 PM, Mark Shuttleworth wrote: > [...] > > No. Indicators are menus, they have left-click only. There are > occasionally "hidden treasures" like the results of scroll-wheel on the > sound indicator, but we're not going back to the complete anarchy of > panel applets that randomly support different clicks and itneractions. > > Mark Then how about middle click activating a "default action" of an indicator? Perhaps have one of the actions that are present in the menu be specified by the application as the default, then the indicator applet unifies this into one manner of interaction with the indicators to trigger these default actions. I think this would lead to the same kind of standardization that the application indicators is supposed to bring, without cutting back too much on functionality -- a good compromise. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] Messaging menu: efficiently dismissing messages
On Wednesday 14,April,2010 08:46 PM, Vishnoo wrote: > On Wed, 2010-04-14 at 10:02 +0200, Thorsten Wilms wrote: >> On Wed, 2010-04-14 at 07:52 +0200, Conscious User wrote: >> >>> So I was wondering if it wouldn't be interesting for the >>> messaging menu to have a "clear" button of some sort, >>> which would remove all indicators at once. >> >> Left and right-click or taken, but perhaps middle-click on the icon >> could be offered as shortcut for this? That could be one of those things >> you have to know about, but that are great if you do. >> >> > > Do all mouse [mice ;)] have a middle-click button. > AFAIK , not all have them. > Few have a hidden middle-click using the scroll-wheel press as a > middle-click. [not everyone uses this though] > What about laptops having touchpads, they dont have middle-clicks? [Some > users do configure the middle-clicks by using a two-finger tap or > whatever] > > Seems like a restriction when we base actions on middle-clicks. > Preferably we should avoid the middle-clicks for such features. I believe Ubuntu has 3-button emulation enabled by default (at least, I had to disable mine on mice for a particular game that required button1+button3 be recognized differently from button2). Also, we aren't considering basing whole new actions on middle-clicks, we're discussing about providing shortcuts to certain actions which are already available in the indicator's menu, so if users have crippled mice, they just have to go the longer route. :-) -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] Middle-click on indicators
On Wednesday 14,April,2010 09:54 PM, Frederik Nnaji wrote: > On Wed, Apr 14, 2010 at 14:00, Chow Loong Jin <mailto:hyper...@ubuntu.com>> wrote: > > Then how about middle click activating a "default action" of an > indicator? > > [...] > > I think this would lead to the same kind of standardization that the > application > indicators is supposed to bring, without cutting back too much on > functionality -- a good compromise. > > middle click is desktop-specific. > a netbook, (sub-)notebook, tablet or touchscreen device would not > support that action without an additional modifyer. Really? I thought all Ubuntu installations had 3-button emulation enabled (left+right click = middle click) by default, which I had mentioned in my previous post (the one between this one and the quoted one). At the very least, it is enabled on my notebook, and I have heard from #ubuntu-desktop that evdev (the X driver for input devices) has this emulation enabled by default. > using the middle button would also be inconsistent with Gnome's current > guidelines, see: > http://library.gnome.org/devel/hig-book/stable/input-mouse.html.en#mouse-buttons > according to the above guidelines, usage of the middle button would in > this particular case be addressed to the advanced user only, thereby > resulting in being a "hidden treasure". This is exactly the use case we are going for. We want a *shortcut* to default actions in the indicator for *advanced* users. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] Middle-click on indicators
On Thursday 15,April,2010 07:53 AM, Cody Russell wrote: > On Wed, 2010-04-14 at 20:00 +0800, Chow Loong Jin wrote: >> Then how about middle click activating a "default action" of an >> indicator? >> Perhaps have one of the actions that are present in the menu be >> specified by the >> application as the default, then the indicator applet unifies this >> into one >> manner of interaction with the indicators to trigger these default >> actions. > > I have never seen a menu that behaves like this. As Mark said, the > whole point of this effort was to make the panel indicators behave in > the same way as menus (or at least very close). Frankly speaking, I'm quite tired of this reasoning. "Menus don't do this", "Menus don't do that". Did you also realize that menus don't have icons as buttons? They have *text* buttons. > We're already stretching that slightly with the inclusion of things like > sliders and volume scrolling, but we're (hopefully!) not stretching too > far away from the concept of a menu. But we we should really exercise > restraint here and not doing crazy stuff just because we can. Just > because middle click isn't being used doesn't mean we should start using > it. But we shouldn't limit ourselves to menu-like concepts alone, just for the sake of being like menus. Otherwise let's just be menu-like all the way and get rid of the icons in the application indicators, replacing them with text. If that sounds stupid to you, then please give some thought to all the other menu-like things you are attempting to emulate, or the non-menu-like things you are attempting to remove in something that was not originally a menu, while removing frequently used functionalities of the past solution and decreasing user productivity just for the sake of being like menus. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] Middle-click on indicators
On Thursday 15,April,2010 01:24 PM, Cody Russell wrote: > On Thu, 2010-04-15 at 11:09 +0800, Chow Loong Jin wrote: >> Frankly speaking, I'm quite tired of this reasoning. "Menus don't do >> this", >> "Menus don't do that". Did you also realize that menus don't have >> icons as >> buttons? They have *text* buttons. > > It's never been common for menus to be used from icons, true, but we're > not the first. Chrome does it. I've seen it in some other random > places as well but I can't think of specific examples right now. > Indicators can be designed based on either text or icons, just like > menus can be. Chrome and even Internet Explorer do it, yes. But do you notice something? Those menus are actually menus that come from toolbar buttons that have tooltips to describe their icons, but that's another whole different issue that deserves a thread of its own. > Regardless, using menus as a model was the original decision, and > implementation-wise that's what we're doing. It's a little late to try > to change course. If you think that was a bad decision, that's a > different conversation. But here we're talking about adding new > features to specific instances of menus.. if middle-click corresponds to > a particular action in an indicator menu, shouldn't the same thing be > possible in all menus? You are missing my point. I am not disputing the decision to use menus as a model (like you said, that is for a different discussion). I am saying that we should not keep ourselves locked to menus and menus alone, rejecting all other features for the sole purpose of being a menu. An indicator is not a menu, no matter how much you may attempt to model it after a menu, and it serves a different purpose from that of the menus you are talking about. For example, a normal menu has many actions, out of which only a small subset of which are very frequently used. These would be abstracted out into toolbar icons (one-click access), e.g. Back, Forward, Refresh, New Tab, etc, and/or given keyboard accelerators, which can then be triggered as long as the window the menu belongs to has focus. Now take a look at our application indicators. Each application indicator has many actions, and most of them will have *one* frequently used one, i.e. "Show/Hide Application". We cannot assign these actions keyboard shortcuts, because the "window" that owns these menus is the panel, and it does not make sense to have to focus the panel in order to trigger these keyboard shortcuts. An alternative would be to use global keyboard shortcuts, but I do not foresee that ending well. We do not have a toolbar to abstract these actions out into. But wait! These application indicators are *already* icons. They look and act more like toolbar buttons that have menus (much like the Back/Forward history dropdown menu in Firefox) than actual traditional text-based menus that you see at the top of each window. So, why would it not make sense to provide one-click access to the aforementioned frequently used action? The following point has probably been raised before and beaten to death before, but the time taken to aim for one application indicator icon, click for menu to open, then aim *again* for the menu item needed is significantly more than the time it takes to aim for the application indicator icon and click *once*. I would say that the former case would result in slightly less than twice the time, and approximately twice the effort taken compared to the latter case. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] Middle-click on indicators
On Thursday 15,April,2010 03:48 PM, Mark Shuttleworth wrote: > [...] >> >> The following point has probably been raised before and beaten to death >> before, >> but the time taken to aim for one application indicator icon, click for menu >> to >> open, then aim *again* for the menu item needed is significantly more than >> the >> time it takes to aim for the application indicator icon and click *once*. I >> would say that the former case would result in slightly less than twice the >> time, and approximately twice the effort taken compared to the latter case. >> > > I don't fault your logic. But I can disagree with your taste. I think it > would be crass if we encouraged every app indicator to have a secret > bunch of behaviours associated with specific clicks. I know that opening > up a possibility like this results in a mess - an unusuable mishmash of > secrets. ... which is exactly what Conscious User and I said we were not proposing. We were proposing that one action be specified by the application to libappindicator to be the default. Then indicator-application (the applet) decides how to activate this default action, which we proposed to be middle-click. > > We *will* have some hidden treasures, like the scrollwheel-on-volume. > But they will be few and far between, and they will be on systemic > indicators rather than app indicators, for the moment. I don't hope to have any of the proposed features in Lucid -- FinalFreeze should have activated by now, and UIFreeze long ago. These proposals are for Maverick, and releases after it. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] Middle-click on indicators
On Thursday 15,April,2010 04:13 PM, Conscious User wrote: > >> ... which is exactly what Conscious User and I said we were not proposing. We >> were proposing that one action be specified by the application to >> libappindicator to be the default. Then indicator-application (the applet) >> decides how to activate this default action, which we proposed to be >> middle-click. > > The same standardization could be applied to the scrollwheel. A > scrollwheel action can only be associated to an indicator *if* > such action can also be done via normal menu interaction. This > is better than brushing those cases off as "hidden treasures". And similar to what Remco proposed (double-click/default actions be bolded), we could perhaps place intuitive scrolling icons on these actions that can be triggered via the scroll wheel for discoverability. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] User feedback from the new WM control order
On Thursday 15,April,2010 06:12 PM, Luke Benstead wrote: > Just to quickly add my experience to this. I've not yet accidentally > hit the close button, however I have on several occasions hit minimize > when aiming for the Applications menu. I also tweeted about it in > frustration: http://twitter.com/kazade/status/12155652979 > > I'm now totally confused, because I'm liking the left side but this > continual mishitting will probably force me to change it, which is a > shame. If we do pick up Gnome Shell for 10.10 where there is a > hoverable "Activities" menu in the same place as the current > Applications menu then I think this will just get worse. I don't think it will be an issue with GNOME Shell, as the top-left corner is a hot corner for triggering the overlay mode so you don't need to click the button, just flick your cursor to the top left corner. The button is just there for discoverability and to provide tablet users with something to poke, I think. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] User feedback from the new WM control order
On Thursday 15,April,2010 06:35 PM, Luke Benstead wrote: >> I don't think it will be an issue with GNOME Shell, as the top-left corner >> is a >> hot corner for triggering the overlay mode so you don't need to click the >> button, just flick your cursor to the top left corner. The button is just >> there >> for discoverability and to provide tablet users with something to poke, I >> think. > > My point is, when moving the mouse to close/min/max you could > inadvertently hit the hot corner, although I don't have Gnome shell > here to test how far that corner extends so it may be a non-issue. I believe the corner is only 1 pixel by 1 pixel, similar to Compiz's hot edges. Clicking the button is a separate issue though. If this poses a problem, I think it do not think it would be much better on the right side, since the me/log out menu is there. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer 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] Middle-click on indicators
On Tuesday 20,April,2010 05:53 PM, Matthew Paul Thomas wrote: > Philipp Wendler wrote on 15/04/10 14:18: >> ... >> Am 15/04/10 14:15, schrieb Matthew Paul Thomas: >> ... >>> But even though (a variation of) that guideline has been around since >>> Windows 95, it hasn't worked out well. Many users have given up on >>> left-clicking on notification area items -- probably, I think, because >>> the left-click action wasn't predictable or memorable enough. Instead, >>> they right-click to get the menu every time. "What? You can left-click >>> on that thing and it does something different from right clicking? >>> Dude, why didn't anybody tell me this? I've been doing it the hard way >>> all this time!" >>> <http://blogs.msdn.com/oldnewthing/archive/2009/05/01/9581563.aspx> > >> For me this shows that it is not worth trying to let the indicators >> behave exactly like a single other UI component. This interaction >> pattern is the same as for almost all icons in Windows (desktop, start >> menu, files in the explorer etc., with toolbars being probably the >> single big exception) and for these icons everybody knows how to use >> it. But indicators look somewhat different and users expect them to do >> something different, so they don't expect indicators to support the >> same interaction pattern. > > How do they look different? The only difference I can see is that they > have icons in their titles. So does the Applications menu. I don't quite see the similarity between the Applications menu and the application indicators, really. But I do see the similarity between a toolbar icon that has a menu, and an application indicator. The Applications menu has an icon *and* text. Application indicators have icons as the buttons instead of text, and unlike toolbar icons, they do not have tooltips. In this aspect, I can only see application indicators as the bastard child of menus and toolbar icons. An aforementioned example of a menu that does not use text in its menu buttons was Google Chromium, but its menu comes from a toolbar button, not a menu button -- it lives on the toolbar. > [...] -- Kind regards, Chow Loong Jin 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] Tasque, Giver
On Thursday 22,April,2010 10:48 PM, Frederik Nnaji wrote: > On Thu, Apr 22, 2010 at 15:12, John Lea wrote: >> I think a first step towards making Tasque work with Ubuntu One could be >> moving it to using CouchDB for it's own storage. The best person to talk to >> about this is Stuart Langridge, see https://launchpad.net/~sil >> <https://launchpad.net/%7Esil>. >> > > exactly, CouchDB is perfect for this! > i'll hail him. > > Thanks John, you helped me greatly. Before we start using CouchDB more extensively, how about making erlang processes drinking the CPU at a steady 1% of a 2GHz Core 2 Duo, and making the whole set of CouchDB things take less memory? My findings, from using Gwibber so far: If I kill gwibber and all the erlang and couch things, my battery power consumption drops by approximately 2 Watts, from ~16W to ~14W, gaining me approximately half an hour worth of battery. Surely a microblogging client, and potentially more things using Couch shouldn't take this much power? Or actually, just couch running alone is bad enough. -- Kind regards, Chow Loong Jin 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] Hovering to open items on the top panel
On Thursday 22,April,2010 10:51 PM, Luke Benstead wrote: > I've just been thinking about the new indicators, and how there were > some complaints about it adding a click to get to stuff in the menus. > Then I thought, it would be pretty cool if all the menus on the panel > (including Applications, Places, System, Me menu, Indicators and the > calendar ) opened on hover. That would reduce pretty much any action > on the top panel to a single click (e.g. launching a program, opening > a folder, setting your status etc.) > > It makes a lot of sense especially with complaints about hitting the > close button on maximized windows accidentally etc. if the > Applications menu appeared on hover that would remove that risk. It makes the accidental hover over these menus a lot more painful. I'd rather not have this. -- Kind regards, Chow Loong Jin 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] Farewell to the notification area
On Sunday 25,April,2010 05:55 PM, Mark Shuttleworth wrote: > > And you think malware couldn't put up a systray icon tricking you into > thinking you have updates? You think you would be able to tell the > difference? The panel icon is just as fakeable as the popup. Frankly speaking, I think I'd have a lot more trouble faking a notification area icon/indicator or whatever we want to call it these days than a popup, from a website point of view. I'm talking about all those weird banners that have Windows-like window borders. These popups can be just as easily spoofed using Ubuntu-styled window borders. -- Kind regards, Chow Loong Jin 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] Farewell to the notification area
justification to revert back to the previous behaviour. The > problem is the previous behaviour isn't secure. In any case it is more secure than the current behaviour. And much less obstrusive/disruptive to workflow too. There was mention of using colour in the messaging indicator to show that there are messages, as these stand out from monochrome icons. There is also colour used for the battery icon to show critical levels of power. So why not this? Let's just stick a bright red icon next to the indicators. Given that all of the indicators will eventually be monochrome, this would be a good and consistent way of getting user attention. Further points: A pop-under that does not steal focus will not get my attention until I close all my windows, after which I may need to shut down immediately due to being in a hurry, hence not getting security updates installed. A pop-up that *does* steal focus will get my attention, but it will break my workflow, and if I was a regular user who stares at the keyboard to type, I'd have typed a whole paragraph of words into the update-manager window. Then I would have lost work and be so annoyed with it that I'd just close it anyway, defeating the purpose of popping up in my face. And then there would be no further indication that I have updates, so I would just forget about it. An *icon* in the panel that is bright red in a set of monochrome icons, will catch my attention, and I would be able to attend to it when I am free enough for updates. Having the "reboot please" icon sitting around in the notification area/application indicators area, but not this, is _inconsistent_. We might as well just keep the "reboot now" window open, and always on top, so it always gets in the user's face until he/she reboots. -- Kind regards, Chow Loong Jin 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] Application Indicators v. 2
On Tuesday 27,April,2010 04:05 AM, Ted Gould wrote: > On Mon, 2010-04-26 at 21:53 +0200, Sense Hofstede wrote: >>> Quick Lookup Information >>> >>> Applications have previously have made some information quickly available by >>> using a tooltip on the icon. While I don't wish to start the tooltip >>> discussion again, what I'm curious about is we can't find a solution for >>> this information that isn't a tooltip. Does some sort of standard menu item >>> help? Could we put it somewhere else? >>> >> Skipping the rest of your questions: I think that it would be best to >> only allow certain applications to display 'quick lookup information'. >> I'm thinking: put all media players together with all other >> audio-using-applications -- USE PulseAudio's features! -- in the sound >> menu and make there room for showing the currently playing song. Put >> other 'quick lookup information' in the battery applet, etc. >> >> All this information would not be put in there using ugly hacks like >> insensitive menu items, but instead using a predefined protocol. The >> applet can than process the information. We could show the information >> in a tooltip, but we could also use insensitive menu items if we >> cannot think of anything else. We could also do both, we have the >> information and can decide how to process it. > > I think it makes sense for current song and battery level. Are there > other cases of extra information that we'd need to cater to? I think there was the issue of upload/download speed of Transmission which used to be displayed in a tooltip, though I cannot really remember. I think Deluge might have a similar mechanism as well, and KTorrent (but that's for KDE). -- Kind regards, Chow Loong Jin 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] Application Indicators v. 2
On Tuesday 27,April,2010 03:48 AM, Ted Gould wrote: > > > For application indicators we're currently only taking icon names for > the icons. This allows for consistent theming of the icons along with > the panel theme. The problem that this creates is when dealing with > dynamically generated icons. There are several applications that abuse > this (Bacula comes to mind) but applications like GNOME Settings Daemon > uses this for the current keyboard layout (putting two letters of text > as the icon). I'd prefer to avoid sending all the theme information and > update signals required to implement drawing of the icon to the > application. Is there another way that we can provide dynamic icons? Regarding this point, can we not model it after the image-data hint of the org.freedesktop.Notifications spec? I believe it sends a pixmap through D-Bus from an application to notify-osd/notification-daemon. Considering the size of the indicators, these icons should be pretty small, compared to the kinds of images sent to notify-osd, so it should not cause a huge memory leak like it did with notify-osd. -- Kind regards, Chow Loong Jin 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] Skipping Multiple songs?
On Tuesday 27,April,2010 05:13 PM, Vishnoo wrote: > Hi, > With the indicator applications menu and music player menu, I can skip > one song at a time. > > However , if i have to skip multiple songs , it is a bit tiring to open > the menu each time and to skip songs one by one. > The only other option to do it faster is to bring up the player window. > > Do others often try to skip multiple songs? > Is there a way to make this easier? [Probably, right-click to skip and > not close the menu?] > This sounds like functionality for.. *cough*the scrollwheel!*cough**cough*. No really, I am still using Karmic, and still get my nice scrollwheel functionality, but I believe I will miss it greatly once I switch to Lucid+indicator-application. -- Kind regards, Chow Loong Jin 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] Finger Swipe Gadgets
On Wednesday 28,April,2010 07:05 AM, Benjamin Humphrey wrote: > It would be kickass if you could grin at your computer to make it unlock. It would be really funny to watch someone pulling different variants of a face at the computer, failing and retrying due to shortcomings in the face recognition software. :-D -- Kind regards, Chow Loong Jin 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] Skipping Multiple songs?
On Wednesday 28,April,2010 10:47 PM, Frederik Nnaji wrote: > On Tue, Apr 27, 2010 at 20:58, Jan Claeys <mailto:li...@janc.be>> wrote: > > Obviously, shoehorning everything into standard menu items shouldn't be > our goal... > > > Do others often try to skip multiple songs? > > Is there a way to make this easier? [Probably, right-click to skip and > > not close the menu?] > > I think the drop-down from the "musicplayer indicator" should show the > currently playing song (maybe with an album picture?), the location in > the song (maybe also as a slider that can be used to seek?), and widgets > for the basic operations you will want to do (skip, play/pauze, > rate, ...?). > > > perhaps like this? (mockup attached..) That mockup looks really similar to the large tooltips that Rhythmbox and Banshee were having prior to app-indicator-ification. -- Kind regards, Chow Loong Jin 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] Two suggested designs for the Sound Indicator
On Monday 03,May,2010 05:44 PM, Alex Lourie wrote: > On Mon, May 3, 2010 at 12:31 PM, Nicholas Ipsen(Sephiroth_VII) > mailto:sephiroth7...@gmail.com>> wrote: > > I think it'd be better to keep the ordering static and alphabetical, > in order to make it easier for users to establish muscle memory of > how to use the menu. > > > I don't agree. What if I have 10 applications that support sound > settings? Will they all always appear in the list? That would be > horrible user experience. > > Will only *running* applications be there? Then no muscle memory can be > developed, as the list will be populated and re-sorted when new > application runs; this will cause some applications change their > location in the list. I think some persistence can be built up by having applications always reappear in the same location, similar to how application indicators are ordered. -- Kind regards, Chow Loong Jin 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] Two suggested designs for the Sound Indicator
On Monday 03,May,2010 06:54 PM, Jan-Christoph Borchardt wrote: > On 3 May 2010 12:11, Sense Hofstede wrote: >> On 3 May 2010 12:04, Jan-Christoph Borchardt wrote: >>> On 3 May 2010 11:15, Alex Lourie wrote: >>>> On Mon, May 3, 2010 at 12:07 PM, Sense Hofstede wrote: >>>>> On 3 May 2010 11:04, Alex Lourie wrote: >>>>>> How about a dinamic ordering in the indicator? >>>>>> >>>>>> So if I don't have any music player currently running (or playing), the >>>>>> an >>>>>> "active" application should appear first (for example, Firefox, or >>>>>> better >>>>>> even - VOIP application, such as empathy or Skype). >>>>> >>>>> Very good idea! It would indeed be a huge usability benefit if the >>>>> applications are sorted on their activity so you can easily set the >>>>> volume of the application you're most likely interacting with. >>>>> >>>> >>>> You could even "hide" everything else in some kind of a submenu... so you'd >>>> only see the media player (if running), the application you're running >>>> currently and the master volume. If current application doesn't support >>>> audio, then show the first few that do. Everything else could be in "Other >>>>> " entry. >>> >>> Absolutely. By default there should be only one volume slider for all >>> programs (like now). A control for every program (e. g. gedit …) will >>> just confuse users. >> >> FYI, 'gedit' there was a joke. Of course there should _NOT_ be an >> entry for for every programme. > > I know. I could have said Firefox as well. ;) Firefox is more likely to appear on the list, and would be especially useful, since Firefox doesn't have volume controls of its own. -- Kind regards, Chow Loong Jin 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] Two suggested designs for the Sound Indicator
On Monday 03,May,2010 07:03 PM, Martín Soto wrote:
> Hello Sense:
>
> As far as I can see, in your mail you only mention using PulseAudio's
> functionality as the main justification for your design, which is a
> purely technical reason. We should rather start by thinking about use
> cases: what are people supposed to do with this functionality?
>
> My problem with your design is that, as far as I can tell, the large
> majority of people won't want to play more than one sound source at the
> same time. You are watching a video, or playing some background musing,
> or chatting with someone, but doing two or more of these at the same
> time is very rare, because they clearly interfere with each other.\
I think listening to music while chatting is not rare at all. I do it, and many
other people I know do the same. And considering how much noise was made over
the one-application-rules-the-sound-card bug that existed prior to ALSA's dmix
coming into the picture, I think it's not rare at all to have more than one
application playing sounds at the same time.
I'd be exceptionally bothered if my sound was automatically paused in order to
play notification sounds which appear every time someone sends me an instant
message (think rapid succession from someone who types fast, which is not at all
uncommon these days).
As for playing videos, keep in mind that not all videos have sound. When I watch
a video that has no sound, I keep my music playing. When I watch a video that
has no useful sound (stupid background music that annoys me), I mute my browser
and keep my music playing. Such videos are pretty common on Youtube.
> So, for example, if you're playing background music and want to watch
> that video you just got from your pal over IM, you'll probably pause the
> music. And if someone calls you over Skype when you're watching the
> video, you'll pause it before taking the call. Given that this is the
> case, a single volume slider should suffice. The only "normal" situation
> I can think about where it makes sense to have sound mixed or
> superimposed is when notification sounds ("you have new mail") play on
> top of other sources. For this case, the volume of notifications should
> be made so that they're audible over the sound that is currently
> playing, which is something that probably can be achieved automatically
> anyway.
I have a habit of playing music (softly) while talking to friends on Skype due
to my multitasking habits, and due to the fact that I can't really function
properly without music playing.
Now, I don't mind the idea of having notification sounds playing over my music,
but I definitely do not like the idea of making my music softer just to hear
notification sounds.
> This said, there are some people who will want to mix sound from several
> sources, such as DJs and other performance artists or people working on
> sound production. I doubt, however, that they will want to use an
> indicator menu as their UI, and will have to be provided with a
> specialized solution anyway.
>
> Do people see other use cases I'm missing?
--
Kind regards,
Chow Loong Jin
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] Two suggested designs for the Sound Indicator
On Monday 03,May,2010 09:38 PM, Jan-Christoph Borchardt wrote:
> 2010/5/3 Martín Soto :
>> My problem with your design is that, as far as I can tell, the large
>> majority of people won't want to play more than one sound source at the same
>> time. You are watching a video, or playing some background musing, or
>> chatting with someone, but doing two or more of these at the same time is
>> very rare, because they clearly interfere with each other.
>>
>> So, for example, if you're playing background music and want to watch that
>> video you just got from your pal over IM, you'll probably pause the music.
>> And if someone calls you over Skype when you're watching the video, you'll
>> pause it before taking the call. Given that this is the case, a single
>> volume slider should suffice. The only "normal" situation I can think about
>> where it makes sense to have sound mixed or superimposed is when
>> notification sounds ("you have new mail") play on top of other sources. For
>> this case, the volume of notifications should be made so that they're
>> audible over the sound that is currently playing, which is something that
>> probably can be achieved automatically anyway.
>
> Thanks for writing out my post in full:
> On 3 May 2010 12:04, Jan-Christoph Borchardt wrote:
>> Absolutely. By default there should be only one volume slider for all
>> programs (like now). A control for every program (e. g. gedit …) will
>> just confuse users.
>>
>> I am sceptic on how the use cases are anyway: When you are listening
>> to music, you normally do not watch a movie at the same time. If
>> certain notifications are masked by loud music, there should be a
>> function to automatically slightly dim every other sound when a
>> notification is playing (in a subtle, not in an annoying way, of
>> course).
>
> +
>
> On 3 May 2010 13:14, Chow Loong Jin wrote:
>> On Monday 03,May,2010 06:54 PM, Jan-Christoph Borchardt wrote:
>>> I know. I could have said Firefox as well. ;)
>>
>> Firefox is more likely to appear on the list, and would be especially useful,
>> since Firefox doesn't have volume controls of its own.
>
> What would be the use case for Firefox sound controls? It would only
> add another control to the already present main sound slider and the
> many more sliders from various video and audio sites (Youtube, Last.fm
> etc.).
Think of all those flashy annoying myspace pages that play music and don't
provide any controls. Do you honestly believe that all the video and audio
players out there embedded into web pages have volume controls?
And what about all those Facebook games out there that have annoying background
music that cannot be muted? I think Firefox is a great candidate to have a sound
control of its own in the sound indicator, similar to the way it's currently
done in Sound Preferences.
There is a further thread somewhere down the line about how annoying it is to
have to switch to the appropriate application and turn off sound for a call. Now
imagine how much more annoying it would be to look through ~30 different tabs to
figure out which webpage is making sound and disable it.
--
Kind regards,
Chow Loong Jin
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] Two suggested designs for the Sound Indicator
On Monday 03,May,2010 10:17 PM, Martín Soto wrote:
>
>
> On Mon, May 3, 2010 at 1:23 PM, Chow Loong Jin <mailto:hyper...@ubuntu.com>> wrote:
>
> I think listening to music while chatting is not rare at all. I do
> it, and many
> other people I know do the same. And considering how much noise was
> made over
> the one-application-rules-the-sound-card bug that existed prior to
> ALSA's dmix
> coming into the picture, I think it's not rare at all to have more
> than one
> application playing sounds at the same time.
>
>
> Some people do listen to music while talking to someone else on the
> Internet phone. I do it myself on occasion, but I don't think this is
> so common, though. The common case for simultaneous sound playback is a
> lot more related with applications such as IM clients playing short
> sounds while something else is playing in the background. People want to
> listen to music and still be able to tell when an IM arrives.
>
> I'd be exceptionally bothered if my sound was automatically paused
> in order to
> play notification sounds which appear every time someone sends me an
> instant
> message (think rapid succession from someone who types fast, which
> is not at all
> uncommon these days).
>
>
> I guess almost everyone would be bothered in this case. This is the
> reason why I wrote:
>
>> The only "normal" situation
>> I can think about where it makes sense to have sound mixed or
>> superimposed is when notification sounds ("you have new mail") play on
>> top of other sources. For this case, the volume of notifications should
>> be made so that they're audible over the sound that is currently
>> playing, which is something that probably can be achieved automatically
>> anyway.
>
> That is, notification-type sounds should be mixed with whatever else
> that is playing. I think, however, that their volume can probably be
> selected automatically in such a way that they are heard on top of the
> background. This way we don't force people to fiddle with another volume
> slider in order to hear their notifications.
Sorry, I read that as "soften the music to let notification sounds be heard" and
my response was meant to be phrased the same way. Choosing a default
notification volume that is higher than other things should do the job well
enough. Anything else is likely to annoy the user, especially audiophiles among
other users who get touchy when their music is disturbed.
>
>
> As for playing videos, keep in mind that not all videos have sound.
> When I watch
> a video that has no sound, I keep my music playing. When I watch a
> video that
> has no useful sound (stupid background music that annoys me), I mute
> my browser
> and keep my music playing. Such videos are pretty common on Youtube.
>
>
> I bet most people won't bother to mute the video. Since most youtube
> videos aren't longer than two or three minutes, they'll just endure the
> music if they have to. So this is probably a rather advanced use case,
> but I may be wrong.
Youtube has a queue. You can chain up hours long worth of videos using that.
>> So, for example, if you're playing background music and want to watch
>> that video you just got from your pal over IM, you'll probably pause the
>> music. And if someone calls you over Skype when you're watching the
>> video, you'll pause it before taking the call. Given that this is the
>> case, a single volume slider should suffice.
>
> I have a habit of playing music (softly) while talking to friends on
> Skype due
> to my multitasking habits, and due to the fact that I can't really
> function
> properly without music playing.
>
>
> Although I thing, as I said above, that this is not so common, it's
> still an interesting use case. If I'm listening to music and a call
> arrives, for example, I'd rather have the music paused automatically as
> soon as I take the call.
There's a difference between "not so common," and "non-existent." I understand
your concern that my use cases may be uncommon, but what you appeared to be
doing earlier was saying something like "well most people would do X, so let's
assume that everyone acts the same way and remove all other use cases."
--
Kind regards,
Chow Loong Jin
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] Two suggested designs for the Sound Indicator
On Monday 03,May,2010 10:22 PM, Martín Soto wrote: > > > On Mon, May 3, 2010 at 4:11 PM, Chow Loong Jin <mailto:hyper...@ubuntu.com>> wrote: > > Think of all those flashy annoying myspace pages that play music and > don't > provide any controls. Do you honestly believe that all the video and > audio > players out there embedded into web pages have volume controls? > > And what about all those Facebook games out there that have annoying > background > music that cannot be muted? I think Firefox is a great candidate to > have a sound > control of its own in the sound indicator, similar to the way it's > currently > done in Sound Preferences. > > There is a further thread somewhere down the line about how annoying > it is to > have to switch to the appropriate application and turn off sound for > a call. Now > imagine how much more annoying it would be to look through ~30 > different tabs to > figure out which webpage is making sound and disable it. > > > This sounds perfect for a new Firefox extension. No, my point is that controlling the volume is the desktop environment's job. Not each individual applications' job. Please don't forget that Firefox isn't the only browser out there, and that the browser war is almost as religious as the editor war. Someone also mentioned somewhere earlier in the thread that this is not limited to Flash games in a browser alone, but other random games as well. I know of a friend who plays music from a media player in the background while playing FPS games. -- Kind regards, Chow Loong Jin 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] Two suggested designs for the Sound Indicator
On Wednesday 05,May,2010 12:48 AM, David Hamm wrote: > I may have suggested getting rid of the system wide volume in the > past, but only for the reason that most hardware already has a system > wide volume- and for that reason alone. Linux however caters to such a > broad environment it is a necessity to keep this function. Please keep in mind that most notebooks do not have hardware volume controls, since any hardware volume buttons/controls actually send events to the OS which will be the one handling the volume control. -- Kind regards, Chow Loong Jin 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] Fwd: Open Letter: The issues with client-side-window-decorations
On Sun, 06 Jun 2010 14:39:40 -0500 Ted Gould wrote: > On Sat, 2010-06-05 at 23:31 -0400, Scott Kitterman wrote: > > So I think it's worth continuing the conversation. I'm personally quite > > concerned that we are about to have a permanent split between GTK/Gnome and > > Qt/KDE on this topic that will make future work on desktop consistency much > > more difficult. > > Why couldn't Qt support themes that specify the window title as well? > There's already work on keeping the theming across toolkits, it seems > like this just extends it. I don't see this as creating a larger gap as > before to get consistency you need to make a GTK, Qt, KWin, Compiz and > Metacity theme (they pull from each other, but you need to check them > all) and now you just have to make a larger GTK and Qt theme. > > --Ted > There were other issues as well, such as closing/forcing hanging applications to quit using the "x" button, and minimizing applications that are still currently hung while waiting for them to un-hang themselves. These two use cases would no longer be possible with CSD, as mentioned in the open letter. And as the letter mentioned, CSD doesn't appear to bring much (any?) pros despite all the obvious cons highlighted, yet we're going the CSD route. Couldn't we have more information about this? All I've seen so far are posts refuting some of the cons highlighted, but none highlighting the possible benefits CSD can bring. I'm sure that if we have good reasons for implementing CSD, it would calm the concerns many seem to have about CSD. -- Kind regards, Chow Loong Jin signature.asc Description: 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] Putting some brakes on the enthusiasm
On Tue, 8 Jun 2010 13:55:26 -0700 David Hamm wrote: > "The key principle to keep in mind here is that if you are healthy a > salmonella infection is not a big deal." > http://www.healingdaily.com/detoxification-diet/raw-eggs.htm But in this case, we also want to cater to these unhealthy people to whom salmonella infection is a big deal. -- Kind regards, Chow Loong Jin signature.asc Description: 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] Lock Screen / Guest Session / Switch From / Log Out / Suspend / Hibernate / Shut Down
On Saturday 19,June,2010 04:17 PM, Kristoffer Lundén wrote: > Re: Suspend/Hibernate - is it possible, technically, to do both? If so, > the session could be saved to both memory and swap, and if the power > remains, it could wake up from suspend, but if the power has gone away, > it could boot from hibernate, with loss of data or session. I seem to > recall, vaguely, that Macs do something like that, but it may be that it > saves to hibernate if power goes low or something. Or I may just have > dreamed it. :) It's pm-suspend-hybrid on Ubuntu. If I recall correctly, it didn't work correctly for all machines. Also, this method of sleeping is slow, as it needs to write things to the disk first prior to sleeping. The main reason I currently use suspend instead of hibernate all the time is because of the (relatively) long time it takes for a machine to fully hibernate, even when using TuxOnIce, which is much faster than the default method. I believe suspend-hybrid isn't ready for consumption just yet. -- Kind regards, Chow Loong Jin 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] Yet another discussion on window resizing
On Tue, 22 Jun 2010 09:33:27 -0700 Dylan McCall wrote: > Here is yet another discussion on resizing windows, this time driven > by status bars! > > MacOS has a similar situation to us, with very narrow window borders. > In its case, they don't even _try_ to offer resizing by the window > edge. (The idea being, I suppose, that any control less than five > pixels in any direction will be very difficult to reliably use). > Rendering that resizing situation less of an issue, MacOS has the very > unusual functionality for expanding windows, and pretty well every > window has a client-owned resizing grip in the bottom right. > > Gnome has a _similar_ solution in place. We don't have the cool > maximize behaviour (and it would probably anger a great number of > people if it was implemented), but any window that happens to have a > status bar will probably have a resize grip as well. Unfortunately, > this resize grip is not a widget you can just drop in easily; it's > fused to the status bar widget. (Further demonstrating that the darn > things have no objective and should stop being called status bars). > > So, here is the problem: there's a plan to get rid of of status bars > and replace them with ephemeral hint bars. > > And now, I'll bring your attention back to everyone's favourite bug, > lp:160311 (“Resizing windows by grabbing window borders is > difficult”). > https://bugs.edge.launchpad.net/ubuntu/+source/metacity/+bug/160311 > > The status bar work shouldn't make that bug worse, but in the current > direction it will. > > > > I discussed a possible solution for this somewhere, and nobody really > gathered what I was babbling about. To fix that, I finally made a > quick mockup today… > > http://people.ubuntu.com/~dylanmccall/mockups/metacity-resize-control/mockup.html > > That describes a visible resize control drawn by the window manager. > It should fade in when the user moves the mouse near a window's bottom > right corner. It should only appear for the window that is in the > foreground. Clicking it would do the same thing as clicking and > dragging the corner of a window's border, except there's a lot more to > click and much more meaningful visual feedback. > It does miss a critical detail, of course, but I, err, never saved the > SVG. The resize control should go _behind_ the window, not in front of > it. That way it sticks out from the window but doesn't interfere with > anything in the client area. (As drawn there, it would become very > difficult for some people to use scroll bars). > > > > I'm sure there are some other clever solutions here! Maybe even some > plans attached to the Windicators / Hint bars work :) > So, I am curious to know: is there anything happening in this space? > Should there be? I personally prefer using Alt + Middle button to resize windows, and find that it's much easier since there's a much larger click area than just a pixel-thick border. Another method of resizing is using the "Resize" option from the window menu, which positions the cursor in the middle of the window. The direction the window is resized in is then chosen from the direction you first move your mouse in after clicking the "Resize" option. Perhaps we could improve on one of these methods and make it more obvious to users. -- Kind regards, Chow Loong Jin signature.asc Description: 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] Executable file dialog box...
On Tuesday 21,September,2010 09:20 PM, Luke Benstead wrote: > On 21 September 2010 13:54, Remco <mailto:remc...@gmail.com>> > wrote: > > On Tue, Sep 21, 2010 at 12:38, Luke Benstead <mailto:kaz...@gmail.com>> wrote: > > I'm wondering if we need this dialog at all, surely we can code in a > little > > bit of logic here. How about: > > > > If the file is executable and: > > > > 1. If the file is binary and the extension not associated to a program, > > attempt to run it > > or > > 2. If the file is text and has the #! line at the top, try to run it. > Add > > "Run as a Program" and "Run as a Terminal Program" to the right click > menu > > or > > 3. If the file is text, open it in the default editor and add "Run as a > > Program" and "Run as a Terminal Program" to the right click menu > > > > That way double clicking a file will do what the user expects most of > the > > time, and give the option of alternative behaviour if necessary. > > > > Thoughts? > > This may have security implications. What if the file is a malicious > bash script? GNOME attempts to help the user avoid running malicious > code. Double clicking a text file downloaded from the internet should > not be a gamble. You double click the file to study it, and suddenly > it deletes all your files. > > > I did consider this, however, when you download a file from the Internet via > Firefox the executable bit is turned off, you have to already consciously go > and > enable it otherwise double clicking the file just opens it in a text editor. On the other hand, pendrives, majority of which are formatted with a vfat file system, are mounted in a way that results in all the files being executable by default. I believe the same goes for NTFS file systems which are popular for external hard disks. > The current dialog doesn't seem to be about security (otherwise there would > be a > warning stating that) it seems to exist because Nautilus doesn't know what you > want to do with the file. Right, and it can't, because there's no way to tell whether the executable bit was set intentionally or not. > [...] -- Kind regards, Chow Loong Jin 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] preferred applications
On Monday 04,October,2010 05:57 PM, Matthew Paul Thomas wrote: > [...] > I would love to see results of this user test: Before the test, install > Ubuntu from scratch, then install Chromium alongside Firefox, then put a > shortcut to some Web site on the desktop. Then in the test, get the > participant to double-click on the shortcut to open it in Firefox, then > close Firefox. Now show them Chromium, and say, "If you wanted that > shortcut to open in Chromium whenever you double-clicked on it, what > would you do?" I don't believe this issue is as simple as you try to make it out to be. Let's extend the user test a little: Delete the shortcut, start a chat and post a URL in the chat, get the participant to click on it to have it open to Chromium, and close it again. Now show them Firefox, and say, "If you wanted that link to open in Firefox whenever you clicked on it, what would you do?" -- Kind regards, Chow Loong Jin 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] Implementation of a built-in screencaster in Unity like there is in GNOME Shell
On Wednesday 02,February,2011 04:31 AM, Ward Muylaert wrote: > Eh, that doesn't sound like it has anything to do with GNOME Shell or Unity, > but > more like simply running a screencasting program in the background that > triggers > on that particular key combo. I believe GNOME Shell actually does have screencasting functionality built into it, which triggers upon that key combination. -- Kind regards, Loong Jin 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] Regarding the Sound Menu Spec's closing of inactive audio applications
On Tuesday 08,February,2011 09:36 PM, Matthew Paul Thomas wrote: > A window's close button should close the window. Anything else the > program does should aim for the least overall distraction. Please correct me if I am wrong, but does this not mean that the original behaviour of having the media players (Banshee and Rhythmbox) close their windows, but remain running in the background, ready to resume at a moment's notice, is the correct behaviour after all? It seems to me that the original behaviour (as opposed to the current behaviour) closes the window and yields the least overall distraction, thus complying with the statement you made. The user does not need to know that the media player is actually still running in the background. The "Quit" action does create a bit of confusion in that case though. -- Kind regards, Loong Jin 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] We need a short-term solution for mail applications and the messaging menu
On Tuesday 15,March,2011 09:21 AM, Conscious User wrote: > > In an effort to get *some* reaction other than Jeremy's to this > thread, let me ask something to the people of this list: how > many of you actually use Evolution? And how many of you feel > confortable with the current way it's integrated to the > Messaging Menu (and now Unity)? > > More specifically, how many of you think that the current setup > of not being able to hide the window is acceptable while the > separation of mail notification service does not happen? > > I have the impression that the user experience of Evolution > always ends up being overlooked because the majority of > people uses a webmail client and does not really care. I use Thunderbird, which doesn't get hidden either. Evolution should be killed with fire, in my opinion. The entire framework is convoluted as hell, and when facing an unstable network, it hangs completely. Messaging Menu aside, I think the whole issue of hanging due to an unstable network is unacceptable, and hardly the right user experience to be pushing out either. And worse still -- when you have a network calendar added to Evolution, and an unstable network, the desktop calendar applet thing hangs when you attempt to open it. How nice, eh? -- Kind regards, Loong Jin 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] Indicator Emulation for Systray applications
In Ubuntu 11.04, Unity has effectively removed notification area support for almost everything but a few exceptions, which are maintained in a whitelist specified in dconf. I'm not exactly sure why this happened, but I'm thinking that it's something along the lines of forcing all applications to move to the new and improved indicators. This actually got me thinking.. rather than hiding the icons of the applications not in the whitelist, how about emulating indicators for them? Disclaimer: I don't know if this idea has been brought up before, so if it has, please point me in the right direction. I haven't actually given much thought to the implementation, so I don't actually know how hard it is to implement, if it's even possible, but design-wise, it could be something like taking the context menu from the notification area icon and using that as the emulated indicator's menu, and add an extra entry to the top of the menu for launching the application. I think something like that would work for the majority of the indicator-less applications, including our venerable Skype notification area icon that sits in the whitelist. And this would surely be a step up from the current state of not being able to interact with windows that minimize themselves to the notification area, only to disappear completely since the notification area icon wasn't whitelisted. -- Kind regards, Loong Jin 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] Thoughts on Unity design
On 19/05/2011 16:57, Florian Diesch wrote: > > It's about impossible to use "focus follows mouse" and multiple windows > with the global menu, which makes it unusable for me. Not entirely possible -- I use F10 to get to the menus. But I'll agree, it is pretty inconvenient. -- Kind regards, Loong Jin 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] Fwd: Re: People expect the backlight colours on the unity launcher to mean something.
On 26/05/2011 17:29, Jo-Erlend Schinstad wrote: > I originally posted this message to ubuntu-desktop@lists.u-c > and didrocks suggested I forwarded it here. So here goes. :) > [...] Hi Jo-Erlend, While I'll agree it's not immediately obvious what the backlight colours are for, I think the backlight colours following the dominant colour of the icon makes for some pretty good aesthetics. What I have done on my machines is to set the "Backlight Mode" in CompizConfig Settings Manager to "Backlight Toggles", which only icons which have running applications to be backlit. I think having this as default would be a good idea as it makes the running applications a lot more obvious than the other backlight options. -- Kind regards, Loong Jin 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] semi-transparent indicator menus
On 29/10/2011 03:33, Carl Ansell wrote: > Thats nice. But put a window behind the menu, and you won't be able to read > the > text clearly. Not quite. You just need to set the opacity high enough. See http://ubuntuone.com/4ERrPdiNCEvW9XrKjWf0km and http://ubuntuone.com/7LNXXpuBOVSu20JTdSwLf9 for examples of translucent menus with text behind them. -- Kind regards, Loong Jin 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] Indicator menu
On 29/10/2011 19:59, Peterson Silva wrote: > > What I guess I'm trying to say is that Mac OS X and its rounded corners: I'm > all > in for them, if they don't have them patented. But that baloon? Seems like a > circus to me =( > > (Btw, I'm aware that they are on the Unity Launcher (sorta), and I think > that's > one of the subconscious reasons I don't use the right-click on it so much, > even > if I have two of three quicklists set up =P) Um, round corners patented? Are you sure they are? If so, then the designers of all those websites with fancy round corners around their elements need to be sued. -- Kind regards, Loong Jin 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] buttons in file browser
On 02/11/2011 11:14, anthropornis wrote: > Or I could click one button one time. That is the essence of simplicity. You could say that for every commonly used feature there is. I don't frequently change views, for example, but I frequently change between showing hidden files and not. I also create new folders much more frequently than I switch views, and the same can be said about changing the arrangement of items. By your logic, we would have three new buttons for each view, a toggle "Show hidden files" button, perhaps a menu for changing the sorting order of items and a create new folder button in the toolbar, or elsewhere not in the menu. The result would be a beautifully cluttered interface. You can't have everything, and you can't fully please everyone. Incidentally, all of the mentioned actions, except changing sorting order, have keyboard shortcuts for them, which are clearly indicated beside their entries in the menu. I really don't see a problem with the current solution. -- Kind regards, Loong Jin 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] buttons in file browser
On 02/11/2011 12:25, James Jenner wrote: > > The solution before the current solution was to have a toolbar with buttons > for > common actions. Who said that the solution that was 'current' previously had > to > change? Upstream, I guess, but wouldn't you agree it looks much cleaner this way? > I'm not aware of anyone saying that all options should be available by a > toolbar. Just the common ones. One idea would be to allow a user to choose > what > the buttons are available on the toolbar. Maybe have a default set based on > the > common use cases for a browser. The default set *is* based on common use cases. Except, say, the search button which I've never used. But yes, a configurable toolbar would be nice. > And you haven't addressed the issue for accessibility. Not everyone is adapt > at > multi-key pressing like you are. Do we just ignore people who have poor > dexterity so there can be an 'uncluttered' interface (which is a subjective > measure, I would have argued that the previous interface was 'uncluttered'). It really isn't hard to hit Ctrl+[1-3]. No, really. See, your thumb goes on the control key.. and your third finger goes on the number key. Was that so hard? (Let's ignore for a moment the whole hand-must-stay-on-home-row case, because if we go into that, we should obviously exchange the Caps lock key for a Ctrl key and then it gets even easier). > And please don't use reductio ad absurdum, I could equally say that based on > your logic all toolbars from all applications should be removed because it > will > be 'uncluttered'. I would presume that would be equally absurd as your claim > that based on our logic all options should be on a toolbar. I was just ranking things by how frequently used they were. You may change views often, but I don't, and in fact, I use the "Show hidden files" option a lot more. Hence, if we're going to add the change-view buttons onto the toolbar, then please add my show hidden files button, and every $button that everyone else uses most frequently as well to be fair to everyone. I think I've just demonstrated here that this is an option that is rather subjective based on the type of user you're looking at -- a corner case. On the other hand, putting every other toolbar option into the menu (in Nautilus's case, the back/forward button which I'm sure everyone uses, the breadcrumbs and location bar which I'm also sure everyone uses), is rather absurd in comparison. If anyone was using "reductio ad absurdum", that would be you. -- Kind regards, Loong Jin 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] buttons in file browser
On 02/11/2011 12:43, anthropornis wrote: > In Nautilus Elementary I had 3 buttons to switch views (icon, list, compact). > It > was on the same row as the location (text or breadcrumb) and was not cluttered > for me at all. Strange. In my Nautilus Elementary, the buttons were on the status bar beside the zoom slider. But yes, I agree it wasn't cluttered. It looked pretty nice actually. > [...] > But what you suggest is actually interesting -- a customizable tool bar, just > like in LibreOffice, Firefox, and other mainstream applications. Oh my, I > could > potentially have 20 different buttons I could add to my own toolbar, or just > select a subset of, e.g., 3 of those, to put on my personalized tool bar. That > almost sounds like something that has been around for years. That was pretty obvious without having you mention it, but thanks anyway. > I understand that you do not see a problem with the current "solution." That > is > typically how problems begin, one user thinks his way should be the way for > everyone, and just excuse this penchant by throwing out that old bromide "oh, > you can't please everyone". That is true, but it's one thing to actually try, > and another to just say "do it my way". This is why I don't consistently > follow > this mailing list, because there is no shortage of that type of thinking > present > here. Other users? What other users? If I had it my way without considering other users, I would have a show hidden files/folders checkbox somewhere visible on the UI, not hidden in the menu. Try thinking about the greatest common denominator here, why don't you? > The thing is, if people other than yourself have things they can toggle > on/off, > or re-arrange, at will, it does not even have to affect you, or your own views > on clutter. We can ~all~ be closer to happy that way. User interface > precedents > do exist in this area. I never understand why that is so offensive to some > people. Yay, but the UX team wasn't so happy with that, last I checked. *cough* notify-osd *cough* (not that I dislike its default behaviour, by the way) > [...] > PS for the time being I am using GPRename instead of Purrr, but thanks for the > suggestion (that reply didn't make it to the list). Whoops. -- Kind regards, Loong Jin 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 controls to left or buttons to right?
On 27/11/2011 18:32, Enrico Carafa wrote: > if the mouse is in the left part of the windows, the control appear to the > left, > otherwise if the mouse is in the right part of the windows, the control appear > to the right. How does that work for maximized windows when you have indicators in the upper-right of the screen? -- Kind regards, Loong Jin 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] Clippy has noticed you've been trying to click on notifications...
On 29/11/2011 23:08, Matthew Paul Thomas wrote: > > The first reason is that a chat window wouldn't be noticable unless it > was frontmost; it's difficult (or little-known) to make a window > frontmost without making it take focus; and if a window takes focus > while you're working, that's annoying. If a window kept popping up in your face and obscuring what you were working on, it would be just as annoying. -- Kind regards, Loong Jin 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] Notifications in unity
On 02/12/2011 03:45, Dylan McCall wrote: > On Wed, Nov 30, 2011 at 12:08 PM, Conscious User > wrote: >> The most obvious one is the ugly gap when no synchronous notification >> is being shown. But I personally think that making synchronous and >> asynchronous informations have the same appearance and positioning >> is a mistake by itself. > > That this is the case should raise a red flag for everyone who has > paid attention to NotifyOSD. A big part of the design is that an > application can't control where notifications are. It can't treat a > notification bubble as a part of its own user interface — neither as a > dialog box nor a fancy tooltip. Yet indicator-sound is doing that > intentionally, by default! That same thing goes against a big part of > indicators, too: indicator-sound has no place assuming that indicators > are at the top right of the screen or in any way related to > notifications. I'll assume you're talking about the notification that pops up when you scroll on the volume icon. This notification is exactly the same as the notification when you press the volume buttons on the keyboard. I don't see any part of this behaviour depending on the position of the notification on the desktop. Whether the volume indicator appears at the top right, bottom left, or even centre of the screen, this behaviour will be consistent between your sound indicator and your keyboard volume buttons and is unlikely to look out of place (or at least any more out of place than it will if it's in the centre/bottom left anyway). -- Kind regards, Loong Jin 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] Clippy has noticed you've been trying to click on notifications...
On 02/12/2011 19:46, Matthew Paul Thomas wrote: > True. But it could appear only when someone starts a conversation, > rather than every time they say something. That only makes it slightly better. It's still just as disruptive at the beginning of a conversation. In contrast, a notification allows me to glance or ignore the message and reach a safe point for context-switching before actually attending to the message. I think what's needed is a better way of linking the notifications to the messaging indicator. -- Kind regards, Loong Jin 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] why compiz in place of mutter
On 29/01/2012 16:22, supernova wrote: > Goodmorning (GMT+1) to all. Yesterday I tried Precise, and it works > very good. I have seen that it is a bit slower and more fat than the > gnome-shell, as it happened for 11.10, 11.04, ... . I guess it is due > to compiz, which is more heavy than mutter. Why don't use mutter then? > Unity doesn't use effects as rotation and wobbly. So mutter could be > sufficient. Before Unity came along, Compiz was much leaner than Mutter/GNOME Shell was, using around 20MB of memory at any point of time, and not leaking any. After Unity came along, Compiz's memory consumption jumped up to ~80-100MB. If anything, Unity is why Compiz is running slower and "fatter" than previously. -- Kind regards, Loong Jin 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] why compiz in place of mutter
On 29/01/2012 20:55, Conscious User wrote: > > Em 29-01-2012 10:10, Chow Loong Jin escreveu: >> On 29/01/2012 16:22, supernova wrote: >>> Goodmorning (GMT+1) to all. Yesterday I tried Precise, and it works >>> very good. I have seen that it is a bit slower and more fat than the >>> gnome-shell, as it happened for 11.10, 11.04, ... . I guess it is due >>> to compiz, which is more heavy than mutter. Why don't use mutter then? >>> Unity doesn't use effects as rotation and wobbly. So mutter could be >>> sufficient. >> >> Before Unity came along, Compiz was much leaner than Mutter/GNOME Shell was, >> using around 20MB of memory at any point of time, and not leaking any. After >> Unity came along, Compiz's memory consumption jumped up to ~80-100MB. >> >> If anything, Unity is why Compiz is running slower and "fatter" than >> previously. > > > If I remember correctly, Unity came along at the same time > Compiz 0.9.0 did, and 0.9.0 was the complete rewrite from > C to C++. So Unity is probably not the only reason. Not quite. I was using a Compiz 0.9.0 compiled using the script from git://anongit.compiz.org/users/soreau/scripts before Unity came along, and its memory consumption was ~20MB. Unity made all the difference. -- Kind regards, Loong Jin 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] why compiz in place of mutter
On 29/01/2012 23:53, supernova wrote: > maybe it is because I have intel graphics, but I find gnomeshell > faster then unity, at first and clean installation I mean. Let's hope > better for the future... I have two laptops, one of which runs on the Intel GMA 965/X3100, and another running on Sandy Bridge graphics. I can safely say that under both of these conditions, in no case is Mutter faster than Unity. It's probably an issue of perception and bad press floating around, which can possibly stem from Compiz being that much more customizable than Mutter. -- Kind regards, Loong Jin 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
