Re: kubuntu kdebase patches to plasma
Sebastian Kügler kde.org> writes: > Does this also fix the "we don't get notifications from HAL about > brightness changes"-problem? > > I've been working around this in the battery applet for some time now, > it only updates the brightness slider when the applet pops up. The patch works around that problem: Whenever Solid changes the brightness it sends a message through dbus to PowerDevil. PowerDevil then forwards the brightness change to its dbus signal so the battery applet can update the slider or display an OSD. On Friday 13 November 2009 05:04:32 Aaron J. Seigo wrote: > if the patch is upstreamed in Qt, we can take a look at this one more > closely. The required patches have landed upstream in Qt 4.6.0 / kdelibs trunk (2009-12-07). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kubuntu kdebase patches to plasma
On November 13, 2009, Celeste Lyn Paul wrote: > This isn't a new discussion wrt Kubuntu and we've more than "suddenly > noticed". This is the third? time we've submitted the patch with our > arguments for changes. One, it is part of our process since we don't > want to deviate from upstream as much as possible, and Two, we really > do think this patch is an improvement. We are free to defend it and > you are free to ignore it as usual. as a suggestion: resubmitting the same patches with the same rational after it's already been discussed and rejected is probably not overly useful. in fact, it's frustrating. sending new patches upstream is useful. sending old patches with new approaches in the code or new information can be. -- 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
Re: kubuntu kdebase patches to plasma
On Fri, Nov 13, 2009 at 1:50 PM, Aaron J. Seigo wrote: > On November 13, 2009, Celeste Lyn Paul wrote: >> In some cases you have some text that is always on, some text that is >> only on via mouseover, and some text that is never on (not all entries >> have subtext, e.g. System Settings). This behavior is inconsistent and >> confusing in addition to some of these problems: > > the behaviour is not meant to be consistent in terms of "does it paint the > same way every time". it's meant to be consistent in terms of "provides the > necessary information to the user without overloading the display". as for > confusing, it's only confusing if you try and figure out why we've done it the > way we've done it (reverse engineering the design); i have yet to hear from an > actually confused user (versus a user trying to pick out issues because they > are playing "clever critic") though we used to hear all the time from them > before the disambiguation. > >> * When you have some items with subtext on by default (such as when >> you have multiple browsers installed), there is less of an affordance >> to check for the subtext hints because some are already visible, so >> why would you keep looking? > > i'm not sure why that would matter in the least. it also becomes very evident > that they normally show on hover, and that hover information is not > particularly useful when there's just one "Do Foo" app anyways. your > assumption here is that, in the common case where there is no overlap between > application generic names, that the subtext is the important bit. if it is, > then let's switch to application names first as the default. i'm not sure > "KTorrent", "KsCD", etc. is really the most user friendly approach however. > >> * When some labels are on by default but others appear on mouseover, >> it looks like a bug before you figure out the "disambiguity" pattern > > but it's not a bug; i'm all for making things as "immediately sensible" as > possible until the "immediately sensible" causes problems for others. in this > case, it solves a real problem our users were really facing and if others > puzzle over that, well, that's just unfortunate. nobody's hurt, and those who > need it (who happen to be most people confronted with three "Web Browser" > entries) are helped. > > in fact, i bet if we didn't do this that we'd be hearing from you about the > three "Web Browser" entry situation. > >> * Subtext on mouseover requires the user to read with their mouse >> which is awkward and unnatural, nevermind impossible on touch >> interfaces and adds burden to those using a keyboard instead of a >> mouse for accessibility reasons. > > the subtext, except in the case of needing disambiguation, is not critical to > making a decision. so you don't need to mouse over. unless we didn't show the > disambiguations. then we'd have a problem. > >> * For the task-based labels, mouseover subtext make it more difficult >> for users to find applications by name -- which does happen. People >> get recommendations for installing "Marble" not "Desktop Globe". It >> only supports a single use case. > > thankfully we offer search first and foremost. we also found that clusters of > mysteriously named applications like "Marble" are less useful to people than > "Desktop Globe", and that when people are told about marble they are told it's > "mapping software" or "a desktop globe". > > when looking for specific items, menu hierarchies generally suck no matter > what the strategy, though some strategies are better than others. we are > promoting search, with the menu as a way to explore what's available or to go > to items you already know or can guess the location of. and in those cases the > functionality is usually more important than the name of the binary on disk. > >> * For the application-based labels, if you are unfamiliar with the >> names or branding, you *must* read with your mouse. > > that's why we default to generic names. application labels are for people who > know what they are doing. > >> * When there are no labels, or the labels are not visible, the primary >> label looks disproportionately small compared to the icon because a >> space must be made for the subtext. > > and yet when you mouse over it becomes evident. if you would like to provide a > artist's mockup of a different layout that fulfills the needs outlined here, > please feel free to do so. it's easy to jab at the current layout until you > actually try and make something better. > >> I just don't see any compelling reasons why the subtext should be >> turned off. "Unclutter" the interface doesnt work for me; if the >> subtext is "clutter" then the labels are bad and should be improved or >> it is noise and shouldnt be there at all. > > "unclutter" does work for me, since it looks horrific with dense bodies of > text everywhere. you may not agree with that aesthetic, but it's the aesthetic > that's been chosen. we can argue it and the relative merits of Dali versus
Re: kubuntu kdebase patches to plasma
On November 13, 2009, Celeste Lyn Paul wrote: > In some cases you have some text that is always on, some text that is > only on via mouseover, and some text that is never on (not all entries > have subtext, e.g. System Settings). This behavior is inconsistent and > confusing in addition to some of these problems: the behaviour is not meant to be consistent in terms of "does it paint the same way every time". it's meant to be consistent in terms of "provides the necessary information to the user without overloading the display". as for confusing, it's only confusing if you try and figure out why we've done it the way we've done it (reverse engineering the design); i have yet to hear from an actually confused user (versus a user trying to pick out issues because they are playing "clever critic") though we used to hear all the time from them before the disambiguation. > * When you have some items with subtext on by default (such as when > you have multiple browsers installed), there is less of an affordance > to check for the subtext hints because some are already visible, so > why would you keep looking? i'm not sure why that would matter in the least. it also becomes very evident that they normally show on hover, and that hover information is not particularly useful when there's just one "Do Foo" app anyways. your assumption here is that, in the common case where there is no overlap between application generic names, that the subtext is the important bit. if it is, then let's switch to application names first as the default. i'm not sure "KTorrent", "KsCD", etc. is really the most user friendly approach however. > * When some labels are on by default but others appear on mouseover, > it looks like a bug before you figure out the "disambiguity" pattern but it's not a bug; i'm all for making things as "immediately sensible" as possible until the "immediately sensible" causes problems for others. in this case, it solves a real problem our users were really facing and if others puzzle over that, well, that's just unfortunate. nobody's hurt, and those who need it (who happen to be most people confronted with three "Web Browser" entries) are helped. in fact, i bet if we didn't do this that we'd be hearing from you about the three "Web Browser" entry situation. > * Subtext on mouseover requires the user to read with their mouse > which is awkward and unnatural, nevermind impossible on touch > interfaces and adds burden to those using a keyboard instead of a > mouse for accessibility reasons. the subtext, except in the case of needing disambiguation, is not critical to making a decision. so you don't need to mouse over. unless we didn't show the disambiguations. then we'd have a problem. > * For the task-based labels, mouseover subtext make it more difficult > for users to find applications by name -- which does happen. People > get recommendations for installing "Marble" not "Desktop Globe". It > only supports a single use case. thankfully we offer search first and foremost. we also found that clusters of mysteriously named applications like "Marble" are less useful to people than "Desktop Globe", and that when people are told about marble they are told it's "mapping software" or "a desktop globe". when looking for specific items, menu hierarchies generally suck no matter what the strategy, though some strategies are better than others. we are promoting search, with the menu as a way to explore what's available or to go to items you already know or can guess the location of. and in those cases the functionality is usually more important than the name of the binary on disk. > * For the application-based labels, if you are unfamiliar with the > names or branding, you *must* read with your mouse. that's why we default to generic names. application labels are for people who know what they are doing. > * When there are no labels, or the labels are not visible, the primary > label looks disproportionately small compared to the icon because a > space must be made for the subtext. and yet when you mouse over it becomes evident. if you would like to provide a artist's mockup of a different layout that fulfills the needs outlined here, please feel free to do so. it's easy to jab at the current layout until you actually try and make something better. > I just don't see any compelling reasons why the subtext should be > turned off. "Unclutter" the interface doesnt work for me; if the > subtext is "clutter" then the labels are bad and should be improved or > it is noise and shouldnt be there at all. "unclutter" does work for me, since it looks horrific with dense bodies of text everywhere. you may not agree with that aesthetic, but it's the aesthetic that's been chosen. we can argue it and the relative merits of Dali versus Escher over a glass of wine sometime. the subtext is clutter only when it's shown all the time for all entries. the subtext is an aid to the user who w
Re: kubuntu kdebase patches to plasma
On Fri, Nov 13, 2009 at 10:27 AM, Marco Martin wrote: > On Friday 13 November 2009, Celeste Lyn Paul wrote: >> On Thu, Nov 12, 2009 at 11:04 PM, Aaron J. Seigo wrote: >> > On November 12, 2009, Jonathan Riddell wrote: >> >> kubuntu_19_always_show_kickoff_subtext.diff, the subtexts in kickoff >> >> sometimes show always and sometimes on mouse over, this makes that >> >> consistent. It's been discussed here before. >> >> http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ >> >>ann >> >> otate/head%3A/debian/patches/kubuntu_19_always_show_kickoff_subtext.diff >> > >> > this patch is, usability-wise, wrong. the subtexts are shown when >> > disambiguation is necessary. otherwise you need to mouse over them to >> > figure out what's what. >> >> I'm not sure what you mean. Are you suggesting only showing the >> subtext when there are multiple applications and not for any other >> applications? And do you mean on by default or mouseover (your comment >> is ambiguous)? > > I suppose the behaviour it has now. > -show only the main text, that is the generic name > -show the subtext (the app name) on mouse over > -if there are two entries with the same generic name always show the subtext, > to disambiguare between the two In some cases you have some text that is always on, some text that is only on via mouseover, and some text that is never on (not all entries have subtext, e.g. System Settings). This behavior is inconsistent and confusing in addition to some of these problems: * When you have some items with subtext on by default (such as when you have multiple browsers installed), there is less of an affordance to check for the subtext hints because some are already visible, so why would you keep looking? * When some labels are on by default but others appear on mouseover, it looks like a bug before you figure out the "disambiguity" pattern * Subtext on mouseover requires the user to read with their mouse which is awkward and unnatural, nevermind impossible on touch interfaces and adds burden to those using a keyboard instead of a mouse for accessibility reasons. * For the task-based labels, mouseover subtext make it more difficult for users to find applications by name -- which does happen. People get recommendations for installing "Marble" not "Desktop Globe". It only supports a single use case. * For the application-based labels, if you are unfamiliar with the names or branding, you *must* read with your mouse. * When there are no labels, or the labels are not visible, the primary label looks disproportionately small compared to the icon because a space must be made for the subtext. I just don't see any compelling reasons why the subtext should be turned off. "Unclutter" the interface doesnt work for me; if the subtext is "clutter" then the labels are bad and should be improved or it is noise and shouldnt be there at all. > > Cheers, > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Celeste Lyn Paul KDE Usability Project KDE e.V. Board of Directors www.kde.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kubuntu kdebase patches to plasma
On Friday 13 November 2009, Celeste Lyn Paul wrote: > On Thu, Nov 12, 2009 at 11:04 PM, Aaron J. Seigo wrote: > > On November 12, 2009, Jonathan Riddell wrote: > >> kubuntu_19_always_show_kickoff_subtext.diff, the subtexts in kickoff > >> sometimes show always and sometimes on mouse over, this makes that > >> consistent. It's been discussed here before. > >> http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ > >>ann > >> otate/head%3A/debian/patches/kubuntu_19_always_show_kickoff_subtext.diff > > > > this patch is, usability-wise, wrong. the subtexts are shown when > > disambiguation is necessary. otherwise you need to mouse over them to > > figure out what's what. > > I'm not sure what you mean. Are you suggesting only showing the > subtext when there are multiple applications and not for any other > applications? And do you mean on by default or mouseover (your comment > is ambiguous)? I suppose the behaviour it has now. -show only the main text, that is the generic name -show the subtext (the app name) on mouse over -if there are two entries with the same generic name always show the subtext, to disambiguare between the two Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kubuntu kdebase patches to plasma
On Thu, Nov 12, 2009 at 11:04 PM, Aaron J. Seigo wrote: > On November 12, 2009, Jonathan Riddell wrote: >> kubuntu_19_always_show_kickoff_subtext.diff, the subtexts in kickoff >> sometimes show always and sometimes on mouse over, this makes that >> consistent. It's been discussed here before. >> http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ann >> otate/head%3A/debian/patches/kubuntu_19_always_show_kickoff_subtext.diff > > this patch is, usability-wise, wrong. the subtexts are shown when > disambiguation is necessary. otherwise you need to mouse over them to figure > out what's what. I'm not sure what you mean. Are you suggesting only showing the subtext when there are multiple applications and not for any other applications? And do you mean on by default or mouseover (your comment is ambiguous)? >> kubuntu_71_default_plasma_layout.diff has our changes to the default >> layout. We used to do this with a config file override but that was >> unreliable. It adds the microblog applet to the desktop (social from the >> start, all the rage). It adds quickaccess, showdesktop, networkmanagement >> and our indicatordisplay applets to the panel. The clock shows the date >> by default, because I like to know what day it is. >> http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ann >> otate/head%3A/debian/patches/kubuntu_71_default_plasma_layout.diff > > in 4.4 and beyond, you should use a plasma-desktop javascript for this. all > the flexibility you could ever want and then some, and you won't need to carry > a patch. see the docs in kdebase/workspace/plasma/design/plasma-desktop- > scripting and the examples in kdeexamples. > >> kubuntu_91_plasma_autostart_condition.desktop is added so we can stop >> plasma-desktop being run for netbook edition. It would be good to >> find a better way to select between plasma-desktop and plasma-netbook, >> preferably as an X session at KDM. >> http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ann >> otate/head%3A/debian/patches/kubuntu_91_plasma_autostart_condition.desktop > > marco recently implemented this for 4.4. marco can elaborate. > >> kubuntu_101_brightness_fn_keys_and_osd.diff adds a brightness on >> screen widget for brightness keys, it also needs patches to Qt and >> kdelibs to work >> http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ann >> otate/head%3A/debian/patches/kubuntu_101_brightness_fn_keys_and_osd.diff > > if the patch is upstreamed in Qt, we can take a look at this one more closely. > > -- > 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 > > -- Celeste Lyn Paul KDE Usability Project KDE e.V. Board of Directors www.kde.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kubuntu kdebase patches to plasma
On Friday 13 November 2009 05:04:32 Aaron J. Seigo wrote: > > kubuntu_101_brightness_fn_keys_and_osd.diff adds a brightness on > > screen widget for brightness keys, it also needs patches to Qt and > > kdelibs to work > > http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/a > >nn > > otate/head%3A/debian/patches/kubuntu_101_brightness_fn_keys_and_osd.diff > > if the patch is upstreamed in Qt, we can take a look at this one more > closely. Does this also fix the "we don't get notifications from HAL about brightness changes"-problem? I've been working around this in the battery applet for some time now, it only updates the brightness slider when the applet pops up. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kubuntu kdebase patches to plasma
On November 12, 2009, Jonathan Riddell wrote: > kubuntu_19_always_show_kickoff_subtext.diff, the subtexts in kickoff > sometimes show always and sometimes on mouse over, this makes that > consistent. It's been discussed here before. > http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ann > otate/head%3A/debian/patches/kubuntu_19_always_show_kickoff_subtext.diff this patch is, usability-wise, wrong. the subtexts are shown when disambiguation is necessary. otherwise you need to mouse over them to figure out what's what. > kubuntu_71_default_plasma_layout.diff has our changes to the default > layout. We used to do this with a config file override but that was > unreliable. It adds the microblog applet to the desktop (social from the > start, all the rage). It adds quickaccess, showdesktop, networkmanagement > and our indicatordisplay applets to the panel. The clock shows the date > by default, because I like to know what day it is. > http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ann > otate/head%3A/debian/patches/kubuntu_71_default_plasma_layout.diff in 4.4 and beyond, you should use a plasma-desktop javascript for this. all the flexibility you could ever want and then some, and you won't need to carry a patch. see the docs in kdebase/workspace/plasma/design/plasma-desktop- scripting and the examples in kdeexamples. > kubuntu_91_plasma_autostart_condition.desktop is added so we can stop > plasma-desktop being run for netbook edition. It would be good to > find a better way to select between plasma-desktop and plasma-netbook, > preferably as an X session at KDM. > http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ann > otate/head%3A/debian/patches/kubuntu_91_plasma_autostart_condition.desktop marco recently implemented this for 4.4. marco can elaborate. > kubuntu_101_brightness_fn_keys_and_osd.diff adds a brightness on > screen widget for brightness keys, it also needs patches to Qt and > kdelibs to work > http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ann > otate/head%3A/debian/patches/kubuntu_101_brightness_fn_keys_and_osd.diff if the patch is upstreamed in Qt, we can take a look at this one more closely. -- 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
