Re: The future of virtual desktops
A Quinta, 3 de Março de 2011 06:36:02 Aaron J. Seigo você escreveu: On Friday, February 25, 2011, Hans Chen wrote: - I see virtual desktops (VDs) as subordinate to activities this is incorrect. disabuse yourself of this notion. , i.e., each activity should have its own set of virtual desktops. Currently VDs are not activity aware. i don't particularly see the benefit of this. it is in theory possible (kwin is already aware of activities), but unless there is significant benefit to such a thing, it will be very complex to add to the configuration GUI. - There is an option to kind of merge activities and virtual desktops no, there isn't. (Different widgets for each desktop). I know that it was added due to popular demand, but now that activities also manage windows I don't think it is needed anymore. (Some users are not going to like this, I know.) yes, like the people we implemented that feature for in the first place: people who want different wallpapers and widgets on each desktop. virtual desktops and activities are actually, not just in theory but actually, orthogonal. we know this from usage patterns of real live users. :) I catualy think that the activities change UI should ilustrate exactly that; the ortogonal nature of them :) we would show stacks of activities showing all their VD's the vd's would be aligned horozontaly(small thumbnails of them) and the activities would be on the verical axis yes Ortogonal :D in this UI one should be able to create more Vd's for an activitie or create more activities. since their creation is show in ortogonal places it will help people wraping their brains around the concept. The point of entery tor this feature showd in a minimised form alow to switch activities on one click. -- oxygen guy, I make the pretty pictures ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kdelibs] plasma: after applet's dataupdated is called, dirty=false
On Thursday 03 March 2011, Aaron J. Seigo wrote: On Wednesday, March 2, 2011, Marco Martin wrote: Git commit 87c356421fdf4587fa8b82a3f148e9bad2fa5edb by Marco Martin. Committed on 02/03/2011 at 22:04. Pushed by mart into branch 'master'. after applet's dataupdated is called, dirty=false in DataEnginePrivate::connectSource, if it's an immediate call, and QMetaObject::invokeMethod(visualization, dataUpdated is called, means the datacontainers' dirty bit must be set to false, otherwise we will get two subsequent dataUpdated can it have countereffects? it's _probably_ safe, but this is moderately intricate (if not overly complex) code. have you tried it with both synchronous and asynchronous (e.g. weather) dataengines? i didn't find any counter effect, with sync and async engines... will still keep an eye on it and should definitely get around adding some tests for that in the testengine thing. Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add a system tray option to always show all items
On Feb. 26, 2011, 1:31 p.m., Marco Martin wrote: hmm i'm not sure about it, i don't see an huge use case of showing icons that are meant to be passive (so not telling anything useful at the moment) however the patch is well done (i appreciate disabling the combo boxes when the always show all option is checked) so hmm, yeah, i'm a bit on the fence on this one but if there aren't other objections i think it can go in Aaron J. Seigo wrote: i object on the basis that you don't see a use case for it. let's not get into the (bad) habbit of adding UI just because we can't think of a reason not to. :) Obviously I can only speak for myself here, but my use case for having such an option is that I find things appearing and disappearing from the system tray (or other places) of their own accord extremely distracting. Especially since this affects other things as well - with a full taskbar a new item in the system tray can change its width resulting in a rearrangement of the rows and tasks that I thought were in a particular place ending up somewhere else. My memory expects things to stay where they were put, or at least where they were when I last looked - hence my preference for keeping all system tray items visible, on KDE or any other desktop. The desired operation can be achieved in other was, of course. But this option can be implemented with no substantial code changes, very little visual intrusion and no effect at all on those users who choose not to use it. - Jonathan --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100743/#review1667 --- On Feb. 25, 2011, 4:33 p.m., Jonathan Marten wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100743/ --- (Updated Feb. 25, 2011, 4:33 p.m.) Review request for Plasma. Summary --- If the user wishes to have all system tray items visible at all times, there is no single setting to allow this. The only option is to go to System Tray Settings - Entries and set all of the Visibility combo boxes to Always Visible, and repeat this whenever a new item appears. All versions of a popular closed source operating system have this option for the system tray. This change adds a check box Always show all system tray items below the list on the Entries page. Checking this sets all items (current and any new ones that may appear in future) to be always visible and disables the Visibility column. It is still possible to access the Keyboard Shortcut column. The default is for this option not to be set, so the system tray operation is the same as before. Diffs - plasma/generic/applets/systemtray/ui/applet.h b0e9a55 plasma/generic/applets/systemtray/ui/applet.cpp bd2d8ff plasma/generic/applets/systemtray/ui/autohide.ui 3b6efff plasma/generic/applets/systemtray/ui/taskarea.h 091763c plasma/generic/applets/systemtray/ui/taskarea.cpp cfa503b Diff: http://git.reviewboard.kde.org/r/100743/diff Testing --- Built kde-workspace with these changes, checked operation of system tray and settings dialogue with this option checked and not checked. Thanks, Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Fwd: Re: [Fwd: Re: New properties for StatusNotifierItem: Accessible Label (1/3)]]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aaron J. Seigo wrote on 03/03/11 06:15: On Tuesday, March 1, 2011, Matthew Paul Thomas wrote: ... But in general, while all interactive graphic-only elements should have accessible labels, not all of them need tooltips. example? Icon-only labels at opposite ends of a slider: for example, muted at one end and maximum-volume at the other, or low-zoom at one end and high-zoom at the other. The icons should have accessible labels, but to a sighted user they are obvious enough that tooltips would be silly. (If they weren't obvious enough, the correct fix would be to make the labels plain text, as slider labels often are, not to give them tooltips.) ... In a survey by Opera Software of 3,219,487 Web pages that used the img element, 2,520,939 of them (78%) used alt=, while 367,132 (11%) used title=. http://dev.opera.com/articles/view/mama-images-elements-and-formats/#img As far as I know, there are no public statistics on how often img elements have distinct alt= and title= values. But we can conclude, at least, that Web authors care enough about accessibility to provide accessible equivalents most of the time. after years of getting it pounded into their heads and with the added bonus that this text is often used for things like tooltips ... they still fail 11% of the time. ... That is because the img API was apparently designed without any thought for accessibility. http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element If the syntax had been img src=...alternate/img, it would have been much more obvious that an alternate was expected and what it was for. Sure, some people would still have routinely written img src=.../img. But fewer people would have, because it would have been more obvious that that was missing something than that img src=... is missing something. http://sweng.the-davies.net/Home/rustys-api-design-manifesto So I think it is important to bake accessible labels into the API in a way that makes it obvious that they are needed, even for things that shouldn't have tooltips. http://behindthecurtain.us/2010/06/12/my-first-week-with-the-iphone/ - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1v5oEACgkQ6PUxNfU6eco0iwCgguPHPPa99u+NupQP7VF3F0Bb Gt0An3QkHeQgxUYM2Fl4A+o77cdg1rCr =yE+G -END PGP SIGNATURE- ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Fwd: Re: [Fwd: Re: New properties for StatusNotifierItem: Accessible Label (1/3)]]
On Thursday, March 3, 2011, Matthew Paul Thomas wrote: Aaron J. Seigo wrote on 03/03/11 06:15: On Tuesday, March 1, 2011, Matthew Paul Thomas wrote: ... But in general, while all interactive graphic-only elements should have accessible labels, not all of them need tooltips. example? Icon-only labels at opposite ends of a slider: for example, muted at one end and maximum-volume at the other, or low-zoom at one end and high-zoom at the other. The icons should have accessible labels, but to a sighted user they are obvious enough that tooltips would be silly. (If they weren't obvious enough, the correct fix would be to make the labels plain text, as slider labels often are, not to give them tooltips.) i was hoping for examples relevant to the topic at hand, namely status notifiers / app indicators. :) In a survey by Opera Software of 3,219,487 Web pages that used the img element, 2,520,939 of them (78%) used alt=, while 367,132 (11%) used title=. http://dev.opera.com/articles/view/mama-images-elements-and-formats/#im g As far as I know, there are no public statistics on how often img elements have distinct alt= and title= values. But we can conclude, at least, that Web authors care enough about accessibility to provide accessible equivalents most of the time. after years of getting it pounded into their heads and with the added bonus that this text is often used for things like tooltips ... they still fail 11% of the time. ... That is because the img API was apparently designed without any thought for accessibility. true ... but: If the syntax had been img src=...alternate/img, it would have been much more obvious that an alternate was expected and what it was for. Sure, some people would still have routinely written img src=.../img. But fewer people would have, because it would have been more obvious that that was missing something than that img src=... is missing something. img src=http://idontcare.com/haha.png; / :) most API is abusable, and app developers will do just that. a truly crappy part of reality. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
