Re: bug target for 4.5
On Friday 07 May 2010, Shaun Reich wrote: On Thu, May 6, 2010 at 6:00 PM, David Hubner hubn...@ntlworld.com wrote: I don't know.. we do have Bill Gates with a 'B' name :) KInfoCenter has been rewritten and commited, as such i have closed all wishes and bugs that were to do with the old code that were fixed in the new code. Should have closed about 10-12 bugs. He was actually referring only to plasma - hence the plasma-devel list :) There are far, far more global kde bugs ;-) not that lowering the bug of the rest of the platform is bad, eh :) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: problem with the notification plasmoid
You should be able to choose them when you create the bug, but not afterwards Beat Wolf Am Freitag 07 Mai 2010, um 00.27:12 schrieb Markus: Am Donnerstag 06 Mai 2010, 21:21:27 schrieb Marco Martin: ah, so not actually the notifications widget. the product to choose in bugzilla is plasma and the component is widget-devicenotifier Just FYI: Normal users can't set the component manually. Only admins can. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: bug target for 4.5
On Friday 07 May 2010, Aaron J. Seigo wrote: hi all :) we're nearing feature freeze and i'd like to propose a bug target that's maybe a bit different than in the past, mostly because of the amount of code, number of users and number of open reports. in the past, i've set out a hard # target to reach. i think this release it's a lot harder to peg such a number. so let's try this instead: let's try to end every day with a lower number of open reports than at the start of that day. right now we are at 955 which is some 30 less than a couple days ago. kudos to everyone closing bugs. if we end each day less than we start, we'll at least be below 900 by the time we release. can we do it? yes we can! (or so says Bob the Builder. and Barak. can't argue with two guys whose name begins with 'B', now can you? ;) it's a good target. right now given our ratio of popularity/resources, is not realistic to expect the bug number keeping low during feature periods. so what we can do realistically is: - having the bug number steadily decreasing for all freeze period - identifying and fixing the most annoying/showstopper ones - besides the raw bug count, each one of us should identify an area where the user experience is rather poor (even if working) and try improve that, things like bad layouting, widgets that exit from parents, missing icons, things like that. Personally my foe will be Plama::Dialog, there are many places it's simply horrile, places at wrong positions (see taskbar groups or the widget explorer) resizes with terrible flickering, it as wrong sizes or things like that. those are all things that are not strictly showstopper, but gives a quite cheap experience Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: bug target for 4.5
On Friday 07 May 2010, 07:30 Marco Martin wrote: - besides the raw bug count, each one of us should identify an area where the user experience is rather poor (even if working) and try improve that, things like bad layouting, widgets that exit from parents, missing icons, things like that. +1 :) From a marketing perspective (not that I'm an expert in this area but...) I can see a lot of people comparing 4.5 with 3.5 in terms of how stable and polished this release will be. It would be wonderful to get a little bit more of love in these two areas for the major problems so we get some good karma after the release :) Cheers! -- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- 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
Review Request: Stop using oxygen as a theme element fallback before 'default' (Air)
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3903/ --- Review request for Plasma. Summary --- If a user starts Plasma on a machine where the configured desktop theme is not available, a fallback is used for each element. If the theme is completely missing, default fallbacks, in order oxygen and default are used. This means that Oxygen elements are used in preference to Air elements. With common configurations, this results in black text on the black/dark Oxygen elements, which is unusable. This patch removes oxygen from the fallbacks, leaving default (Air). Since both oxygen and air are installed by kdebase-workspace they are equally likely to be present. Diffs - trunk/KDE/kdelibs/plasma/theme.cpp 1123666 Diff: http://reviewboard.kde.org/r/3903/diff Testing --- Thanks, Will ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: system tray work
On 02/05/2010 23:36, Fredrik Höglund wrote: On Thursday 29 April 2010, Aaron J. Seigo wrote: On April 29, 2010, Marco Martin wrote: i think i like more the second option. the only problem is that the ui for it would be rather clunky (there would be two distinct shortcut configurations in 2 different places that do almost the same thing) yes, a little clunky. perhaps room for improvement in the future. bonus points for working with any entry in the system tray though ;) which reminds me: someday we really ought to implement some keyboard navigation :) I like this option as well. Keyboard shortcuts are important for accessability, so this is something that really should work with all icons and not just with klipper. Anyway, I've attached the current version of the Klipper patch. Aside from the keyboard shortcut there's also the issue that the dbus menu isn't always updated when the clipboard history changes. Sometimes it is, sometimes it isn't. I'm hoping Aurélien has some idea about that. I just had a look at it, and could not reproduce it :/. Do you know of a way to reliably reproduce it? About the patch: I noticed that left-click shows the menu directly instead of going through dbusmenu, which is a bit inconsistent (even if it's nice for testing!). I tried to improve it by replacing the code in tray.cpp like this: diff --git a/workspace/klipper/tray.cpp b/workspace/klipper/tray.cpp index e392698..7c02e45 100644 --- a/workspace/klipper/tray.cpp +++ b/workspace/klipper/tray.cpp @@ -43,8 +43,7 @@ KlipperTray::KlipperTray() setStatus( Active ); setStandardActionsEnabled( false ); setContextMenu( m_klipper-history()-popup() ); -connect( this, SIGNAL( activateRequested( bool, QPoint )), m_klipper, -SLOT( slotPopupMenu( bool, QPoint))); +setAssociatedWidget( m_klipper-history()-popup() ); connect( m_klipper-history(), SIGNAL(changed()), SLOT(slotSetToolTipFromHistory())); slotSetToolTipFromHistory(); connect( m_klipper, SIGNAL(passivePopup(QString,QString)), SLOT(passive_popup(QString,QString))); (Calling setAssociatedWidget() on the menu is a little-known feature of KSNI which causes the left-click to trigger the menu) But it's not enough because KStatusNotifierItem shows the menu itself instead of sending a menu request over DBus. Which is understandable because there is currently no way to send a menu request. This would be a good addition in my opinion, what do you think about this? Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Stop using oxygen as a theme element fallback before 'default' (Air)
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3903/#review5497 --- If the complete theme is missing, then I'd say 'OK, use air' (aka default). The problem with defaulting the items from air instead of oxygen is back-compatibility. Before Air, most themes were made incomplete - not defining elements relying those will be loaded from oxygen (remember, most kde-look themes are dark). Intoduction of Air as /default/ broke most of those themes, and that is the reason why in the fallback mechanism elements of oxygen needed to go first. - Ivan On 2010-05-07 13:17:50, Will Stephenson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3903/ --- (Updated 2010-05-07 13:17:50) Review request for Plasma. Summary --- If a user starts Plasma on a machine where the configured desktop theme is not available, a fallback is used for each element. If the theme is completely missing, default fallbacks, in order oxygen and default are used. This means that Oxygen elements are used in preference to Air elements. With common configurations, this results in black text on the black/dark Oxygen elements, which is unusable. This patch removes oxygen from the fallbacks, leaving default (Air). Since both oxygen and air are installed by kdebase-workspace they are equally likely to be present. Diffs - trunk/KDE/kdelibs/plasma/theme.cpp 1123666 Diff: http://reviewboard.kde.org/r/3903/diff Testing --- Thanks, Will ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Stop using oxygen as a theme element fallback before 'default' (Air)
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3903/#review5498 --- /me seconds Ivan. That's why oxygen was explicitly put as fallback, even if air always was complete. a theme can explicitly set air as its fallback tough - Marco On 2010-05-07 13:17:50, Will Stephenson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3903/ --- (Updated 2010-05-07 13:17:50) Review request for Plasma. Summary --- If a user starts Plasma on a machine where the configured desktop theme is not available, a fallback is used for each element. If the theme is completely missing, default fallbacks, in order oxygen and default are used. This means that Oxygen elements are used in preference to Air elements. With common configurations, this results in black text on the black/dark Oxygen elements, which is unusable. This patch removes oxygen from the fallbacks, leaving default (Air). Since both oxygen and air are installed by kdebase-workspace they are equally likely to be present. Diffs - trunk/KDE/kdelibs/plasma/theme.cpp 1123666 Diff: http://reviewboard.kde.org/r/3903/diff Testing --- Thanks, Will ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: InputTypeWatcher, to mobilize the plasma widgets
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3914/ --- Review request for Plasma. Summary --- this little class (that probably have to stay private) is a little central place for widget to see how they should behave. with touchscreen some things have to change for everybody, like refusing hover events, always. other widgets will have to change even more, for instance ScrollWidget will have to replace the scrollbars with some simple scroll indicators that appears over the contents and only while animating. it's now done with a simpe config file, it would be cool doing it completely dinamically, and actually by querying the hardware. but i don't thiunk it exists any sane system to hgave reliably thi kind of informations (like if a poiter devie is a mouse otr a touchscreen) so for now it would have to be manually configured. It kinda sucks, but i think it's a quite important feature anyways, quite crucial for touchscreens, and would be still easy to change if is going to stay private for now Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1123761 /trunk/KDE/kdelibs/plasma/private/inputtypewatcher.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/inputtypewatcher_p.h PRE-CREATION /trunk/KDE/kdelibs/plasma/widgets/pushbutton.cpp 1123761 Diff: http://reviewboard.kde.org/r/3914/diff Testing --- Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: InputTypeWatcher, to mobilize the plasma widgets
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3914/#review5505 --- the idea is sound, but the implementation leaves me queasy :) this really ought to be implemented somewhere else (e.g. Qt). keeping a list of every widget we have around is not great ... also, i wonder if this really needs to be runtime configurable, or can we assume a static hardware profile? or is one of the design requirements to support switching between a tablet mode and a laptop mode? (that is actually probably quite valid...) but as this is not a trivial thing and given where we are in the release cycle, can we put this off until 4.6? - Aaron On 2010-05-07 17:58:06, Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3914/ --- (Updated 2010-05-07 17:58:06) Review request for Plasma. Summary --- this little class (that probably have to stay private) is a little central place for widget to see how they should behave. with touchscreen some things have to change for everybody, like refusing hover events, always. other widgets will have to change even more, for instance ScrollWidget will have to replace the scrollbars with some simple scroll indicators that appears over the contents and only while animating. it's now done with a simpe config file, it would be cool doing it completely dinamically, and actually by querying the hardware. but i don't thiunk it exists any sane system to hgave reliably thi kind of informations (like if a poiter devie is a mouse otr a touchscreen) so for now it would have to be manually configured. It kinda sucks, but i think it's a quite important feature anyways, quite crucial for touchscreens, and would be still easy to change if is going to stay private for now Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1123761 /trunk/KDE/kdelibs/plasma/private/inputtypewatcher.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/inputtypewatcher_p.h PRE-CREATION /trunk/KDE/kdelibs/plasma/widgets/pushbutton.cpp 1123761 Diff: http://reviewboard.kde.org/r/3914/diff Testing --- Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: InputTypeWatcher, to mobilize the plasma widgets
On 2010-05-07 20:13:04, Aaron Seigo wrote: the idea is sound, but the implementation leaves me queasy :) this really ought to be implemented somewhere else (e.g. Qt). keeping a list of every widget we have around is not great ... also, i wonder if this really needs to be runtime configurable, or can we assume a static hardware profile? or is one of the design requirements to support switching between a tablet mode and a laptop mode? (that is actually probably quite valid...) but as this is not a trivial thing and given where we are in the release cycle, can we put this off until 4.6? yes, better postpone it. by the way, yes, i think a runtime switching capability would be the little thing we have more - Marco --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3914/#review5505 --- On 2010-05-07 17:58:06, Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3914/ --- (Updated 2010-05-07 17:58:06) Review request for Plasma. Summary --- this little class (that probably have to stay private) is a little central place for widget to see how they should behave. with touchscreen some things have to change for everybody, like refusing hover events, always. other widgets will have to change even more, for instance ScrollWidget will have to replace the scrollbars with some simple scroll indicators that appears over the contents and only while animating. it's now done with a simpe config file, it would be cool doing it completely dinamically, and actually by querying the hardware. but i don't thiunk it exists any sane system to hgave reliably thi kind of informations (like if a poiter devie is a mouse otr a touchscreen) so for now it would have to be manually configured. It kinda sucks, but i think it's a quite important feature anyways, quite crucial for touchscreens, and would be still easy to change if is going to stay private for now Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1123761 /trunk/KDE/kdelibs/plasma/private/inputtypewatcher.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/inputtypewatcher_p.h PRE-CREATION /trunk/KDE/kdelibs/plasma/widgets/pushbutton.cpp 1123761 Diff: http://reviewboard.kde.org/r/3914/diff Testing --- Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
