Review Request: Make “Edit File Type” button more discoverable
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101800/ --- Review request for kdelibs. Summary --- On IRC this evening somebody found it hard to find the options to edit a specific file type. The KCM is a mess unfortunately but I told him that you could edit specific file types directly from the properties dialog. That button is hard to spot, though, which I also often found annoying. It is neither labled nor does it stand out as “button”. This patch solves that issue. It is in need of discussion whether the label itself should stay but the button definitly has to look like a clickable target. Diffs - kio/kfile/kpropertiesdialog.cpp 3382daa Diff: http://git.reviewboard.kde.org/r/101800/diff Testing --- Thanks, Kai Uwe
Re: Review Request: Fix global shortcuts that needs shift key, like for example ctrl+% (ctrl+shift+5 on many keyboards)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101520/#review4244 --- This review has been submitted with commit 568cb9268a3f940564d155526cb81cec4327cbf6 by Simon Persson to branch master. - Commit On June 6, 2011, 11:02 a.m., Simon Persson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101520/ > --- > > (Updated June 6, 2011, 11:02 a.m.) > > > Review request for KDE Runtime and Michael Jansen. > > > Summary > --- > > Second patch to fix this bug, depends on patch in review request 101515. > > KKeySequenceWidget used to enter shortcuts removes shift from the recorded > shortcut if the symbol produced from that physical key is different when > shift is used (upper/lowercase letters doesn't count). kglobalaccel needs to > include shift in the grab in order to be triggered on this class of > shortcuts, and then in the keypress event handler it also needs to strip the > shift again before checking which shortcut was just triggered. > > > This addresses bugs 179504, 197548 and 215030. > http://bugs.kde.org/show_bug.cgi?id=179504 > http://bugs.kde.org/show_bug.cgi?id=197548 > http://bugs.kde.org/show_bug.cgi?id=215030 > > > Diffs > - > > kglobalaccel/kglobalaccel_x11.cpp 2576d2e > > Diff: http://git.reviewboard.kde.org/r/101520/diff > > > Testing > --- > > Tested using the master branch, running in a Xephyr session using gb,us and > se keyboard layouts. The tested layout needs to be the first entry in the > list of layouts in the keyboard layout switcher, otherwise it will not work. > Works for all the !"£$%^&*()_+ etc, no regression on shortcuts with only a > number, only a letter or shift+letter. Also no regression on alt+shift+tab or > ctrl+shift+esc. > > > Thanks, > > Simon > >
Re: Review Request: Fix meta+shift+tab and similar global shortcuts.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101523/#review4245 --- This review has been submitted with commit 6026c3a32056bdbae6964e25abf712870edf5aac by Simon Persson to branch master. - Commit On June 6, 2011, 11:24 a.m., Simon Persson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101523/ > --- > > (Updated June 6, 2011, 11:24 a.m.) > > > Review request for KDE Runtime and Michael Jansen. > > > Summary > --- > > When entering (ctrl,alt,meta+) shift+tab as a new shortcut KKeySequenceWidget > gets "backtab" as the key pressed but records "tab", because it looks/sounds > better I guess... When either of backtab or tab is used with shift as a > shortcut in an application Qt triggers the shortcut. kglobalaccel gets the > keypress event as "backtab" which is correct but only triggers shortcuts with > "backtab" in them and such shortcuts are not possible for the user to enter > using kshortcutseditor. > > This patch makes kglobalaccel look for both tab and backtab when triggered, > same as Qt does. > > KWin should possibly be patched to have alt+shift+tab as its default > shortcut, currently it has alt+shift+backtab (which is why it works even > without this patch...). That would solve the issue that currently a user can > enter alt+shift+tab as shortcut for something else and the conflict is not > detected. > > > This addresses bugs 174142, 258467, 261296, and 274006. > http://bugs.kde.org/show_bug.cgi?id=174142 > http://bugs.kde.org/show_bug.cgi?id=258467 > http://bugs.kde.org/show_bug.cgi?id=261296 > http://bugs.kde.org/show_bug.cgi?id=274006 > > > Diffs > - > > kglobalaccel/globalshortcutcontext.cpp fc2e6a6 > > Diff: http://git.reviewboard.kde.org/r/101523/diff > > > Testing > --- > > Tested using master branch, running in a Xephyr session. Switching between > plasma activities with meta+shift+tab now works. > > > Thanks, > > Simon > >
Re: Review Request: Export the function isShiftAsModifierAllowed() from KKeySequenceWidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101515/#review4242 --- This review has been submitted with commit a651984be97932adbe3e67fee2d7c6eff40b060f by Simon Persson to branch master. - Commit On June 6, 2011, 8:46 a.m., Simon Persson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101515/ > --- > > (Updated June 6, 2011, 8:46 a.m.) > > > Review request for kdelibs and Michael Jansen. > > > Summary > --- > > First of two patches to fix a set of bugs for global shortcuts involving > shift key. Not sure if this can go in 4.7 because of the freeze? It adds a > new function to the API for the sake of a bugfix. Prepared the following > commit message: > > Export the function isShiftAsModifierAllowed() > > This function inside KKeySequnceWidgetPrivate is needed by kglobalaccel, > export here rather than duplicating code and risk falling out of sync. > Also add Qt::Key_Backtab to the list, this is not needed internally > since there is a special case for Alt+Shift+Tab to not be recorded as > Alt+Backtab but other users of this function will need it. > > > This addresses bugs 179504, 197548 and 215030. > http://bugs.kde.org/show_bug.cgi?id=179504 > http://bugs.kde.org/show_bug.cgi?id=197548 > http://bugs.kde.org/show_bug.cgi?id=215030 > > > Diffs > - > > kdeui/widgets/kkeysequencewidget.h b9aafdc > kdeui/widgets/kkeysequencewidget.cpp a35c2b4 > > Diff: http://git.reviewboard.kde.org/r/101515/diff > > > Testing > --- > > > Thanks, > > Simon > >
Re: Review Request: Allow use of shift together with multimedia keys in shortcuts
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101530/#review4243 --- This review has been submitted with commit 4cee79c5e24bb40ad024ba520f4fce93ad7848d0 by Simon Persson to branch master. - Commit On June 7, 2011, 7:21 a.m., Simon Persson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101530/ > --- > > (Updated June 7, 2011, 7:21 a.m.) > > > Review request for kdelibs and Michael Jansen. > > > Summary > --- > > Make this beautiful piece of code even more beautiful! The proper fix would > be to add platform-specific functions to check if shift changes the symbol > produced when the key is pressed, but that will have to wait. > > > This addresses bug 184195. > http://bugs.kde.org/show_bug.cgi?id=184195 > > > Diffs > - > > kdeui/widgets/kkeysequencewidget.cpp a35c2b4 > > Diff: http://git.reviewboard.kde.org/r/101530/diff > > > Testing > --- > > Not tested. > > > Thanks, > > Simon > >
Re: Request: Inclusion of kio-upnp-ms to kde-runtime KIO slaves
Hi, too bad noone was up to push it finally into kde-runtime when it was ready for it, but let's pick it up again now: Mardi, le 26 avril 2011, à 14:53, Nikhil Marathe a écrit: > Hi, > > KDE SC 4.7 soft feature freeze is close, and I would like to propose > the UPnP MediaServer KIO slave > (https://projects.kde.org/projects/playground/base/kio-upnp-ms/) be > included into the set of kio slaves shipped with kde-runtime. The > slave was created as part of GSoC 2010 - Amarok and KDE UPnP support > and it was decided that it should be merged into kde-runtime at some > point. > > A couple of reasons I believe the slave is now ready for standard release > is: 1) HUpnp (http://herqq.org/news.html) - the Qt based UPnP library used > by the slave has a stable API and ABI with the release of 1.0.0 about 3 > weeks ago. > 2) The slave has been considerably simplified and single threaded, and > stable now. > 3) The slave is independent and can be conditionally compiled and > installed if HUpnp is installed. kdelibs already contains a > FindHUpnp.cmake to find the HUpnp library. > 4) The Solid UPnP backend (enabled in 4.7, again if HUpnp is found) > automatically launches UPnP media servers in the file manager with the > slave. 4b) And that Places integration of 4) will be useless if there is no upnp-ms kio-slave, people would click on the mediaserver icon but see nothing in the list 5) It is also used by Amarok since 2.4.0 (if found) 6) It adds no further dependencies than there are with kdelibs (i.e. HUpnp as optional library, if not found the kio-slave will be simply skipped). So UPnP support in Solid is aligned with kio-upnp-ms here. > My exams get over this week and I can ensure that krazy checks pass > and the code is cleaned up some more. But then Nikhil had his job life interfering, so could not spend any time on pushing this request forward :( I did a short code review, looked fine (could not comment on HUPnP usage, but who can besides Nikhil?), and some code optimization patches I did even got merged by Nikhil meanwhile. > There is inline documentation where required, and the search and > browse API documentation exists. There is no user > manual since it is a slave. I am confident about having it ready by > hard feature freeze. I also would consider it ready for first serious usage. After all it will enable all KIO-enabled programs to access the media content on UPnP media servers out there (e.g. Xbox), at least to a certain degree. So, release-team, what would you think about an exception to still include the upnp-ms kio-slave in kde-runtime 4.7? After all it was ready, just noone replied to him besides Kevin and me both saying "Keep it coming!". It does not affect any other code, as it is an isolated kio-slave. Might not even be compiled if some distro has not yet HUpnp packages. But if there are HUpnp packages the Places integration (Dolphin/filedialog) for UPnP media servers will be useless without this kio-slave. So distros would have to install this kio-slave anyway. So it might make sense to have the kio-slave already in kde-runtime, instead of extragear, where I would like to push it otherwise, so it can be released together with the SC 4.7 officially and distros know about this additional feature/kio-slave. If you say No (understandable): What is the process to make the playground/base repo of kio-upnp-ms an extragear/base repo in times of git repos? Could not find it documented on techbase, pointers welcome. And how would that repo be marked that it should be included in the SC 4.7 release process? If you say Yes (would be welcome): Tomorrow/Today evening (wednesday, 29 june) I would see to create a branch from kde-runtime master where the commit history of the kio-upnp-ms repo is merged (been there, done that), have that reviewed by someone and then backport that merge to 4.7 branch. Okay? Cheers Friedrich -- Desktop Summit 2011 in Berlin - Registered already? - www.desktopsummit.org
Re: Intended organization of KDE Frameworks
On Tuesday 28 Jun 2011 17:27:35 Aaron J. Seigo wrote: > On Monday, June 27, 2011 22:18:08 Ingo Klöcker wrote: > > > Localization is not only about user visible texts, It is also about > > > kconfig having per language keys, it is about kstandarddirs::locate > > > being able to find localized icons, etc. > > > > I hear you, but by the definition of Tier 1 none of this can be used in > > Tier 1 frameworks because "Tier 1 frameworks depend only on Qt itself > > and no other Qt based framework". > > other possibilities include: > > * approving a "tier 1 dep exception" for localization; this was discussed > at Platform 11 as possible, though probably not preferable to: > > * improving localization in Qt5 and merging in the best bits of KDE in this > regard there > > there is alread some work going on for his which started at Platform 11. i > don't know what the current status of it is and how many of the > localization bits will land in Qt5, but this would be, imho at least, the > best possible result. That would be me then :-) I'll have some emails for the list shortly on these subjects including the discussions at QtCS. In short, most of what we want looks likely to happen. However, its not all about the Locale stuff I'm doing, stuff like the KStandardDirs::locate is more about paths and platform plugins which guys like David are looking into. I'm not sure when a library would need Icons, but they will sometimes need Translation and Locale for error messages, and paths to grab other stuff. So yeah, a lot of this depends on getting stuff into Qt to work better with KDE as a supported Platform. John.
Re: Intended organization of KDE Frameworks
On Monday, June 27, 2011 22:18:08 Ingo Klöcker wrote: > > Localization is not only about user visible texts, It is also about > > kconfig having per language keys, it is about kstandarddirs::locate > > being able to find localized icons, etc. > > I hear you, but by the definition of Tier 1 none of this can be used in > Tier 1 frameworks because "Tier 1 frameworks depend only on Qt itself > and no other Qt based framework". other possibilities include: * approving a "tier 1 dep exception" for localization; this was discussed at Platform 11 as possible, though probably not preferable to: * improving localization in Qt5 and merging in the best bits of KDE in this regard there there is alread some work going on for his which started at Platform 11. i don't know what the current status of it is and how many of the localization bits will land in Qt5, but this would be, imho at least, the best possible result. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
