Re: OSD above fullscreen windows
On Tuesday 12 August 2014, Vishesh Handa wrote: With Volume, I can maybe understand that you don't want to show it on top and the relevant application should be showing it. Maybe. With the others, they definitely should be. on use cases like a media center, i would see more being always the application deciding how to show it.. but, is something that can be put as a policy who does what, so if we decide the osd is always on top, then the hig should say full screen applications shouldn't try to show brightness, volume etc If the outcome is a change, then let's do it properly by introducing another type and layer - I don't want to semantically abuse types as we used to. I want to have Plasma pass as much information to KWin as possible - we need that for the Wayland world anyway where Plasma cannot just bypass the window manager. Okay. So lets introduce a new type, and use the actual Notification type for Notifications instead of a dock type. This is something that should be done regardless of the discussion. +1 -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119669: Fix broken creation of kstartupconfigfiles
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119669/ --- (Updated Aug. 12, 2014, 9:42 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-workspace Description --- Fix broken creation of kstartupconfigfiles kstartupconfigfiles contains a list of files to compare mtimes on to see if we need to rebuild kstartupconfig. This wasn't being created correctly so we failed to rebuild if any configs updated. This was broken in Qt5 porting: -const QStringList dirs = KGlobal::dirs()-kfsstnd_prefixes().split( KPATH_SEPARATOR, QString::SkipEmptyParts); +const QStringList dirs = QStandardPaths::standardLocations(QStandardPaths::GenericDataLocation); Diffs - startkde/kstartupconfig/kdostartupconfig.cpp af6062c Diff: https://git.reviewboard.kde.org/r/119669/diff/ Testing --- Checked output of kstartupconfigfiles was sane. Updated ksplashrc, ran kstartupconfig5 (NOT kdostartupconfig5) checked kstartupconfig was regenerated. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minimum translation percentage for Plasma 5 release
El Dimarts, 12 d'agost de 2014, a les 11:56:40, Māris Nartišs va escriure: Hello Vincenzo, I read Martin's reply as it would not hurt to have partial translation. Keep in mind the motivating factor. I joined KDE, QGIS and GRASS GIS translation efforts because the shipped translations were incomplete, imperfect or even bogus. Artificial percentage doesn't provide the quality of translation. Right, percentage is a weak metric for quality, translation can still be totally broken at 100% Those, who are following this mailing list, probably have noticed languageo FOO is FUBARED and I want to take over it to fix it type e-mails. Thus if the choice is between partial translation vs no translation, I would vote for partial translation. Although I liked Franklin's idea - 70% = warning barrier and like 50% = hard barrier. If a language fails below 70% - warn the maintainer. If there is no response from the maintainer within N release(s), stop shipping as it is unmaintained. Thus there would be no 69.9% issue and maintainers struggling to keep up the % would still have a chance to get language shipped as long as they care. Thing is as I mentioned, we should not punish the user because a maintainer stopped caring, at 50% a software may still be very much useful. A no ship barrier still would be nice, as there are some languages having 0% translated strings. Listing such language as an one of KDE (SC) languages would make us a laughing stock. Sure, I agree that 0% makes no sense, so let's say something as low as maybe 15% to make sure it starts being useful, i think with 15% you can have the most used buttons, etc translated already (of course you can also have obscure stuf translated, as said percentage is a weak metric) Sorry, Albert, this offer adds some extra work for you. Why would it be extra work, we already have this concept ;) And i'm not doing the plasma 5 releases anyway :D Cheers, Albert Just my 0.02, Maris. 2014-08-12 11:30 GMT+03:00 Vincenzo Reale smart2...@baslug.org: In data martedì 12 agosto 2014 10:17:59, Martin Schlander ha scritto: Mandag den 11. august 2014 20:37:28 skrev Albert Astals Cid: So I am leaning towards no minimum, but I certainly welcome all comments and am open to change. Opinions? Hmmm, as a translator it's probably in my interest not to have any minimum, even though I don't plan to be flirting with 70% completion very much. The question is whether very incomplete translations might hurt KDE/Plasma in the eyes of users, more than having no translations at all. But I'm leaning towards no, probably not. Hi all, I fully agree with Martin's statement. Incomplete translations are really ugly to see. It's better having no translations. Regards, Vincenzo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minimum translation percentage for Plasma 5 release
El Dimarts, 12 d'agost de 2014, a les 11:39:49, Pino Toscano va escriure: Hi, On Tuesday 12 August 2014 11:56:40 Māris Nartišs wrote: Keep in mind the motivating factor. I joined KDE, QGIS and GRASS GIS translation efforts because the shipped translations were incomplete, imperfect or even bogus. Please do keep in mind most of our final users are not skilled in English, nor want/can contribute, and so on. For them, a incomplete (or low quality as well) translation can just produce the result of making them stop using the application/desktop environment altogether, possibly giving a bad advertising because KThisApp is totally funny/crap in my language (and yes, I've seen over the past years example of both users not using something because of incomplete/bad translations, and of bad advertising). I'm confused here, you first argue that most of our final users are not skilled in English but then you seem to argue for requiring a high percentage of translations, which means we're leaving those out in the cold when possibly/maybe at 15% or 25% they would have enough translations to get the basics translated and to guess the rest. Cheers, Albert ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minimum translation percentage for Plasma 5 release
El Dimarts, 12 d'agost de 2014, a les 08:43:14, Franklin Weng va escriure: 2014-08-12 2:37 GMT+08:00 Albert Astals Cid aa...@kde.org: Hi, in the 4.x world we have something called Essential Packages for translations that is basically a set of minimum percentage of some files that you need to get if you want the whole translation of your language to be released with the 4.x SC. For KDE Frameworks we have decided to not have a minimum of translation. Each Framework will ship the translation files it has available. The question here is if we want it or not for Plasma = 5.1. If we only ship languages with say = 70% we ensure that the shipped languages have a reasonable number of translations (one can't ensure quality). On the other hand a hard limit is also a bit unfair to users, if the translation drops to 69.5% because the translator went MIA, they will stop getting the translation. Also it makes it harder for smaller teams to get contributors, since the moment we drop it, it gets less visibility and thus it's harder for the small team to get new contributors to help them reach the required percentage again. Well, maybe not to drop it in certain range like 65%, but to warn the coordinator when under 70%. And when the translation rate is under 70% for three consecutive versions (even in 69%) it can be dropped. The thing is, if we do that, we are punishing Joe user that probably can still use the software at 69% Cheers, Albert Franklin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minimum translation percentage for Plasma 5 release
On Tue, Aug 12, 2014 at 2:43 AM, Franklin Weng frank...@goodhorse.idv.tw wrote: 2014-08-12 2:37 GMT+08:00 Albert Astals Cid aa...@kde.org: Hi, in the 4.x world we have something called Essential Packages for translations that is basically a set of minimum percentage of some files that you need to get if you want the whole translation of your language to be released with the 4.x SC. For KDE Frameworks we have decided to not have a minimum of translation. Each Framework will ship the translation files it has available. The question here is if we want it or not for Plasma = 5.1. If we only ship languages with say = 70% we ensure that the shipped languages have a reasonable number of translations (one can't ensure quality). On the other hand a hard limit is also a bit unfair to users, if the translation drops to 69.5% because the translator went MIA, they will stop getting the translation. Also it makes it harder for smaller teams to get contributors, since the moment we drop it, it gets less visibility and thus it's harder for the small team to get new contributors to help them reach the required percentage again. Well, maybe not to drop it in certain range like 65%, but to warn the coordinator when under 70%. And when the translation rate is under 70% for three consecutive versions (even in 69%) it can be dropped. Franklin What I would suggest is to only advertise as available languages the ones above K%, but still distribute all translations, because there's little reason to keep to ourselves some of the translations. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: OSD above fullscreen windows
On Tue, Aug 12, 2014 at 11:11 AM, Marco Martin notm...@gmail.com wrote: On Tuesday 12 August 2014, Vishesh Handa wrote: With Volume, I can maybe understand that you don't want to show it on top and the relevant application should be showing it. Maybe. With the others, they definitely should be. on use cases like a media center, i would see more being always the application deciding how to show it.. but, is something that can be put as a policy who does what, so if we decide the osd is always on top, then the hig should say full screen applications shouldn't try to show brightness, volume etc However when you're watching a movie in $player and you hit your multimedia volume keys, you are actually modifying the system volume level, not the application volume level. Therefore I believe changing the volume using your keyboard (which is handled by kmix) should always show the system OSD for volume, application should handle when you change the application volume (using the app's shortcut). Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 112208: KMix qml applet
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112208/#review64369 --- For me it looks fine, with some questions: 1) Is this completely decoupled from KMix? I do not see a open mixer to open the main application. 2) Is it supposed to be integrated in KMix 3) In general, the question is how to progress from here. Diego, do you want KMix integration, or a standalone app? Have any ideas or plans to get it in KDE? - Christian Esken On May 4, 2014, 9:46 p.m., Diego Casella wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112208/ --- (Updated May 4, 2014, 9:46 p.m.) Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and Igor Poboiko. Repository: kmix Description --- KMix qml applet. As you can see from the screenshot, the applet is pretty much functional: you can display all the controls available, change its orientation, and decide to whether show all of them or just the Master Control, and refresh its status when new controls are added/removed/updated (such as Amarok current playing track). See screenshots below :) Differences from the old kmix tray: * no media player controls ( I never investigated how to get them, but honestly opening the audio applet to change/skip/pause audio track makes little sense to me ... if anyone wants this feature back, don't be shy and step in); * the button used to select which Mixers are visible has been changed to open Phonon kcm page: since visible mixers are already configurable from KMix app, having a button to show KMix *and* a button to modify Mixers visibilty made little sense here too, so I preferred to give more visibility to Phonon kcm; Known issues: * there is still no way to get notified of mouse wheel events over the popupIcon, so it is not possible to scroll over to increase/decrease the master control volume; * no scroll events over the sliders too; * if you want to use the applet you most likely will disable KMix tray icon but, if you do so, KMix will show its GUI at every login and you have to close it manually. This requires KMix to be patched. Furthermore, if you click KMix Setup button, KMix window will not restored anymore: this needs to be pathed as well. * resize doesn't work properly. Diffs - plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml 7e87c8e plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 26f2968 plasma/kmix-applet-qml/contents/ui/MixersList.qml 66bda73 plasma/kmix-applet-qml/contents/ui/VerticalControl.qml 1702be7 plasma/kmix-applet-qml/contents/ui/VerticalMixerListDelegate.qml bab9ac6 plasma/kmix-applet-qml/contents/ui/kmixapplet.qml eecb91c Diff: https://git.reviewboard.kde.org/r/112208/diff/ Testing --- Tested against master and works fine. File Attachments Default look https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png Menu Actions https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png Applet Config Options https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png Vertical Control https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png ToolButton label and Config page after updates https://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png Control Icon and Label left aligned https://git.reviewboard.kde.org/media/uploaded/files/2013/08/27/kmix_applet6.png Kmix, horizontal view https://git.reviewboard.kde.org/media/uploaded/files/2014/05/04/9d6b0ca4-5a75-45cc-ab8e-61b13d4079e6__kmix_horizontal_new.png Kmix applet, vertical view https://git.reviewboard.kde.org/media/uploaded/files/2014/05/04/7efb308a-c306-47c2-883f-64d1f32db5b5__kmix_vertical_new.png Thanks, Diego Casella ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119733: nicer cmake output
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119733/ --- Review request for Plasma and Martin Gräßlin. Repository: plasma-workspace Description --- make clear there isn't a release of prison Diffs - klipper/CMakeLists.txt 9b75e9c Diff: https://git.reviewboard.kde.org/r/119733/diff/ Testing --- Thanks, Jonathan Riddell ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 112208: KMix qml applet
On Aug. 12, 2014, 1:19 p.m., Christian Esken wrote: For me it looks fine, with some questions: 1) Is this completely decoupled from KMix? I do not see a open mixer to open the main application. 2) Is it supposed to be integrated in KMix 3) In general, the question is how to progress from here. Diego, do you want KMix integration, or a standalone app? Have any ideas or plans to get it in KDE? Note that new work on QML based KMix has started, however this will be Plasma5 only -- http://apachelog.wordpress.com/2014/08/11/volume/ - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112208/#review64369 --- On May 4, 2014, 11:46 p.m., Diego Casella wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112208/ --- (Updated May 4, 2014, 11:46 p.m.) Review request for Plasma, Aaron J. Seigo, Christian Esken, Marco Martin, and Igor Poboiko. Repository: kmix Description --- KMix qml applet. As you can see from the screenshot, the applet is pretty much functional: you can display all the controls available, change its orientation, and decide to whether show all of them or just the Master Control, and refresh its status when new controls are added/removed/updated (such as Amarok current playing track). See screenshots below :) Differences from the old kmix tray: * no media player controls ( I never investigated how to get them, but honestly opening the audio applet to change/skip/pause audio track makes little sense to me ... if anyone wants this feature back, don't be shy and step in); * the button used to select which Mixers are visible has been changed to open Phonon kcm page: since visible mixers are already configurable from KMix app, having a button to show KMix *and* a button to modify Mixers visibilty made little sense here too, so I preferred to give more visibility to Phonon kcm; Known issues: * there is still no way to get notified of mouse wheel events over the popupIcon, so it is not possible to scroll over to increase/decrease the master control volume; * no scroll events over the sliders too; * if you want to use the applet you most likely will disable KMix tray icon but, if you do so, KMix will show its GUI at every login and you have to close it manually. This requires KMix to be patched. Furthermore, if you click KMix Setup button, KMix window will not restored anymore: this needs to be pathed as well. * resize doesn't work properly. Diffs - plasma/kmix-applet-qml/contents/ui/HorizontalControl.qml 7e87c8e plasma/kmix-applet-qml/contents/ui/HorizontalMixerListDelegate.qml 26f2968 plasma/kmix-applet-qml/contents/ui/MixersList.qml 66bda73 plasma/kmix-applet-qml/contents/ui/VerticalControl.qml 1702be7 plasma/kmix-applet-qml/contents/ui/VerticalMixerListDelegate.qml bab9ac6 plasma/kmix-applet-qml/contents/ui/kmixapplet.qml eecb91c Diff: https://git.reviewboard.kde.org/r/112208/diff/ Testing --- Tested against master and works fine. File Attachments Default look https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet.png Menu Actions https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet1.png Applet Config Options https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet2.png Vertical Control https://git.reviewboard.kde.org/media/uploaded/files/2013/08/22/kmix_applet3.png ToolButton label and Config page after updates https://git.reviewboard.kde.org/media/uploaded/files/2013/08/24/kmix_applet5.png Control Icon and Label left aligned https://git.reviewboard.kde.org/media/uploaded/files/2013/08/27/kmix_applet6.png Kmix, horizontal view https://git.reviewboard.kde.org/media/uploaded/files/2014/05/04/9d6b0ca4-5a75-45cc-ab8e-61b13d4079e6__kmix_horizontal_new.png Kmix applet, vertical view https://git.reviewboard.kde.org/media/uploaded/files/2014/05/04/7efb308a-c306-47c2-883f-64d1f32db5b5__kmix_vertical_new.png Thanks, Diego Casella ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119733: nicer cmake output
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119733/#review64371 --- hmm, no stable release currently but then checks for a stable release 1.2.0? - Marco Martin On Ago. 12, 2014, 11:34 a.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119733/ --- (Updated Ago. 12, 2014, 11:34 a.m.) Review request for Plasma and Martin Gräßlin. Repository: plasma-workspace Description --- make clear there isn't a release of prison Diffs - klipper/CMakeLists.txt 9b75e9c Diff: https://git.reviewboard.kde.org/r/119733/diff/ Testing --- Thanks, Jonathan Riddell ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119720: Streamline device notifier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119720/#review64373 --- The name, especially the German translation could be improved IMO. That would also be in line with other changes (example Network Management became Networks). I'd suggest Removable Devices instead of Device Notifier. Thoughts? - Sebastian Kügler On Aug. 11, 2014, 7:18 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119720/ --- (Updated Aug. 11, 2014, 7:18 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- This streamlines the device notifier plasmoid. - Remove redundand Available devices label and only show No devices available if there aren't any (Maybe rename Device Notifier to something less geeky, that replaces the former heading?) - Use the same Heading as the notifications for the sections Diffs - applets/devicenotifier/package/contents/ui/FullRepresentation.qml 9070788 Diff: https://git.reviewboard.kde.org/r/119720/diff/ Testing --- Yup. File Attachments Device Notifier (before) https://git.reviewboard.kde.org/media/uploaded/files/2014/08/11/c44f1937-d712-4516-b0e7-a7177ef3715b__devicenotifyold.png Device Notifier (after) https://git.reviewboard.kde.org/media/uploaded/files/2014/08/11/53c802f5-9d1a-4176-8025-e3b3dab45d93__devicenotifynew.png Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: OSD above fullscreen windows
On Tuesday, August 12, 2014 11:11:08 Marco Martin wrote: On Tuesday 12 August 2014, Vishesh Handa wrote: With Volume, I can maybe understand that you don't want to show it on top and the relevant application should be showing it. Maybe. With the others, they definitely should be. on use cases like a media center, i would see more being always the application deciding how to show it.. but, is something that can be put as a policy who does what, so if we decide the osd is always on top, then the hig should say full screen applications shouldn't try to show brightness, volume etc Looking at my TVs, it always shows the OSD when volume changes, that would be something I'd also expect a media center to do. -- 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 119720: Streamline device notifier
On Aug. 12, 2014, 2:29 p.m., Sebastian Kügler wrote: The name, especially the German translation could be improved IMO. That would also be in line with other changes (example Network Management became Networks). I'd suggest Removable Devices instead of Device Notifier. Thoughts? +1 - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119720/#review64373 --- On Aug. 11, 2014, 9:18 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119720/ --- (Updated Aug. 11, 2014, 9:18 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- This streamlines the device notifier plasmoid. - Remove redundand Available devices label and only show No devices available if there aren't any (Maybe rename Device Notifier to something less geeky, that replaces the former heading?) - Use the same Heading as the notifications for the sections Diffs - applets/devicenotifier/package/contents/ui/FullRepresentation.qml 9070788 Diff: https://git.reviewboard.kde.org/r/119720/diff/ Testing --- Yup. File Attachments Device Notifier (before) https://git.reviewboard.kde.org/media/uploaded/files/2014/08/11/c44f1937-d712-4516-b0e7-a7177ef3715b__devicenotifyold.png Device Notifier (after) https://git.reviewboard.kde.org/media/uploaded/files/2014/08/11/53c802f5-9d1a-4176-8025-e3b3dab45d93__devicenotifynew.png Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Use of KDirWatch
On Tuesday, August 12, 2014 00:10:59 Aleix Pol wrote: Should we maybe agree that KDirWatch::self() is harmful in the context of plasma? It's not more harmful than anywhere else, IMO. We should keep an eye out for it in review requests, though. The shared KDirWatch can be useful, and we shouldn't disallow it (but still have a critical eye on correct usage). 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: Review Request 110216: Rename Screen Locker screensaver KCM to Lock Screen
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/110216/#review64377 --- It's fixed in Plasma 5, anyway. - Sebastian Kügler On Aug. 11, 2014, 7:14 p.m., Will Stephenson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/110216/ --- (Updated Aug. 11, 2014, 7:14 p.m.) Review request for Plasma and Marco Martin. Repository: kde-workspace Description --- 'Screen Locker' sounds wrong, a locker is something you keep your books at school in. 'Lock Screen' is currently frequently used in English on phones and is also used by Gnome Shell for their screensaver replacement. Diffs - kcontrol/screensaver/screensaver.desktop d1f887a Diff: https://git.reviewboard.kde.org/r/110216/diff/ Testing --- Thanks, Will Stephenson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119720: Streamline device notifier
On Aug. 12, 2014, 12:29 nachm., Sebastian Kügler wrote: The name, especially the German translation could be improved IMO. That would also be in line with other changes (example Network Management became Networks). I'd suggest Removable Devices instead of Device Notifier. Thoughts? Martin Klapetek wrote: +1 Maybe Storage Devices or Devices Storage because obviously your mouse, keyboard and phone don't appear in there. - Kai Uwe --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119720/#review64373 --- On Aug. 11, 2014, 7:18 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119720/ --- (Updated Aug. 11, 2014, 7:18 nachm.) Review request for Plasma. Repository: plasma-workspace Description --- This streamlines the device notifier plasmoid. - Remove redundand Available devices label and only show No devices available if there aren't any (Maybe rename Device Notifier to something less geeky, that replaces the former heading?) - Use the same Heading as the notifications for the sections Diffs - applets/devicenotifier/package/contents/ui/FullRepresentation.qml 9070788 Diff: https://git.reviewboard.kde.org/r/119720/diff/ Testing --- Yup. File Attachments Device Notifier (before) https://git.reviewboard.kde.org/media/uploaded/files/2014/08/11/c44f1937-d712-4516-b0e7-a7177ef3715b__devicenotifyold.png Device Notifier (after) https://git.reviewboard.kde.org/media/uploaded/files/2014/08/11/53c802f5-9d1a-4176-8025-e3b3dab45d93__devicenotifynew.png Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119720: Streamline device notifier
On Aug. 12, 2014, 12:29 nachm., Sebastian Kügler wrote: The name, especially the German translation could be improved IMO. That would also be in line with other changes (example Network Management became Networks). I'd suggest Removable Devices instead of Device Notifier. Thoughts? Martin Klapetek wrote: +1 Kai Uwe Broulik wrote: Maybe Storage Devices or Devices Storage because obviously your mouse, keyboard and phone don't appear in there. Err, I misread yours as Devices hence the second part of my comment. Can't it show non-removable, too?, ie. *Removable* sounds too specific to me. - Kai Uwe --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119720/#review64373 --- On Aug. 11, 2014, 7:18 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119720/ --- (Updated Aug. 11, 2014, 7:18 nachm.) Review request for Plasma. Repository: plasma-workspace Description --- This streamlines the device notifier plasmoid. - Remove redundand Available devices label and only show No devices available if there aren't any (Maybe rename Device Notifier to something less geeky, that replaces the former heading?) - Use the same Heading as the notifications for the sections Diffs - applets/devicenotifier/package/contents/ui/FullRepresentation.qml 9070788 Diff: https://git.reviewboard.kde.org/r/119720/diff/ Testing --- Yup. File Attachments Device Notifier (before) https://git.reviewboard.kde.org/media/uploaded/files/2014/08/11/c44f1937-d712-4516-b0e7-a7177ef3715b__devicenotifyold.png Device Notifier (after) https://git.reviewboard.kde.org/media/uploaded/files/2014/08/11/53c802f5-9d1a-4176-8025-e3b3dab45d93__devicenotifynew.png Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: OSD above fullscreen windows
On Tue, Aug 12, 2014 at 2:37 PM, Sebastian Kügler se...@kde.org wrote: On Tuesday, August 12, 2014 11:11:08 Marco Martin wrote: On Tuesday 12 August 2014, Vishesh Handa wrote: With Volume, I can maybe understand that you don't want to show it on top and the relevant application should be showing it. Maybe. With the others, they definitely should be. on use cases like a media center, i would see more being always the application deciding how to show it.. but, is something that can be put as a policy who does what, so if we decide the osd is always on top, then the hig should say full screen applications shouldn't try to show brightness, volume etc Looking at my TVs, it always shows the OSD when volume changes, that would be something I'd also expect a media center to do. Maybe we want different OSD when fullscreen. I've never seen a TV with the volume information on the center. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119720: Streamline device notifier
On Aug. 12, 2014, 12:29 p.m., Sebastian Kügler wrote: The name, especially the German translation could be improved IMO. That would also be in line with other changes (example Network Management became Networks). I'd suggest Removable Devices instead of Device Notifier. Thoughts? Martin Klapetek wrote: +1 Kai Uwe Broulik wrote: Maybe Storage Devices or Devices Storage because obviously your mouse, keyboard and phone don't appear in there. Kai Uwe Broulik wrote: Err, I misread yours as Devices hence the second part of my comment. Can't it show non-removable, too?, ie. *Removable* sounds too specific to me. The primary use-case is removable storage devices, I'd be cool with both, Storage Devices and Removable Devices, both are a clear improvement over what it currently says. - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119720/#review64373 --- On Aug. 11, 2014, 7:18 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119720/ --- (Updated Aug. 11, 2014, 7:18 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- This streamlines the device notifier plasmoid. - Remove redundand Available devices label and only show No devices available if there aren't any (Maybe rename Device Notifier to something less geeky, that replaces the former heading?) - Use the same Heading as the notifications for the sections Diffs - applets/devicenotifier/package/contents/ui/FullRepresentation.qml 9070788 Diff: https://git.reviewboard.kde.org/r/119720/diff/ Testing --- Yup. File Attachments Device Notifier (before) https://git.reviewboard.kde.org/media/uploaded/files/2014/08/11/c44f1937-d712-4516-b0e7-a7177ef3715b__devicenotifyold.png Device Notifier (after) https://git.reviewboard.kde.org/media/uploaded/files/2014/08/11/53c802f5-9d1a-4176-8025-e3b3dab45d93__devicenotifynew.png Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: OSD above fullscreen windows
On Tuesday, August 12, 2014 15:38:33 Aleix Pol wrote: On Tue, Aug 12, 2014 at 2:37 PM, Sebastian Kügler se...@kde.org wrote: On Tuesday, August 12, 2014 11:11:08 Marco Martin wrote: On Tuesday 12 August 2014, Vishesh Handa wrote: With Volume, I can maybe understand that you don't want to show it on top and the relevant application should be showing it. Maybe. With the others, they definitely should be. on use cases like a media center, i would see more being always the application deciding how to show it.. but, is something that can be put as a policy who does what, so if we decide the osd is always on top, then the hig should say full screen applications shouldn't try to show brightness, volume etc Looking at my TVs, it always shows the OSD when volume changes, that would be something I'd also expect a media center to do. Maybe we want different OSD when fullscreen. I've never seen a TV with the volume information on the center. We already have that (assuming media center is its own shell and uses its own Look and Feel package). The OSD is loaded from LF. -- 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: OSD above fullscreen windows
On Tuesday 12 August 2014, Aleix Pol wrote: Looking at my TVs, it always shows the OSD when volume changes, that would be something I'd also expect a media center to do. Maybe we want different OSD when fullscreen. I've never seen a TV with the volume information on the center. and this would cause problems exactly in ... ? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: OSD above fullscreen windows
On Tue, Aug 12, 2014 at 3:58 PM, Marco Martin notm...@gmail.com wrote: On Tuesday 12 August 2014, Aleix Pol wrote: Looking at my TVs, it always shows the OSD when volume changes, that would be something I'd also expect a media center to do. Maybe we want different OSD when fullscreen. I've never seen a TV with the volume information on the center. and this would cause problems exactly in ... ? It's not a problem :D i was just pointing out that we want to take into account such details. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minutes Monday Plasma Hangout
On Monday 11 August 2014, Marco Martin wrote: On Monday 11 August 2014, Sebastian Kügler wrote: - Working on LookFeel KCM One thing I would like to hear opinions about on this is: the look and feel kcm depends from 2 things inside 2 repositories: * the lookandfeelaccess class inside plasma-workspace, that at the moment is static * from plasma-desktop, kcms/krdb/krdb.cpp that is static as well, is used to apply colors icons etc to gtk and qt-only apps (now also to kde4 apps) so, either lookandfeelaccess becomes a public library or gets copied in plasma-desktop.. opinions? to better exemplify, i did put the kcm on plasma-desktop (had to copy the lookandfeelaccess class) so now it does some of the required fancy stuff like immediately applying icons, cursors, widget style, colors to gtk apps.. (discovered a neat bug in the meantime, that QQuickWidget that was supposed to solve all our problems just dies and stops rendering if the widget style changes, but eh, whatever..) all of that code is horrible kitten-killer old stuff, and comes from old kcms, so i tried to use as much as possible including their files (some from kcminput, some from krdb.cpp that's statically linked by half of the kcms) so, horrible++ but i would go this way as the least horrible -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119738: Port Fuzzy Clock to Plasma 5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119738/ --- Review request for Plasma. Repository: kdeplasma-addons Description --- This ports the infamous Fuzzy Clock to Plasma 5. The code is derived from digital clock with the fuzzy logic derived from the original implementation. I had to substitute %1 by $1 in the i18n strings (and replace them back), otherwise I got I18N_EXCESSIVE_ARGUMENTS thingies appended to my fuzzy string. Missing is the ability to show the time zone (really needed here?), and the Percent of taskbar size slider because that layouting logic copied from digital clock is beyond me :) Also missing is the Configure time format (why's there no Configure Date and Time in digital clock?) because fuzzy clock doesn't really adhere to the locale anyway and I didn't want to yet again duplicate that ProcessRunner plugin which seems to have been copied all over the place already. Diffs - applets/fuzzy-clock/fuzzyClockConfig.ui 15cc658 applets/fuzzy-clock/package/contents/config/config.qml PRE-CREATION applets/fuzzy-clock/package/contents/config/main.xml PRE-CREATION applets/fuzzy-clock/package/contents/ui/FuzzyClock.qml PRE-CREATION applets/fuzzy-clock/package/contents/ui/configAppearance.qml PRE-CREATION applets/fuzzy-clock/package/contents/ui/main.qml PRE-CREATION applets/fuzzy-clock/package/metadata.desktop PRE-CREATION applets/fuzzy-clock/plasma-clock-fuzzy.desktop 5f6d30b applets/CMakeLists.txt 661ecb4 applets/fuzzy-clock/CMakeLists.txt 1068150 applets/fuzzy-clock/Messages.sh c8c9f06 applets/fuzzy-clock/fuzzyClock.h 9bf5c4e applets/fuzzy-clock/fuzzyClock.cpp 2cd189d Diff: https://git.reviewboard.kde.org/r/119738/diff/ Testing --- I've been running it since yesterday evening and didn't notice unusual behavior, except that due to the update interval of 30s it doesn't update right away when session is resumed from Suspend (but I guess this is a Plasma issue?). Also it tends to cut off in a vertical panel due to its (sane) minimum font size (smallest theme font) being larger than in the original implementation where it used to get super tiny then. File Attachments In horizontal panel https://git.reviewboard.kde.org/media/uploaded/files/2014/08/12/35e0fea1-8a28-4ddb-9a81-9112bb85eab5__fuzzyinapanel.png On the Desktop https://git.reviewboard.kde.org/media/uploaded/files/2014/08/12/a246f3b3-bb12-4756-8069-594d25bd39f6__fuzzyonthedesktop.png Configuration UI https://git.reviewboard.kde.org/media/uploaded/files/2014/08/12/a144ea07-e18a-4a90-965a-3db51d91fb5d__fuzzyconfig.png Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119739: Don't hardcode applet configuration sidebar size
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119739/ --- Review request for Plasma. Repository: plasma-desktop Description --- The sidebar in the applet configuration which tries to mimic the sidebar in traditional KCMs is hardcoded to 100px resulting in cramped text on my machine. The grid * 7 is completely arbitrary and I don't like it but I have no idea what heuristics Qt uses to determin the size of that panel. Diffs - desktoppackage/contents/configuration/AppletConfiguration.qml 546b8db Diff: https://git.reviewboard.kde.org/r/119739/diff/ Testing --- It looks fine on my machine (fonts at 180dpi) but somebody with an ordinary display should definitely verify that. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5.0.1 tars
On Mon, Aug 11, 2014 at 10:39:58PM +0400, Alexey Shvetsov wrote: hi! Plasma 5.x depends on bluedevil. May be its good to have bluedevil snapshot for plasma? Where does it depend on bluedevil? Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-packager] Re: Plasma 5.0.1 tars
Plasma 5.0.1 is out, remember to update the wiki page if you're making packages https://community.kde.org/Plasma/Packages http://kde.org/announcements/plasma-5.0.1.php Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119739: Don't hardcode applet configuration sidebar size
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119739/#review64396 --- Ship it! Ship It! - David Edmundson On Aug. 12, 2014, 6:32 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119739/ --- (Updated Aug. 12, 2014, 6:32 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- The sidebar in the applet configuration which tries to mimic the sidebar in traditional KCMs is hardcoded to 100px resulting in cramped text on my machine. The grid * 7 is completely arbitrary and I don't like it but I have no idea what heuristics Qt uses to determin the size of that panel. Diffs - desktoppackage/contents/configuration/AppletConfiguration.qml 546b8db Diff: https://git.reviewboard.kde.org/r/119739/diff/ Testing --- It looks fine on my machine (fonts at 180dpi) but somebody with an ordinary display should definitely verify that. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119745: Hide member documentation for classes in imports
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119745/#review64404 --- Ship it! Ship It! - Marco Martin On Aug. 12, 2014, 8:12 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119745/ --- (Updated Aug. 12, 2014, 8:12 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- These classes are exposed only as QML so we should only show members the user can actually use. The invokable is moved to the top so we only need one block to hide things. It's not great having to add tags manually, but it's the best I've found; especially as we can't just hide member variables as we need Q_INVOKABLES. If this gets approved I'll do the other plasma docs. Diffs - src/declarativeimports/core/framesvgitem.h 117d10c Diff: https://git.reviewboard.kde.org/r/119745/diff/ Testing --- File Attachments Generated Output https://git.reviewboard.kde.org/media/uploaded/files/2014/08/12/c28277e8-bdd7-4cca-aafb-e36679369dd7__api.png Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119653: batterymonitor: Make BatteryIcon animation run only while the BatteryIcon is visible.
On Авг. 7, 2014, 8:15 п.п., Kai Uwe Broulik wrote: Thanks for taking care of this! Kai Uwe Broulik wrote: Since this is a simple bugfix, please commit to the Plasma/5.0 branch once 5.0.1 is released. Thanks! Bugfixes like these usually go into the stable branch and then are merged to master, forgot to mention that. Done. - Nikita --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119653/#review64014 --- On Авг. 7, 2014, 8:21 п.п., Nikita Skovoroda wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119653/ --- (Updated Авг. 7, 2014, 8:21 п.п.) Review request for Plasma. Repository: plasma-workspace Description --- batterymonitor: Make BatteryIcon animation run only while the BatteryIcon is visible. This change disables the BatteryIcon animation when that icon is not visible. Should be trivial to review. Before this change, plasma was causing a 10-15% CPU load (at one kernel) when using a notebook with ac adapter plugged in and the new systemtray is open, even if different tab from «batterymonitor» is visible. With this change, it should not load CPU with this animation when a different tab is open in systemtray and the batterymonitor tab is not visible. Diffs - applets/batterymonitor/package/contents/ui/BatteryItem.qml e496f0161732f8c7079036c23784cae4a366a595 Diff: https://git.reviewboard.kde.org/r/119653/diff/ Testing --- Works for me. No regressions observed. Thanks, Nikita Skovoroda ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119745: Hide member documentation for classes in imports
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119745/ --- (Updated Aug. 12, 2014, 9:15 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- These classes are exposed only as QML so we should only show members the user can actually use. The invokable is moved to the top so we only need one block to hide things. It's not great having to add tags manually, but it's the best I've found; especially as we can't just hide member variables as we need Q_INVOKABLES. If this gets approved I'll do the other plasma docs. Diffs - src/declarativeimports/core/framesvgitem.h 117d10c Diff: https://git.reviewboard.kde.org/r/119745/diff/ Testing --- File Attachments Generated Output https://git.reviewboard.kde.org/media/uploaded/files/2014/08/12/c28277e8-bdd7-4cca-aafb-e36679369dd7__api.png Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Minimum translation percentage for Plasma 5 releases (second take)
After talking to a few people here in Randa about this issue, I come with an updated suggestion. * We ship all translations that are over a very low limit (say 5%) * When selecting a language in the language KCM that has less than $PERCENTAGE we show a dialog saying something like Yo man, we know the translation of Plasma is not completed into this language, at the moment is at $CURRENTPERCENTAGE, you are still free to use it, and if you want to cotnribute to improve it, plz go to $SOMEURL - needs better wording This way we set the expectations correctly, and people that prefer running translated even if it's just 23%, can do it, and people that think that running low-translated software is a SIN are told and can't complain anymore. Probably we want to do this in other situations like startup of plasma after an upgrade, etc. I'd suggest $PERCENTAGE to be quite high, something like 90% we used to have for kde-runtime. What do you think? Cheers, Albert ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minimum translation percentage for Plasma 5 releases (second take)
Albert Astals Cid ha scritto: After talking to a few people here in Randa about this issue, I come with an updated suggestion. * We ship all translations that are over a very low limit (say 5%) * When selecting a language in the language KCM that has less than $PERCENTAGE we show a dialog saying something like Yo man, we know the translation of Plasma is not completed into this language, at the moment is at $CURRENTPERCENTAGE, you are still free to use it, and if you want to cotnribute to improve it, plz go to $SOMEURL - needs better wording What would happen when the language is automatically chosen based on the system one (i.e. the user does not pass through the KCM)? Probably like the upgrade point described below. This way we set the expectations correctly, and people that prefer running translated even if it's just 23%, can do it, and people that think that running low-translated software is a SIN are told and can't complain anymore. Probably we want to do this in other situations like startup of plasma after an upgrade, etc. I'd suggest $PERCENTAGE to be quite high, something like 90% we used to have for kde-runtime. But is this going to be the percentage of what? plasma-desktop, plasma-frameworks, and also other frameworks used by Plasma? Or...? Would you oppose the a by-language team threshold if the code to maintain it in the release scripts magically popped up? Ciao -- Luigi ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119748: Properly align KickoffButtons to center when in vertical mode
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119748/ --- Review request for Plasma. Repository: plasma-desktop Description --- The labels in Kickoff are misaligned when Kickoff is in vertical mode (see the first screenshot). This patch fixes it by making sure the KickoffButton is always as wide as the parent container, even when the label string is shorter, so that the text is always centered. Diffs - applets/kickoff/package/contents/ui/KickoffButton.qml 3a55c46 Diff: https://git.reviewboard.kde.org/r/119748/diff/ Testing --- File Attachments Before https://git.reviewboard.kde.org/media/uploaded/files/2014/08/12/cc2752ee-9684-42e4-b146-d918351951f8__kickoff-before.png After https://git.reviewboard.kde.org/media/uploaded/files/2014/08/12/dd8b7151-2ab1-43de-acaf-b010d57e3efb__kickoff-after.png Thanks, Dan Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119748: Properly align KickoffButtons to center
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119748/ --- (Updated Aug. 13, 2014, 2:35 a.m.) Review request for Plasma. Changes --- Now the icons and the labels are both horizontally and vertically centered in both vertical and horizontal mode \o/ (see the last screenshot) Repository: plasma-desktop Description --- The first and the last labels in Kickoff are misaligned (see the first screenshot) for some reason - even though the Label correctly fills the entire parent width, the test is still aligned to left. To workaround this issue, this patch wraps the Label into an Item - now the labels are correctly aligned in the center . I don't have any explanation for why does this happen, nor do I understand why wrapping the stuff in Item fixes the problem, so please don't ask (but please explain it to me if you happen to know) :-). Diffs (updated) - applets/kickoff/package/contents/ui/KickoffButton.qml 3a55c46 Diff: https://git.reviewboard.kde.org/r/119748/diff/ Testing --- Tested Kickoff in vertical and horizontal mode, all tab labels are correctly centered File Attachments (updated) Before https://git.reviewboard.kde.org/media/uploaded/files/2014/08/12/cc2752ee-9684-42e4-b146-d918351951f8__kickoff-before.png After https://git.reviewboard.kde.org/media/uploaded/files/2014/08/12/dd8b7151-2ab1-43de-acaf-b010d57e3efb__kickoff-after.png After 2 https://git.reviewboard.kde.org/media/uploaded/files/2014/08/13/3676134b-051f-4d19-93b7-d699ffa91288__kickoff-after2.png Thanks, Dan Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119748: Properly align KickoffButtons to center
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119748/ --- (Updated Aug. 13, 2014, 2:37 a.m.) Review request for Plasma. Repository: plasma-desktop Description (updated) --- The icons and labels are misaligned (both vertically and horizontally) in Kickoff (see the first screenshow) - this patch makes sure that the content of the tab is always centered in both vertical and horizontal mode (see the last screenshot). Diffs - applets/kickoff/package/contents/ui/KickoffButton.qml 3a55c46 Diff: https://git.reviewboard.kde.org/r/119748/diff/ Testing --- Tested Kickoff in vertical and horizontal mode, all tab labels are correctly centered File Attachments (updated) Before https://git.reviewboard.kde.org/media/uploaded/files/2014/08/12/cc2752ee-9684-42e4-b146-d918351951f8__kickoff-before.png After 2 https://git.reviewboard.kde.org/media/uploaded/files/2014/08/13/3676134b-051f-4d19-93b7-d699ffa91288__kickoff-after2.png Thanks, Dan Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minimum translation percentage for Plasma 5 release
2014-08-12 18:05 GMT+08:00 Albert Astals Cid aa...@kde.org: Well, maybe not to drop it in certain range like 65%, but to warn the coordinator when under 70%. And when the translation rate is under 70% for three consecutive versions (even in 69%) it can be dropped. The thing is, if we do that, we are punishing Joe user that probably can still use the software at 69% Cheers, Albert Yes, I agree with it. But it is also about the community contributions. If 1. a language is under soft limit for several releases, 2. a language is warned for several times and announced about to be kicked out from KDE framework, 3. nobody cares about it (therefore nobody is coming out to save it) -- the most important does KDE have to keep this language anymore? Even a language is kicked out, if anyone decides to save the language, they can do it any time and the language will be restored in the next release. zh_TW Traditional Chinese used to be warned once before I become the coordinator... Fortunately there were several people coming out to save zh_TW from being kicked out. BTW, maybe in the supported language list we can also list the languages which used to be in KDE Framework but then kicked out due to lack of maintain, so that anyone who cares about the language can know and do something. Franklin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
