Re: Breadcrumbs in Kickoff
On Tuesday 20 December 2011 17:54:02 Martin Gräßlin wrote: > Up to now nobody gave a proper reason *why* we should add a back button. > Just because we can is no reason, sorry. > First, I understand that the back button is gone and I'm not advocating its return. I do think I understand why there is a backlash about this option, and it stems from two points: 1) The back button was a much larger button to hit. According to Fitt's Law[1], the smaller a target is to hit, the longer it takes. The breadcrumbs, being smaller, decreases the speed at which someone can hit the target. It is readily apparent to me, as I only recently got introduced to it. 2) The position of the breadcrumbs is on the upper right hand corner. People will first look for information to the upper left hand part of the screen. With the breadcrumbs positioned where they are, its first of all hard to find compared to the back button. I can't remember if people brought up with RTL languages see upper right hand first, but at least for LTR it is. Based upon these two points, a couple of simple solutions present themselves: 1) Make the text a little bigger. Since users will approach the breadcrumbs from the bottom, increasing the height will help them hit the button easier. This will probably require some fiddling with to ensure the best possible result. 2) At least for LTR, move the breadcrumbs over to the left hand side. This will help users more easily find the breadcrumbs and choose an option. This also helps with selection, as any overshoot to return to the beginning, when approached from the right, will hit the edge of the screen and avoid too much backtracking, making it easier for users to hit. Note this only applies in Kickoff's default location, but I don't think most people will have an issue. Thoughts? If these ideas sound useful, I'll try to cook up a patch to implment them. Matthew [1] http://en.wikipedia.org/wiki/Fitts%27s_law ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: Re: Review Request: Change activity by rolling the mouse wheel over the showActivityManager widget.
Le mardi 27 décembre 2011 22:09:33 Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= a écrit : > On Tuesday 27 December 2011 21:49:24 Guillaume DE BURE wrote: > > I use the keyboard shortcut (meta + tab) quite often. However I remember > > once someone (maybe, marco ?) proposed an "exposé like" effect, with > > activities as rows, and desktop as columns. That could be extremely useful, > > especially for dragging windows between desktop / activities. Does that > > still sound like a good idea ? Would it be difficult to do ? > There is one problem with that: when an activity is closed we do not know > which windows are there. If an activity is suspended we most likely due not > have a pixmap for this window as the driver discarded it for the long time > unmapped window. So unless someone has a genious idea how to get thumbnails of > non existing windows, it will be difficult to implement :-) Thought this was just relevant for running activities... But maybe you could start activities from there also ? No sure you would need preview for non running activities, that might just confuse the user, no ? > > (The genious idea might be as simple as storing screenshots from the window > when it got closed, activity switched, whatever. 4.9 will hopefully see nice > QML bindings in KWin, so that might be implementable. Help welcome) > > Cheers > Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: Review Request: Change activity by rolling the mouse wheel over the showActivityManager widget.
On Tuesday 27 December 2011 21:49:24 Guillaume DE BURE wrote: > I use the keyboard shortcut (meta + tab) quite often. However I remember > once someone (maybe, marco ?) proposed an "exposé like" effect, with > activities as rows, and desktop as columns. That could be extremely useful, > especially for dragging windows between desktop / activities. Does that > still sound like a good idea ? Would it be difficult to do ? There is one problem with that: when an activity is closed we do not know which windows are there. If an activity is suspended we most likely due not have a pixmap for this window as the driver discarded it for the long time unmapped window. So unless someone has a genious idea how to get thumbnails of non existing windows, it will be difficult to implement :-) (The genious idea might be as simple as storing screenshots from the window when it got closed, activity switched, whatever. 4.9 will hopefully see nice QML bindings in KWin, so that might be implementable. Help welcome) Cheers Martin 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: Re: Review Request: Change activity by rolling the mouse wheel over the showActivityManager widget.
Le mardi 27 décembre 2011 15:58:31 Sebastian =?ISO-8859-1?Q?K=FCgler?= a écrit : > On Tuesday, December 27, 2011 14:11:34 Marco Martin wrote: > > On Tuesday 27 December 2011, Simone Gaiarin wrote: > > > To fix the two problem it is just necessary to add a configuration > > > dialog to the plasmoid in a such way that the user must intentionally > > > enable this feature before use it. What do you think about this > > > solution? I'll work on it. > > > > no, adding a configuration option for every potentially problematic feature > > is a too easy shortcut that has been done too much in the past, and is a > > thing we are finally manage to get out of. > > > > as i said, a solution can be a combination of: > > a) make the activity switching way more intuitive, with animations, an osd > > that says the activity name for an instant, in any case something obvious > > b) only cycle troucg runnung activities (and by default there is only one > > running activity) so if someone never seen them/doesn't use them, doesn't > > get anything with the mouse wheel > > > > this may or may not be intuitive enough, but is important to avoid the > > shortcut of "just throwing another configuration option in" > > One could also make it a hover interface, a bit like opening a QMenu while the > mouse is over that button (but not directly underneath it, as that makes > interaction harder). Or maybe fold the button out to a list of activities when > clicked (a bit like the devicenotifier does it). > > One of the problems I see is that the Activity Switcher still feels a bit too > modal, the switcher is also in my normal usage often at least half a screen > away from my mouse, and in the case of the toolbox, even across the entire > screen. The activity switcher in the panel has a much better position. I use the keyboard shortcut (meta + tab) quite often. However I remember once someone (maybe, marco ?) proposed an "exposé like" effect, with activities as rows, and desktop as columns. That could be extremely useful, especially for dragging windows between desktop / activities. Does that still sound like a good idea ? Would it be difficult to do ? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: Breadcrumbs in Kickoff
On Tuesday 27 December 2011 20:16:48 Kevin Kofler wrote: > Martin Gräßlin wrote: > > Which significant number of critical comments? How many users have > > commented here in the thread and reported bugs? 5? 10? 20? We are talking > > about a feature which will be used by millions of users. If we get to a > > thousand users complaining we can start to think about significant > > numbers. > > FYI, we've got a bunch of complaints on #fedora-kde about this. Not everyone > affected goes post to plasma-devel. define a bunch. 20 people per day? 50 per day? One per month? Seriously we have millions of users and I doubt that Fedora KDE users on IRC is our primary target group for Kickoff. If a user knows the word IRC I would say he needs a different launcher: recommend them to use krunner, they will like it :-) 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: Re: Breadcrumbs in Kickoff
Martin Gräßlin wrote: > Which significant number of critical comments? How many users have > commented here in the thread and reported bugs? 5? 10? 20? We are talking > about a feature which will be used by millions of users. If we get to a > thousand users complaining we can start to think about significant > numbers. FYI, we've got a bunch of complaints on #fedora-kde about this. Not everyone affected goes post to plasma-devel. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Change activity by rolling the mouse wheel over the showActivityManager widget.
Summarizing: 1)No redundant configuration interface should be added. 2)Only cycle through active activity is fine, but the dbus interface should provide a method to get the list of active activity to simplify the work, or it will be necessary to make a dbus call for every activity to check if it is active. But what is the sense of active or unactive activity? 3)The tooltip popup of the widget now says: "Click to show the activity manager". We can add a description like: "Scroll to switch activity." With this two changes who do not use activities can't do any mista since the widget does not do anything even if he scroll over it. Instead the activity aware user can know how the widget work from the tooltip. 4)Later, as a final improvement an osd with the activity name can be added. What do you think? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Change activity by rolling the mouse wheel over the showActivityManager widget.
On Tuesday, December 27, 2011 14:11:34 Marco Martin wrote: > On Tuesday 27 December 2011, Simone Gaiarin wrote: > > To fix the two problem it is just necessary to add a configuration > > dialog to the plasmoid in a such way that the user must intentionally > > enable this feature before use it. What do you think about this > > solution? I'll work on it. > > no, adding a configuration option for every potentially problematic feature > is a too easy shortcut that has been done too much in the past, and is a > thing we are finally manage to get out of. > > as i said, a solution can be a combination of: > a) make the activity switching way more intuitive, with animations, an osd > that says the activity name for an instant, in any case something obvious > b) only cycle troucg runnung activities (and by default there is only one > running activity) so if someone never seen them/doesn't use them, doesn't > get anything with the mouse wheel > > this may or may not be intuitive enough, but is important to avoid the > shortcut of "just throwing another configuration option in" One could also make it a hover interface, a bit like opening a QMenu while the mouse is over that button (but not directly underneath it, as that makes interaction harder). Or maybe fold the button out to a list of activities when clicked (a bit like the devicenotifier does it). One of the problems I see is that the Activity Switcher still feels a bit too modal, the switcher is also in my normal usage often at least half a screen away from my mouse, and in the case of the toolbox, even across the entire screen. The activity switcher in the panel has a much better position. -- 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: Review Request: Change activity by rolling the mouse wheel over the showActivityManager widget.
On Tuesday 27 December 2011, Simone Gaiarin wrote: > To fix the two problem it is just necessary to add a configuration > dialog to the plasmoid in a such way that the user must intentionally > enable this feature before use it. What do you think about this > solution? I'll work on it. no, adding a configuration option for every potentially problematic feature is a too easy shortcut that has been done too much in the past, and is a thing we are finally manage to get out of. as i said, a solution can be a combination of: a) make the activity switching way more intuitive, with animations, an osd that says the activity name for an instant, in any case something obvious b) only cycle troucg runnung activities (and by default there is only one running activity) so if someone never seen them/doesn't use them, doesn't get anything with the mouse wheel this may or may not be intuitive enough, but is important to avoid the shortcut of "just throwing another configuration option in" Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Change activity by rolling the mouse wheel over the showActivityManager widget.
To fix the two problem it is just necessary to add a configuration dialog to the plasmoid in a such way that the user must intentionally enable this feature before use it. What do you think about this solution? I'll work on it. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Reset time format upon user request
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103434/#review9302 --- This review has been submitted with commit 8bd86323cdbd11ffafb71b6d8f4836d0d4339af3 by Lamarque V. Souza to branch KDE/4.8. - Commit Hook On Dec. 19, 2011, 2:03 p.m., Lamarque Vieira Souza wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103434/ > --- > > (Updated Dec. 19, 2011, 2:03 p.m.) > > > Review request for kdelibs and Plasma. > > > Description > --- > > The patch resets time format in digital clock plasmoid when the user changes > the 24h configuration in active-settings. > > The reset part is from kdelibs/kdecore/localization/klocale_kde.cpp. I am > wondering if I should add this change to kdelibs instead of kde-workspace to > avoid duplicating code. Anyway, I wanted someone to review the code to see if > there can be any side effect. > > > This addresses bug 289094. > http://bugs.kde.org/show_bug.cgi?id=289094 > > > Diffs > - > > plasma/generic/applets/digital-clock/clock.h 4aec3fd > plasma/generic/applets/digital-clock/clock.cpp dd03692 > > Diff: http://git.reviewboard.kde.org/r/103434/diff/diff > > > Testing > --- > > Works in Plasma Active. In Plasma Desktop kcmlocale does not call > KGlobalSettings::self()->emitChange(KGlobalSettings::SettingsChanged) so it > does not take effect. Other kcm modules (e.g. keyboard), call emitChange. > > > Thanks, > > Lamarque Vieira Souza > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Make KGlobalSettings reread locale settings before calling settingsChanged().
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103469/#review9300 --- This review has been submitted with commit 7bc79dbefc2f52f92657d87c13c73170a5313e40 by Lamarque V. Souza to branch KDE/4.8. - Commit Hook On Dec. 19, 2011, 10:15 p.m., Lamarque Vieira Souza wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103469/ > --- > > (Updated Dec. 19, 2011, 10:15 p.m.) > > > Review request for kdelibs and Plasma. > > > Description > --- > > This is patch number 3 to fix bug #289094 (top bar time incorrectly displays > in 24 hour format). The other patches are against plasma-mobile and > kde-workspace (http://git.reviewboard.kde.org/r/103434), all three patches > must be applied to fix the bug. I think this is a much simpler solution than > the one I suggested in http://git.reviewboard.kde.org/r/103434. > > > This addresses bug 289094. > http://bugs.kde.org/show_bug.cgi?id=289094 > > > Diffs > - > > kdecore/localization/klocale.h 3495431 > kdecore/localization/klocale.cpp 499bf11 > kdecore/localization/klocale_p.h 4ed8e3f > kdeui/kernel/kglobalsettings.h cb8f7e2 > kdeui/kernel/kglobalsettings.cpp 819b314 > > Diff: http://git.reviewboard.kde.org/r/103469/diff/diff > > > Testing > --- > > > Thanks, > > Lamarque Vieira Souza > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
question about panel size guideline
Hi, While doing bug triaging, i found some bugs related to the panel behavior or property. so, do we have some guideline regarding the panel for example: - minimum size or maximum size - behavior of each component put inside panel when panel grow or shrink - etc Thanks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Change activity by rolling the mouse wheel over the showActivityManager widget.
On Tuesday 27 December 2011, Sebastian Kügler wrote: > I think that this change is problematic from an interaction point of view, > it seems very easy to accidentally trigger, and in that case all windows > are gone, the desktop changes completely, and users who triggered this > feature unaware of it will likely be very confused and think they've just > broken their system. It's also not discoverable, making it hard to find > even for those that would understand it. > > Not sure how to address those, maybe you have an idea? looks like we really need a cute activity switching kwin effect :p -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Change activity by rolling the mouse wheel over the showActivityManager widget.
Hi Simone, Thanks for your patch to the activity switcher. Making pieces of the UI easier to use is always welcome. I thought a bit about your patch, though, and I see two problems with it as it is right now. On Monday, December 26, 2011 23:45:58 Simone Gaiarin wrote: > Rolling the mouse wheel over the showActivityManager change the current > activity. In this way it's not necessary to open the activities menu, > select the activity and close the menu and the activity change is faster. I think that this change is problematic from an interaction point of view, it seems very easy to accidentally trigger, and in that case all windows are gone, the desktop changes completely, and users who triggered this feature unaware of it will likely be very confused and think they've just broken their system. It's also not discoverable, making it hard to find even for those that would understand it. Not sure how to address those, maybe you have an idea? Cheers, -- 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: questions about Plasma Package
Hey Giorgos, On Saturday, December 24, 2011 16:05:31 Giorgos Tsiapaliwkas wrote: > here some questions about the plasma package > > 1.every plasmoid has these 3 dirs code,data,animations. > What kind of files should exist in those 3? > Does those 3 have any "special" effects to the plasmoids like the > ui/config.ui? No side-effects. Basically, the only thing you need is a metadata.desktop file and a mainscript (which is defined in the metadata.desktop file). The rest, (including names of directories inside content) is just eye-candy. Just delete what's not needed. > 2.in the declarative-plasmoids repository there is a > plasma-applet-$plasmoid.desktop file which > has the same contents as the desktop file in contents/metadata.desktop. > Do we need both of them? (cmake is making just a copy) It's the same file, different name: metadata.desktop : definition for the package plasma-applet-$plasmoid.desktop : this is how the KDE plugin loader finds the applets. The best way is indeed to have cmake copy the metadata.desktop file. And yep, we need both. > here, http://community.kde.org/Plasma/Package > > it mentions that every plasmoid's root dir must follow this name policy. > $PlasmoidName-$PlasmoidVersion, > > in the declarative plasmoids this policy is not being followed. > Doesn't the policy apply anymore? This policy seems new to me, I don't think it applies right now (but don't really know if it should, or if we found a good reason for it not to). > I want to give some love in this wiki page,so if you want something to > be changed please let me know. Hope the above helps :) -- 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
Mouse wheel support for the activity widget
Hi, I've implemented the functionality for changing the activity rolling the mouse wheel over the showActivityManager plasmoid. I like this functionality because I can put the widget on the panel and change the activity without doing 'show desktop>roll over desktop' or 'open activity panel > select activity > close activity panel', I've attached a patch to the email. If you like it maybe you can merge it upstream. Bye Simone Gaiarin wheel.patch Description: Binary data ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Change activity by rolling the mouse wheel over the showActivityManager widget.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103548/ --- (Updated Dec. 26, 2011, 10:46 p.m.) Review request for Plasma and Aaron J. Seigo. Description --- Rolling the mouse wheel over the showActivityManager change the current activity. In this way it's not necessary to open the activities menu, select the activity and close the menu and the activity change is faster. Diffs - plasma/desktop/applets/showActivityManager/showActivityManager.h f58fbb71a633f7f2ee3185650a9a7cbb083ec955 plasma/desktop/applets/showActivityManager/showActivityManager.cpp e77df0d82c64562390fc922105cd3aea9af138a2 Diff: http://git.reviewboard.kde.org/r/103548/diff/diff Testing --- The plasmoid works fine after the patch. Thanks, Simone Gaiarin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Change activity by rolling the mouse wheel over the showActivityManager widget.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103548/ --- Review request for Plasma and Aaron J. Seigo. Description --- Rolling the mouse wheel over the showActivityManager change the current activity. In this way it's not necessary to open the activities menu, select the activity and close the menu and the activity change is faster. Diffs - plasma/desktop/applets/showActivityManager/showActivityManager.h f58fbb71a633f7f2ee3185650a9a7cbb083ec955 plasma/desktop/applets/showActivityManager/showActivityManager.cpp e77df0d82c64562390fc922105cd3aea9af138a2 Diff: http://git.reviewboard.kde.org/r/103548/diff/diff Testing --- The plasmoid works fine after the patch. Thanks, Simone Gaiarin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Mouse wheel support for activity widget
Hi all, I've implemented the functionality for changing the activity rolling the mouse wheel over the showActivityManager plasmoid. I've attached a patch to the email. If it is good enough, it can be merged upstream. Bye wheel.patch Description: Binary data ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Make KGlobalSettings reread locale settings before calling settingsChanged().
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103469/#review9292 --- Ship it! Looks good. You can commit to kdelibs, branch KDE/4.8 - David Faure On Dec. 19, 2011, 10:15 p.m., Lamarque Vieira Souza wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103469/ > --- > > (Updated Dec. 19, 2011, 10:15 p.m.) > > > Review request for kdelibs and Plasma. > > > Description > --- > > This is patch number 3 to fix bug #289094 (top bar time incorrectly displays > in 24 hour format). The other patches are against plasma-mobile and > kde-workspace (http://git.reviewboard.kde.org/r/103434), all three patches > must be applied to fix the bug. I think this is a much simpler solution than > the one I suggested in http://git.reviewboard.kde.org/r/103434. > > > This addresses bug 289094. > http://bugs.kde.org/show_bug.cgi?id=289094 > > > Diffs > - > > kdecore/localization/klocale.h 3495431 > kdecore/localization/klocale.cpp 499bf11 > kdecore/localization/klocale_p.h 4ed8e3f > kdeui/kernel/kglobalsettings.h cb8f7e2 > kdeui/kernel/kglobalsettings.cpp 819b314 > > Diff: http://git.reviewboard.kde.org/r/103469/diff/diff > > > Testing > --- > > > Thanks, > > Lamarque Vieira Souza > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
