On Thu, 2009-10-01 at 09:18 -0400, Kris Warkentin wrote: > Kok, Auke wrote: > > > > There is a difference between semantics and what you want. The developers > > need to > > invest extra time to make (arguably non-compliant and broken or not) > > applications > > work because they're being put into a windowing system which is new. This > > needs > > thought, effort, and most of all, time. > > I appreciate that features don't appear by 'magic' and require effort. > What I object to is acting as if applications using the tray is somehow > 'broken'. As I pointed out in another reply, there is nothing > non-compliant about using a system tray since it's clearly defined on > FreeDesktop.org: > > http://standards.freedesktop.org/systemtray-spec/latest/
Equally there's nothing that says we HAVE to have everything on FDO. Using the systray when it's there is not broken, but using it the way a small number of apps do is broken, even on a desktop system using GNOME or KDE (the user could choose to remove it). > > The problem will get fixed. You could suggest the issue perhaps also to > > (your > > favorite project) maintainers as they might just be able to do something > > sensible > > if the systray is not present. Like, not actually hiding yourself or > > exiting. > > Thank you. I just wanted someone to acknowledge that it's a legitimate > concern. I doubt that changing every app in the world that uses the > system tray to comply with Moblin is practical but yes, on a small scale > for a few apps it might be doable. > > I recognize that the problem with the systray is that many applications > abuse it and use it for much more than just simple notifications (thanks > Windows ;-) > > I really like Moblin's coherent user experience with notification, > messaging, web, etc. all using a unified framework. It's absolutely the > way to go and when it's done it will be fantastic for developers. At > the moment however, we're stuck with customer requirements for things > that don't quite 'fit'. If you really want a system tray, then you can add some other panel with systray to Moblin 2.1 and it will work. For example you could use MatchboxII panel to do this. > I'm fine with the concept of not having a tray as long as there is a > reasonable alternative. I started this example in another email and got > no reply so lets try again: > > 1) Closed source telephony app...let's call it 'Trype' (tm) that we > can't really modify. > 2) Needs to be running to accept incoming calls. > 3) Should be hidden when not in use. Why should it be hidden when not in use? Or put another way, if Trype is sitting on a zone of it's own then when I'm, for example, browsing the web in another zone it is hidden (from me). What's the difference, other than you've now added another complex interaction into the system. > 4) Needs to be 'raiseable' to make outgoing calls. You don't need to raise it, you just need to switch to the zone it's in. > So a tray is one solution. What about others? Perhaps apps could > 'minimize' to their launcher icon so that when you click it again they > raise? That's an OSXey thing to do but it's not bad. Perhaps there > could be some notion of minimizing that doesn't require something as > ugly as a task bar. Something like small, transparent icons over the > desktop that get bigger/opaque when you hover and can click to raise? Because we don't want the background to be a mess of throbbing distracting icons? If you're talking about modifying 3rd party apps to make this sort of thing happen, then why not just modify them to use the Moblin UI correctly. Use the notifications, panels, and zones that we already have. No need for anything else. If you're talking about doing something like this using the systray spec then I'd be skeptical it's doable. IIRC applets don't emit a signal when they change state, so in your example the desktop icon wouldn't know when to start throbing. Paul > A picture is worth a thousand words so I attached a quick mockup of what > that might look like. > > I'm thinking it might be possible to make the notion of minimizing and > docking look the same from the user perspective. This might fit in well > with the 'one maximized app per zone' model. > > Just trying to come up with ideas. I'm sure there are others out there too. > > cheers, > > Kris > _______________________________________________ > Moblin dev Mailing List > [email protected] > > To manage or unsubscribe from this mailing list visit: > http://lists.moblin.org/listinfo/dev or your user account on > http://moblin.org once logged in. > > For more information on the Moblin Developer Mailing lists visit: > http://moblin.org/community/mailing-lists -- Intel Open Source Technology Centre http://oss.intel.com/ _______________________________________________ Moblin dev Mailing List [email protected] To manage or unsubscribe from this mailing list visit: http://lists.moblin.org/listinfo/dev or your user account on http://moblin.org once logged in. For more information on the Moblin Developer Mailing lists visit: http://moblin.org/community/mailing-lists
