Re: The future of virtual desktops
On Fri, Feb 25, 2011 at 2:44 AM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, February 24, 2011, Hans Chen wrote: What I want to know is the following: Are there any plans or outlines regarding how to proceed with virtual desktop (and activities)? Are they they are orthogonal concepts and i don't think we should at this time get too worked up about them. for those who don't use virtual desktops now - not an issue for those who don't use activities - not an issue for those who use both happily - not an issue people who know virtual desktops but who are learning and using activities are the only ones really affected, and i think it's likely to be a growing pains issue as they adjust. it may just as well work itself out naturally. Doing this kind of case-by-case analysis is a great idea: many times something which sounds sensible in the abstract ends up looking quite different when you look at the individual cases it applies to. But I'm not sure if these are necessarily the most appropriate lines along which we should be separating things into cases. First of all, though, a question: what is the Plasma project's goal with activities? I'm assuming the goal is to have people notice them, be intrigued by them, start using them, benefit from them, and tell other people about them, who then start the process anew; but maybe that's mistaken and it's something different -- say, something more modest like, well it's there if people want it, but if they don't we don't really care, maybe. Going ahead with my assumptions, my concern is that the way things usually work isn't I'm using X / want to start using X - let's figure out what X is, understand it, and learn how to use it; rather, it's X sounds really interesting, I understand how it might help improve my experience/productivity - let's start using it. In other words, the part covered by notice them, be intrigued by them, start using them above. If we view 'understanding' as a necessary precondition for 'want to start using', rather than the other way around, then the cases break down like this: a) those people who are familiar with / understand / use neither virtual desktops nor activies b) those people who understand virtual desktops, but not activities c) those people who understand activities, but not virtual desktops d) those people who understand both of them For (d), obviously there is no issue. For (c) (if there are people like this at all), if the goal is to have people use activities, there is also no issue. For (b) and especially (a), I think there would be issues. Simply put, trying to understand two superficially similar but fundamentally different things at the same time -- or even something superficially similar to but fundamentally different from something you already know -- can be very confusing. A lot of assumptions get triggered by the superficial similarity, a lot of them very wrong, and it takes a lot of time and pain before you realize which ones are wrong, how they are wrong, and what you should be assuming instead. For a familiar example, let's look at the time when both activities (groups of plasmoids) and virtual desktops (groups of windows) were presented spatially, as a grid. Both of them tried to occupy the same mental area at the same time: switching between groups of things using a spatial grid. No amount of explaining succeeded in making people understand that really, the two are different. (And even having to explain things is bad; it's much better if they are intuitive and/or obvious.) The resulting confusion is a big part of why the evil separate-activity-per-virtual-desktop option was born. Now, activities are no longer spatial, which was a good decision; but instead activities are invading the conceptual territory of virtual desktops from a different direction: managing groups of windows. My fear is that when people are confronted with two advanced features which are both intended for grouping windows, the result will either be that they get royally confused (as with spatial activities), or that they go eh, this is a bit difficult, I don't feel like dealing with it right now, and then they never get around trying it, and instead are just left with a vague negative impression. I would assume that only a few very advanced users would really want to use both at the same time; therefore my proposed solution would be to move virtual desktops into the settings alongside other power-user window management features like tabbing and tiling (though I'm open to being persuaded of others). The case for activities could be made much more effectively if you didn't have to detour into how is this different from virtual desktops, why do we have both every half sentence, and could instead say activities are better than virtual desktops: here is why. And then you could just say at the end we acknowledge that while activities are better for the majority of use cases, there are still some where virtual desktops are
Re: The future of virtual desktops
2011/2/25 Gábor Lehel illiss...@gmail.com: On Fri, Feb 25, 2011 at 2:44 AM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, February 24, 2011, Hans Chen wrote: What I want to know is the following: Are there any plans or outlines regarding how to proceed with virtual desktop (and activities)? Are they they are orthogonal concepts and i don't think we should at this time get too worked up about them. for those who don't use virtual desktops now - not an issue for those who don't use activities - not an issue for those who use both happily - not an issue people who know virtual desktops but who are learning and using activities are the only ones really affected, and i think it's likely to be a growing pains issue as they adjust. it may just as well work itself out naturally. Doing this kind of case-by-case analysis is a great idea: many times something which sounds sensible in the abstract ends up looking quite different when you look at the individual cases it applies to. But I'm not sure if these are necessarily the most appropriate lines along which we should be separating things into cases. First of all, though, a question: what is the Plasma project's goal with activities? I'm assuming the goal is to have people notice them, be intrigued by them, start using them, benefit from them, and tell other people about them, who then start the process anew; but maybe that's mistaken and it's something different -- say, something more modest like, well it's there if people want it, but if they don't we don't really care, maybe. Going ahead with my assumptions, my concern is that the way things usually work isn't I'm using X / want to start using X - let's figure out what X is, understand it, and learn how to use it; rather, it's X sounds really interesting, I understand how it might help improve my experience/productivity - let's start using it. In other words, the part covered by notice them, be intrigued by them, start using them above. If we view 'understanding' as a necessary precondition for 'want to start using', rather than the other way around, then the cases break down like this: a) those people who are familiar with / understand / use neither virtual desktops nor activies b) those people who understand virtual desktops, but not activities c) those people who understand activities, but not virtual desktops d) those people who understand both of them For (d), obviously there is no issue. For (c) (if there are people like this at all), if the goal is to have people use activities, there is also no issue. For (b) and especially (a), I think there would be issues. Simply put, trying to understand two superficially similar but fundamentally different things at the same time -- or even something superficially similar to but fundamentally different from something you already know -- can be very confusing. A lot of assumptions get triggered by the superficial similarity, a lot of them very wrong, and it takes a lot of time and pain before you realize which ones are wrong, how they are wrong, and what you should be assuming instead. For a familiar example, let's look at the time when both activities (groups of plasmoids) and virtual desktops (groups of windows) were presented spatially, as a grid. Both of them tried to occupy the same mental area at the same time: switching between groups of things using a spatial grid. No amount of explaining succeeded in making people understand that really, the two are different. (And even having to explain things is bad; it's much better if they are intuitive and/or obvious.) The resulting confusion is a big part of why the evil separate-activity-per-virtual-desktop option was born. Now, activities are no longer spatial, which was a good decision; but instead activities are invading the conceptual territory of virtual desktops from a different direction: managing groups of windows. My fear is that when people are confronted with two advanced features which are both intended for grouping windows, the result will either be that they get royally confused (as with spatial activities), or that they go eh, this is a bit difficult, I don't feel like dealing with it right now, and then they never get around trying it, and instead are just left with a vague negative impression. I would assume that only a few very advanced users would really want to use both at the same time; therefore my proposed solution would be to move virtual desktops into the settings alongside other power-user window management features like tabbing and tiling (though I'm open to being persuaded of others). The case for activities could be made much more effectively if you didn't have to detour into how is this different from virtual desktops, why do we have both every half sentence, and could instead say activities are better than virtual desktops: here is why. And then you could just say at the end we acknowledge
Re: QML code style
On Thu, Jan 20, 2011 at 9:57 PM, Artur de Souza aso...@kde.org wrote:
Quoting Marco Martin notm...@gmail.com:
Artur, do you know something more about coding conventions used
internally for
QML/QtComponents? if sensible we could just steal, ehm, i mean adopt them ;)
In QtComponents we use the links below as a reference:
http://doc.qt.nokia.com/4.7-snapshot/codingconventions.html
https://developer.mozilla.org/En/Developer_Guide/Coding_Style
and I could also find the guidelines below one e-mail:
1. avoid using ';', unless strictly needed (just use it if you are writing
multiple commands on the same line and even in this case avoid the last
semicolon).
target: statusbar; property: y
2. avoid writing more than one command on the same line :-), but this is not
strict.
The example below is good, IMO these cases, PropertyChanges and Animation,
can have their properties on one line.
states: State {
name: 'hidden'
when: window.statusbarVisible == false
PropertyChanges { target: statusbar; y: -statusbar.height }
}
transitions: Transition {
NumberAnimation { target: statusbar; property: y; duration: 300;
easing.type: Easing.InOutQuad }
}
3. use a blank space after and before curly braces (when in the same line)
'{', '}'
MouseArea {
id: mouseArea
anchors.fill: parent
onClicked: { button.clicked() }
}
4. use 4 spaces for indentation (no tabs)
5. use double quotes for strings: string instead of 'string'
I kind of dislike more than one command in the same line and for JS
stuff I put ; in every end of line/command (while in QML code we
avoid them). I can find a link explaining the reason behind ending
with ; every JS line if you want.
You are also right that it's going to be very good to setup some
naming guidelines for id's. It can be really a mess if we don't
follow some guideline.
Ah, something I almost forgot: following some scripting languages,
properties that we would like to make private/protected are declared
with __ preprending their names, for example:
property int __protected: 0
Sorry for the necro, but: you can also transplant the d-pointer idiom
into QML for private properties. Like this:
TextOrWhatever
{
text: d.some_private_property
QtObject
{
id: d
property string some_private_property
}
}
Cheers,
Artur
---
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
--
Work is punishment for failing to procrastinate effectively.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plugins in WebView
are qtwebkit plugins in-process or out of process? IANAPD, but having a flash plugin in a webpage crash all of plasma does not sound like fun times... On Sat, Feb 27, 2010 at 12:55 AM, Aaron J. Seigo ase...@kde.org wrote: On February 25, 2010, Mathieu Ducharme wrote: - bool pluginsEnabled() - void setPluginsEnabled(bool) i don't know if we need to / want to offer full access to QWebSettings, but would a simple(r) setAttribute(QWebSettings::Attribute, bool) do the trick? the rest of the things in QWebSettings don't look overly useful for the use cases we have in plasma? -- 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Work is punishment for failing to procrastinate effectively. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Bug 198661 (Option to disable scroll wheel on taskbar)
Okay. I don't want to get into a protracted argument so I'll just say this and then leave it up to you: Obviously you can't please everyone. You don't need to cater to the needs of every single person who files a bug report. The goal should be to please the large majority of people. Sensible defaults, in other words. (Even in the extended meaning of sensible defaults about which options to allow in the first place). If there's a couple of people who still don't like it, they can patch the code themselves. In this case, the sensible solution which would please the most people appears, to me, to be to disable scrollwheel-switching on the taskbar by default, but offer it as an option, and to just leave it enabled everywhere else. Disabling it globally (even via an option) doesn't work: everywhere else -besides- the taskbar, I *want* to be able to use things with the scrollwheel; I interact with the pager exclusively in this way, for example. On the other hand, enabling it globally isn't a perfect solution either, when the taskbar gets scrolled by accident ten times for every time that it's done intentionally[1]. And offering a separate option for every single widget is obviously not a good solution either. This isn't simple nor elegant. But what you get at the intersection of humans and computers isn't simple nor elegant. Part of usability is finding those places where the elegant model in the code doesn't mesh up well with actual human behaviour, and then putting ugly hacks in the code to accomodate it. (I guess something which would be helpful here is a section in the HIG regarding when and how widgets should respond to scroll events with things other than scrolling. I'd be willing to help draft one, actually, but given that I'm just a dumb programmer and not a usability specialist, I'm not sure my help would be welcome. If it would, where do I inquire?) (And obviously, I was assuming here that I'm part of the large majority myself, but if that's not true and most people do actually want to enable/disable scrollwheel actions *globally*, then I'm the one who should be getting shafted. But the same principle should apply, I think.) [1] To be entirely accurate, I don't seem to actually have problems with this any longer. I guess after suffering long enough I adjusted and learned new habits. But it was very annoying for a time. On Tue, Dec 22, 2009 at 10:38 PM, Aaron J. Seigo ase...@kde.org wrote: On December 19, 2009, Gábor Lehel wrote: decided to put a giant clock or pager along the middle of their bottom panel they would have similar issues, but who does that? it happens less frequently with smaller targets, but it does happen. and yes, we do get reports about it. so no, i'm not interested in patches that fix it in one place or even multiple patches that fix it in multiple places with independent settings. one global option should do. -- 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Work is punishment for failing to procrastinate effectively. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Bug 198661 (Option to disable scroll wheel on taskbar)
is there a real, common and valid use case that states i want to do mouse wheeling over the tasks widget but not the pager? i'd suggest the answer is no. With respect, I am not sure this is true. I personally have had no problems with things being wheel-enabled anywhere else besides the taskbar (well, maybe the desktop, but that's already configurable). In many places it is quite convenient. Why? There are two general cases which tend to happen: (1) I am scrolling through a web page, .cpp file, etc., and my finger, for half a moment, veers outside of the thin strip at the edge of the touchpad designated for scrolling, causing the cursor to move a hundred or so pixels downward onto the taskbar, where the rest of the scrolling motion is then finished. (2) I am reading a document, and after getting to the bottom of it, I scroll downwards, not realizing that the cursor is in fact resting over the taskbar and not the document. In either case, this leads to severe disruption of concentration and general chaos. Why is this only a problem with the taskbar (and the desktop), and not other things? I suggest it is because the taskbar is a big huge target (even bigger and huger due to Fitt's Law) along the middle of the bottom of the screen, making it very easy to move the cursor over it accidentally, whereas other things aren't. I mean, I guess if someone decided to put a giant clock or pager along the middle of their bottom panel they would have similar issues, but who does that? Minimizing the number of configuration options is a noble goal, and your concern that once this option is granted for the taskbar it's a slippery slope and it'll end up proliferating all over the place is understandable, but I don't think, in this case, that those assumptions are actually self-evident. On Mon, Dec 14, 2009 at 10:42 PM, Aaron J. Seigo ase...@kde.org wrote: hi Ravi .. On December 13, 2009, Ravi Vagadia wrote: Hello , this is my first patch :) thanks for the patch. note that we use the KDE libs coding style: http://techbase.kde.org/Policies/Kdelibs_Coding_Style and it's good practice to keep new code in line with that style. also note that we tend to use http://reviewboard.kde.org for patch review. anyways, on to the actual issue here: should scroll wheeling move around through the taskbar. i honestly don't think it's worth yet another option in the tasks widget. in general, options for 'what happens when i click this button' tend to get pretty annoying when they are found everywhere. but the real issue: is there a real, common and valid use case that states i want to do mouse wheeling over the tasks widget but not the pager? i'd suggest the answer is no. people want to turn off the scrolling in the tasks widget because they have crappy hardware or poor motor control. since that's the reason, they tend to have the same request for the pager. and the clock. and other widgets that support mouse wheeling. so if we are going to do this, i'd prefer to see a general solution with one configuration option in one location. -- 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Work is punishment for failing to procrastinate effectively. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
