Re: Review Request: plasma_applet_folderview - folder previews on mouse hover
On Sept. 2, 2011, 7:05 a.m., Aaron J. Seigo wrote: just remove the context menu integration and the rest seems to work just fine. nice :) do you have a commit account, or do you need one of us to push it to master for you? yeah, the actionCollection is not necessary. Didn't know it was about context menu, though. No, I don't have a commit account here. - Greg --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102300/#review6230 --- On Sept. 1, 2011, 10:56 a.m., Greg T wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102300/ --- (Updated Sept. 1, 2011, 10:56 a.m.) Review request for KDE Base Apps and Plasma. Summary --- Hello, this is my attempt to resolve Bug 250703. The diff adds a gui option in the settings dialog which configures the click to view option. It was quite fun because most of the time I didn't know what I'm doing :) This addresses bug 250703. http://bugs.kde.org/show_bug.cgi?id=250703 Diffs - plasma/applets/folderview/folderview.h 35a0625 plasma/applets/folderview/folderview.cpp 6e95c40 plasma/applets/folderview/folderviewDisplayConfig.ui 961296d plasma/applets/folderview/iconview.h 4d736c5 Diff: http://git.reviewboard.kde.org/r/102300/diff Testing --- it compiles fine on kde 4.6.5 and does also work. Thanks, Greg
Re: Review Request: Add Configure Desktop Search button (to open Nepomuk KCM) into Nepomukcontroller Statuswidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102523/ --- (Updated Sept. 3, 2011, 4:22 p.m.) Review request for KDE Runtime and Nepomuk. Changes --- Added nepomuk to the review group. Summary --- This little patch adds a Configure Desktop Search button to the nepomukcontroller statuswidget (the little status dialog that appears if you left-click on the nepomuk tray icon). I know that you can access strigi configuration via the tray icon's context menu but I often found myself opening the status dialog and then wanting to get to the config dialog from there. Can't harm, can it? :) I also added a pause/resume icon to the suspend/resume button. Diffs - nepomuk/kcm/statuswidget.h 11f20b6 nepomuk/kcm/statuswidget.cpp f3074dd nepomuk/kcm/statuswidget.ui ab210c8 Diff: http://git.reviewboard.kde.org/r/102523/diff Testing --- Thanks, Kai Uwe
Re: Review Request: Set the properties action fom mainWindow actionCollection
On May 25, 2011, 10:31 a.m., Christoph Feck wrote: What is the status of this review? Has it been submitted? If yes, please close it. OMG, didn't got the email from the review :/! will look into this tomorrow and commit/close/whatever needs to be done. Sorry :/ - Alex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101076/#review3510 --- On April 10, 2011, 9:54 a.m., Alex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101076/ --- (Updated April 10, 2011, 9:54 a.m.) Review request for KDE Base Apps. Summary --- In order to have a proper kiosk support in dolphin we should use standard actions whether we can. Dolphin does it right but a few exceptions, this try to fix one of those. the properties action from items is made by getting it from the mainWindow::actionCollection but the properties action from openViewportContextMenu is custom, which bypasses kiosk. The patch simply replace the custom properties action and uses the mainWindow::actionCollection one. Diffs - dolphin/src/dolphincontextmenu.cpp 0aa82b2 Diff: http://git.reviewboard.kde.org/r/101076/diff Testing --- Compare the result of clicking on the Properties custom action and the standard one. Thanks, Alex
Review Request: systemsettings/fonts: DPI setting is X11-only
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102527/ --- Review request for KDE Base Apps, KDE Runtime and kdewin. Summary --- In systemsettings/fonts, the DPI setting affects only X11. Therefor, this setting should only be enabled when compiling on X11 (and not for compiling on MS Windows or other non-X11 window systems). Diffs - kcontrol/fonts/fonts.h 7f1c2d0 kcontrol/fonts/fonts.cpp 5a1728d Diff: http://git.reviewboard.kde.org/r/102527/diff Testing --- Tested on X11, adding an #undef Q_WS_X11 for testing purpose. Thanks, Lukas
Re: Re: Re: playground-libs/libkvkontakte has moved to kdereview
A Dissabte, 3 de setembre de 2011, Alexander Potashev vàreu escriure: 2011/9/2 Albert Astals Cid aa...@kde.org: Personally i prefer things not to be released from kdereview. Gilles Caulier (digiKam and KIPI-Plugins maintainer) told me that the tarball for KIPI-Plugins 2.1.0 will probably be created tomorrow. Therefore I hope to release libkvkontakte also tomorrow. Should now this library be moved to extragear/libs or playground/libs? Seems everyone was happy with review so move it to extragear? Anyway i prefer things not to be released from playground either (yes i know lots of people do it, that's why it is my personal opinion) so if you can not get it to be moved or prefer to stay in kdereview a bit more please do not let my personal opinion block you from doing a release. Albert -- Alexander Potashev
Re: Re: Re: playground-libs/libkvkontakte has moved to kdereview
2011/9/4 Albert Astals Cid aa...@kde.org: Seems everyone was happy with review so move it to extragear? Anyway i prefer things not to be released from playground either (yes i know lots of people do it, that's why it is my personal opinion) so if you can not get it to be moved or prefer to stay in kdereview a bit more please do not let my personal opinion block you from doing a release. I've already decided that libkvkontakte will be released (i.e. tarball-ed) today as part of digiKam SC, because otherwise we either need to remove the VKontakte export plugin from kipi-plugins or release libkvkontakte later in a separate tarball making life harder for packagers. -- Alexander Potashev
Re: Review Request: Change konqueror tabs look and feel
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102519/#review6263 --- Showing less text even when you have the space for it sounds like its not an improvement to me. - Thomas On Sept. 2, 2011, 10:51 a.m., Bellegarde Cédric wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102519/ --- (Updated Sept. 2, 2011, 10:51 a.m.) Review request for KDE Base Apps. Summary --- This patch change konqueror tabs behaviours with fixed size like in firefox, rekonq, ... Tabs size is fixed and text is adapted to this size. Diffs - konqueror/src/konqtabs.cpp d627fad Diff: http://git.reviewboard.kde.org/r/102519/diff Testing --- Screenshots --- Konqueror patched http://git.reviewboard.kde.org/r/102519/s/247/ Thanks, Bellegarde
Re: QML support in kde.org services
On Sun, Sep 4, 2011 at 2:18 PM, Stefan Majewsky stefan.majew...@googlemail.com wrote: 2. api.kde.org doesn't show QML elements. Problem with this is that Doxygen does not support QML (yet anyway), actually I would not know how to make this work in a sane manner considering that plenty of QML elements will be directly based of a CPP object... (in phonon we actually have the documentation in the cpp object which implements the element). So, doing this in a meaningful way would likely require using qdoc for QML element documentation.
Re: QML support in kde.org services
On Sunday 04 September 2011 8:18:30 AM Stefan Majewsky wrote: Hi, we have many server-side services which do not yet support QML: 3. ebn.kde.org doesn't search through QML files (e.g. for orthography issues). Krazy already checks QML files. Currently checks: license, copyright, spelling, iconnames, endswithnewline if there are more checks needed, we can discuss that.
Re: QML support in kde.org services
Harald Sitter wrote: On Sun, Sep 4, 2011 at 2:18 PM, Stefan Majewsky stefan.majew...@googlemail.com wrote: 2. api.kde.org doesn't show QML elements. Problem with this is that Doxygen does not support QML (yet anyway), actually I would not know how to make this work in a sane manner considering that plenty of QML elements will be directly based of a CPP object... (in phonon we actually have the documentation in the cpp object which implements the element). So, doing this in a meaningful way would likely require using qdoc for QML element documentation. I think that's something we should consider for kf5 anyway, for the same reason. qdoc is more free now than when doxygen was created, though it might not have all useful features of doxygen. Those might need to be added.
Re: Review Request: Set the properties action fom mainWindow actionCollection
On May 25, 2011, 10:31 a.m., Christoph Feck wrote: What is the status of this review? Has it been submitted? If yes, please close it. Alex Fiestas wrote: OMG, didn't got the email from the review :/! will look into this tomorrow and commit/close/whatever needs to be done. Sorry :/ I've marked it as submitted, the change is in KDE/4.7 dunno if I commit it or Peter did, anyway it is there. - Alex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101076/#review3510 --- On April 10, 2011, 9:54 a.m., Alex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101076/ --- (Updated April 10, 2011, 9:54 a.m.) Review request for KDE Base Apps. Summary --- In order to have a proper kiosk support in dolphin we should use standard actions whether we can. Dolphin does it right but a few exceptions, this try to fix one of those. the properties action from items is made by getting it from the mainWindow::actionCollection but the properties action from openViewportContextMenu is custom, which bypasses kiosk. The patch simply replace the custom properties action and uses the mainWindow::actionCollection one. Diffs - dolphin/src/dolphincontextmenu.cpp 0aa82b2 Diff: http://git.reviewboard.kde.org/r/101076/diff Testing --- Compare the result of clicking on the Properties custom action and the standard one. Thanks, Alex
Review Request: Fixed KHelpCenter Font Scaling (bug 243082)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102528/ --- Review request for KDE Runtime. Summary --- When user clicked a button to change font size the entire document was zoomed, instead of just the font size. This meant that the text would run past the right edge and user had to scroll horizontaly to read the whole line. After this patch only the font size changes. This addresses bug 243082. http://bugs.kde.org/show_bug.cgi?id=243082 Diffs - khelpcenter/mainwindow.h 6912e5a khelpcenter/mainwindow.cpp e7997b6 khelpcenter/view.h ea91128 khelpcenter/view.cpp 47b4713 Diff: http://git.reviewboard.kde.org/r/102528/diff Testing --- Clicking on the buttons to change font size now does the right thing. I changed the font size and restarted KHelpCenter and the fonsize is saved across restart. Thanks, Jure
Re: Review Request: Change konqueror tabs look and feel
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102519/#review6262 --- A quick search on b.k.o did not turn anything up, although I for one would immediately open one now that I know there isn't one. (Note that I != submitter.) konqueror/src/konqtabs.cpp http://git.reviewboard.kde.org/r/102519/#comment5504 As far as I can see, there is no provision for making the tabs smaller when there are many of them, like in Firefox and Rekonq. Bellegarde, I think it would be more appropriate to add this functionality to KTabBar, e.g. KTabBar::setUseUniformTabSize(bool), with the default being false for compatibility reasons. I'm a bit disappointed that an important point of the whole uniform tab size model is missing in this and also in the Rekonq implementation. In Firefox and Chrome, when there are many tabs, so the tab size is smaller than the default, and you close some of the tabs, the tab size is not adapted immediately, but only when the cursor leaves the tabbar. This is extremely useful because it allows to close multiple tabs at once by just clicking at the same spot again and again. Speaking of implementation, all you would have to add is calculating and applying an optimal tab size (something like qMin(200, tabBar.size() / tabBar.count())) in the leaveEvent (and when a new tab is added). If you could do that (in KTabBar), that would rock hard. - Stefan On Sept. 2, 2011, 10:51 a.m., Bellegarde Cédric wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102519/ --- (Updated Sept. 2, 2011, 10:51 a.m.) Review request for KDE Base Apps. Summary --- This patch change konqueror tabs behaviours with fixed size like in firefox, rekonq, ... Tabs size is fixed and text is adapted to this size. Diffs - konqueror/src/konqtabs.cpp d627fad Diff: http://git.reviewboard.kde.org/r/102519/diff Testing --- Screenshots --- Konqueror patched http://git.reviewboard.kde.org/r/102519/s/247/ Thanks, Bellegarde
Bro tip: gitk --first-parent
Hi, If you use gitk and are working in a git repo with lots of merges between branches, it can be overwhelming to see all the commits in branches which have been merged in (eg, the commits in the 4.7 and active branches when trying to look at the frameworks branch). The way to see commits that were actually made on the frameworks branch, and not commits that were merged in, is to use gitk --first-parent. It is documented in the git-log man page, because gitk accepts most standard git commands for dealing with refs. If you don't use gitk and don't understand git see: http://lostechies.com/joshuaflanagan/2010/09/03/use-gitk-to-understand-git/
Re: Bro tip: gitk --first-parent
Sent this too early. Meant to supply a link. Stephen Kelly wrote: Hi, If you use gitk and are working in a git repo with lots of merges between branches, it can be overwhelming to see all the commits in branches which have been merged in (eg, the commits in the 4.7 and active branches when trying to look at the frameworks branch). The way to see commits that were actually made on the frameworks branch, and not commits that were merged in, is to use gitk --first-parent. It is documented in the git-log man page, because gitk accepts most standard git commands for dealing with refs. http://www.kernel.org/pub/software/scm/git/docs/git-log.html If you don't use gitk and don't understand git see: http://lostechies.com/joshuaflanagan/2010/09/03/use-gitk-to-understand- git/ All the best, Steve.
