Javascript window.open Test

From adawit at kde.org Wed Jun 1 04:33:51 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Wed, 01 Jun 2011 03:33:51 -0000 Subject: Review Request: PATCH: Honor size and coordinates when creating new Konqueror windows In-Reply-To: <20110531174130.8839.38211@vidsolbach.de> References: <20110531174130.8839.38211@vidsolbach.de> Message-ID: <20110601033351.29280.2979@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101477/ ----------------------------------------------------------- (Updated June 1, 2011, 3:33 a.m.) Review request for KDE Base Apps and David Faure. Changes ------- Added a test case for anyone that wants to test the scenario outlined in the description section. Summary ------- Currently new window creation in KonqMainWindow::slotCreateNewWindow does not honor the supplied cooridnate and size information under certain circumstances. For example, if you click on a javascript link that opens a new window, then the new window will always be maximized, regardless of the size information supplied by the javascript window.open call, as long as the Konqueror window where you clicked on the link is also maximized. Even when the original window is not maximized, if you maximize and close the newly created window, then clicking on the javscript window.open link again will result in a maximized window. The attached patch addresses all of the above issues by making sure the coordinate and size information are always honored during new window creation. Diffs ----- konqueror/src/konqmainwindow.cpp 56aa379 Diff: http://git.reviewboard.kde.org/r/101477/diff Testing (updated) ------- Javascript window.open Test window.open test Test #1: ======= 1.) Copy the HTML snippet above into a file and open it with konqueror. 2.) Maximize the Konqueror window. 3.) Click on the link. 4.) Notice new window is opened maximized. Test #2: ======= 5.) Repeat steps 2-4 above, but do not maximize the Konqueror window in step 2. 6.) The new window opened when you clicked on the link should be of correct size. 7.) Maximize this new window, then close it. 8.) Click on the javascript link again. 9.) Notice how the new window is opened maximized. After applying the patch, none of the above test scenarios should be reproducible. Thanks, Dawit -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpwhiting at kde.org Wed Jun 1 04:55:59 2011 From: jpwhiting at kde.org (Jeremy Whiting) Date: Tue, 31 May 2011 21:55:59 -0600 Subject: QComboBox vs KConfigDialogManager Message-ID: Hey all, I wanted to document the source of a bug I just found the cause of and get some input on possible fixes. The bug I noticed was that using qt 4.8 konversation stopped showing timestamps in the chat window. After discussing with Eike I realized the TimestampFormat in my konversationrc was getting saved by KConfigXT as the Combobox currentIndex (0, 1, or 2) instead of the currentText ("hh:mm", etc.) So I spent some time debugging in KCoreConfigSkeleton and KConfigDialogManager and found that KConfigDialogManager::property gets the property to save by using the following algorithm. 1) Check if the widget has a kcfg_property is set on the widget. If so, use that property's value as the property to record. 2) Check if the widget has a User property to save (This was not set in QComboBox in 4.7 but is set in 4.8 to the currentIndex property) 3) Try casting to a combobox and use the current text if the combobox is editable, otherwise use the currentIndex Anyone here can guess where the problem lies? So the question is should the USER property in QComboBox be currentIndex, and if so should we: a) change all our .ui files KComboBox, QComboBox widgets to have kcfg_property set if we want to save the currentText as the value of the config item. b) change the algorithm in KConfigDialogManager somehow to do the right thing. thoughts, opinions, etc. all welcome Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << From aseigo at kde.org Wed Jun 1 06:13:43 2011 From: aseigo at kde.org (Aaron J. Seigo) Date: Wed, 01 Jun 2011 07:13:43 +0200 Subject: QComboBox vs KConfigDialogManager In-Reply-To: References: Message-ID: <1586127.duYccl2mLp@freedom> On Tuesday, May 31, 2011 21:55:59 Jeremy Whiting wrote: > 1) Check if the widget has a kcfg_property is set on the widget. If so, use > that property's value as the property to record. > 2) Check if the widget has a User property to save (This was not set in > QComboBox in 4.7 but is set in 4.8 to the currentIndex property) > 3) Try casting to a combobox and use the current text if the combobox is > editable, otherwise use the currentIndex > > Anyone here can guess where the problem lies? erf! > a) change all our .ui files KComboBox, QComboBox widgets to have > kcfg_property set if we want to save the currentText as the value of the > config item. this doesn't sound like a great solution since it means not only a lot of work and testing in our own repos (with a high risk of missing something), but it will affect all third parties as well (which we can't guarantee will notice or provide a fix on their own). a fix, even if it is a (well documented with comments ;) work-around, in KConfigDialogManager would probably be more valuable as a 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From argonel at gmail.com Wed Jun 1 06:42:13 2011 From: argonel at gmail.com (argonel) Date: Wed, 1 Jun 2011 01:42:13 -0400 Subject: kio/scheduler: Does not compile with Qt from 4.8 branch In-Reply-To: <201104260054.02447.ogoffart@kde.org> References: <201104241253.18252.christoph@maxiom.de> <201104241642.22987.christoph@maxiom.de> <3089208.rebBN4v6ZN@midna> <201104260054.02447.ogoffart@kde.org> Message-ID: On Mon, Apr 25, 2011 at 6:54 PM, Olivier Goffart wrote: > In this case, we have to see if we can fix it in Qt. I do not see any solution > on top of my head. We have to discuss if it is ok to break this use case if > there is no solution. The Qt documentation, about signals and slots[1] says this: "Since slots are normal member functions, they follow the normal C++ rules when called directly. However, as slots, they can be invoked by any component, regardless of its access level, via a signal-slot connection. This means that a signal emitted from an instance of an arbitrary class can cause a private slot to be invoked in an instance of an unrelated class." This makes a promise that any class can use a private slot without access checking. It doesn't say how that slot was declared, just that the private slot can be invoked by any other class. The change to Q_PRIVATE_SLOT introduces access checking of slots and breaks the promise, and so it needs to be left unchanged until Qt 5. Regards, Eli. [1] http://doc.qt.nokia.com/latest/signalsandslots.html#slots From j.maceachern at gmail.com Wed Jun 1 07:07:48 2011 From: j.maceachern at gmail.com (Jeffery MacEachern) Date: Wed, 01 Jun 2011 06:07:48 -0000 Subject: Review Request: Add Activity Awareness to KFilePlaces* Widget (OnlyInActivity) In-Reply-To: <20110513023009.3290.40184@vidsolbach.de> References: <20110513023009.3290.40184@vidsolbach.de> Message-ID: <20110601060748.1256.38266@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101348/ ----------------------------------------------------------- (Updated June 1, 2011, 6:07 a.m.) Review request for kdelibs, Ivan Čukić, Kevin Ottens, and David Faure. Summary ------- Adds an "Only show in this Activity" option to the KFilePlaces Widget and support in the underlying model code. Currently only "one activity"/"all activities" are supported as choices; I think this should be sufficient, and anything more complicated would be hard to make usable. Diffs ----- kfile/CMakeLists.txt ceae140 kfile/kfileplaceeditdialog.h d5b030a kfile/kfileplaceeditdialog.cpp d798b4d kfile/kfileplacesmodel.h b3dd821 kfile/kfileplacesmodel.cpp b037084 kfile/kfileplacesview.cpp 6a343b3 Diff: http://git.reviewboard.kde.org/r/101348/diff Testing ------- Tested on Project Neon/Kubuntu Natty. Created several activities, added Place bookmarks, set them to only show in the current activity, and switched activities. Everything worked as intended. EDIT: one small known issue - the OnlyInActivity setting doesn't take when the bookmark is first created; you have to hit Edit and re-check the box. Thanks, Jeffery -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantinos.smanis at gmail.com Wed Jun 1 08:38:42 2011 From: konstantinos.smanis at gmail.com (Konstantinos Smanis) Date: Wed, 1 Jun 2011 10:38:42 +0300 Subject: Review Request: kcm-grub2 In-Reply-To: References: Message-ID: On Thu, May 26, 2011 at 00:03, Konstantinos Smanis wrote: >> The following line should probably be simplified (see >> http://websvn.kde.org/?revision=1184860&view=revision): >> >> src/kcm_grub2.cpp:113: QTreeWidgetItem *item = new >> QTreeWidgetItem(ui.treeWidget_recover, QStringList(QString()) << name >> << partition->filePath() << volume->label() << volume->fsType() << >> i18n("%1 GiB", QString::number(volume->size() / 1073741824))); > > Thanks. Fixed: http://commits.kde.org/kcm-grub2/87eac2b1ef0b8f3a1907b86ab7054b99a0ed5ab9 > > Konstantinos If noone else objects, would it be possible for a sysadmin to make the move? Thanks, Konstantinos From thiago at kde.org Wed Jun 1 09:39:53 2011 From: thiago at kde.org (Thiago Macieira) Date: Wed, 01 Jun 2011 10:39:53 +0200 Subject: kio/scheduler: Does not compile with Qt from 4.8 branch In-Reply-To: References: <201104241253.18252.christoph@maxiom.de> <201104260054.02447.ogoffart@kde.org> Message-ID: <11474348.NSNn2TteeC@doriath> On Wednesday, 1 de June de 2011 01:42:13 argonel wrote: > This makes a promise that any class can use a private slot without > access checking. It doesn't say how that slot was declared, just that > the private slot can be invoked by any other class. The change to > Q_PRIVATE_SLOT introduces access checking of slots and breaks the > promise, and so it needs to be left unchanged until Qt 5. You're assuming you're allowed to use Q_PRIVATE_SLOT. That macro is not documented, so any use of it outside Qt is suspect by itself. Qt makes promise of source compatibility when using it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From familiarizedb at bk.ru Wed Jun 1 11:48:43 2011 From: familiarizedb at bk.ru (=?koi8-r?B?9sXO0SDi0sHHyc7B?=) Date: Wed, 1 Jun 2011 02:48:43 -0800 Subject: =?koi8-r?b?8NLPxMHAIMTPzSDOxcTP0s/HzyE=?= Message-ID: <20110601024843.q729oxxz931216@www.yandex.ru> Срочно продается кирпичный жилoй дoм(коттедж) 450 м кв..Ярославскoе шоcсе,14 км от МКAД. г Пушкино,мкр КЛЯЗЬМA. Гостинная с камином. Кухня столовая. 5 спален. Сауна,бассейн,тренажерный зал. Гараж на 2 места. Ухоженный лaндшафт. Все коммуникации. Гараж на 2 м/м. Рядом лес,река. тел: 898599O1469 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Kst mailing list Kst at kde.org https://mail.kde.org/mailman/listinfo/kst From jpwhiting at kde.org Wed Jun 1 15:47:26 2011 From: jpwhiting at kde.org (Jeremy Whiting) Date: Wed, 1 Jun 2011 08:47:26 -0600 Subject: kio/scheduler: Does not compile with Qt from 4.8 branch In-Reply-To: <11474348.NSNn2TteeC@doriath> References: <201104241253.18252.christoph@maxiom.de> <201104260054.02447.ogoffart@kde.org> <11474348.NSNn2TteeC@doriath> Message-ID: Until those that know the code get this issue sorted out, I've pasted a small workaround that gets it to build here: http://paste.kde.org/77059/ Jeremy On Wed, Jun 1, 2011 at 2:39 AM, Thiago Macieira wrote: > On Wednesday, 1 de June de 2011 01:42:13 argonel wrote: > > This makes a promise that any class can use a private slot without > > access checking. It doesn't say how that slot was declared, just that > > the private slot can be invoked by any other class. The change to > > Q_PRIVATE_SLOT introduces access checking of slots and breaks the > > promise, and so it needs to be left unchanged until Qt 5. > > You're assuming you're allowed to use Q_PRIVATE_SLOT. That macro is not > documented, so any use of it outside Qt is suspect by itself. Qt makes > promise > of source compatibility when using it. > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Senior Product Manager - Nokia, Qt Development Frameworks > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adawit at kde.org Wed Jun 1 18:25:11 2011 From: adawit at kde.org (Dawit A) Date: Wed, 1 Jun 2011 13:25:11 -0400 Subject: kio/scheduler: Does not compile with Qt from 4.8 branch In-Reply-To: References: <201104241253.18252.christoph@maxiom.de> <201104260054.02447.ogoffart@kde.org> <11474348.NSNn2TteeC@doriath> Message-ID: Isn't this problem easily solvable by changing those slots defined in Q_PRIVATE_SLOT to actual private slots of KIO::Scheduler and forwarding the call to the existing code ? See attached patch. On Wed, Jun 1, 2011 at 10:47 AM, Jeremy Whiting wrote: > Until those that know the code get this issue sorted out, I've pasted a > small workaround that gets it to build here: > http://paste.kde.org/77059/ > > Jeremy > > On Wed, Jun 1, 2011 at 2:39 AM, Thiago Macieira wrote: >> >> On Wednesday, 1 de June de 2011 01:42:13 argonel wrote: >> > This makes a promise that any class can use a private slot without >> > access checking. It doesn't say how that slot was declared, just that >> > the private slot can be invoked by any other class. The change to >> > Q_PRIVATE_SLOT introduces access checking of slots and breaks the >> > promise, and so it needs to be left unchanged until Qt 5. >> >> You're assuming you're allowed to use Q_PRIVATE_SLOT. That macro is not >> documented, so any use of it outside Qt is suspect by itself. Qt makes >> promise >> of source compatibility when using it. >> >> -- >> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >> Senior Product Manager - Nokia, Qt Development Frameworks >> PGP/GPG: 0x6EF45358; fingerprint: >> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: kio_scheduler.patch Type: application/octet-stream Size: 2957 bytes Desc: not available URL: From null at kde.org Wed Jun 1 19:49:01 2011 From: null at kde.org (Commit Hook) Date: Wed, 01 Jun 2011 18:49:01 -0000 Subject: Review Request: PATCH: When user selects 'Open With...', show the open with dialog In-Reply-To: <20110530155022.10424.3084@vidsolbach.de> References: <20110530155022.10424.3084@vidsolbach.de> Message-ID: <20110601184901.1208.48048@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101474/#review3618 ----------------------------------------------------------- This review has been submitted with commit e36179d6d9a34f2cbfdbc0b72348618dd468c1b5 by Dawit Alemayehu. - Commit On May 30, 2011, 3:50 p.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101474/ > ----------------------------------------------------------- > > (Updated May 30, 2011, 3:50 p.m.) > > > Review request for KDE Base Apps and David Faure. > > > Summary > ------- > > The attached patch fixes the following types of scenarios using Konqueror: > > 1.) Go to ftp://ftp.kde.org/pub/kde > 2.) Click on the README file > 3.) Choose "Open->Open With..." when prompted to select what app to open the document with. > > Without the patch, instead of getting the open with dialog the document is opened with the default application associated with that mime-type. > > > Diffs > ----- > > konqueror/src/konqmainwindow.cpp 321d407 > > Diff: http://git.reviewboard.kde.org/r/101474/diff > > > Testing > ------- > > > Thanks, > > Dawit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpwhiting at kde.org Wed Jun 1 20:29:36 2011 From: jpwhiting at kde.org (Jeremy Paul Whiting) Date: Wed, 01 Jun 2011 19:29:36 -0000 Subject: Review Request: Fix KComboBox KConfigXT bug when using qt 4.8 Message-ID: <20110601192936.3419.52432@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101486/ ----------------------------------------------------------- Review request for kdelibs and Eike Hein. Summary ------- QComboBox in qt 4.8 sets currentIndex as it's USER property. Which breaks kconfigxt saving of kcombobox values as the text inside them. I noticed this in konversation's timestampformat setting which was getting saved as 0, or 1 depending on the index of the combobox, rather than the text of the combobox. Diffs ----- kdeui/dialogs/kconfigdialogmanager.cpp 0209f49 Diff: http://git.reviewboard.kde.org/r/101486/diff Testing ------- This works here and shouldn't cause any problems even with qt 4.7 or so, just makes QComboBox special casing come before USER property checking rather than after. Thanks, Jeremy Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpwhiting at kde.org Wed Jun 1 20:31:34 2011 From: jpwhiting at kde.org (Jeremy Whiting) Date: Wed, 1 Jun 2011 13:31:34 -0600 Subject: QComboBox vs KConfigDialogManager In-Reply-To: <1586127.duYccl2mLp@freedom> References: <1586127.duYccl2mLp@freedom> Message-ID: On Tue, May 31, 2011 at 11:13 PM, Aaron J. Seigo wrote: > On Tuesday, May 31, 2011 21:55:59 Jeremy Whiting wrote: > > 1) Check if the widget has a kcfg_property is set on the widget. If so, > use > > that property's value as the property to record. > > 2) Check if the widget has a User property to save (This was not set in > > QComboBox in 4.7 but is set in 4.8 to the currentIndex property) > > 3) Try casting to a combobox and use the current text if the combobox is > > editable, otherwise use the currentIndex > > > > Anyone here can guess where the problem lies? > > erf! > > > a) change all our .ui files KComboBox, QComboBox widgets to have > > kcfg_property set if we want to save the currentText as the value of the > > config item. > > this doesn't sound like a great solution since it means not only a lot of > work > and testing in our own repos (with a high risk of missing something), but > it > will affect all third parties as well (which we can't guarantee will notice > or > provide a fix on their own). Indeed, I posted that more as an absurd solution than one I would recommend. > a fix, even if it is a (well documented with > comments ;) work-around, in KConfigDialogManager would probably be more > valuable as a result. > I just uploaded a diff to reviewboard that fixes the problem here. Let me know if it's ok to ship. Jeremy > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogoffart at bepointbe.be Wed Jun 1 20:02:20 2011 From: ogoffart at bepointbe.be (Olivier Goffart) Date: Wed, 1 Jun 2011 21:02:20 +0200 Subject: kio/scheduler: Does not compile with Qt from 4.8 branch In-Reply-To: References: <201104241253.18252.christoph@maxiom.de> Message-ID: <201106012102.21300.ogoffart@bepointbe.be> Le Wednesday 01 June 2011, Dawit A a écrit : > Isn't this problem easily solvable by changing those slots defined in > Q_PRIVATE_SLOT to actual private slots of KIO::Scheduler and > forwarding the call to the existing code ? See attached patch. there could also be a static private schedulerPrivate() function in KIO::Scheduler, and the Q_PRIVATE_SLOT uses that function. > > On Wed, Jun 1, 2011 at 10:47 AM, Jeremy Whiting wrote: > > Until those that know the code get this issue sorted out, I've pasted a > > small workaround that gets it to build here: > > http://paste.kde.org/77059/ > > > > Jeremy > > > > On Wed, Jun 1, 2011 at 2:39 AM, Thiago Macieira wrote: > >> On Wednesday, 1 de June de 2011 01:42:13 argonel wrote: > >> > This makes a promise that any class can use a private slot without > >> > access checking. It doesn't say how that slot was declared, just that > >> > the private slot can be invoked by any other class. The change to > >> > Q_PRIVATE_SLOT introduces access checking of slots and breaks the > >> > promise, and so it needs to be left unchanged until Qt 5. > >> > >> You're assuming you're allowed to use Q_PRIVATE_SLOT. That macro is not > >> documented, so any use of it outside Qt is suspect by itself. Qt makes > >> promise > >> of source compatibility when using it. > >> > >> -- > >> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > >> Senior Product Manager - Nokia, Qt Development Frameworks > >> PGP/GPG: 0x6EF45358; fingerprint: > >> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 From christoph at maxiom.de Wed Jun 1 21:44:24 2011 From: christoph at maxiom.de (Christoph Feck) Date: Wed, 01 Jun 2011 20:44:24 -0000 Subject: Review Request: Fix KComboBox KConfigXT bug when using qt 4.8 In-Reply-To: <20110601192936.3419.52432@vidsolbach.de> References: <20110601192936.3419.52432@vidsolbach.de> Message-ID: <20110601204424.6354.50651@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101486/#review3619 ----------------------------------------------------------- Ship it! Looks good, thanks. - Christoph On June 1, 2011, 7:29 p.m., Jeremy Paul Whiting wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101486/ > ----------------------------------------------------------- > > (Updated June 1, 2011, 7:29 p.m.) > > > Review request for kdelibs and Eike Hein. > > > Summary > ------- > > QComboBox in qt 4.8 sets currentIndex as it's USER property. Which breaks kconfigxt saving of kcombobox values as the text inside them. I noticed this in konversation's timestampformat setting which was getting saved as 0, or 1 depending on the index of the combobox, rather than the text of the combobox. > > > Diffs > ----- > > kdeui/dialogs/kconfigdialogmanager.cpp 0209f49 > > Diff: http://git.reviewboard.kde.org/r/101486/diff > > > Testing > ------- > > This works here and shouldn't cause any problems even with qt 4.7 or so, just makes QComboBox special casing come before USER property checking rather than after. > > > Thanks, > > Jeremy Paul > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Wed Jun 1 22:54:16 2011 From: null at kde.org (Commit Hook) Date: Wed, 01 Jun 2011 21:54:16 -0000 Subject: Review Request: Fix KComboBox KConfigXT bug when using qt 4.8 In-Reply-To: <20110601192936.3419.52432@vidsolbach.de> References: <20110601192936.3419.52432@vidsolbach.de> Message-ID: <20110601215416.9060.41073@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101486/#review3620 ----------------------------------------------------------- This review has been submitted with commit d44186bce4670d2985fb6aba8dba59bbd2c4c77a by Jeremy Whiting. - Commit On June 1, 2011, 7:29 p.m., Jeremy Paul Whiting wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101486/ > ----------------------------------------------------------- > > (Updated June 1, 2011, 7:29 p.m.) > > > Review request for kdelibs and Eike Hein. > > > Summary > ------- > > QComboBox in qt 4.8 sets currentIndex as it's USER property. Which breaks kconfigxt saving of kcombobox values as the text inside them. I noticed this in konversation's timestampformat setting which was getting saved as 0, or 1 depending on the index of the combobox, rather than the text of the combobox. > > > Diffs > ----- > > kdeui/dialogs/kconfigdialogmanager.cpp 0209f49 > > Diff: http://git.reviewboard.kde.org/r/101486/diff > > > Testing > ------- > > This works here and shouldn't cause any problems even with qt 4.7 or so, just makes QComboBox special casing come before USER property checking rather than after. > > > Thanks, > > Jeremy Paul > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mat69 at gmx.net Wed Jun 1 22:58:31 2011 From: mat69 at gmx.net (Matthias Fuchs) Date: Wed, 01 Jun 2011 21:58:31 -0000 Subject: Review Request: Keeps the selection after showing/hiding hidden files. Message-ID: <20110601215831.9720.52122@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101487/ ----------------------------------------------------------- Review request for KDE Base Apps, Peter Penz and Frank Reininghaus. Summary ------- Still only files that are shown will be selected, thus selecting hidden files and then hiding hidden files will deselect those. This addresses bug 177215. http://bugs.kde.org/show_bug.cgi?id=177215 Diffs ----- dolphin/src/views/dolphinview.cpp 4bc901b Diff: http://git.reviewboard.kde.org/r/101487/diff Testing ------- Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.penz19 at gmail.com Wed Jun 1 23:48:48 2011 From: peter.penz19 at gmail.com (Peter Penz) Date: Wed, 01 Jun 2011 22:48:48 -0000 Subject: Review Request: Keeps the selection after showing/hiding hidden files. In-Reply-To: <20110601215831.9720.52122@vidsolbach.de> References: <20110601215831.9720.52122@vidsolbach.de> Message-ID: <20110601224848.11585.81228@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101487/#review3621 ----------------------------------------------------------- Thanks for the patch. I just had a look and if I don't miss anything it should be sufficient to just add the line: m_selectedItems = selectedItems(); to DolphinView::setShowHiddenFiles(). I'm not really happy with how the selections are remembered in DolphinView in general: We have m_selectedItems to remember the selection when e.g. changing views and there is m_newFileNames for the usecase where the KFileItems are not available yet and only the new names are known. I'm currently working on a (let's say) "new view-engine" in Dolphin for 4.8 that should allow us to get rid of at least m_selectedItems but for 4.7 it would be great if we could get in this fix. Would it be possible that you check whether 'm_selectedItems = selectedItems();' is sufficient? I'm quite sure this should work but probably I'm missing something... Thanks :-) - Peter On June 1, 2011, 9:58 p.m., Matthias Fuchs wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101487/ > ----------------------------------------------------------- > > (Updated June 1, 2011, 9:58 p.m.) > > > Review request for KDE Base Apps, Peter Penz and Frank Reininghaus. > > > Summary > ------- > > Still only files that are shown will be selected, thus selecting hidden files and then hiding hidden files will deselect those. > > > This addresses bug 177215. > http://bugs.kde.org/show_bug.cgi?id=177215 > > > Diffs > ----- > > dolphin/src/views/dolphinview.cpp 4bc901b > > Diff: http://git.reviewboard.kde.org/r/101487/diff > > > Testing > ------- > > > Thanks, > > Matthias > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mat69 at gmx.net Wed Jun 1 23:56:37 2011 From: mat69 at gmx.net (Matthias Fuchs) Date: Wed, 01 Jun 2011 22:56:37 -0000 Subject: Review Request: Keeps the selection after showing/hiding hidden files. In-Reply-To: <20110601224848.11585.81228@vidsolbach.de> References: <20110601224848.11585.81228@vidsolbach.de> Message-ID: <20110601225637.11784.40929@vidsolbach.de> > On June 1, 2011, 10:48 p.m., Peter Penz wrote: > > Thanks for the patch. I just had a look and if I don't miss anything it should > > be sufficient to just add the line: > > m_selectedItems = selectedItems(); > > to DolphinView::setShowHiddenFiles(). > > > > I'm not really happy with how the selections are remembered in DolphinView in > > general: We have m_selectedItems to remember the selection when e.g. changing > > views and there is m_newFileNames for the usecase where the KFileItems are not > > available yet and only the new names are known. > > > > I'm currently working on a (let's say) "new view-engine" in Dolphin for 4.8 > > that should allow us to get rid of at least m_selectedItems but for 4.7 it > > would be great if we could get in this fix. > > > > Would it be possible that you check whether 'm_selectedItems = > > selectedItems();' is sufficient? I'm quite sure this should work but probably > > I'm missing something... Thanks :-) Indeed that works too and is a lot (!) nicer. :) Yeah the m_newFileNames is not really nice and can't handle multiple corner cases like kio operations that were paused in between e.g. because of existing files etc. - Matthias ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101487/#review3621 ----------------------------------------------------------- On June 1, 2011, 9:58 p.m., Matthias Fuchs wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101487/ > ----------------------------------------------------------- > > (Updated June 1, 2011, 9:58 p.m.) > > > Review request for KDE Base Apps, Peter Penz and Frank Reininghaus. > > > Summary > ------- > > Still only files that are shown will be selected, thus selecting hidden files and then hiding hidden files will deselect those. > > > This addresses bug 177215. > http://bugs.kde.org/show_bug.cgi?id=177215 > > > Diffs > ----- > > dolphin/src/views/dolphinview.cpp 4bc901b > > Diff: http://git.reviewboard.kde.org/r/101487/diff > > > Testing > ------- > > > Thanks, > > Matthias > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Thu Jun 2 00:00:21 2011 From: null at kde.org (Commit Hook) Date: Wed, 01 Jun 2011 23:00:21 -0000 Subject: Review Request: Keeps the selection after showing/hiding hidden files. In-Reply-To: <20110601215831.9720.52122@vidsolbach.de> References: <20110601215831.9720.52122@vidsolbach.de> Message-ID: <20110601230021.12394.32197@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101487/#review3623 ----------------------------------------------------------- This review has been submitted with commit 7993626ee89a7924d55d0c6f8455438459f1de88 by Matthias Fuchs. - Commit On June 1, 2011, 9:58 p.m., Matthias Fuchs wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101487/ > ----------------------------------------------------------- > > (Updated June 1, 2011, 9:58 p.m.) > > > Review request for KDE Base Apps, Peter Penz and Frank Reininghaus. > > > Summary > ------- > > Still only files that are shown will be selected, thus selecting hidden files and then hiding hidden files will deselect those. > > > This addresses bug 177215. > http://bugs.kde.org/show_bug.cgi?id=177215 > > > Diffs > ----- > > dolphin/src/views/dolphinview.cpp 4bc901b > > Diff: http://git.reviewboard.kde.org/r/101487/diff > > > Testing > ------- > > > Thanks, > > Matthias > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Thu Jun 2 00:01:42 2011 From: null at kde.org (Commit Hook) Date: Wed, 01 Jun 2011 23:01:42 -0000 Subject: Review Request: Keeps the selection after showing/hiding hidden files. In-Reply-To: <20110601215831.9720.52122@vidsolbach.de> References: <20110601215831.9720.52122@vidsolbach.de> Message-ID: <20110601230142.12626.27082@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101487/#review3624 ----------------------------------------------------------- This review has been submitted with commit 154e601205d0137b02db45b9f18d8a4f1fdfec35 by Matthias Fuchs. - Commit On June 1, 2011, 9:58 p.m., Matthias Fuchs wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101487/ > ----------------------------------------------------------- > > (Updated June 1, 2011, 9:58 p.m.) > > > Review request for KDE Base Apps, Peter Penz and Frank Reininghaus. > > > Summary > ------- > > Still only files that are shown will be selected, thus selecting hidden files and then hiding hidden files will deselect those. > > > This addresses bug 177215. > http://bugs.kde.org/show_bug.cgi?id=177215 > > > Diffs > ----- > > dolphin/src/views/dolphinview.cpp 4bc901b > > Diff: http://git.reviewboard.kde.org/r/101487/diff > > > Testing > ------- > > > Thanks, > > Matthias > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sommerluk at gmail.com Wed Jun 1 11:04:42 2011 From: sommerluk at gmail.com (Lukas Sommer) Date: Wed, 01 Jun 2011 10:04:42 -0000 Subject: Review Request: startkde.cmake should treat font dpi like kcontrol/krdb/krdb.cpp does In-Reply-To: <20110522094853.15361.4384@vidsolbach.de> References: <20110522094853.15361.4384@vidsolbach.de> Message-ID: <20110601100442.11405.40672@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101410/ ----------------------------------------------------------- (Updated June 1, 2011, 10:04 a.m.) Review request for KDE Base Apps, KDE Runtime and kdelibs. Changes ------- Updated diff. The new diff includes the corresponding changes for the GUI, with the following characteristicas: - Default is not forcing any DPI value - If the user wants, he can choose dpi values from 1 dpi up to 1000 dpi. (This is a little bit arbitrary. However, QSpinBox's default maximum value is 99, and this would not be sufficient.) - Each step in the spinbox are 24 dpi, because the common covenience values 72, 96 and 120 are multiples of 24. Going in steps of 24 maybe makes fonts look better. However, the user can choose manually any value ... - I've notices that the DPI setting is also available on MS Windows, but hasn't any effect there because Xft isn't available. Maybe this field should not build on Windows? (Some #ifdef ...?) - There is no "live preview" of the dpi value for the fonts. Maybe this should be done in a seperate patch? Summary ------- I've been experimenting a little bit with custom font dpi sizes in $HOME/.kde4/share/config/kcmfonts There, you can set custom font dpi value. Although the user interface (systemsettings/fonts) only provides 0 (don't force a dpi, use the system default instead), 96 and 120 as choice, in the config file you can put (manually) arbitrary values. This works mostly fine because kcontrol/krdb/krdb.cpp simply processes the dpi value of the config file "as is". However, startkde.cmake doesn't. It checks if the value is 96 or 120. If not, the value is ignored and the system default is used. Result: When you use e.g. 200 as dpi value and restart KDE, then KWin uses the default value (96 dpi on my system) for the window title, while the applications themself are displayed using 200 dpi. So the applications fonts are as big as desired, but the window title is too small. See the attached screenshot. This behaviour is inconsistent. startkde.cmake should follow the same police as kcontrol/krdb/krdb.cpp does. This patch fixes this. (The user interface could be adopted in another patch.) (Make this work would benefit people who need a high display resolution. Example: You connect your computer to your plasma tv and you want to be still be able to read the text although you are at a distance of 5 meters from the tv monitor. See also bug 272266) Diffs (updated) ----- kcontrol/fonts/fonts.h 2c722d4 kcontrol/fonts/fonts.cpp 0cd2666 startkde.cmake dde9c23 Diff: http://git.reviewboard.kde.org/r/101410/diff Testing ------- I've applied the patch to my local /usr/bin/startkde file, and it works fine. Screenshots ----------- http://git.reviewboard.kde.org/r/101410/s/171/ Thanks, Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From sommerluk at gmail.com Wed Jun 1 11:54:44 2011 From: sommerluk at gmail.com (Lukas Sommer) Date: Wed, 01 Jun 2011 10:54:44 -0000 Subject: Review Request: startkde.cmake should treat font dpi like kcontrol/krdb/krdb.cpp does In-Reply-To: <20110601100442.11405.40672@vidsolbach.de> References: <20110601100442.11405.40672@vidsolbach.de> Message-ID: <20110601105444.14082.3103@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101410/ ----------------------------------------------------------- (Updated June 1, 2011, 10:54 a.m.) Review request for KDE Base Apps, KDE Runtime and kdelibs. Summary ------- I've been experimenting a little bit with custom font dpi sizes in $HOME/.kde4/share/config/kcmfonts There, you can set custom font dpi value. Although the user interface (systemsettings/fonts) only provides 0 (don't force a dpi, use the system default instead), 96 and 120 as choice, in the config file you can put (manually) arbitrary values. This works mostly fine because kcontrol/krdb/krdb.cpp simply processes the dpi value of the config file "as is". However, startkde.cmake doesn't. It checks if the value is 96 or 120. If not, the value is ignored and the system default is used. Result: When you use e.g. 200 as dpi value and restart KDE, then KWin uses the default value (96 dpi on my system) for the window title, while the applications themself are displayed using 200 dpi. So the applications fonts are as big as desired, but the window title is too small. See the attached screenshot. This behaviour is inconsistent. startkde.cmake should follow the same police as kcontrol/krdb/krdb.cpp does. This patch fixes this. (The user interface could be adopted in another patch.) (Make this work would benefit people who need a high display resolution. Example: You connect your computer to your plasma tv and you want to be still be able to read the text although you are at a distance of 5 meters from the tv monitor. See also bug 272266) This addresses bug 190489. http://bugs.kde.org/show_bug.cgi?id=190489 Diffs ----- kcontrol/fonts/fonts.h 2c722d4 kcontrol/fonts/fonts.cpp 0cd2666 startkde.cmake dde9c23 Diff: http://git.reviewboard.kde.org/r/101410/diff Testing ------- I've applied the patch to my local /usr/bin/startkde file, and it works fine. Screenshots ----------- http://git.reviewboard.kde.org/r/101410/s/171/ Thanks, Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.chvatal at gmail.com Wed Jun 1 12:10:50 2011 From: tomas.chvatal at gmail.com (=?utf-8?b?VG9tw6HFoSBDaHbDoXRhbA==?=) Date: Wed, 01 Jun 2011 11:10:50 -0000 Subject: Review Request: Preffer new hunspell library over the old one in the finder Message-ID: <20110601111050.15748.46226@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101484/ ----------------------------------------------------------- Review request for kdelibs. Summary ------- When using FindHUNSPELL on system where both hunspell-1.2 and hunspell-1.3 are around the old version is preffered by the finder. This patch reverts the logic so the later is preffered. Diffs ----- cmake/modules/FindHUNSPELL.cmake 9ed944f Diff: http://git.reviewboard.kde.org/r/101484/diff Testing ------- Thanks, Tomáš -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.friedrichsmeier at ruhr-uni-bochum.de Thu Jun 2 09:38:15 2011 From: thomas.friedrichsmeier at ruhr-uni-bochum.de (Thomas Friedrichsmeier) Date: Thu, 02 Jun 2011 08:38:15 -0000 Subject: Review Request: Fix keypress stealing issue Message-ID: <20110602083815.1231.65203@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101491/ ----------------------------------------------------------- Review request for kdelibs and David Faure. Summary ------- Shortcut context was not set correctly for the new "Find Text as You Type" action, which can result in the khtmlpart "stealing" '/'-keypresses from other widgets in the same main window. This patch would fix that in the most straight-forward fashion. However: a) I do wonder, why this is not simply set for *all* applicable actions (including those which do not have a shortcut set by default, but might have a user-configured shortcut!). I.e. something like foreach (QAction *action, actionCollection()->actions()) { action->setShortcutContext(Qt::WidgetWithChildrenShortcut); } But perhaps I am overlooking something? b) This is sort of OT, but I could not help wondering: I was pretty confused about the difference between Find... and Find Text as You Type. Since Find... really is find-as-you-type, too. Before I finally gathered it from the sources. May I suggest condensing the three actions - Find... - Find Text as You Type - Find Links as You Type to two actions - Find Text (with default shortcuts Ctrl+F *and* '/') - Find Links Regards Thomas Diffs ----- khtml/khtml_part.cpp ec89b0c8083989afb52ebde714e1fe757ab2e387 Diff: http://git.reviewboard.kde.org/r/101491/diff Testing ------- Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph at maxiom.de Thu Jun 2 09:51:25 2011 From: christoph at maxiom.de (Christoph Feck) Date: Thu, 02 Jun 2011 08:51:25 -0000 Subject: Review Request: Preffer new hunspell library over the old one in the finder In-Reply-To: <20110601111050.15748.46226@vidsolbach.de> References: <20110601111050.15748.46226@vidsolbach.de> Message-ID: <20110602085125.2029.16882@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101484/#review3626 ----------------------------------------------------------- Ship it! HUNSPELL is the only optional dependency that is missing from my kdelibs build, so I cannot test, but if you say it works better this way, please commit :) - Christoph On June 1, 2011, 11:10 a.m., Tomáš Chvátal wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101484/ > ----------------------------------------------------------- > > (Updated June 1, 2011, 11:10 a.m.) > > > Review request for kdelibs. > > > Summary > ------- > > When using FindHUNSPELL on system where both hunspell-1.2 and hunspell-1.3 are around the old version is preffered by the finder. > > This patch reverts the logic so the later is preffered. > > > Diffs > ----- > > cmake/modules/FindHUNSPELL.cmake 9ed944f > > Diff: http://git.reviewboard.kde.org/r/101484/diff > > > Testing > ------- > > > Thanks, > > Tomáš > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at kamago.net Thu Jun 2 13:03:58 2011 From: greg at kamago.net (=?utf-8?q?Gr=C3=A9gory_Oestreicher?=) Date: Thu, 02 Jun 2011 12:03:58 -0000 Subject: Review Request: Fix auth warnings when authentication is legitimate Message-ID: <20110602120358.12852.64148@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101493/ ----------------------------------------------------------- Review request for kdelibs and Dawit Alemayehu. Summary ------- Commit 3bbd4496bc introduced spurious warnings when auth info was added to HTTP request and authentication succeeded as the response code will never be 401 or 407 in that case. This patch takes into account the previous response code when deciding if a warning should be issued. Diffs ----- kioslave/http/http.cpp b4d3c65 Diff: http://git.reviewboard.kde.org/r/101493/diff Testing ------- Tested that the expected behaviour is still wanted, and that successful authentication attempts did not result in warnings. Thanks, Grégory -------------- next part -------------- An HTML attachment was scrubbed... URL: From adawit at kde.org Thu Jun 2 13:52:42 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Thu, 02 Jun 2011 12:52:42 -0000 Subject: Review Request: Fix auth warnings when authentication is legitimate In-Reply-To: <20110602120358.12852.64148@vidsolbach.de> References: <20110602120358.12852.64148@vidsolbach.de> Message-ID: <20110602125242.14900.73390@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101493/#review3628 ----------------------------------------------------------- Ship it! Good catch. - Dawit On June 2, 2011, 12:03 p.m., Grégory Oestreicher wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101493/ > ----------------------------------------------------------- > > (Updated June 2, 2011, 12:03 p.m.) > > > Review request for kdelibs and Dawit Alemayehu. > > > Summary > ------- > > Commit 3bbd4496bc introduced spurious warnings when auth info was added to HTTP request and authentication succeeded as the response code will never be 401 or 407 in that case. > > This patch takes into account the previous response code when deciding if a warning should be issued. > > > Diffs > ----- > > kioslave/http/http.cpp b4d3c65 > > Diff: http://git.reviewboard.kde.org/r/101493/diff > > > Testing > ------- > > Tested that the expected behaviour is still wanted, and that successful authentication attempts did not result in warnings. > > > Thanks, > > Grégory > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Thu Jun 2 13:55:18 2011 From: null at kde.org (Commit Hook) Date: Thu, 02 Jun 2011 12:55:18 -0000 Subject: Review Request: Fix auth warnings when authentication is legitimate In-Reply-To: <20110602120358.12852.64148@vidsolbach.de> References: <20110602120358.12852.64148@vidsolbach.de> Message-ID: <20110602125518.15029.68959@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101493/#review3629 ----------------------------------------------------------- This review has been submitted with commit 53730995400665b24be3186c7c475980d0e8cd79 by Gregory Oestreicher. - Commit On June 2, 2011, 12:03 p.m., Grégory Oestreicher wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101493/ > ----------------------------------------------------------- > > (Updated June 2, 2011, 12:03 p.m.) > > > Review request for kdelibs and Dawit Alemayehu. > > > Summary > ------- > > Commit 3bbd4496bc introduced spurious warnings when auth info was added to HTTP request and authentication succeeded as the response code will never be 401 or 407 in that case. > > This patch takes into account the previous response code when deciding if a warning should be issued. > > > Diffs > ----- > > kioslave/http/http.cpp b4d3c65 > > Diff: http://git.reviewboard.kde.org/r/101493/diff > > > Testing > ------- > > Tested that the expected behaviour is still wanted, and that successful authentication attempts did not result in warnings. > > > Thanks, > > Grégory > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at opensource.sf-tec.de Thu Jun 2 21:09:22 2011 From: kde at opensource.sf-tec.de (Rolf Eike Beer) Date: Thu, 02 Jun 2011 20:09:22 -0000 Subject: Review Request: Update KActionCollection member documentation Message-ID: <20110602200922.5596.15018@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101494/ ----------------------------------------------------------- Review request for kdelibs. Summary ------- KActionCollection is missing parameter documention on some members. And one has even a bogus one. Diffs ----- kdeui/actions/kactioncollection.h 076088b Diff: http://git.reviewboard.kde.org/r/101494/diff Testing ------- Thanks, Rolf Eike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mat69 at gmx.net Thu Jun 2 21:53:55 2011 From: mat69 at gmx.net (Matthias Fuchs) Date: Thu, 2 Jun 2011 22:53:55 +0200 Subject: Creating a public pixmap overlays method based on icon overlays? Message-ID: <201106022253.55966.mat69@gmx.net> Hi, I was looking at BUG:190579 [1] and realised that there is a general problem in KDE that does not only apply to folders: As soon as you have preview enabled you won't get any more icon overlays for images, no matter if you look at images directly or at folders containing images (the later most likely because the previews are pointed over the overlay). So I thought what should be done is to also display overlays for previews. Yet the overlay method only applies to icons at the moment. [2] The code that is used [3] can be easily adpated to pixmaps not having the same width and height. [4] I even tried it and it looks good enough in my opinion. Now I need your feedback: Should a more general method like that be added? Should that method be used for previews and also KIconLoader? And where should such a method be placed, I mean in which header? Cheers, matthias [1] https://bugs.kde.org/show_bug.cgi?id=190579 [2] KIcon (const QString &iconName, KIconLoader *iconLoader, const QStringList &overlays) and KIconLoader::loadIcon [3] KIconLoaderPrivate::drawOverlays at kiconloader.cpp:357 [4] something like: const int height = pix.size().height(); const int width = pix.size().width(); const int iconSize = qMin(width, height); ... and then using height/width instead of iconSize for the x/y values of the following QPoints. From kubito at gmail.com Fri Jun 3 00:16:28 2011 From: kubito at gmail.com (Raphael Kubo da Costa) Date: Thu, 02 Jun 2011 20:16:28 -0300 Subject: Review Request: kcm-grub2 In-Reply-To: (Konstantinos Smanis's message of "Wed, 1 Jun 2011 10:38:42 +0300") References:

Message-ID: <871uzb9643.fsf@gmail.com> Konstantinos Smanis writes: > On Thu, May 26, 2011 at 00:03, Konstantinos Smanis > wrote: >>> The following line should probably be simplified (see >>> http://websvn.kde.org/?revision=1184860&view=revision): >>> >>> src/kcm_grub2.cpp:113: QTreeWidgetItem *item = new >>> QTreeWidgetItem(ui.treeWidget_recover, QStringList(QString()) << name >>> << partition->filePath() << volume->label() << volume->fsType() << >>> i18n("%1 GiB", QString::number(volume->size() / 1073741824))); >> >> Thanks. Fixed: http://commits.kde.org/kcm-grub2/87eac2b1ef0b8f3a1907b86ab7054b99a0ed5ab9 >> >> Konstantinos > > If noone else objects, would it be possible for a sysadmin to make the move? This is not really an objection, as I have not looked at the code. But having two different projects with practically identical names (kcm_grub2 and kcmgrub2) is quite confusing. It'd be nice if this could be worked out, as both projects have actually asked for review and to be moved to the same final destination (extragear/sysadmin). From nsm.nikhil at gmail.com Thu Jun 2 23:07:49 2011 From: nsm.nikhil at gmail.com (Nikhil Marathe) Date: Thu, 2 Jun 2011 15:07:49 -0700 Subject: Request: Inclusion of kio-upnp-ms to kde-runtime KIO slaves In-Reply-To: <201106022339.08364.kossebau@kde.org> References: <201105221349.28245.kossebau@kde.org> <201106022339.08364.kossebau@kde.org> Message-ID: On Thu, Jun 2, 2011 at 2:39 PM, Friedrich W. H. Kossebau wrote: > Hi, > > (all follow-ups only to kde-core-devel please, copying also amarok-devel this > time to get your attention and comments, amarokers) > > guess you are still heavily occupied by more important things, Nikhil :) > Still I think it would be good to have the upnp-ms kio-slave as part of the > SC 4.7 release, for now in extragear, not kde-runtime, given the state in the > release cycle (can move to kde-runtime for 4.8). > If you can share a minute please tell if you are okay with me pushing to get > your kio-slave into extragear, so it still can be officially part of SC 4.7 > Yes sorry about that. I'm starting to discover that giving time for FOSS after coding for 7-8 hours on other FOSS (Mozilla) is hard :) Yes, the slave does not need major changes anymore, and I would not mind a push to extragear. > > @Amarok people: So since 2.4.0 Amarok makes use of the upnp-ms kio-slave, > right? Can you tell which distros already ship it? > And do you make use of that kio-slave's upnptypes.h, which has been renamed to > upnp-ms-types.h now? How is integration exactly done, what are the > dependencies, how do you detect the kio-slave? So that code was written by me too. The amarok code ships its own copy of upnptypes.h which is called upnptypes.h. There are no external compile time dependencies, the UPnP collection is always compiled. At runtime, it simply tries to load a upnp-ms:// URL for every device that Cagibi reports. If it fails, no collection is added. > >> From what grep tells me, there are only three strings to be translated (and >> some more in the tests, but I do think you can/should remove i18n from >> there, testers usually don't need/want translated strings), and only for >> errors, so translators (and users) might be okay with an exception here. >> >> > > Just pushed a branch "codeOptimization" with my proposals for those > optimization. If you find time, please give it a review and comment on it or > merge it to master, Nikhil :) > Adding the FindHUpnp.cmake is needed, as kdelibs does not install them, so > kio-upnp-ms needs a copy. Thanks for the changes, I'll take a look. Regards, Nikhil From kubito at gmail.com Thu Jun 2 23:55:13 2011 From: kubito at gmail.com (Raphael Kubo da Costa) Date: Thu, 02 Jun 2011 22:55:13 -0000 Subject: Review Request: Update KActionCollection member documentation In-Reply-To: <20110602200922.5596.15018@vidsolbach.de> References: <20110602200922.5596.15018@vidsolbach.de> Message-ID: <20110602225513.11993.64598@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101494/#review3646 ----------------------------------------------------------- Ship it! Looks OK, the new apidox even looks similar to its counterpart in kstandardaction.h. - Raphael On June 2, 2011, 8:09 p.m., Rolf Eike Beer wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101494/ > ----------------------------------------------------------- > > (Updated June 2, 2011, 8:09 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > KActionCollection is missing parameter documention on some members. And one has even a bogus one. > > > Diffs > ----- > > kdeui/actions/kactioncollection.h 076088b > > Diff: http://git.reviewboard.kde.org/r/101494/diff > > > Testing > ------- > > > Thanks, > > Rolf Eike > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kossebau at kde.org Thu Jun 2 22:39:07 2011 From: kossebau at kde.org (Friedrich W. H. Kossebau) Date: Thu, 2 Jun 2011 23:39:07 +0200 Subject: Request: Inclusion of kio-upnp-ms to kde-runtime KIO slaves In-Reply-To: <201105221349.28245.kossebau@kde.org> References: <201105221349.28245.kossebau@kde.org> Message-ID: <201106022339.08364.kossebau@kde.org> Hi, (all follow-ups only to kde-core-devel please, copying also amarok-devel this time to get your attention and comments, amarokers) guess you are still heavily occupied by more important things, Nikhil :) Still I think it would be good to have the upnp-ms kio-slave as part of the SC 4.7 release, for now in extragear, not kde-runtime, given the state in the release cycle (can move to kde-runtime for 4.8). If you can share a minute please tell if you are okay with me pushing to get your kio-slave into extragear, so it still can be officially part of SC 4.7 @Amarok people, please see below for a question to you. Dimanche, le 22 mai 2011, à 13:49, Friedrich W. H. Kossebau a écrit: > Hi Nikhil, > > Jeudi, le 12. mai 2011, à 01:38, Nikhil Marathe a écrit: > > On Wed, May 11, 2011 at 4:04 PM, Friedrich W. H. Kossebau > > > > wrote: > > > Hi Nikhil, > > > > > > you know that today, April 12th, is already Hard Feature Freeze?! Would > > > be really sad if your upnp-ms kio-slave misses the deadline now! > > > > Hi Fredrik, > > I have been moving halfway across the world the last 4-5 days and so I > > couldn't really do anything. > > For starting on a job, I guess? So congrats for that, wish you much joy! :) > > > I am at work, and don't have access to my laptop right now, but I'll > > ensure your changes are in by tonight. > > Aren't there circumstances under which certain features get some > > leeway in being merged even after hard feature > > freeze due to exceptional reasons? Any chance we can do this for the > > slave, since the code itself has been pretty > > well tested already. > > I would think there is a chance, if you can list the reasons: > Do you know of distris which have the upnp-ms kio-slave in use? > Which versions of Amarok make use of it/depend on it? > And what ever else you think makes the release-team and others confident > the inclusion now will be still okay and worth an exception. @Amarok people: So since 2.4.0 Amarok makes use of the upnp-ms kio-slave, right? Can you tell which distros already ship it? And do you make use of that kio-slave's upnptypes.h, which has been renamed to upnp-ms-types.h now? How is integration exactly done, what are the dependencies, how do you detect the kio-slave? > From what grep tells me, there are only three strings to be translated (and > some more in the tests, but I do think you can/should remove i18n from > there, testers usually don't need/want translated strings), and only for > errors, so translators (and users) might be okay with an exception here. > > Just pushed a branch "codeOptimization" with my proposals for those optimization. If you find time, please give it a review and comment on it or merge it to master, Nikhil :) Adding the FindHUpnp.cmake is needed, as kdelibs does not install them, so kio-upnp-ms needs a copy. > > >> If there is no objection I would like to request a merge into > > >> kde-runtime. I will edit the 4.7 feature plan for the same. > > > > > > I would think this is already a request ;) But if there is not enough > > > time now and others would like to do their own review before it gets > > > into kde-runtime, as there has not been an official merge request yet > > > via > > > https://git.reviewboard.kde.org, let's at least do the trick to still > > > be part of the next release wave by "upgrading" the repo from > > > playground to Extragear/Base as fast as possible. > > > > Do you mean I should abandon the inclusion in 4.7 and instead aim for > > 4.8? I really think this should go in 4.7. > > So do I, and surely do Kevin and the metalworkers (because e.g. the Places > integration would be useless otherwise). But you must push for it yourself, > you are the maintainer. Or ask somebody else to do that in-place for you if > life currently has swamped you with even more important tasks :) I would be > willing to do so, if you want. Cheers Friedrich -- Desktop Summit 2011 in Berlin - Registered already? - www.desktopsummit.org From urban.widmark at gmail.com Thu Jun 2 12:08:59 2011 From: urban.widmark at gmail.com (Urban Widmark) Date: Thu, 02 Jun 2011 11:08:59 -0000 Subject: Review Request: KMainWindow::parseGeometry() fails to position with positive coordinates Message-ID: <20110602110859.9521.71405@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101492/ ----------------------------------------------------------- Review request for kdelibs. Summary ------- When an X geometry is given on the command line, parseGeometry() will, for positive positions, use geometry().x()/.y() instead of the x/y value parsed from the string. This causes positive positions to not work. For negative values the string values are used. No direct bugs reported on this that I can find, but the odd position behavior is noted in some --geometry related bugs: Comment #6, http://bugs.kde.org/show_bug.cgi?id=165355 http://bugs.kde.org/show_bug.cgi?id=230663 For the KMainWindow --geometry parsing to work for both size and position, the client application will have to call applyMainWindowSettings() or restoreWindowSize(). The parsing done by KMainWindowPrivate::init() will only set position. Not sure if that is good, as a user of the window I would expect it to use all of the --geometry data at the same time (either on creation or some later call). Diffs ----- kdeui/widgets/kmainwindow.cpp 1d27722 Diff: http://git.reviewboard.kde.org/r/101492/diff Testing ------- Using a KApplication program with a KMainWindow that also calls applyMainWindowSettings (keditbookmarks), positions verified using xwininfo: keditbookmarks --geometry 400x300+100+200 keditbookmarks --geometry 400x300-100+200 keditbookmarks --geometry 400x300+100-200 keditbookmarks --geometry 400x300-100+200 keditbookmarks --geometry 400x300 keditbookmarks --geometry +100+200 Without patch all +coords are replaced by 0. Negative positions do not account for window decorations as the size of those are not known. I suspect the user will have to adjust for that in their input. Thanks, Urban -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.chvatal at gmail.com Thu Jun 2 17:29:09 2011 From: tomas.chvatal at gmail.com (=?utf-8?b?VG9tw6HFoSBDaHbDoXRhbA==?=) Date: Thu, 02 Jun 2011 16:29:09 -0000 Subject: Review Request: Preffer new hunspell library over the old one in the finder In-Reply-To: <20110602085125.2029.16882@vidsolbach.de> References: <20110602085125.2029.16882@vidsolbach.de> Message-ID: <20110602162909.26281.38700@vidsolbach.de> > On June 2, 2011, 8:51 a.m., Christoph Feck wrote: > > HUNSPELL is the only optional dependency that is missing from my kdelibs build, so I cannot test, but if you say it works better this way, please commit :) Hmm, unless having account on identity mean that I also have write access to kde git repos we can safely assume that I can't commit :) - Tomáš ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101484/#review3626 ----------------------------------------------------------- On June 1, 2011, 11:10 a.m., Tomáš Chvátal wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101484/ > ----------------------------------------------------------- > > (Updated June 1, 2011, 11:10 a.m.) > > > Review request for kdelibs. > > > Summary > ------- > > When using FindHUNSPELL on system where both hunspell-1.2 and hunspell-1.3 are around the old version is preffered by the finder. > > This patch reverts the logic so the later is preffered. > > > Diffs > ----- > > cmake/modules/FindHUNSPELL.cmake 9ed944f > > Diff: http://git.reviewboard.kde.org/r/101484/diff > > > Testing > ------- > > > Thanks, > > Tomáš > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From urban.widmark at gmail.com Thu Jun 2 20:09:27 2011 From: urban.widmark at gmail.com (Urban Widmark) Date: Thu, 2 Jun 2011 21:09:27 +0200 Subject: Command line options stripped for KUniqueApplication In-Reply-To: <1824829.S5zgqlOc52@freedom> References: <1824829.S5zgqlOc52@freedom> Message-ID: On Fri, May 27, 2011 at 11:54 AM, Aaron J. Seigo wrote: > one other little "gotcha" is that some unique apps do open a new window when > launched a second time, just in the same process. it would be really nice if > such applications could note that they do so and thus always leave the flags > alone. Thanks for your comments. Have had a further think and look at this. konsole uses KUniqueApplication and opens windows like you describe. There is an inconsistency between a KApplication and KUniqueApplication regarding options. Probably doesn't matter, but a KApplication gets to keep the kde/qt specific options but a KUniqueApplication always loses them. So if I make a utility class of some kind that looks at options, it would work differently depending on the application class used, even for the initial instance. Why doesn't KUniqueApplication::newInstance() get the options that were used to create the new instance as a parameter? That way it could react to them if it wanted to, but the options for the main program would be unchanged - unless the application decides to update them. To do that would require some changes to KCmdLineArgs and its internal helper classes. Today you can only have one instance of options, since it all depends on KCmdLineArgsStatic. I think that can be done without removing anything from the API, but probably need to add some functions to be able to manipulate additional KCmdLineArgs instances (or possibly better with a separate class for this). To avoid duplicating code the static version could be expressed in terms of a dynamically allocated one. KCmdLineArgs::saveAppArgs() / KCmdLineArgs::loadAppArgs() would not remove all QT/KDE args. No options would be overwritten automatically when a second instance starts, which is what happens today for non-KDE/QT args and a KUniqueApplication. Any objections to that idea? From null at kde.org Fri Jun 3 08:43:37 2011 From: null at kde.org (Commit Hook) Date: Fri, 03 Jun 2011 07:43:37 -0000 Subject: Review Request: Update KActionCollection member documentation In-Reply-To: <20110602200922.5596.15018@vidsolbach.de> References: <20110602200922.5596.15018@vidsolbach.de> Message-ID: <20110603074337.28983.22173@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101494/#review3649 ----------------------------------------------------------- This review has been submitted with commit 1fde3604395dc5a75c23489fdb11f5ab55c72ca2 by Rolf Eike Beer. - Commit On June 2, 2011, 8:09 p.m., Rolf Eike Beer wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101494/ > ----------------------------------------------------------- > > (Updated June 2, 2011, 8:09 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > KActionCollection is missing parameter documention on some members. And one has even a bogus one. > > > Diffs > ----- > > kdeui/actions/kactioncollection.h 076088b > > Diff: http://git.reviewboard.kde.org/r/101494/diff > > > Testing > ------- > > > Thanks, > > Rolf Eike > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bart.cerneels at kde.org Fri Jun 3 11:40:03 2011 From: bart.cerneels at kde.org (Bart Cerneels) Date: Fri, 3 Jun 2011 12:40:03 +0200 Subject: [Kde-hardware-devel] Re: Request: Inclusion of kio-upnp-ms to kde-runtime KIO slaves In-Reply-To: <201106022339.08364.kossebau@kde.org> References: <201105221349.28245.kossebau@kde.org> <201106022339.08364.kossebau@kde.org> Message-ID: On Thu, Jun 2, 2011 at 23:39, Friedrich W. H. Kossebau wrote: > Hi, > > (all follow-ups only to kde-core-devel please, copying also amarok-devel this > time to get your attention and comments, amarokers) > > guess you are still heavily occupied by more important things, Nikhil :) > Still I think it would be good to have the upnp-ms kio-slave as part of the > SC 4.7 release, for now in extragear, not kde-runtime, given the state in the > release cycle (can move to kde-runtime for 4.8). > If you can share a minute please tell if you are okay with me pushing to get > your kio-slave into extragear, so it still can be officially part of SC 4.7 > > @Amarok people, please see below for a question to you. > > Dimanche, le 22 mai 2011, à 13:49, Friedrich W. H. Kossebau a écrit: >> Hi Nikhil, >> >> Jeudi, le 12. mai 2011, à 01:38, Nikhil Marathe a écrit: >> > On Wed, May 11, 2011 at 4:04 PM, Friedrich W. H. Kossebau >> > >> > wrote: >> > > Hi Nikhil, >> > > >> > > you know that today, April 12th, is already Hard Feature Freeze?! Would >> > > be really sad if your upnp-ms kio-slave misses the deadline now! >> > >> > Hi Fredrik, >> > I have been moving halfway across the world the last 4-5 days and so I >> > couldn't really do anything. >> >> For starting on a job, I guess? So congrats for that, wish you much joy! :) >> >> > I am at work, and don't have access to my laptop right now, but I'll >> > ensure your changes are in by tonight. >> > Aren't there circumstances under which certain features get some >> > leeway in being merged even after hard feature >> > freeze due to exceptional reasons? Any chance we can do this for the >> > slave, since the code itself has been pretty >> > well tested already. >> >> I would think there is a chance, if you can list the reasons: >> Do you know of distris which have the upnp-ms kio-slave in use? >> Which versions of Amarok make use of it/depend on it? >> And what ever else you think makes the release-team and others confident >> the inclusion now will be still okay and worth an exception. > > @Amarok people: So since 2.4.0 Amarok makes use of the upnp-ms kio-slave, > right? Can you tell which distros already ship it? > And do you make use of that kio-slave's upnptypes.h, which has been renamed to > upnp-ms-types.h now? How is integration exactly done, what are the > dependencies, how do you detect the kio-slave? > >> From what grep tells me, there are only three strings to be translated (and >> some more in the tests, but I do think you can/should remove i18n from >> there, testers usually don't need/want translated strings), and only for >> errors, so translators (and users) might be okay with an exception here. >> >> > > Just pushed a branch "codeOptimization" with my proposals for those > optimization. If you find time, please give it a review and comment on it or > merge it to master, Nikhil :) > Adding the FindHUpnp.cmake is needed, as kdelibs does not install them, so > kio-upnp-ms needs a copy. > >> > >> If there is no objection I would like to request a merge into >> > >> kde-runtime. I will edit the 4.7 feature plan for the same. >> > > >> > > I would think this is already a request ;) But if there is not enough >> > > time now and others would like to do their own review before it gets >> > > into kde-runtime, as there has not been an official merge request yet >> > > via >> > > https://git.reviewboard.kde.org, let's at least do the trick to still >> > > be part of the next release wave by "upgrading" the repo from >> > > playground to Extragear/Base as fast as possible. >> > >> > Do you mean I should abandon the inclusion in 4.7 and instead aim for >> > 4.8? I really think this should go in 4.7. >> >> So do I, and surely do Kevin and the metalworkers (because e.g. the Places >> integration would be useless otherwise). But you must push for it yourself, >> you are the maintainer. Or ask somebody else to do that in-place for you if >> life currently has swamped you with even more important tasks :) I would be >> willing to do so, if you want. > > Cheers > Friedrich > -- Since Nikhil is busy I'm maintaining the upnp-ms collection in Amarok, obviously we do depend on a KDE release with the upnp-ms KIO slave. I'll try to take a look at your branch, but I'm expecting core devs to pick up the slave. Bart From adawit at kde.org Fri Jun 3 18:46:19 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Fri, 03 Jun 2011 17:46:19 -0000 Subject: Review Request: Do not emit KLineEdit::textEdited when a user scrolls through the popup completion list Message-ID: <20110603174619.21870.31675@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101498/ ----------------------------------------------------------- Review request for kdelibs. Summary ------- Currently it is impossible to scroll through the popup completion items in Konqueror's searchbar plugin. The problem stems from the fact that whenever a user scrolls through the popup completion list, not only does KLineEdit update its text, and as a result emit the textChanged signal, but it also emits the textEdited signal. This causes the searchbar plugin which relies on the textEdited signal to update the matching items from the search engine, to continually retrieve new matches everytime the user presses the arrow keys to scroll through the completion items in the popup completion box. This results in unpredictable behavior since the list is updated while the user is pressing the scrolling keys. The attached patch stops KLineEdit from emitting textEdited during scrolling through the list of completion items. This addresses bug 256954. http://bugs.kde.org/show_bug.cgi?id=256954 Diffs ----- kdeui/widgets/klineedit.cpp 0dd3690 Diff: http://git.reviewboard.kde.org/r/101498/diff Testing ------- Thanks, Dawit -------------- next part -------------- An HTML attachment was scrubbed... URL: From adawit at kde.org Fri Jun 3 18:54:16 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Fri, 03 Jun 2011 17:54:16 -0000 Subject: Review Request: KMainWindow::parseGeometry() fails to position with positive coordinates In-Reply-To: <20110602110859.9521.71405@vidsolbach.de> References: <20110602110859.9521.71405@vidsolbach.de> Message-ID: <20110603175416.22268.23317@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101492/#review3651 ----------------------------------------------------------- kdeui/widgets/kmainwindow.cpp Why change x to nx and y to ny ? What is that supposed to signify ? kdeui/widgets/kmainwindow.cpp isn't this if statement supposed to use YValue instead ? - Dawit On June 2, 2011, 11:08 a.m., Urban Widmark wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101492/ > ----------------------------------------------------------- > > (Updated June 2, 2011, 11:08 a.m.) > > > Review request for kdelibs. > > > Summary > ------- > > When an X geometry is given on the command line, parseGeometry() will, for positive positions, use geometry().x()/.y() instead of the x/y value parsed from the string. This causes positive positions to not work. For negative values the string values are used. > > No direct bugs reported on this that I can find, but the odd position behavior is noted in some --geometry related bugs: > Comment #6, http://bugs.kde.org/show_bug.cgi?id=165355 > http://bugs.kde.org/show_bug.cgi?id=230663 > > > For the KMainWindow --geometry parsing to work for both size and position, the client application will have to call applyMainWindowSettings() or restoreWindowSize(). The parsing done by KMainWindowPrivate::init() will only set position. Not sure if that is good, as a user of the window I would expect it to use all of the --geometry data at the same time (either on creation or some later call). > > > Diffs > ----- > > kdeui/widgets/kmainwindow.cpp 1d27722 > > Diff: http://git.reviewboard.kde.org/r/101492/diff > > > Testing > ------- > > Using a KApplication program with a KMainWindow that also calls applyMainWindowSettings (keditbookmarks), positions verified using xwininfo: > keditbookmarks --geometry 400x300+100+200 > keditbookmarks --geometry 400x300-100+200 > keditbookmarks --geometry 400x300+100-200 > keditbookmarks --geometry 400x300-100+200 > keditbookmarks --geometry 400x300 > keditbookmarks --geometry +100+200 > > Without patch all +coords are replaced by 0. > Negative positions do not account for window decorations as the size of those are not known. I suspect the user will have to adjust for that in their input. > > > Thanks, > > Urban > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adawit at kde.org Fri Jun 3 20:58:03 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Fri, 03 Jun 2011 19:58:03 -0000 Subject: Review Request: KMainWindow::parseGeometry() fails to position with positive coordinates In-Reply-To: <20110603185819.25060.57449@vidsolbach.de> References: <20110603185819.25060.57449@vidsolbach.de> Message-ID: <20110603195803.27670.70072@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101492/#review3653 ----------------------------------------------------------- Looks good, however should the new if statements have an else that defaulted to previous behavior ? That is should not if ( !(m & XValue) ) x = this->x(); if ( !(m & YValue) ) y = this->y(); be x = (!(m & XValue)) ? this->x() : geometry.x(); y = (!(m & YValue)) ? this->y() : geometry.y(); instead or using the else statement if you prefer ? - Dawit On June 3, 2011, 6:58 p.m., Urban Widmark wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101492/ > ----------------------------------------------------------- > > (Updated June 3, 2011, 6:58 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > When an X geometry is given on the command line, parseGeometry() will, for positive positions, use geometry().x()/.y() instead of the x/y value parsed from the string. This causes positive positions to not work. For negative values the string values are used. > > No direct bugs reported on this that I can find, but the odd position behavior is noted in some --geometry related bugs: > Comment #6, http://bugs.kde.org/show_bug.cgi?id=165355 > http://bugs.kde.org/show_bug.cgi?id=230663 > > > For the KMainWindow --geometry parsing to work for both size and position, the client application will have to call applyMainWindowSettings() or restoreWindowSize(). The parsing done by KMainWindowPrivate::init() will only set position. Not sure if that is good, as a user of the window I would expect it to use all of the --geometry data at the same time (either on creation or some later call). > > > Diffs > ----- > > kdeui/widgets/kmainwindow.cpp 1d27722 > > Diff: http://git.reviewboard.kde.org/r/101492/diff > > > Testing > ------- > > Using a KApplication program with a KMainWindow that also calls applyMainWindowSettings (keditbookmarks), positions verified using xwininfo: > keditbookmarks --geometry 400x300+100+200 > keditbookmarks --geometry 400x300-100+200 > keditbookmarks --geometry 400x300+100-200 > keditbookmarks --geometry 400x300-100+200 > keditbookmarks --geometry 400x300 > keditbookmarks --geometry +100+200 > > Without patch all +coords are replaced by 0. > Negative positions do not account for window decorations as the size of those are not known. I suspect the user will have to adjust for that in their input. > > > Thanks, > > Urban > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adawit at kde.org Fri Jun 3 22:00:48 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Fri, 03 Jun 2011 21:00:48 -0000 Subject: Review Request: Two important KUrlCompletion fixes... Message-ID: <20110603210048.31241.45135@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101499/ ----------------------------------------------------------- Review request for kdelibs. Summary ------- The attached patch fixes two long stand bugs in KUrlCompletion: #1. No completion for executables when the mode is set to KUrlCompletion::ExeCompletion as reported in the bugs listed above. #2. For every text completion request a new directory listing thread is unnecessarily created due to a logic error in KUrlCompletion::customEvent. This means that every keypress in the location bar of apps like Konqueror, Dolphin and the input box of Krunner results in the creation of a new thread directory lister, which of course is waste. This addresses bugs 77169 and 116639. http://bugs.kde.org/show_bug.cgi?id=77169 http://bugs.kde.org/show_bug.cgi?id=116639 Diffs ----- kio/kio/kurlcompletion.cpp 86aa9d3 Diff: http://git.reviewboard.kde.org/r/101499/diff Testing ------- Made sure executable completion in KOpenWith dialog works correctly. Made sure a directory lister thread is not created for every completion request (completion should be much faster). Made sure the unit test class, kurlcompletiontest, passes with the fixes. Thanks, Dawit -------------- next part -------------- An HTML attachment was scrubbed... URL: From adawit at kde.org Sat Jun 4 01:53:43 2011 From: adawit at kde.org (Dawit A) Date: Fri, 3 Jun 2011 20:53:43 -0400 Subject: Review Request: [PATCH] Change HTML thumbnail generator to use kdewebkit to fix bug 248478 In-Reply-To: References: <20110515052733.32514.79909@vidsolbach.de> <20110527215736.9660.87615@vidsolbach.de> Message-ID: Hello Maksim, Do you have any plans for pushing this into git master/KDE 4.6 branch ? Either your patch or mine needs to make it into KDE 4.7. On Sat, May 28, 2011 at 11:02 AM, Maksim Orlovich wrote: > Or you could just do this 1-line + comments change: > commit 4c65ecb9fb5ca6aba393189a818e2cfcb414b228 > Author: Maks Orlovich > Date: Sat May 28 11:01:16 2011 -0400 > > Don't ask KHTMLRun to handle embedding cases with > onlyLocalReferences, we want to > swallow them ourselves given what the mode is for. > > Fixes what #248478 turned to (original issue got fixed > organically, follow up > comments are technically unrelated) > > BUG: 248478 > > diff --git a/khtml/khtml_part.cpp b/khtml/khtml_part.cpp > index ec89b0c..817e606 100644 > --- a/khtml/khtml_part.cpp > +++ b/khtml/khtml_part.cpp > @@ -4299,11 +4297,12 @@ bool KHTMLPart::processObjectRequest( > khtml::ChildFrame *child, const KUrl &_url > // though -> the reference becomes invalid -> crash is likely > KUrl url( _url ); > > - // If we are not permitting anything remote, or khtmlrun called us with > - // empty url + mimetype to indicate a loading error, we obviosuly failed > + // khtmlrun called us with empty url + mimetype to indicate a > loading error, > + // we obviosuly failed; but we can return true here since we don't want it > + // doing anything more, while childLoadFailure is enough to notify our kid. > if ( d->m_onlyLocalReferences || ( url.isEmpty() && > mimetype.isEmpty() ) ) { > childLoadFailure(child); > - return false; > + return true; > } > > // we also want to ignore any spurious requests due to closing > when parser is being cleared. These should be > > > > On 5/27/11, Dawit Alemayehu wrote: >> >> ----------------------------------------------------------- >> This is an automatically generated e-mail. To reply, visit: >> http://git.reviewboard.kde.org/r/101365/ >> ----------------------------------------------------------- >> >> (Updated May 27, 2011, 9:57 p.m.) >> >> >> Review request for KDE Runtime. >> >> >> Summary (updated) >> ------- >> >> The attached patch fixes the html thumbnail generator so that it won't show >> the "Open With" dialog box whenever it encounters frames and other content >> such as flash. >> >> Please note that I changed the engine not because of ideological preference, >> but rather because I cannot figure out how to fix it with khtml. >> >> >> This addresses bug 248478. >> http://bugs.kde.org/show_bug.cgi?id=248478 >> >> >> Diffs >> ----- >> >> kioslave/thumbnail/CMakeLists.txt 9789109 >> kioslave/thumbnail/htmlcreator.h 6903db7 >> kioslave/thumbnail/htmlcreator.cpp c623606 >> >> Diff: http://git.reviewboard.kde.org/r/101365/diff >> >> >> Testing >> ------- >> >> >> Thanks, >> >> Dawit >> >> > From adawit at kde.org Sat Jun 4 06:12:56 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Sat, 04 Jun 2011 05:12:56 -0000 Subject: Review Request: Two important KUrlCompletion fixes... In-Reply-To: <20110603210048.31241.45135@vidsolbach.de> References: <20110603210048.31241.45135@vidsolbach.de> Message-ID: <20110604051256.16618.79736@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101499/ ----------------------------------------------------------- (Updated June 4, 2011, 5:12 a.m.) Review request for kdelibs. Changes ------- Updated description and added more bug reports to the bugs list. Summary (updated) ------- The attached patch fixes two long stand bugs in KUrlCompletion: #1. No completion for executables when the mode is set to KUrlCompletion::ExeCompletion as reported in the bugs listed above. #2. For every text completion request a new directory listing thread is unnecessarily created due to a logic error in KUrlCompletion::customEvent. This means that every keypress in the location bar of apps like Konqueror, Dolphin and the input box of Krunner causes the the creation of a new directory lister thread when in reality none needs to be created until there is a directory change, e.g. if you type /usr/ instead of two lister threads (for / and /usr/) you get 5 for each and every key press. This addresses bugs 77169, 116639 and 158124. http://bugs.kde.org/show_bug.cgi?id=77169 http://bugs.kde.org/show_bug.cgi?id=116639 http://bugs.kde.org/show_bug.cgi?id=158124 Diffs ----- kio/kio/kurlcompletion.cpp 86aa9d3 Diff: http://git.reviewboard.kde.org/r/101499/diff Testing ------- Made sure executable completion in KOpenWith dialog works correctly. Made sure a directory lister thread is not created for every completion request (completion should be much faster). Made sure the unit test class, kurlcompletiontest, passes with the fixes. Thanks, Dawit -------------- next part -------------- An HTML attachment was scrubbed... URL: From urban.widmark at gmail.com Fri Jun 3 19:58:19 2011 From: urban.widmark at gmail.com (Urban Widmark) Date: Fri, 03 Jun 2011 18:58:19 -0000 Subject: Review Request: KMainWindow::parseGeometry() fails to position with positive coordinates In-Reply-To: <20110602110859.9521.71405@vidsolbach.de> References: <20110602110859.9521.71405@vidsolbach.de> Message-ID: <20110603185819.25060.57449@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101492/ ----------------------------------------------------------- (Updated June 3, 2011, 6:58 p.m.) Review request for kdelibs. Changes ------- Use this->x() and this->y() instead of renaming the x, y variables. Look at YValue for the Y coordinate ... Summary ------- When an X geometry is given on the command line, parseGeometry() will, for positive positions, use geometry().x()/.y() instead of the x/y value parsed from the string. This causes positive positions to not work. For negative values the string values are used. No direct bugs reported on this that I can find, but the odd position behavior is noted in some --geometry related bugs: Comment #6, http://bugs.kde.org/show_bug.cgi?id=165355 http://bugs.kde.org/show_bug.cgi?id=230663 For the KMainWindow --geometry parsing to work for both size and position, the client application will have to call applyMainWindowSettings() or restoreWindowSize(). The parsing done by KMainWindowPrivate::init() will only set position. Not sure if that is good, as a user of the window I would expect it to use all of the --geometry data at the same time (either on creation or some later call). Diffs (updated) ----- kdeui/widgets/kmainwindow.cpp 1d27722 Diff: http://git.reviewboard.kde.org/r/101492/diff Testing ------- Using a KApplication program with a KMainWindow that also calls applyMainWindowSettings (keditbookmarks), positions verified using xwininfo: keditbookmarks --geometry 400x300+100+200 keditbookmarks --geometry 400x300-100+200 keditbookmarks --geometry 400x300+100-200 keditbookmarks --geometry 400x300-100+200 keditbookmarks --geometry 400x300 keditbookmarks --geometry +100+200 Without patch all +coords are replaced by 0. Negative positions do not account for window decorations as the size of those are not known. I suspect the user will have to adjust for that in their input. Thanks, Urban -------------- next part -------------- An HTML attachment was scrubbed... URL: From urban.widmark at gmail.com Fri Jun 3 23:08:58 2011 From: urban.widmark at gmail.com (Urban Widmark) Date: Fri, 03 Jun 2011 22:08:58 -0000 Subject: Review Request: KMainWindow::parseGeometry() fails to position with positive coordinates In-Reply-To: <20110603195803.27670.70072@vidsolbach.de> References: <20110603195803.27670.70072@vidsolbach.de> Message-ID: <20110603220858.2029.84974@vidsolbach.de> > On June 3, 2011, 7:58 p.m., Dawit Alemayehu wrote: > > Looks good, however should the new if statements have an else that defaulted to previous behavior ? That is should not > > > > if ( !(m & XValue) ) > > x = this->x(); > > if ( !(m & YValue) ) > > y = this->y(); > > > > be > > > > x = (!(m & XValue)) ? this->x() : geometry.x(); > > y = (!(m & YValue)) ? this->y() : geometry.y(); > > > > instead or using the else statement if you prefer ? > > No, when the flags are set the x/y variables will have been set by XParseGeometry() to the users input. Use of geometry().x() in the original code is wrong. Hmm, there is another bug in the original code. If you have XNegative set it will use the w value, without checking the WidthValue flag and without having initialized it to any default (eg a geometry string of "-400-300"). Will change it to always set defaults and to use the fact that XParseGeometry() does not change arguments that are not defined in the input string. - Urban ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101492/#review3653 ----------------------------------------------------------- On June 3, 2011, 6:58 p.m., Urban Widmark wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101492/ > ----------------------------------------------------------- > > (Updated June 3, 2011, 6:58 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > When an X geometry is given on the command line, parseGeometry() will, for positive positions, use geometry().x()/.y() instead of the x/y value parsed from the string. This causes positive positions to not work. For negative values the string values are used. > > No direct bugs reported on this that I can find, but the odd position behavior is noted in some --geometry related bugs: > Comment #6, http://bugs.kde.org/show_bug.cgi?id=165355 > http://bugs.kde.org/show_bug.cgi?id=230663 > > > For the KMainWindow --geometry parsing to work for both size and position, the client application will have to call applyMainWindowSettings() or restoreWindowSize(). The parsing done by KMainWindowPrivate::init() will only set position. Not sure if that is good, as a user of the window I would expect it to use all of the --geometry data at the same time (either on creation or some later call). > > > Diffs > ----- > > kdeui/widgets/kmainwindow.cpp 1d27722 > > Diff: http://git.reviewboard.kde.org/r/101492/diff > > > Testing > ------- > > Using a KApplication program with a KMainWindow that also calls applyMainWindowSettings (keditbookmarks), positions verified using xwininfo: > keditbookmarks --geometry 400x300+100+200 > keditbookmarks --geometry 400x300-100+200 > keditbookmarks --geometry 400x300+100-200 > keditbookmarks --geometry 400x300-100+200 > keditbookmarks --geometry 400x300 > keditbookmarks --geometry +100+200 > > Without patch all +coords are replaced by 0. > Negative positions do not account for window decorations as the size of those are not known. I suspect the user will have to adjust for that in their input. > > > Thanks, > > Urban > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From urban.widmark at gmail.com Fri Jun 3 23:09:55 2011 From: urban.widmark at gmail.com (Urban Widmark) Date: Fri, 03 Jun 2011 22:09:55 -0000 Subject: Review Request: KMainWindow::parseGeometry() fails to position with positive coordinates In-Reply-To: <20110603185819.25060.57449@vidsolbach.de> References: <20110603185819.25060.57449@vidsolbach.de> Message-ID: <20110603220955.2032.42594@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101492/ ----------------------------------------------------------- (Updated June 3, 2011, 10:09 p.m.) Review request for kdelibs. Changes ------- Always set default values for size/position. Always calculate min/max width/height. Summary (updated) ------- When an X geometry is given on the command line, parseGeometry() will, for positive positions, use geometry().x()/.y() instead of the x/y value parsed from the string. This causes positive positions to not work. For negative values the string values are used, but the w/h variables will be used uninitialized unless both a size and position are given. No direct bugs reported on this that I can find, but the odd position behavior is noted in some --geometry related bugs: Comment #6, http://bugs.kde.org/show_bug.cgi?id=165355 http://bugs.kde.org/show_bug.cgi?id=230663 For the KMainWindow --geometry parsing to work for both size and position, the client application will have to call applyMainWindowSettings() or restoreWindowSize(). The parsing done by KMainWindowPrivate::init() will only set position. Not sure if that is good, as a user of the window I would expect it to use all of the --geometry data at the same time (either on creation or some later call). Diffs (updated) ----- kdeui/widgets/kmainwindow.cpp 1d27722 Diff: http://git.reviewboard.kde.org/r/101492/diff Testing (updated) ------- Using a KApplication program with a KMainWindow that also calls applyMainWindowSettings (keditbookmarks), positions verified using xwininfo: keditbookmarks --geometry 400x300+100+200 keditbookmarks --geometry 400x300-100+200 keditbookmarks --geometry 400x300+100-200 keditbookmarks --geometry 400x300-100+200 keditbookmarks --geometry 400x300 keditbookmarks --geometry +100+200 keditbookmarks --geometry -400-300 Without patch all +coords are replaced by 0. Negative positions do not account for window decorations as the size of those are not known. I suspect the user will have to adjust for that in their input. Negative positions also has a problem that parseGeometry(false) is called before keditbookmarks has set a (default) size on the window, so it is 640x480. Thanks, Urban -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantinos.smanis at gmail.com Fri Jun 3 11:49:24 2011 From: konstantinos.smanis at gmail.com (Konstantinos Smanis) Date: Fri, 3 Jun 2011 13:49:24 +0300 Subject: Review Request: kcm-grub2 In-Reply-To: References:

Message-ID: Raphael Kubo da Costa gmail.com> writes: > Konstantinos Smanis gmail.com> writes: > > > On Thu, May 26, 2011 at 00:03, Konstantinos Smanis > > gmail.com> wrote: > >>> The following line should probably be simplified (see > >>> http://websvn.kde.org/?revision=1184860&view=revision): > >>> > >>> src/kcm_grub2.cpp:113: QTreeWidgetItem *item = new > >>> QTreeWidgetItem(ui.treeWidget_recover, QStringList(QString()) << name > >>> << partition->filePath() << volume->label() << volume->fsType() << > >>> i18n("%1 GiB", QString::number(volume->size() / 1073741824))); > >> > >> Thanks. Fixed: http://commits.kde.org/kcm-grub2/87eac2b1ef0b8f3a1907b86ab7054b99a0ed5ab9 > >> > >> Konstantinos > > > > If noone else objects, would it be possible for a sysadmin to make the move? > > This is not really an objection, as I have not looked at the code. But > having two different projects with practically identical names > (kcm_grub2 and kcmgrub2) is quite confusing. It'd be nice if this could > be worked out, as both projects have actually asked for review and to be > moved to the same final destination (extragear/sysadmin). I have talked with Alberto Mattea (the maintainer of kcmgrub2) and he has agreed to give up his request for inclusion in extragear. Our conversation has been over plain e-mails, so I cannot prove this. Perhaps I should contact him to confirm this? Konstantinos From kubito at gmail.com Sat Jun 4 10:21:30 2011 From: kubito at gmail.com (Raphael Kubo da Costa) Date: Sat, 04 Jun 2011 06:21:30 -0300 Subject: Review Request: kcm-grub2 In-Reply-To: (Konstantinos Smanis's message of "Fri, 3 Jun 2011 13:49:24 +0300") References:

Message-ID: <87aady7y05.fsf@gmail.com> Konstantinos Smanis writes: > I have talked with Alberto Mattea (the maintainer of kcmgrub2) and he > has agreed to give up his request for inclusion in extragear. > > Our conversation has been over plain e-mails, so I cannot prove this. > Perhaps I should contact him to confirm this? That sounds like getting rid of dandruff by decapitation ;) I thought one of you would just rename your project, as it looks like there are still going to be two projects with almost the exact same name, just not in the same location in KDE. From null at kde.org Sat Jun 4 18:30:06 2011 From: null at kde.org (Commit Hook) Date: Sat, 04 Jun 2011 17:30:06 -0000 Subject: Review Request: Two important KUrlCompletion fixes... In-Reply-To: <20110604051256.16618.79736@vidsolbach.de> References: <20110604051256.16618.79736@vidsolbach.de> Message-ID: <20110604173006.16451.72094@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101499/#review3667 ----------------------------------------------------------- This review has been submitted with commit d9997d711e493416a35a49cb84700c7b77441211 by Dawit Alemayehu. - Commit On June 4, 2011, 5:12 a.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101499/ > ----------------------------------------------------------- > > (Updated June 4, 2011, 5:12 a.m.) > > > Review request for kdelibs. > > > Summary > ------- > > The attached patch fixes two long stand bugs in KUrlCompletion: > > #1. No completion for executables when the mode is set to KUrlCompletion::ExeCompletion as reported in the bugs listed above. > #2. For every text completion request a new directory listing thread is unnecessarily created due to a logic error in KUrlCompletion::customEvent. This means that every keypress in the location bar of apps like Konqueror, Dolphin and the input box of Krunner causes the the creation of a new directory lister thread when in reality none needs to be created until there is a directory change, e.g. if you type /usr/ instead of two lister threads (for / and /usr/) you get 5 for each and every key press. > > > This addresses bugs 77169, 116639 and 158124. > http://bugs.kde.org/show_bug.cgi?id=77169 > http://bugs.kde.org/show_bug.cgi?id=116639 > http://bugs.kde.org/show_bug.cgi?id=158124 > > > Diffs > ----- > > kio/kio/kurlcompletion.cpp 86aa9d3 > > Diff: http://git.reviewboard.kde.org/r/101499/diff > > > Testing > ------- > > Made sure executable completion in KOpenWith dialog works correctly. > Made sure a directory lister thread is not created for every completion request (completion should be much faster). > Made sure the unit test class, kurlcompletiontest, passes with the fixes. > > > Thanks, > > Dawit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guy-kde at maurel.de Sat Jun 4 18:39:28 2011 From: guy-kde at maurel.de (Guy Maurel) Date: Sat, 04 Jun 2011 17:39:28 -0000 Subject: Review Request: a very little fix In-Reply-To: <20110524173300.27542.23392@vidsolbach.de> References: <20110524173300.27542.23392@vidsolbach.de> Message-ID: <20110604173928.16888.36834@vidsolbach.de> > On May 24, 2011, 5:33 p.m., Jaime Torres Amate wrote: > > kdecore/config/kconfigdata.h, line 265 > > > > > > Even better, change it to log the previous value and the new one. > > But look, it is commented. yes it is commented, but if you want to use it, it is wrong/or at the wrong line. One line below would be right. - Guy ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101433/#review3485 ----------------------------------------------------------- On May 24, 2011, 4:17 p.m., Guy Maurel wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101433/ > ----------------------------------------------------------- > > (Updated May 24, 2011, 4:17 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > corrected to the right variable > > > Diffs > ----- > > kdecore/config/kconfigdata.h 0dff4ad > > Diff: http://git.reviewboard.kde.org/r/101433/diff > > > Testing > ------- > > > Thanks, > > Guy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Sat Jun 4 19:25:15 2011 From: null at kde.org (Commit Hook) Date: Sat, 04 Jun 2011 18:25:15 -0000 Subject: Review Request: PATCH: Honor size and coordinates when creating new Konqueror windows In-Reply-To: <20110601033351.29280.2979@vidsolbach.de> References: <20110601033351.29280.2979@vidsolbach.de> Message-ID: <20110604182515.19788.11681@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101477/#review3670 ----------------------------------------------------------- This review has been submitted with commit 8ea273f60ef6b55609dd38383ea69e7558133d1d by Dawit Alemayehu. - Commit On June 1, 2011, 3:33 a.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101477/ > ----------------------------------------------------------- > > (Updated June 1, 2011, 3:33 a.m.) > > > Review request for KDE Base Apps and David Faure. > > > Summary > ------- > > Currently new window creation in KonqMainWindow::slotCreateNewWindow does not honor the supplied cooridnate and size information under certain circumstances. For example, if you click on a javascript link that opens a new window, then the new window will always be maximized, regardless of the size information supplied by the javascript window.open call, as long as the Konqueror window where you clicked on the link is also maximized. Even when the original window is not maximized, if you maximize and close the newly created window, then clicking on the javscript window.open link again will result in a maximized window. > > The attached patch addresses all of the above issues by making sure the coordinate and size information are always honored during new window creation. > > > Diffs > ----- > > konqueror/src/konqmainwindow.cpp 56aa379 > > Diff: http://git.reviewboard.kde.org/r/101477/diff > > > Testing > ------- > > > > Javascript window.open Test > > > window.open test > > > > Test #1: > ======= > 1.) Copy the HTML snippet above into a file and open it with konqueror. > 2.) Maximize the Konqueror window. > 3.) Click on the link. > 4.) Notice new window is opened maximized. > > Test #2: > ======= > 5.) Repeat steps 2-4 above, but do not maximize the Konqueror window in step 2. > 6.) The new window opened when you clicked on the link should be of correct size. > 7.) Maximize this new window, then close it. > 8.) Click on the javascript link again. > 9.) Notice how the new window is opened maximized. > > After applying the patch, none of the above test scenarios should be reproducible. > > > Thanks, > > Dawit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Sat Jun 4 19:25:46 2011 From: null at kde.org (Commit Hook) Date: Sat, 04 Jun 2011 18:25:46 -0000 Subject: Review Request: PATCH: Honor size and coordinates when creating new Konqueror windows In-Reply-To: <20110601033351.29280.2979@vidsolbach.de> References: <20110601033351.29280.2979@vidsolbach.de> Message-ID: <20110604182546.19792.18205@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101477/#review3671 ----------------------------------------------------------- This review has been submitted with commit 67625dcea346e1f54da49809d38e9db528ac7ef5 by Dawit Alemayehu. - Commit On June 1, 2011, 3:33 a.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101477/ > ----------------------------------------------------------- > > (Updated June 1, 2011, 3:33 a.m.) > > > Review request for KDE Base Apps and David Faure. > > > Summary > ------- > > Currently new window creation in KonqMainWindow::slotCreateNewWindow does not honor the supplied cooridnate and size information under certain circumstances. For example, if you click on a javascript link that opens a new window, then the new window will always be maximized, regardless of the size information supplied by the javascript window.open call, as long as the Konqueror window where you clicked on the link is also maximized. Even when the original window is not maximized, if you maximize and close the newly created window, then clicking on the javscript window.open link again will result in a maximized window. > > The attached patch addresses all of the above issues by making sure the coordinate and size information are always honored during new window creation. > > > Diffs > ----- > > konqueror/src/konqmainwindow.cpp 56aa379 > > Diff: http://git.reviewboard.kde.org/r/101477/diff > > > Testing > ------- > > > > Javascript window.open Test > > > window.open test > > > > Test #1: > ======= > 1.) Copy the HTML snippet above into a file and open it with konqueror. > 2.) Maximize the Konqueror window. > 3.) Click on the link. > 4.) Notice new window is opened maximized. > > Test #2: > ======= > 5.) Repeat steps 2-4 above, but do not maximize the Konqueror window in step 2. > 6.) The new window opened when you clicked on the link should be of correct size. > 7.) Maximize this new window, then close it. > 8.) Click on the javascript link again. > 9.) Notice how the new window is opened maximized. > > After applying the patch, none of the above test scenarios should be reproducible. > > > Thanks, > > Dawit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsdgeos at terra.es Sun Jun 5 01:22:07 2011 From: tsdgeos at terra.es (Albert Astals Cid) Date: Sun, 05 Jun 2011 00:22:07 -0000 Subject: Review Request: Rebuild fake locale as soon as possible Message-ID: <20110605002207.2449.31711@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101509/ ----------------------------------------------------------- Review request for kdelibs. Summary ------- By calling locale() instead of d->locale we ensure we kill and rebuild the locale as soon as possible in the chain, since calling functions in klocale can end up calling kglobal::locale again that might kill the fake locale and then we end up in trouble because we just killed ourselves (see backtrace in https://bugs.kde.org/show_bug.cgi?id=274169) This addresses bug 274169. http://bugs.kde.org/show_bug.cgi?id=274169 Diffs ----- kdecore/kernel/kglobal.cpp 45a6c5a Diff: http://git.reviewboard.kde.org/r/101509/diff Testing ------- vlc does not crash anymore. Other apps start fine. Thanks, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsdgeos at terra.es Sun Jun 5 01:23:22 2011 From: tsdgeos at terra.es (Albert Astals Cid) Date: Sun, 05 Jun 2011 00:23:22 -0000 Subject: Review Request: Rebuild fake locale as soon as possible In-Reply-To: <20110605002207.2449.31711@vidsolbach.de> References: <20110605002207.2449.31711@vidsolbach.de> Message-ID: <20110605002322.2532.5514@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101509/ ----------------------------------------------------------- (Updated June 5, 2011, 12:23 a.m.) Review request for kdelibs. Summary (updated) ------- By calling locale() instead of d->locale we ensure we kill and rebuild the locale as soon as possible in the chain, since calling functions in klocale can end up calling kglobal::locale again that might kill the fake locale and then we end up in trouble because we just killed ourselves ( see backtrace in https://bugs.kde.org/show_bug.cgi?id=274169 ) This addresses bug 274169. http://bugs.kde.org/show_bug.cgi?id=274169 Diffs ----- kdecore/kernel/kglobal.cpp 45a6c5a Diff: http://git.reviewboard.kde.org/r/101509/diff Testing ------- vlc does not crash anymore. Other apps start fine. Thanks, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehtatus at gmail.com Sun Jun 5 08:20:10 2011 From: mehtatus at gmail.com (tushar mehta) Date: Sun, 5 Jun 2011 12:50:10 +0530 Subject: Regarding kdelibs/kio Message-ID: Hi all, I am currently trying to understand how kde applications uses kio for doing file related operations. I am currently working on kget and as part of my summer of code project task I need to figure out how we can have speed limit on transfer using kio protocols like http/ftp. Do have we have any sample examples or documentation related to KIO? Any reference will be very helpful. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adawit at kde.org Sun Jun 5 20:04:06 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Sun, 05 Jun 2011 19:04:06 -0000 Subject: Review Request: Fix GUI thread blocking caused by KFilePreviewGenerator when disablingpreview Message-ID: <20110605190406.19783.43301@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101512/ ----------------------------------------------------------- Review request for kdelibs and Peter Penz. Summary ------- The attached single line patch fixes KFilePreviewGenertor such that it does not completely block the GUI thread and hence lock up the application when you enable and disable preview in a directory that contains large number of files. This fix still only solves the problem partially in that the app will no longer lock up for a very long period of time. Instead you get a few second lockup if you have an old machine like mine (Pentium D). It might not be noticable on much faster machines. However, such lock ups are to be expected because of how this class is designed to work. It is one of those few classes that can really benefit from being multi-threaded. Perhaps based on the ideas from http://labs.qt.nokia.com/2010/01/21/qt-graphics-and-performance-generating-content-in-threads/. Diffs ----- Diff: http://git.reviewboard.kde.org/r/101512/diff Testing ------- The following test was done to confirm the problem as well as to test the fix: - In Dolphin or Konqueror, enable HTML file preview. - Navigate to Qt's html documentation folder (/usr/share/doc/qt/html on my system). - Turn on preview if it is not already enabled. - Scroll up and down to see the preview working. - Disable preview and see what happens. Thanks, Dawit -------------- next part -------------- An HTML attachment was scrubbed... URL: From adawit at kde.org Sun Jun 5 20:07:38 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Sun, 05 Jun 2011 19:07:38 -0000 Subject: Review Request: Fix GUI thread blocking caused by KFilePreviewGenerator when disabling preview In-Reply-To: <20110605190406.19783.43301@vidsolbach.de> References: <20110605190406.19783.43301@vidsolbach.de> Message-ID: <20110605190738.19906.76424@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101512/ ----------------------------------------------------------- (Updated June 5, 2011, 7:07 p.m.) Review request for kdelibs and Peter Penz. Summary (updated) ------- The attached single line patch fixes KFilePreviewGenertor such that it does not completely block the GUI thread and hence lock up the application when you enable and disable preview in a directory that contains large number of files. This fix still only solves the problem partially in that the app will no longer lock up for a very long period of time. Instead you get a few second lockup if you have an old machine like mine (Pentium D). It might not be noticable on much faster machines. However, such lock ups are to be expected because of how this class is designed to work. It is one of those few classes that can really benefit from being multi-threaded. Perhaps based on the ideas from http://labs.qt.nokia.com/2010/01/21/qt-graphics-and-performance-generating-content-in-threads/. Diffs ----- Diff: http://git.reviewboard.kde.org/r/101512/diff Testing ------- The following test was done to confirm the problem as well as to test the fix: - In Dolphin or Konqueror, enable HTML file preview. - Navigate to Qt's html documentation folder (/usr/share/doc/qt/html on my system). - Turn on preview if it is not already enabled. - Scroll up and down to see the preview working. - Disable preview and see what happens. Thanks, Dawit -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Sun Jun 5 20:50:17 2011 From: null at kde.org (Commit Hook) Date: Sun, 05 Jun 2011 19:50:17 -0000 Subject: Review Request: Do not emit KLineEdit::textEdited when a user scrolls through the popup completion list In-Reply-To: <20110603174619.21870.31675@vidsolbach.de> References: <20110603174619.21870.31675@vidsolbach.de> Message-ID: <20110605195017.21212.65303@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101498/#review3692 ----------------------------------------------------------- This review has been submitted with commit 8db60a2fe40fc00cbf2774afd3c74e8f6ea03c02 by Dawit Alemayehu. - Commit On June 3, 2011, 5:46 p.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101498/ > ----------------------------------------------------------- > > (Updated June 3, 2011, 5:46 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > Currently it is impossible to scroll through the popup completion items in Konqueror's searchbar plugin. The problem stems from the fact that whenever a user scrolls through the popup completion list, not only does KLineEdit update its text, and as a result emit the textChanged signal, but it also emits the textEdited signal. This causes the searchbar plugin which relies on the textEdited signal to update the matching items from the search engine, to continually retrieve new matches everytime the user presses the arrow keys to scroll through the completion items in the popup completion box. This results in unpredictable behavior since the list is updated while the user is pressing the scrolling keys. > > The attached patch stops KLineEdit from emitting textEdited during scrolling through the list of completion items. > > > This addresses bug 256954. > http://bugs.kde.org/show_bug.cgi?id=256954 > > > Diffs > ----- > > kdeui/widgets/klineedit.cpp 0dd3690 > > Diff: http://git.reviewboard.kde.org/r/101498/diff > > > Testing > ------- > > > Thanks, > > Dawit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Sun Jun 5 20:50:58 2011 From: null at kde.org (Commit Hook) Date: Sun, 05 Jun 2011 19:50:58 -0000 Subject: Review Request: Do not emit KLineEdit::textEdited when a user scrolls through the popup completion list In-Reply-To: <20110603174619.21870.31675@vidsolbach.de> References: <20110603174619.21870.31675@vidsolbach.de> Message-ID: <20110605195058.21263.58569@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101498/#review3693 ----------------------------------------------------------- This review has been submitted with commit 26c378fe5cf0da01b64177470ddddd0eb51add12 by Dawit Alemayehu. - Commit On June 3, 2011, 5:46 p.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101498/ > ----------------------------------------------------------- > > (Updated June 3, 2011, 5:46 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > Currently it is impossible to scroll through the popup completion items in Konqueror's searchbar plugin. The problem stems from the fact that whenever a user scrolls through the popup completion list, not only does KLineEdit update its text, and as a result emit the textChanged signal, but it also emits the textEdited signal. This causes the searchbar plugin which relies on the textEdited signal to update the matching items from the search engine, to continually retrieve new matches everytime the user presses the arrow keys to scroll through the completion items in the popup completion box. This results in unpredictable behavior since the list is updated while the user is pressing the scrolling keys. > > The attached patch stops KLineEdit from emitting textEdited during scrolling through the list of completion items. > > > This addresses bug 256954. > http://bugs.kde.org/show_bug.cgi?id=256954 > > > Diffs > ----- > > kdeui/widgets/klineedit.cpp 0dd3690 > > Diff: http://git.reviewboard.kde.org/r/101498/diff > > > Testing > ------- > > > Thanks, > > Dawit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.penz19 at gmail.com Sun Jun 5 22:12:34 2011 From: peter.penz19 at gmail.com (Peter Penz) Date: Sun, 05 Jun 2011 21:12:34 -0000 Subject: Review Request: Fix GUI thread blocking caused by KFilePreviewGenerator when disabling preview In-Reply-To: <20110605190738.19906.76424@vidsolbach.de> References: <20110605190738.19906.76424@vidsolbach.de> Message-ID: <20110605211234.25063.57433@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101512/#review3694 ----------------------------------------------------------- > The attached single line patch... I think you forgot to attach the single line patch :-) (?) - Peter On June 5, 2011, 7:07 p.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101512/ > ----------------------------------------------------------- > > (Updated June 5, 2011, 7:07 p.m.) > > > Review request for kdelibs and Peter Penz. > > > Summary > ------- > > The attached single line patch fixes KFilePreviewGenertor such that it does not completely block the GUI thread and hence lock up the application when you enable and disable preview in a directory that contains large number of files. > > This fix still only solves the problem partially in that the app will no longer lock up for a very long period of time. Instead you get a few second lockup if you have an old machine like mine (Pentium D). It might not be noticable on much faster machines. However, such lock ups are to be expected because of how this class is designed to work. It is one of those few classes that can really benefit from being multi-threaded. Perhaps based on the ideas from http://labs.qt.nokia.com/2010/01/21/qt-graphics-and-performance-generating-content-in-threads/. > > > Diffs > ----- > > > Diff: http://git.reviewboard.kde.org/r/101512/diff > > > Testing > ------- > > The following test was done to confirm the problem as well as to test the fix: > > - In Dolphin or Konqueror, enable HTML file preview. > - Navigate to Qt's html documentation folder (/usr/share/doc/qt/html on my system). > - Turn on preview if it is not already enabled. > - Scroll up and down to see the preview working. > - Disable preview and see what happens. > > > Thanks, > > Dawit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adawit at kde.org Sun Jun 5 23:13:20 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Sun, 05 Jun 2011 22:13:20 -0000 Subject: Review Request: Fix GUI thread blocking caused by KFilePreviewGenerator when disabling preview In-Reply-To: <20110605190738.19906.76424@vidsolbach.de> References: <20110605190738.19906.76424@vidsolbach.de> Message-ID: <20110605221320.27623.88979@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101512/ ----------------------------------------------------------- (Updated June 5, 2011, 10:13 p.m.) Review request for kdelibs and Peter Penz. Summary ------- The attached single line patch fixes KFilePreviewGenertor such that it does not completely block the GUI thread and hence lock up the application when you enable and disable preview in a directory that contains large number of files. This fix still only solves the problem partially in that the app will no longer lock up for a very long period of time. Instead you get a few second lockup if you have an old machine like mine (Pentium D). It might not be noticable on much faster machines. However, such lock ups are to be expected because of how this class is designed to work. It is one of those few classes that can really benefit from being multi-threaded. Perhaps based on the ideas from http://labs.qt.nokia.com/2010/01/21/qt-graphics-and-performance-generating-content-in-threads/. Diffs (updated) ----- kfile/kfilepreviewgenerator.cpp 50a3db7 Diff: http://git.reviewboard.kde.org/r/101512/diff Testing ------- The following test was done to confirm the problem as well as to test the fix: - In Dolphin or Konqueror, enable HTML file preview. - Navigate to Qt's html documentation folder (/usr/share/doc/qt/html on my system). - Turn on preview if it is not already enabled. - Scroll up and down to see the preview working. - Disable preview and see what happens. Thanks, Dawit -------------- next part -------------- An HTML attachment was scrubbed... URL: From faure at kde.org Sun Jun 5 23:39:20 2011 From: faure at kde.org (David Faure) Date: Sun, 05 Jun 2011 22:39:20 -0000 Subject: Review Request: Do not emit KLineEdit::textEdited when a user scrolls through the popup completion list In-Reply-To: <20110603174619.21870.31675@vidsolbach.de> References: <20110603174619.21870.31675@vidsolbach.de> Message-ID: <20110605223920.28243.42126@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101498/#review3696 ----------------------------------------------------------- Ship it! Reviewed (not this patch, but the committed 26c378fe5c looks correct). Thanks. - David On June 3, 2011, 5:46 p.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101498/ > ----------------------------------------------------------- > > (Updated June 3, 2011, 5:46 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > Currently it is impossible to scroll through the popup completion items in Konqueror's searchbar plugin. The problem stems from the fact that whenever a user scrolls through the popup completion list, not only does KLineEdit update its text, and as a result emit the textChanged signal, but it also emits the textEdited signal. This causes the searchbar plugin which relies on the textEdited signal to update the matching items from the search engine, to continually retrieve new matches everytime the user presses the arrow keys to scroll through the completion items in the popup completion box. This results in unpredictable behavior since the list is updated while the user is pressing the scrolling keys. > > The attached patch stops KLineEdit from emitting textEdited during scrolling through the list of completion items. > > > This addresses bug 256954. > http://bugs.kde.org/show_bug.cgi?id=256954 > > > Diffs > ----- > > kdeui/widgets/klineedit.cpp 0dd3690 > > Diff: http://git.reviewboard.kde.org/r/101498/diff > > > Testing > ------- > > > Thanks, > > Dawit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From faure at kde.org Mon Jun 6 00:48:53 2011 From: faure at kde.org (David Faure) Date: Sun, 05 Jun 2011 23:48:53 -0000 Subject: Review Request: remove functions *Command::name() which are not used In-Reply-To: <20110512065526.15656.18931@vidsolbach.de> References: <20110512065526.15656.18931@vidsolbach.de> Message-ID: <20110605234853.30967.26326@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101343/#review3698 ----------------------------------------------------------- OK, that's one solution. The other solution would be to fix the Undo action to actually show the text of the command to undo, like it does in many other apps ;) Looking at keditbookmarks, it seems to do that using QUndoStack::createUndoAction, which makes sure that the action text is always updated from the text of the current undo command. - David On May 12, 2011, 6:55 a.m., Alexander Potashev wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101343/ > ----------------------------------------------------------- > > (Updated May 12, 2011, 6:55 a.m.) > > > Review request for KDE Base Apps and David Faure. > > > Summary > ------- > > konq-plugins/domtreeviewer builds without there functions. > > May be these functions were left for future integration of domtreeviewer undoable commands' into Konqueror's undo stack. But for now, they only add a few translatable strings the user won't ever see. > > > Diffs > ----- > > konq-plugins/domtreeviewer/domtreecommands.h df8272e > konq-plugins/domtreeviewer/domtreecommands.cpp e4c7fff > > Diff: http://git.reviewboard.kde.org/r/101343/diff > > > Testing > ------- > > konq-plugins/domtreeviewer compiles after this change. > > > Thanks, > > Alexander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From faure at kde.org Mon Jun 6 02:53:57 2011 From: faure at kde.org (David Faure) Date: Mon, 06 Jun 2011 01:53:57 -0000 Subject: Review Request: a very little fix In-Reply-To: <20110524161743.24302.96716@vidsolbach.de> References: <20110524161743.24302.96716@vidsolbach.de> Message-ID: <20110606015357.4890.28657@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101433/#review3699 ----------------------------------------------------------- Ship it! Such trivial fixes don't even need to go through reviewboard :) - David On May 24, 2011, 4:17 p.m., Guy Maurel wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101433/ > ----------------------------------------------------------- > > (Updated May 24, 2011, 4:17 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > corrected to the right variable > > > Diffs > ----- > > kdecore/config/kconfigdata.h 0dff4ad > > Diff: http://git.reviewboard.kde.org/r/101433/diff > > > Testing > ------- > > > Thanks, > > Guy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From faure at kde.org Mon Jun 6 02:54:26 2011 From: faure at kde.org (David Faure) Date: Mon, 06 Jun 2011 01:54:26 -0000 Subject: Review Request: Rebuild fake locale as soon as possible In-Reply-To: <20110605002322.2532.5514@vidsolbach.de> References: <20110605002322.2532.5514@vidsolbach.de> Message-ID: <20110606015426.4946.19697@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101509/#review3700 ----------------------------------------------------------- Ship it! Looks good. - David On June 5, 2011, 12:23 a.m., Albert Astals Cid wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101509/ > ----------------------------------------------------------- > > (Updated June 5, 2011, 12:23 a.m.) > > > Review request for kdelibs. > > > Summary > ------- > > By calling locale() instead of d->locale we ensure we kill and rebuild the locale as soon as possible in the chain, since calling functions in klocale can end up calling kglobal::locale again that might kill the fake locale and then we end up in trouble because we just killed ourselves ( see backtrace in https://bugs.kde.org/show_bug.cgi?id=274169 ) > > > This addresses bug 274169. > http://bugs.kde.org/show_bug.cgi?id=274169 > > > Diffs > ----- > > kdecore/kernel/kglobal.cpp 45a6c5a > > Diff: http://git.reviewboard.kde.org/r/101509/diff > > > Testing > ------- > > vlc does not crash anymore. Other apps start fine. > > > Thanks, > > Albert > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From faure at kde.org Mon Jun 6 02:55:02 2011 From: faure at kde.org (David Faure) Date: Mon, 06 Jun 2011 01:55:02 -0000 Subject: Review Request: Fix compile of KIO with KDE_ENABLE_FINAL enabled. In-Reply-To: <20110502213445.17778.39537@vidsolbach.de> References: <20110502213445.17778.39537@vidsolbach.de> Message-ID: <20110606015502.4947.10328@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101277/#review3701 ----------------------------------------------------------- Ship it! Go for it, my friend. - David On May 2, 2011, 9:34 p.m., Nicolas Alvarez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101277/ > ----------------------------------------------------------- > > (Updated May 2, 2011, 9:34 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > kdelibs compilation is broken with KDE4_ENABLE_FINAL turned ON. The first problem is in kio, where there's two file-static functions with the same name (isLocalRequest) and slightly different code. > > Fixed by renaming one of the functions. > > > Diffs > ----- > > kio/kio/accessmanagerreply_p.cpp ccc7474799734b91112d70dc81945b8fe9b9f96c > > Diff: http://git.reviewboard.kde.org/r/101277/diff > > > Testing > ------- > > Compilation of kdelibs/kio with and without final. Didn't try installing or running. > Other parts of kdelibs still don't work with final. > > > Thanks, > > Nicolas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From faure at kde.org Mon Jun 6 03:04:44 2011 From: faure at kde.org (David Faure) Date: Mon, 06 Jun 2011 02:04:44 -0000 Subject: Review Request: KMainWindow::parseGeometry() fails to position with positive coordinates In-Reply-To: <20110603220955.2032.42594@vidsolbach.de> References: <20110603220955.2032.42594@vidsolbach.de> Message-ID: <20110606020444.5726.75909@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101492/#review3702 ----------------------------------------------------------- Looks good overall, but I think I found a bug with negative coordinates: konqueror --geometry +500-100 gives me a window that xwininfo says is at "744x533+500-29", which doesn't match. I have no experience with this, but it seems to me that negative values are "the distance between the bottom of the window and the bottom of the desktop", while the code is trying to use that for the topleft corner of the window instead (i.e. distance between top of window and bottom of desktop)? When I increase the negative value (e.g. -150) nothing happens, then when I use -300 the window starts moving up. - David On June 3, 2011, 10:09 p.m., Urban Widmark wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101492/ > ----------------------------------------------------------- > > (Updated June 3, 2011, 10:09 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > When an X geometry is given on the command line, parseGeometry() will, for positive positions, use geometry().x()/.y() instead of the x/y value parsed from the string. This causes positive positions to not work. > > For negative values the string values are used, but the w/h variables will be used uninitialized unless both a size and position are given. > > No direct bugs reported on this that I can find, but the odd position behavior is noted in some --geometry related bugs: > Comment #6, http://bugs.kde.org/show_bug.cgi?id=165355 > http://bugs.kde.org/show_bug.cgi?id=230663 > > > For the KMainWindow --geometry parsing to work for both size and position, the client application will have to call applyMainWindowSettings() or restoreWindowSize(). The parsing done by KMainWindowPrivate::init() will only set position. Not sure if that is good, as a user of the window I would expect it to use all of the --geometry data at the same time (either on creation or some later call). > > > Diffs > ----- > > kdeui/widgets/kmainwindow.cpp 1d27722 > > Diff: http://git.reviewboard.kde.org/r/101492/diff > > > Testing > ------- > > Using a KApplication program with a KMainWindow that also calls applyMainWindowSettings (keditbookmarks), positions verified using xwininfo: > keditbookmarks --geometry 400x300+100+200 > keditbookmarks --geometry 400x300-100+200 > keditbookmarks --geometry 400x300+100-200 > keditbookmarks --geometry 400x300-100+200 > keditbookmarks --geometry 400x300 > keditbookmarks --geometry +100+200 > keditbookmarks --geometry -400-300 > > Without patch all +coords are replaced by 0. > Negative positions do not account for window decorations as the size of those are not known. I suspect the user will have to adjust for that in their input. > Negative positions also has a problem that parseGeometry(false) is called before keditbookmarks has set a (default) size on the window, so it is 640x480. > > > Thanks, > > Urban > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From faure at kde.org Mon Jun 6 03:10:27 2011 From: faure at kde.org (David Faure) Date: Mon, 06 Jun 2011 02:10:27 -0000 Subject: Review Request: startkde.cmake should treat font dpi like kcontrol/krdb/krdb.cpp does In-Reply-To: <20110601105444.14082.3103@vidsolbach.de> References: <20110601105444.14082.3103@vidsolbach.de> Message-ID: <20110606021027.5880.94742@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101410/#review3703 ----------------------------------------------------------- Ship it! Looks good. Do you want me to commit this for you, or do you want to get a kde contributor account instead, to be able to commit this directly as well as future patches? :) - David On June 1, 2011, 10:54 a.m., Lukas Sommer wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101410/ > ----------------------------------------------------------- > > (Updated June 1, 2011, 10:54 a.m.) > > > Review request for KDE Base Apps, KDE Runtime and kdelibs. > > > Summary > ------- > > I've been experimenting a little bit with custom font dpi sizes in $HOME/.kde4/share/config/kcmfonts > > There, you can set custom font dpi value. Although the user interface (systemsettings/fonts) only provides 0 (don't force a dpi, use the system default instead), 96 and 120 as choice, in the config file you can put (manually) arbitrary values. This works mostly fine because kcontrol/krdb/krdb.cpp simply processes the dpi value of the config file "as is". > > However, startkde.cmake doesn't. It checks if the value is 96 or 120. If not, the value is ignored and the system default is used. > > Result: When you use e.g. 200 as dpi value and restart KDE, then KWin uses the default value (96 dpi on my system) for the window title, while the applications themself are displayed using 200 dpi. So the applications fonts are as big as desired, but the window title is too small. See the attached screenshot. This behaviour is inconsistent. startkde.cmake should follow the same police as kcontrol/krdb/krdb.cpp does. This patch fixes this. > > (The user interface could be adopted in another patch.) > > (Make this work would benefit people who need a high display resolution. Example: You connect your computer to your plasma tv and you want to be still be able to read the text although you are at a distance of 5 meters from the tv monitor. See also bug 272266) > > > This addresses bug 190489. > http://bugs.kde.org/show_bug.cgi?id=190489 > > > Diffs > ----- > > kcontrol/fonts/fonts.h 2c722d4 > kcontrol/fonts/fonts.cpp 0cd2666 > startkde.cmake dde9c23 > > Diff: http://git.reviewboard.kde.org/r/101410/diff > > > Testing > ------- > > I've applied the patch to my local /usr/bin/startkde file, and it works fine. > > > Screenshots > ----------- > > > http://git.reviewboard.kde.org/r/101410/s/171/ > > > Thanks, > > Lukas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From faure at kde.org Mon Jun 6 03:16:27 2011 From: faure at kde.org (David Faure) Date: Mon, 06 Jun 2011 02:16:27 -0000 Subject: Review Request: Fix keypress stealing issue In-Reply-To: <20110602083815.1231.65203@vidsolbach.de> References: <20110602083815.1231.65203@vidsolbach.de> Message-ID: <20110606021627.6041.39511@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101491/#review3704 ----------------------------------------------------------- Ship it! Patch is okay, I didn't realize the issue was that simple to fix ;) I agree that, especially in a component like khtml, all shortcuts should probably be limited to "when the part widget has focus", like you suggest. About the second question, here's my commit log for 60ae8626e917cb1f3: Re-route the old actions "Find Text as You Type" and "Find Links as You Type" to the findbar. Remove them from the menu, since they are redundant with "Find text", but kept two actions just for the shortcuts: '/' will still activate "find text (not just links)", but the shortcut for "find links" is removed by default, advanced users will have to set one again. Otherwise newbies would get confused after pressing the shortcut (was single-quote) by mistake: Esc and Ctrl+F would still find in links only. ========= No strong opinion though, on whether it's really needed to keep the '/' shortcut for compatibility. Let's email all KDE users and ask them... :-) - David On June 2, 2011, 8:38 a.m., Thomas Friedrichsmeier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101491/ > ----------------------------------------------------------- > > (Updated June 2, 2011, 8:38 a.m.) > > > Review request for kdelibs and David Faure. > > > Summary > ------- > > Shortcut context was not set correctly for the new "Find Text as You Type" action, which can result in the khtmlpart "stealing" '/'-keypresses from other widgets in the same main window. This patch would fix that in the most straight-forward fashion. However: > > a) I do wonder, why this is not simply set for *all* applicable actions (including those which do not have a shortcut set by default, but might have a user-configured shortcut!). I.e. something like > > foreach (QAction *action, actionCollection()->actions()) > { > action->setShortcutContext(Qt::WidgetWithChildrenShortcut); > } > > But perhaps I am overlooking something? > > b) This is sort of OT, but I could not help wondering: > I was pretty confused about the difference between Find... and Find Text as You Type. Since Find... really is find-as-you-type, too. Before I finally gathered it from the sources. May I suggest condensing the three actions > - Find... > - Find Text as You Type > - Find Links as You Type > to two actions > - Find Text (with default shortcuts Ctrl+F *and* '/') > - Find Links > > Regards > Thomas > > > Diffs > ----- > > khtml/khtml_part.cpp ec89b0c8083989afb52ebde714e1fe757ab2e387 > > Diff: http://git.reviewboard.kde.org/r/101491/diff > > > Testing > ------- > > > Thanks, > > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.penz19 at gmail.com Mon Jun 6 06:54:07 2011 From: peter.penz19 at gmail.com (Peter Penz) Date: Mon, 06 Jun 2011 05:54:07 -0000 Subject: Review Request: Fix GUI thread blocking caused by KFilePreviewGenerator when disabling preview In-Reply-To: <20110605221320.27623.88979@vidsolbach.de> References: <20110605221320.27623.88979@vidsolbach.de> Message-ID: <20110606055407.12114.70233@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101512/#review3706 ----------------------------------------------------------- Ship it! Thanks, please just go ahead and push the patch! Regarding the suggestions: Locally I've already a replacement of KFilePreviewGenerator that solves the root-cause of issues like this (I've tested it with directories having 20000 files and more). The replacement will be part of Dolphin in 4.8 and might make KFilePreviewGenerator obsolete in the longterm, but we'll see. In any case there are no plans for doing a larger refactoring in KFilePreviewGenerator, only bugfixes and performance improvements like this are fine. - Peter On June 5, 2011, 10:13 p.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101512/ > ----------------------------------------------------------- > > (Updated June 5, 2011, 10:13 p.m.) > > > Review request for kdelibs and Peter Penz. > > > Summary > ------- > > The attached single line patch fixes KFilePreviewGenertor such that it does not completely block the GUI thread and hence lock up the application when you enable and disable preview in a directory that contains large number of files. > > This fix still only solves the problem partially in that the app will no longer lock up for a very long period of time. Instead you get a few second lockup if you have an old machine like mine (Pentium D). It might not be noticable on much faster machines. However, such lock ups are to be expected because of how this class is designed to work. It is one of those few classes that can really benefit from being multi-threaded. Perhaps based on the ideas from http://labs.qt.nokia.com/2010/01/21/qt-graphics-and-performance-generating-content-in-threads/. > > > Diffs > ----- > > kfile/kfilepreviewgenerator.cpp 50a3db7 > > Diff: http://git.reviewboard.kde.org/r/101512/diff > > > Testing > ------- > > The following test was done to confirm the problem as well as to test the fix: > > - In Dolphin or Konqueror, enable HTML file preview. > - Navigate to Qt's html documentation folder (/usr/share/doc/qt/html on my system). > - Turn on preview if it is not already enabled. > - Scroll up and down to see the preview working. > - Disable preview and see what happens. > > > Thanks, > > Dawit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantinos.smanis at gmail.com Sun Jun 5 11:06:45 2011 From: konstantinos.smanis at gmail.com (Konstantinos Smanis) Date: Sun, 5 Jun 2011 13:06:45 +0300 Subject: Review Request: kcm-grub2 In-Reply-To: References:

Message-ID: Raphael Kubo da Costa gmail.com> writes: > > Konstantinos Smanis gmail.com> writes: > > > I have talked with Alberto Mattea (the maintainer of kcmgrub2) and he > > has agreed to give up his request for inclusion in extragear. > > > > Our conversation has been over plain e-mails, so I cannot prove this. > > Perhaps I should contact him to confirm this? > > That sounds like getting rid of dandruff by decapitation ;) I thought > one of you would just rename your project, as it looks like there are > still going to be two projects with almost the exact same name, just not > in the same location in KDE. What's so great about the name? I mean, I don't like it either but kcm-foo is the standard way of naming a KCModule that configures Foo. KCModules need no fancy names like Calligra or Plasma, users won't ever notice them. I am not against renaming, I just don't get why it's such a big issue. From null at kde.org Mon Jun 6 11:56:44 2011 From: null at kde.org (Commit Hook) Date: Mon, 06 Jun 2011 10:56:44 -0000 Subject: Review Request: Rebuild fake locale as soon as possible In-Reply-To: <20110605002322.2532.5514@vidsolbach.de> References: <20110605002322.2532.5514@vidsolbach.de> Message-ID: <20110606105644.26737.37235@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101509/#review3714 ----------------------------------------------------------- This review has been submitted with commit 45bd5256728fdd6ccaa4151acb630c0e69de40bf by Albert Astals Cid. - Commit On June 5, 2011, 12:23 a.m., Albert Astals Cid wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101509/ > ----------------------------------------------------------- > > (Updated June 5, 2011, 12:23 a.m.) > > > Review request for kdelibs. > > > Summary > ------- > > By calling locale() instead of d->locale we ensure we kill and rebuild the locale as soon as possible in the chain, since calling functions in klocale can end up calling kglobal::locale again that might kill the fake locale and then we end up in trouble because we just killed ourselves ( see backtrace in https://bugs.kde.org/show_bug.cgi?id=274169 ) > > > This addresses bug 274169. > http://bugs.kde.org/show_bug.cgi?id=274169 > > > Diffs > ----- > > kdecore/kernel/kglobal.cpp 45a6c5a > > Diff: http://git.reviewboard.kde.org/r/101509/diff > > > Testing > ------- > > vlc does not crash anymore. Other apps start fine. > > > Thanks, > > Albert > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Mon Jun 6 11:57:28 2011 From: null at kde.org (Commit Hook) Date: Mon, 06 Jun 2011 10:57:28 -0000 Subject: Review Request: Rebuild fake locale as soon as possible In-Reply-To: <20110605002322.2532.5514@vidsolbach.de> References: <20110605002322.2532.5514@vidsolbach.de> Message-ID: <20110606105728.26784.96876@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101509/#review3715 ----------------------------------------------------------- This review has been submitted with commit f3c20b170b1ca17504e13c8311f7e56419644594 by Albert Astals Cid. - Commit On June 5, 2011, 12:23 a.m., Albert Astals Cid wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101509/ > ----------------------------------------------------------- > > (Updated June 5, 2011, 12:23 a.m.) > > > Review request for kdelibs. > > > Summary > ------- > > By calling locale() instead of d->locale we ensure we kill and rebuild the locale as soon as possible in the chain, since calling functions in klocale can end up calling kglobal::locale again that might kill the fake locale and then we end up in trouble because we just killed ourselves ( see backtrace in https://bugs.kde.org/show_bug.cgi?id=274169 ) > > > This addresses bug 274169. > http://bugs.kde.org/show_bug.cgi?id=274169 > > > Diffs > ----- > > kdecore/kernel/kglobal.cpp 45a6c5a > > Diff: http://git.reviewboard.kde.org/r/101509/diff > > > Testing > ------- > > vlc does not crash anymore. Other apps start fine. > > > Thanks, > > Albert > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcooksley at kde.org Mon Jun 6 12:05:52 2011 From: bcooksley at kde.org (Ben Cooksley) Date: Mon, 6 Jun 2011 23:05:52 +1200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 Message-ID: Hi all, I am requesting that a moratorium on dependency bumps for dependencies which are "hard to build" be enacted. This would affect system wide components which rely on root access and are heavily integrated into the system. This would not affect things such as UPower or the like - which aren't heavily integrated - but only heavily integrated things such as the kernel, X and ALSA. Over the past few months it has become increasingly hard to use a distribution which isn't even 1 year old to build KDE trunk. Custom patches, disabled features and compilation failures are fairly common, and represent an extreme barrier to contribution. This would only affect releases after KDE 4.7. Regards, Ben From ervin at kde.org Mon Jun 6 13:46:03 2011 From: ervin at kde.org (Kevin Ottens) Date: Mon, 6 Jun 2011 14:46:03 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE Frameworks In-Reply-To: References: Message-ID: <201106061446.09951.ervin@kde.org> On Monday 6 June 2011 13:05:52 Ben Cooksley wrote: > Over the past few months it has become increasingly hard to use a > distribution which isn't even 1 year old to build KDE trunk. Custom > patches, disabled features and compilation failures are fairly common, > and represent an extreme barrier to contribution. This would only > affect releases after KDE 4.7. Could we talk about more specifics please? I'm not sure where this discussion should go on that ground. Also, I'm generally not a huge fan of creating a policy if that's only a transitional problem, or only a couple of specific dependencies which are painful to deal with. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From null at kde.org Mon Jun 6 16:09:24 2011 From: null at kde.org (Commit Hook) Date: Mon, 06 Jun 2011 15:09:24 -0000 Subject: Review Request: Fix GUI thread blocking caused by KFilePreviewGenerator when disabling preview In-Reply-To: <20110605221320.27623.88979@vidsolbach.de> References: <20110605221320.27623.88979@vidsolbach.de> Message-ID: <20110606150924.10335.7019@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101512/#review3722 ----------------------------------------------------------- This review has been submitted with commit df13ea277bdc314eacbf67b6d6a7b2a3fa7fbaa5 by Dawit Alemayehu. - Commit On June 5, 2011, 10:13 p.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101512/ > ----------------------------------------------------------- > > (Updated June 5, 2011, 10:13 p.m.) > > > Review request for kdelibs and Peter Penz. > > > Summary > ------- > > The attached single line patch fixes KFilePreviewGenertor such that it does not completely block the GUI thread and hence lock up the application when you enable and disable preview in a directory that contains large number of files. > > This fix still only solves the problem partially in that the app will no longer lock up for a very long period of time. Instead you get a few second lockup if you have an old machine like mine (Pentium D). It might not be noticable on much faster machines. However, such lock ups are to be expected because of how this class is designed to work. It is one of those few classes that can really benefit from being multi-threaded. Perhaps based on the ideas from http://labs.qt.nokia.com/2010/01/21/qt-graphics-and-performance-generating-content-in-threads/. > > > Diffs > ----- > > kfile/kfilepreviewgenerator.cpp 50a3db7 > > Diff: http://git.reviewboard.kde.org/r/101512/diff > > > Testing > ------- > > The following test was done to confirm the problem as well as to test the fix: > > - In Dolphin or Konqueror, enable HTML file preview. > - Navigate to Qt's html documentation folder (/usr/share/doc/qt/html on my system). > - Turn on preview if it is not already enabled. > - Scroll up and down to see the preview working. > - Disable preview and see what happens. > > > Thanks, > > Dawit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph at maxiom.de Mon Jun 6 16:31:37 2011 From: christoph at maxiom.de (Christoph Feck) Date: Mon, 06 Jun 2011 15:31:37 -0000 Subject: Review Request: Fix possible memory and D-Bus connection leak in KStatusNotifierItem Message-ID: <20110606153137.11609.26909@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101527/ ----------------------------------------------------------- Review request for kdelibs, Plasma and Marco Martin. Summary ------- According to bug 261180 there is a D-Bus connection leak in KStatusNotifierItem. This patch potentially fixes it, but I do not know how to test it. This addresses bug 261180. http://bugs.kde.org/show_bug.cgi?id=261180 Diffs ----- kdeui/notifications/kstatusnotifieritem.cpp c48ed50 Diff: http://git.reviewboard.kde.org/r/101527/diff Testing ------- Thanks, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgraesslin at kde.org Mon Jun 6 16:48:41 2011 From: mgraesslin at kde.org (Martin =?ISO-8859-1?Q?Gr=E4=DFlin?=) Date: Mon, 06 Jun 2011 17:48:41 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: References: Message-ID: <5130765.7m7Pas7BAs@martin-desktop> On Monday 06 June 2011 23:05:52 Ben Cooksley wrote: > Hi all, > > I am requesting that a moratorium on dependency bumps for dependencies > which are "hard to build" be enacted. This would affect system wide > components which rely on root access and are heavily integrated into > the system. This would not affect things such as UPower or the like - > which aren't heavily integrated - but only heavily integrated things > such as the kernel, X and ALSA. For what modules do you want such a moratorium? Given that you mailed core-devel I assume the Plattform. There I am very sure that we do not need to expect an X12 before KDE 4.8 is released ;-) But given that you mention X I rather think you want to have a moratorium for the Workspaces. In that case please take the request to Plasma devel so that we can discuss raised requirements on a per-component base. A general "moratorium" just looks like a wonderful way to do bike-shedding. > > Over the past few months it has become increasingly hard to use a > distribution which isn't even 1 year old to build KDE trunk. Custom > patches, disabled features and compilation failures are fairly common, > and represent an extreme barrier to contribution. This would only > affect releases after KDE 4.7. Personal opinion: I think it is impossible to want to run the latest software around an old stack. The overall FOSS world is rolling release with everything depending on everything. I cannot see why you want to change that with a moratorium. Cheers Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From thiago at kde.org Mon Jun 6 17:53:24 2011 From: thiago at kde.org (Thiago Macieira) Date: Mon, 06 Jun 2011 18:53:24 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <5130765.7m7Pas7BAs@martin-desktop> References: <5130765.7m7Pas7BAs@martin-desktop> Message-ID: <13788778.c49pUyIHfV@lothlorien> On Monday, 6 de June de 2011 17:48:41 Martin Gräßlin wrote: > Personal opinion: I think it is impossible to want to run the latest > software around an old stack. The overall FOSS world is rolling release > with everything depending on everything. I cannot see why you want to > change that with a moratorium. I agree on that, but I disagree on the age of the "old stack". For example, I'm running the Mandriva rolling-release right now and I can't compile kdepim and kdepimlibs because they haven't packaged yet shared-desktop-ontologies 0.7. That was released less than one month ago. I'd say that hard dependencies need to be at least a couple of months old, unless there's a very good reason for doing otherwise. And in that case, it should be announced in advance so that distributions and users can prepare themselves. * Shared desktop ontologies (0.6.51 or higher) Desktop ontologies Ontologies necessary for the Nepomuk semantic desktop. Download & date: http://sourceforge.net/projects/oscaf/files/shared-desktop-ontologies/0.7/ -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From sebas at kde.org Mon Jun 6 18:26:38 2011 From: sebas at kde.org (Sebastian =?ISO-8859-1?Q?K=FCgler?=) Date: Mon, 06 Jun 2011 19:26:38 +0200 Subject: The Future of our Frameworks Message-ID: <21091853.laQfrAgJOr@marvin.vizzzion.net> Hi all, You've probably been aware that a rather sizable group of KDE developers and stakeholders in our development platform is meeting in Randa, Switzerland to discuss the future of our development frameworks, with the big topic being "modularization of kdelibs". We've had a number of great discussions here about various technical and process-related topics. We are still in the process of making the results digestable, transforming our notes into something that is understandable for those that haven't been able to participate in these -- very productive -- sessions in person. Let me already give you some information on the bigger picture we came up with here, as you are all probably very curious about that. The overall theme was the modularization of kdelibs, kde-runtime, kdepimlibs, kdepim-runtine and kdesupport. With Qt5 -- a change in binary interface -- having been announced, it is a good point in time to introduce some changes to our frameworks that are only possible if we change the ABI -- which Qt5 will do for us anyway. What is the scope? Instead of Platform, we want to consistently use the term "Frameworks", this includes what we currently refer to as kdelibs, kdepimlibs, kde-runtime, kdepim-runtime and kdesupport. We explicitely are not talking about our apps and workspaces, but read on. What do we want to achieve, and why? We want to make it possible to use our frameworks in Qt projects without significant additional dependencies. This means: * We reach out to the Qt development community in a more focused way * We make it easier to use our frameworks * We lower the barrier for contributions * We make our frameworks more suitable for mobile and device-spectrum use cases * We make it possible to select a specific set of features developers would like to use * We improve our QA processes, leading to better quality apps and frameworks We want this to happen with ... * ... no disruption for our users * ... little to no source incompatibilities * ... most apps not needing any significant changes * ... changes, if at all necessary being kept to a minimum What does it mean for users? * No disruption * Most probably invisible * Short term: Iit becomes easier to run kDE apps outside of the Plasma workspaces, including other operating systems * Longer term: We will probably see more apps using KDE technology What does it mean for developers? * We will maintain source compabitility as much as possible * The impact for existing apps will be minimal * We will provide a compabitility library as additional measure to reduce the impact of these changes What does it mean for packagers? * We make it possible to ship our frameworks in a more modular way * We also plan to provide "monolithic tarballs" much as we do now, depending on the needs and preferences of downstreams Please note that this is *not* KDE5, as it doesn't refer to our community, but about our development frameworks. At this point there is also no benefit in talking about KDE 5, since that just opens the door to misinformation. This is also clearly not about our workspaces, or applications. (See http://vizzzion.org/blog/2011/06/there-is-no-kde5/ for a quick explanation.) In order to prevent this thread from growing into an unmanageable load of hundreds of emails, please post specific questions as separate threads. (You can of course reply with praise to this, but anything that is likely to spark a more detailed discussion is probably better off in a separate thread.) Thanks for your attention, and cheers from a wonderful Switzerland, -- sebas, on behalf of the KDE Frameworks team http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 _______________________________________________ This message is from the kde-promo mailing list. Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription. From faure at kde.org Mon Jun 6 19:04:38 2011 From: faure at kde.org (David Faure) Date: Mon, 6 Jun 2011 20:04:38 +0200 Subject: Creating a public pixmap overlays method based on icon overlays? In-Reply-To: <201106022253.55966.mat69@gmx.net> References: <201106022253.55966.mat69@gmx.net> Message-ID: <201106062004.39151.faure@kde.org> On Thursday 02 June 2011, Matthias Fuchs wrote: > Hi, > > I was looking at BUG:190579 [1] and realised that there is a general > problem in KDE that does not only apply to folders: > As soon as you have preview enabled you won't get any more icon overlays > for images, no matter if you look at images directly or at folders > containing images (the later most likely because the previews are pointed > over the overlay). > > So I thought what should be done is to also display overlays for previews. > Yet the overlay method only applies to icons at the moment. [2] > > The code that is used [3] can be easily adpated to pixmaps not having the > same width and height. [4] > I even tried it and it looks good enough in my opinion. > > Now I need your feedback: > Should a more general method like that be added? > Should that method be used for previews and also KIconLoader? > And where should such a method be placed, I mean in which header? Well, it sound like it should be a KIconLoader method since it actually needs KIconLoader to load the overlay icons (line 393). So basically this would just mean making drawOverlays public, AFAICS. -- David Faure, faure at kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). From bcooksley at kde.org Mon Jun 6 19:19:52 2011 From: bcooksley at kde.org (Ben Cooksley) Date: Tue, 7 Jun 2011 06:19:52 +1200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <5130765.7m7Pas7BAs@martin-desktop> References: <5130765.7m7Pas7BAs@martin-desktop> Message-ID: On Tue, Jun 7, 2011 at 3:48 AM, Martin Gräßlin wrote: > On Monday 06 June 2011 23:05:52 Ben Cooksley wrote: >> Hi all, >> >> I am requesting that a moratorium on dependency bumps for dependencies >> which are "hard to build" be enacted. This would affect system wide >> components which rely on root access and are heavily integrated into >> the system. This would not affect things such as UPower or the like - >> which aren't heavily integrated - but only heavily integrated things >> such as the kernel, X and ALSA. > For what modules do you want such a moratorium? Given that you mailed core-devel I > assume the Plattform. There I am very sure that we do not need to expect an X12 before KDE > 4.8 is released ;-) But given that you mention X I rather think you want to have a moratorium > for the Workspaces. In that case please take the request to Plasma devel so that we can > discuss raised requirements on a per-component base. A general "moratorium" just looks like > a wonderful way to do bike-shedding. The Moratorium would extend to all components of the KDE SC distribution. Hence kde-core-devel. >> >> Over the past few months it has become increasingly hard to use a >> distribution which isn't even 1 year old to build KDE trunk. Custom >> patches, disabled features and compilation failures are fairly common, >> and represent an extreme barrier to contribution. This would only >> affect releases after KDE 4.7. > Personal opinion: I think it is impossible to want to run the latest software around an old stack. > The overall FOSS world is rolling release with everything depending on everything. I cannot > see why you want to change that with a moratorium. Other than the very recent incompatibility in the "hard to build" dependencies, a distribution which is less than 1 year old is fine to build KDE. Ocassionally it may be needed to build something such as Clucene from source (which is ok - clucene is not hard to build). The components affected by the Moratorium - namely the Kernel, X and ALSA interfaces are not easy to build. For those of us on non-rolling release distributions the only way to usually get newer versions is a complete system upgrade. That assumes that the latest release has that - more conservative releases might not. > > Cheers > Martin Regards, Ben From mgraesslin at kde.org Mon Jun 6 19:55:54 2011 From: mgraesslin at kde.org (Martin =?ISO-8859-1?Q?Gr=E4=DFlin?=) Date: Mon, 06 Jun 2011 20:55:54 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: References: <5130765.7m7Pas7BAs@martin-desktop> Message-ID: <1605992.40JvaOBKcv@martin-desktop> On Tuesday 07 June 2011 06:19:52 Ben Cooksley wrote: > On Tue, Jun 7, 2011 at 3:48 AM, Martin Gräßlin wrote: > > On Monday 06 June 2011 23:05:52 Ben Cooksley wrote: > >> Hi all, > >> > >> I am requesting that a moratorium on dependency bumps for dependencies > >> which are "hard to build" be enacted. This would affect system wide > >> components which rely on root access and are heavily integrated into > >> the system. This would not affect things such as UPower or the like - > >> which aren't heavily integrated - but only heavily integrated things > >> such as the kernel, X and ALSA. > > For what modules do you want such a moratorium? Given that you mailed core-devel I > > assume the Plattform. There I am very sure that we do not need to expect an X12 before KDE > > 4.8 is released ;-) But given that you mention X I rather think you want to have a moratorium > > for the Workspaces. In that case please take the request to Plasma devel so that we can > > discuss raised requirements on a per-component base. A general "moratorium" just looks like > > a wonderful way to do bike-shedding. > > The Moratorium would extend to all components of the KDE SC > distribution. Hence kde-core-devel. Sorry, but I think this is a very, very bad idea. I cannot judge what requirements e.g. kdepim needs, nor can kdepim developers decide what requirements the workspaces need. The decision on the requirements has to be with the developers who write the code. Communicating such changes is as Thiago's mail shows of course required. > > >> > >> Over the past few months it has become increasingly hard to use a > >> distribution which isn't even 1 year old to build KDE trunk. Custom > >> patches, disabled features and compilation failures are fairly common, > >> and represent an extreme barrier to contribution. This would only > >> affect releases after KDE 4.7. > > Personal opinion: I think it is impossible to want to run the latest software around an old stack. > > The overall FOSS world is rolling release with everything depending on everything. I cannot > > see why you want to change that with a moratorium. > > Other than the very recent incompatibility in the "hard to build" > dependencies, a distribution which is less than 1 year old is fine to > build KDE. Ocassionally it may be needed to build something such as > Clucene from source (which is ok - clucene is not hard to build). > > The components affected by the Moratorium - namely the Kernel, X and > ALSA interfaces are not easy to build. For those of us on non-rolling > release distributions the only way to usually get newer versions is a > complete system upgrade. That assumes that the latest release has that > - more conservative releases might not. I think your examples are rather bad. I do not know about anything in KDE hard-depending on a specific Kernel, X or Alsa version. If at all those are optional dependencies, so why a moratorium? Cheers Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From einar at heavensinferno.net Mon Jun 6 20:05:41 2011 From: einar at heavensinferno.net (Luca Beltrame) Date: Mon, 06 Jun 2011 21:05:41 +0200 Subject: Modularization and other languages' bindings (was: The Future of our Frameworks) In-Reply-To: <21091853.laQfrAgJOr@marvin.vizzzion.net> References: <21091853.laQfrAgJOr@marvin.vizzzion.net> Message-ID: <1798456.Lx7osU5OF4@leon.lan> In data Monday 06 June 2011 19:26:38, Sebastian Kügler ha scritto: (I took the liberty of adding kde-bindings to the CC of tihs specific topic) > We want to make it possible to use our frameworks in Qt projects without > significant additional dependencies. This means: Reading around the plans and this mails, I'd like to ask if bindings for interpreted languages (aside ECMAScript, which has a more or less official blessing thanks to QtScript and friends), were put into the equation. The reason is simple: those too contribute to lowering the barrier of entry for developers, especially the audience that has not a C++ programming background. If things are adjusted (without breaking things), it would be a perfect opportunity to involve the bindings people in the process. > * The impact for existing apps will be minimal Again, this is also a perfect opportunity to get the bindings team on board, to ensure that the changes will not maim the bindings themselves. Notice that this is not a criticism of what's has been done so far: on the contrary, I think the effort is sorely needed. I would just like to point out the existence of these realities (bindings) that albeit small, contribute their little to the use of KDE. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: -------------- next part -------------- _______________________________________________ Kde-bindings mailing list Kde-bindings at kde.org https://mail.kde.org/mailman/listinfo/kde-bindings From aseigo at kde.org Mon Jun 6 21:06:06 2011 From: aseigo at kde.org (Aaron J. Seigo) Date: Mon, 06 Jun 2011 22:06:06 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: References: <5130765.7m7Pas7BAs@martin-desktop> Message-ID: <17911809.h6xGmj1gbX@freedom> On Tuesday, June 7, 2011 06:19:52 Ben Cooksley wrote: > The Moratorium would extend to all components of the KDE SC > distribution. Hence kde-core-devel. imho this is impossible, for the reasons Martin noted. > The components affected by the Moratorium - namely the Kernel, X and > ALSA interfaces are not easy to build. For those of us on non-rolling can you provide an answer to Kevin's initial question, namely: what are the actual cases that triggered this concern? e.g. what currently relies on a recent kernel, X or alsa? for the same sort of reasons we can not make a all-SC decision, it's very hard to have a productive discusson without examples to demonstrate the problem which can then be analyzed and understood. since you mentioned custom patches, disable features and compilation failures, you must have at least a couple of them :) -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bcooksley at kde.org Mon Jun 6 21:29:51 2011 From: bcooksley at kde.org (Ben Cooksley) Date: Tue, 7 Jun 2011 08:29:51 +1200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <17911809.h6xGmj1gbX@freedom> References: <5130765.7m7Pas7BAs@martin-desktop> <17911809.h6xGmj1gbX@freedom> Message-ID: On Tue, Jun 7, 2011 at 8:06 AM, Aaron J. Seigo wrote: > On Tuesday, June 7, 2011 06:19:52 Ben Cooksley wrote: >> The Moratorium would extend to all components of the KDE SC >> distribution. Hence kde-core-devel. > > imho this is impossible, for the reasons Martin noted. > >> The components affected by the Moratorium - namely the Kernel, X and >> ALSA interfaces are not easy to build. For those of us on non-rolling > > can you provide an answer to Kevin's initial question, namely: what are the > actual cases that triggered this concern? e.g. what currently relies on a > recent kernel, X or alsa? I have two examples, Phonon and KWin. First Phonon. The Xine backend has now been deprecated, and has already broken in applications such as Amarok. The VLC backend gives me terrible skipping. Apparently upgrading to a newer version of VLC is needed to use it - but that depends on XCB 1.6. I only have 1.5. Phonon GStreamer - whilst installable, crashes applications on startup - and is therefore unusable. This effectively removes the capability to have multimedia playback using a KDE application. I tried (unsuccessfully unfortunately) to backport some of the fixes which would fix the skipping in Phonon VLC - but that didn't work. Next KWin. It currently depends upon Mesa 7.10. I have a local revert in a private local branch which reverts the dependency check code within KWin to continue to allow me to use compositing. Even though I have Mesa 7.8, I rarely experience KWin crashes - it has only crashed once in the past 2 months. I use an Intel Ironlake based graphics. This patch of mine works perfectly and does not cause any issues. Both of these are requiring new versions of X. > > for the same sort of reasons we can not make a all-SC decision, it's very hard > to have a productive discusson without examples to demonstrate the problem > which can then be analyzed and understood. > > since you mentioned custom patches, disable features and compilation failures, > you must have at least a couple of them :) Whilst the compilation failures don't exist at the moment, I have one working patch - and several that have failed (and don't compile) > > -- > 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 > Regards, Ben From aseigo at kde.org Mon Jun 6 21:38:19 2011 From: aseigo at kde.org (Aaron J. Seigo) Date: Mon, 06 Jun 2011 20:38:19 -0000 Subject: Review Request: Fix possible memory and D-Bus connection leak in KStatusNotifierItem In-Reply-To: <20110606153137.11609.26909@vidsolbach.de> References: <20110606153137.11609.26909@vidsolbach.de> Message-ID: <20110606203819.25945.33626@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101527/#review3726 ----------------------------------------------------------- i doubt this fix is correct. what looks more like is KStatusNotifierItemDBus::~KStatusNotifierItemDBus(). right now this is the implementation: m_dbus.unregisterService(m_service); and perhaps it should include: m_dbus.unregisterObject("/StatusNotifierItem", this); and perhaps even: m_dbus.disconnectFromBus(m_service); (though i expect the latter is done automatically when QDBusConnection is deleted? maybe not though...) kdeui/notifications/kstatusnotifieritem.cpp statusNotifierItemDBus is initialized this way: statusNotifierItemDBus = new KStatusNotifierItemDBus(q); where 'q' is the QObject-derived StatusNotifierItem. and here is the constructor: KStatusNotifierItemDBus::KStatusNotifierItemDBus(KStatusNotifierItem *parent) : QObject(parent), so i'd be very surprised if it wasn't being deleted when KStatusNotifierItem is deleted. can you confirm that it is not being deleted by putting some debug output in ~KStatusNotifierItemDBus? - Aaron J. On June 6, 2011, 3:31 p.m., Christoph Feck wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101527/ > ----------------------------------------------------------- > > (Updated June 6, 2011, 3:31 p.m.) > > > Review request for kdelibs, Plasma and Marco Martin. > > > Summary > ------- > > According to bug 261180 there is a D-Bus connection leak in KStatusNotifierItem. This patch potentially fixes it, but I do not know how to test it. > > > This addresses bug 261180. > http://bugs.kde.org/show_bug.cgi?id=261180 > > > Diffs > ----- > > kdeui/notifications/kstatusnotifieritem.cpp c48ed50 > > Diff: http://git.reviewboard.kde.org/r/101527/diff > > > Testing > ------- > > > Thanks, > > Christoph > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Plasma-devel mailing list Plasma-devel at kde.org https://mail.kde.org/mailman/listinfo/plasma-devel From mgraesslin at kde.org Mon Jun 6 21:42:18 2011 From: mgraesslin at kde.org (Martin =?ISO-8859-1?Q?Gr=E4=DFlin?=) Date: Mon, 06 Jun 2011 22:42:18 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: References: <17911809.h6xGmj1gbX@freedom> Message-ID: <1335160.Fc7ClmKFtQ@martin-desktop> On Tuesday 07 June 2011 08:29:51 Ben Cooksley wrote: > Next KWin. It currently depends upon Mesa 7.10. I have a local revert > in a private local branch which reverts the dependency check code > within KWin to continue to allow me to use compositing. Even though I > have Mesa 7.8, I rarely experience KWin crashes - it has only crashed > once in the past 2 months. I use an Intel Ironlake based graphics. > This patch of mine works perfectly and does not cause any issues. KWin does *not* depend on Mesa 7.10! KWin does not have any build dependencies on Mesa. There is an optional build dependency on OpenGL and XComposite/XDamage. This all is optional! If you use Mesa drivers there is a runtime requirement for at least Mesa 7.10, whose reasons have been explained to you on plasma-devel. Given what you demand this is out of scope as it is not a build dependency. It is just that you don't get the latest features when not having the correct runtime dependency. I might add that using different drivers (NVIDIA or ATI blob as well as GLES/EGL Mesa drivers) do not have this runtime requirement. It is also still possible to use KWin with XRender or without compositing at all. Btw. patches to have an environment variable to overwrite all checks are welcome. Please also note that I will add a runtime requirement to Mesa 7.11 as I have here on my system the start of the Wayland port which will be in 4.8 and requires Mesa 7.11. Cheers Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From richard.dale at telefonica.net Mon Jun 6 21:41:43 2011 From: richard.dale at telefonica.net (Richard Dale) Date: Mon, 6 Jun 2011 21:41:43 +0100 Subject: Modularization and other languages' bindings (was: The Future of our Frameworks) In-Reply-To: <1798456.Lx7osU5OF4@leon.lan> References: <21091853.laQfrAgJOr@marvin.vizzzion.net> <1798456.Lx7osU5OF4@leon.lan> Message-ID: <201106062141.44164.richard.dale@telefonica.net> On Monday, June 06, 2011 08:05:41 PM Luca Beltrame wrote: > In data Monday 06 June 2011 19:26:38, Sebastian Kügler ha scritto: > > (I took the liberty of adding kde-bindings to the CC of tihs specific > topic) > > > We want to make it possible to use our frameworks in Qt projects without > > > significant additional dependencies. This means: > Reading around the plans and this mails, I'd like to ask if bindings for > interpreted languages (aside ECMAScript, which has a more or less official > blessing thanks to QtScript and friends), were put into the equation. I wouldn't say that QtScript has official blessing from Nokia Framworks, in the sense that there is a language bindings project which wraps both the Qt and KDE apis for QtScript programming. Obviously QtScript and QML and both first class citizens in the Qt libraries, but that doesn't mean there are any language bindings similar to PyQt, PySide, QtRuby etc for them. There was a project by Kent Hansen to wrap the Qt apis, which was very large in terms of memory usage and I'm not sure if it is currently maintained. I don't know if anyone ever tried to extend it to cover the KDE apis. I started another QtScript bindings project called 'JSmoke' which is currently stalled because of technical problems with QtScript which got even worse moving from Qt 4.5 to 4.6. That did cover both the Qt and KDE apis, and I really should try and see if it could be made viable for Qt 4.7. > The reason is simple: those too contribute to lowering the barrier of entry > for developers, especially the audience that has not a C++ programming > background. If things are adjusted (without breaking things), it would be a > perfect opportunity to involve the bindings people in the process. The Qt and KDE apis are mainly quite well designed from the point of view of bindings developers. Things like smart pointers in the public apis (as opposed to in the d- pointers) are a bad idea (cf KConfig) Overloading on 'const-ness' is a bad idea for bindings (cf QDBusArgument and KSharedConfig). References to primitive types that are expected to last longer than a method call are a bad idea (cf KConfigSkeleton). But really a large proportion of the apis can be wrapped pretty automatically. > > * The impact for existing apps will be minimal > > Again, this is also a perfect opportunity to get the bindings team on > board, to ensure that the changes will not maim the bindings themselves. > > Notice that this is not a criticism of what's has been done so far: on the > contrary, I think the effort is sorely needed. I would just like to point > out the existence of these realities (bindings) that albeit small, > contribute their little to the use of KDE. I am personally all in favour of the current efforts in making the the kde libs more modular, and allowing people to use a simpler subset if they want. That helps with both targeting at different devices, and it also helps with the learning curve if someone just wants to do a Plasma based widget and only wants to learn about the minimum subset of KDE api calls that they need to do that. -- Richard From bcooksley at kde.org Mon Jun 6 21:51:26 2011 From: bcooksley at kde.org (Ben Cooksley) Date: Tue, 7 Jun 2011 08:51:26 +1200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <1335160.Fc7ClmKFtQ@martin-desktop> References: <17911809.h6xGmj1gbX@freedom> <1335160.Fc7ClmKFtQ@martin-desktop> Message-ID: On Tue, Jun 7, 2011 at 8:42 AM, Martin Gräßlin wrote: > On Tuesday 07 June 2011 08:29:51 Ben Cooksley wrote: >> Next KWin. It currently depends upon Mesa 7.10. I have a local revert >> in a private local branch which reverts the dependency check code >> within KWin to continue to allow me to use compositing. Even though I >> have Mesa 7.8, I rarely experience KWin crashes - it has only crashed >> once in the past 2 months. I use an Intel Ironlake based graphics. >> This patch of mine works perfectly and does not cause any issues. > KWin does *not* depend on Mesa 7.10! KWin does not have any build dependencies on Mesa. > There is an optional build dependency on OpenGL and XComposite/XDamage. This all is optional! > If you use Mesa drivers there is a runtime requirement for at least Mesa 7.10, whose reasons > have been explained to you on plasma-devel. > > Given what you demand this is out of scope as it is not a build dependency. It is just that you > don't get the latest features when not having the correct runtime dependency. I might add that > using different drivers (NVIDIA or ATI blob as well as GLES/EGL Mesa drivers) do not have this > runtime requirement. It is also still possible to use KWin with XRender or without compositing at > all. Btw. patches to have an environment variable to overwrite all checks are welcome. > > Please also note that I will add a runtime requirement to Mesa 7.11 as I have here on my system > the start of the Wayland port which will be in 4.8 and requires Mesa 7.11. Now that is absolutely overboard. OpenSUSE 11.4 isn't even 3 months old. And has Mesa 7.10. You are effectively classifying a distribution as unsuitable for trunk development. You are now depending on components which aren't even in released distributions! (Note that having to live with a desktop without compositing isn't exactly what I would call usable for the long run) > > Cheers > Martin Regards, Ben From neundorf at kde.org Mon Jun 6 21:55:39 2011 From: neundorf at kde.org (Alexander Neundorf) Date: Mon, 6 Jun 2011 22:55:39 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <5130765.7m7Pas7BAs@martin-desktop> References: <5130765.7m7Pas7BAs@martin-desktop> Message-ID: <201106062255.40286.neundorf@kde.org> On Monday, June 06, 2011 05:48:41 PM Martin Gräßlin wrote: ... > Personal opinion: I think it is impossible to want to run the latest > software around an old stack. The overall FOSS world is rolling release > with everything depending on everything. You cannot say it like that. It depends always on the developers of the respective applications. CMake is at 2.8.4 since 3 months or so, and we are still Ok with 2.6.4. Alex From richard.dale at telefonica.net Mon Jun 6 21:51:08 2011 From: richard.dale at telefonica.net (Richard Dale) Date: Mon, 6 Jun 2011 21:51:08 +0100 Subject: [Kde-bindings] Re: Modularization and other languages' bindings (was: The Future of our Frameworks) In-Reply-To: <201106062141.44164.richard.dale@telefonica.net> References: <21091853.laQfrAgJOr@marvin.vizzzion.net> <1798456.Lx7osU5OF4@leon.lan> <201106062141.44164.richard.dale@telefonica.net> Message-ID: <201106062151.08377.richard.dale@telefonica.net> On Monday, June 06, 2011 09:41:43 PM Richard Dale wrote: > I started another QtScript bindings project called 'JSmoke' which is > currently stalled because of technical problems with QtScript which got > even worse moving from Qt 4.5 to 4.6. That did cover both the Qt and KDE > apis, and I really should try and see if it could be made viable for Qt > 4.7. Sorry, a small but important correction - Ian Monroe started this project, not me. -- Richard >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << From mo85 at cornell.edu Mon Jun 6 22:08:24 2011 From: mo85 at cornell.edu (Maksim Orlovich) Date: Mon, 6 Jun 2011 17:08:24 -0400 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <1335160.Fc7ClmKFtQ@martin-desktop> References: <17911809.h6xGmj1gbX@freedom> <1335160.Fc7ClmKFtQ@martin-desktop> Message-ID: > Please also note that I will add a runtime requirement to Mesa 7.11 as I > have here on my system > the start of the Wayland port which will be in 4.8 and requires Mesa 7.11. Why would wayland support have any effect on runtime dependency on X11? From thomas.luebking at gmail.com Mon Jun 6 22:46:47 2011 From: thomas.luebking at gmail.com (Thomas =?UTF-8?B?TMO8Ymtpbmc=?=) Date: Mon, 6 Jun 2011 23:46:47 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: References: <17911809.h6xGmj1gbX@freedom> <1335160.Fc7ClmKFtQ@martin-desktop> Message-ID: <20110606234647.2938c667@gmail.com> Am Mon, 6 Jun 2011 17:08:24 -0400 schrieb Maksim Orlovich : > Why would wayland support have any effect on runtime dependency on > X11? http://groups.google.com/group/wayland-display-server/web/building-and-running-wayland Building mesa Wayland uses the mesa EGL stack, and all extensions required to run EGL on KMS are...... Cheers, Thomas From ervin at kde.org Mon Jun 6 23:04:41 2011 From: ervin at kde.org (Kevin Ottens) Date: Tue, 7 Jun 2011 00:04:41 +0200 Subject: Intended organization of KDE Frameworks Message-ID: <201106070004.52120.ervin@kde.org> Hello lists, As, Sebas pointed out we've been meeting here to work on plans to improve our frameworks offering leading to the decision of leaving the current "kdelibs model" behind and prepare for a more modular suite named KDE Frameworks. If you didn't read his email yet, please do so before going back to this email. Currently, our set of base frameworks is mainly kdesupport, kdelibs and kdepimlibs. Apart from kdesupport which is now splitted, kdelibs and kdepimlibs are collections of libraries. That leads to hiding internal dependencies in those modules, especially in kdelibs, and some of the libraries are more dumping grounds than proper frameworks with a purpose. The new model we're moving to will help us have clearer dependencies and push us toward a more modularized offer. Among other benefits, it will make it easier for third party developers to use our frameworks, and it should also make contributions easier. = Overall organization = In the new KDE Frameworks organization, we're aiming at sorting our libraries along two axes. The first axis deals with the runtime dependencies (organized in Framework Types) while the second axis deals with the link time dependencies (organized in Tiers). The position of a library along of those two axis is mainly a stamp or a label we put on a library, it will come with responsibilities though, and will help us find how to improve a library. In the following lines, we're going to describe the rules summarized in this graph: http://files.kde.org/ervin/platform11/kde-frameworks-matrix.pdf == Framework Types == We will have now three Framework Types: Solutions, Qt Addons (OS Integration) and Qt Addons (Functional). They mainly differ in their runtime dependencies. * Functional Qt Addons shall not have any runtime dependency (think for instance of a split libkconfig, it would drag no runtime at all); * OS Integration Qt Addons can have optional runtime dependencies, if the OS supports the feature they shall use OS facilities, otherwise a runtime dependency might be used to implement the feature (think for instance of a split libkdatetime, it would use ktimezoned on Linux, but on Windows it would directly use Windows APIs); * Solutions implement a full technology or stack, including a library and mandatory runtime dependencies: plugins, servers, etc. (think for instance of Akonadi, KIO or Soprano). == Tiers == The goal of Tiers is to clarify the link time dependencies of our libraries. * Tier 1 frameworks depend only on Qt itself and no other Qt based framework; * Tier 2 frameworks depend only on Qt and Tier 1 frameworks; * Tier 3 frameworks can depend on any Tier 1, 2 or 3 frameworks. == Look & Feel + Consistency == Obviously the naming of that category is difficult. It will contain all the frameworks which won't fit in the nice categories described above. The purpose of those frameworks will be: * to ensure the behavior and look consistency between KDE Applications; * to integrate KDE Applications with the Workspaces. = Examples and Aims = Maybe after reading through all that, it still seems too abstract, that's understandable, so in this part of the email we'll cover a partial example of what our new organization will look like. Keep in mind that it is non exhaustive, and describes the intended situation rather than the current code structure. Work will be required to get there. Throughout this example we will refer to the following graph: http://files.kde.org/ervin/platform11/kde-frameworks-dependencies-plan.pdf We will quickly present a few examples for some of the ten categories: * Tier 1, Functional Qt Addon: kcore libkcore will be a new library adding a few features on top of libQtCore. In particular, it will contain the job classes, handling of command line arguments, text handling classes, file locking, and not much more. Because of that, it will be fairly self contained and will depend only on libQtCore granting it the Tier 1 and Functional labels. * Tier 2, Functional Qt Addon: kconfig libkconfig will be a new library containing our good old KConfig* classes. It uses QtCore, but also the file locking mechanisms provided by libkcore. It brings no runtime payload. Because of that, it will be granted the Tier 2 and Functional labels. * Tier 2, OS Integration: Window Management The window management features of kdeui will be split out into their own library. It will depend on libkgui and Qt, granting it the Tier 2 label. As it provides integration with the OS which in particular might require a runtime payload (although not in that particular case), it is granted the OS Integration label. * Tier 3, Solution: KIO Widgets The current libkio will be split in several parts, one containing the core features, the one we're considering here will contain features like KRun and the other widgets you might want to use with KIO Jobs. It will depend on another Tier 3 framework (Services Traders) granting it the Tier 3 label, it is then allowed to depend on Tier 1 frameworks like solid, or Tier 2 like kconfig. Also, it is part of a complete stack, including KIO Core and a runtime payload (klauncher + ioslaves), that's why it is granted the Solution label. = Conclusion = I hope this email will help clarify what we're aiming at with the KDE Frameworks. We're confident it is a move for a clearer situation regarding the dependencies of our frameworks. Also, it will hopefully give us a framework (no pun intended!) to help us identify which ones can be improved and made easier to use. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From aacid at kde.org Mon Jun 6 23:17:23 2011 From: aacid at kde.org (Albert Astals Cid) Date: Mon, 6 Jun 2011 23:17:23 +0100 Subject: Intended organization of KDE Frameworks In-Reply-To: <201106070004.52120.ervin@kde.org> References: <201106070004.52120.ervin@kde.org> Message-ID: <201106062317.23854.aacid@kde.org> A Monday, June 06, 2011, Kevin Ottens va escriure: > Hello lists, > > Throughout this example we will refer to the following graph: > http://files.kde.org/ervin/platform11/kde-frameworks-dependencies-plan.pdf Shall i read from this graph that we will not be providing translation support for solid, date and time, kauth, kgui and kwidgets (since it would mean a T1 component depending on another T1 component)? Albert From thomas.luebking at gmail.com Mon Jun 6 23:23:48 2011 From: thomas.luebking at gmail.com (Thomas =?UTF-8?B?TMO8Ymtpbmc=?=) Date: Tue, 7 Jun 2011 00:23:48 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: References: <17911809.h6xGmj1gbX@freedom> <1335160.Fc7ClmKFtQ@martin-desktop> Message-ID: <20110607002348.74d060e4@gmail.com> Am Tue, 7 Jun 2011 08:51:26 +1200 schrieb Ben Cooksley : > You are effectively classifying a distribution No, "distribution version vanilla" - iff at all. (You still can develop on master, even run kwin - just not use OpenGL composited kwin from master then - that's not quite the same) Aside this, I'm not entirely firm in the OpenSuSE repositories, but they do provide mesa 7.10 for 11.3 which originally shipped 7.8. Given that this would be called (part of) a Graphics Driver elsewhere and accounting the rapid development of the KMS/X11/Mesa/E?GL(ES)? stack in the recent past as well as - well, quite some bugs & regressions (tm), everything else could just as well be tagged as "stupid". And afaik (Open)SuSE move towards a rolling release as well? > You are now depending on > > as I have here on my system the start of the Wayland port which ^^^^^^^^^^^^^^^^^^^^^^ > components which aren't even in released distributions! it's not even released by the mesa folks so far ;-) > (Note that having to live with a desktop without compositing isn't > exactly what I would call usable for the long run) a) runtime mesa check does no way block compositing. b) Who says you've to use kwin from master then? Why should you _use_ (like: every day for reliable work) anything from master but the stuff you're actually into? Regarding your phonon/vlc issue: what's the configured sink in vlc? (please don't say "standard" - press ctrl+m and check the second tab output) Cheers, Thomas From mo85 at cornell.edu Mon Jun 6 23:33:28 2011 From: mo85 at cornell.edu (Maksim Orlovich) Date: Mon, 6 Jun 2011 18:33:28 -0400 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <20110606234647.2938c667@gmail.com> References: <17911809.h6xGmj1gbX@freedom> <1335160.Fc7ClmKFtQ@martin-desktop> <20110606234647.2938c667@gmail.com> Message-ID: On 6/6/11, Thomas Lübking wrote: > Am Mon, 6 Jun 2011 17:08:24 -0400 > schrieb Maksim Orlovich : > >> Why would wayland support have any effect on runtime dependency on >> X11? > > http://groups.google.com/group/wayland-display-server/web/building-and-running-wayland > Building mesa > > Wayland uses the mesa EGL stack, and all extensions required to run EGL > on KMS are...... Sorry, my wording was poor: OK, wayland needs recent Mesa at runtime, but I am not running Wayland; so why would I need to upgrade my mesa? From kde at kitterman.com Mon Jun 6 23:36:52 2011 From: kde at kitterman.com (Scott Kitterman) Date: Mon, 6 Jun 2011 18:36:52 -0400 Subject: Releases of the thing that was KDE Message-ID: <201106061836.52654.kde@kitterman.com> New thread as requested. I've been told on IRC that we will still have an integrated release of what used to be KDE (I've no clue what to call it now since I think I read KDE SC was deprecated). All I see in the messaging from the platform sprint seems to be about further deconstruction and decentralization. The KDE 4.7 beta 1 tarballs are an inconsistent mess that clearly weren't coherently thought out (don't get me started about modules thinking it'd be a great idea to split tarballs in 4.6.3). [to be clear, I'm not against splitting, I'd just like it to be planned out and done consistently, once so we don't have to redo packaging multiple times]. The results on the platform sprint read like more chaos is coming. I get we need to modularize for a number of important reasons, but I don't see the companion story for how this all gets released as something coherent and functional. Where's that part of the story? Scott K >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << From thomas.luebking at gmail.com Mon Jun 6 23:51:01 2011 From: thomas.luebking at gmail.com (Thomas =?UTF-8?B?TMO8Ymtpbmc=?=) Date: Tue, 7 Jun 2011 00:51:01 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: References: <17911809.h6xGmj1gbX@freedom> <1335160.Fc7ClmKFtQ@martin-desktop> <20110606234647.2938c667@gmail.com> Message-ID: <20110607005101.142719da@gmail.com> Am Mon, 6 Jun 2011 18:33:28 -0400 schrieb Maksim Orlovich : > Sorry, my wording was poor: Might have been my reading as well. Your original question could have perfectly been read like the clarified one. > OK, wayland needs recent Mesa at runtime, > but I am not running Wayland; so why would I need to upgrade my mesa? This i do not know, since i don't have seen Martin's initial wayland supporting code, sorry :-( (I have a vague idea about what it could be, but am not gonna make a fool out of myself, speculating around while his insight is just a mail away ;-) Sorry, Thomas From bradh at frogmouth.net Mon Jun 6 23:55:22 2011 From: bradh at frogmouth.net (Brad Hards) Date: Tue, 7 Jun 2011 08:55:22 +1000 Subject: Releases of the thing that was KDE In-Reply-To: <201106061836.52654.kde@kitterman.com> References: <201106061836.52654.kde@kitterman.com> Message-ID: <201106070855.22700.bradh@frogmouth.net> On Tue, 7 Jun 2011 08:36:52 AM Scott Kitterman wrote: > The results on the platform sprint read like more chaos is coming. > > I get we need to modularize for a number of important reasons, but I don't > see the companion story for how this all gets released as something > coherent and functional. > > Where's that part of the story? Maybe you could let them finish telling the story. Brad From johnlayt at googlemail.com Tue Jun 7 00:02:28 2011 From: johnlayt at googlemail.com (John Layt) Date: Tue, 7 Jun 2011 00:02:28 +0100 Subject: Releases of the thing that was KDE In-Reply-To: <201106061836.52654.kde@kitterman.com> References: <201106061836.52654.kde@kitterman.com> Message-ID: On 6 June 2011 23:36, Scott Kitterman wrote: > > I get we need to modularize for a number of important reasons, but I don't > see > the companion story for how this all gets released as something coherent > and > functional. > > Where's that part of the story? > > Scott K > >From Sebas' email: What does it mean for packagers? * We make it possible to ship our frameworks in a more modular way * We also plan to provide "monolithic tarballs" much as we do now, depending on the needs and preferences of downstreams An email will follow from the people who participated in the Build and Release work group on how they plan to make this work, please wait for them to report back. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << From ervin at kde.org Tue Jun 7 00:05:56 2011 From: ervin at kde.org (Kevin Ottens) Date: Tue, 7 Jun 2011 01:05:56 +0200 Subject: Rules to be approved as part of KDE Frameworks Message-ID: <201106070106.02837.ervin@kde.org> Hello lists, As, Sebas pointed out we've been meeting here to work on plans to improve our frameworks offering leading to the decision of leaving the current "kdelibs model" behind and prepare for a more modular suite named KDE Frameworks. If you didn't read his email yet, please do so before going back to this email. Don't be afraid, this email is likely to be shorter than the previous one. ;-) It might also be easier to understand the content of this email if you first read my previous email about the KDE Frameworks, although that's probably not mandatory. Here, we'll be dealing with what will be part of the KDE Frameworks, the answer is two fold really and depends if we're talking about a library or smaller code contributions. The content is mostly common sense, it is about trying to make explicit the good practices already in place in our community. This email is a draft of a future wiki page to complete our policies (or to be integrated in the existing policy pages). = Library Quality Criteria = Any library should meet the quality criteria to get KDE Frameworks stamps (as described in my previous email). The criteria in question are the following: * the code should follow our license policy; * the code should follow a consistent coding standard (it is encouraged to follow the current kdelibs standard throughout our frameworks but is not mandatory); * the framework should have a scope (no dumping ground); * the code should meet all the dependency criteria of its intended Tier and Framework Type; * the library should maintain binary compatibility until the next major release of KDE Frameworks; * the code should be unit tested with a "sufficient" coverage (the exact number still needs to be determined); * the developers of the library should comply to the "code contribution quality criteria" described below. = Code Contribution Quality Criteria = Since we can expect all the libraries, old and new, to get code contributions, the following rules will be in effect for the "stamped" frameworks: * the "two apps rule" still applies and should be considered like a minimum; * the added code should comply to the dependency policy for the library Tier and Framework Type; * the added code should fit in the library scope; * the contributor has to commit to maintaining the contributed code or find someone to take it over (social contract); * all new features will be developed using the recommended git workflow (pending publication; Cornelius is working on that one); * automated tests should be provided in the same commit as a fix; * commits meant to hit the master branch (bugfixes or merges) should contain a "Reviewed by" or "REVIEW:" in their commit log. = Conclusion = Those rules might seem like a strong departure from what we're used to. On the other hand, if you look at them closely, they are merely making explicit changes to our habits which already happened a while ago during the Qt 3 to Qt 4 port. We're trying here to make them systematic to get even better frameworks than before. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kde at kitterman.com Tue Jun 7 00:09:44 2011 From: kde at kitterman.com (Scott Kitterman) Date: Mon, 06 Jun 2011 19:09:44 -0400 Subject: Releases of the thing that was KDE In-Reply-To: References: <201106061836.52654.kde@kitterman.com> Message-ID: <2388cdc0-9c5c-4155-8bbb-ccfb99b3bcae@email.android.com> John Layt wrote: >On 6 June 2011 23:36, Scott Kitterman wrote: >> >> I get we need to modularize for a number of important reasons, but I >don't >> see >> the companion story for how this all gets released as something >coherent >> and >> functional. >> >> Where's that part of the story? >> >> Scott K >> > >From Sebas' email: > >What does it mean for packagers? > >* We make it possible to ship our frameworks in a more modular way >* We also plan to provide "monolithic tarballs" much as we do now, >depending > on the needs and preferences of downstreams >An email will follow from the people who participated in the Build and >Release work group on how they plan to make this work, please wait for >them >to report back. Fair enough. It might be helpful if someone who knows what topics are yet to come would provide a list. I don't recall this build and release work group being mentioned (I may have missed it). It's much easier to step back and wait for something you know is coming. Scott K >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << From ervin at kde.org Tue Jun 7 00:14:35 2011 From: ervin at kde.org (Kevin Ottens) Date: Tue, 7 Jun 2011 01:14:35 +0200 Subject: Intended organization of KDE Frameworks In-Reply-To: <201106062317.23854.aacid@kde.org> References: <201106070004.52120.ervin@kde.org> <201106062317.23854.aacid@kde.org> Message-ID: <201106070114.35706.ervin@kde.org> On Tuesday 7 June 2011 00:17:23 Albert Astals Cid wrote: > A Monday, June 06, 2011, Kevin Ottens va escriure: > > Hello lists, > > > > Throughout this example we will refer to the following graph: > > http://files.kde.org/ervin/platform11/kde-frameworks-dependencies-plan.pd > > f > > Shall i read from this graph that we will not be providing translation > support for solid, date and time, kauth, kgui and kwidgets (since it > would mean a T1 component depending on another T1 component)? Well, obviously a Tier 1 framework would have to use tr() instead of i18n() for its translation needs. AFAIK that shouldn't be a big issue as libsolid is already in that situation. We're aware that our own translation system provides more feature, but at the level of Tier 1 frameworks the user messages should be simple enough to get away with using tr(). Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From aacid at kde.org Tue Jun 7 00:26:17 2011 From: aacid at kde.org (Albert Astals Cid) Date: Tue, 7 Jun 2011 00:26:17 +0100 Subject: Intended organization of KDE Frameworks In-Reply-To: <201106070114.35706.ervin@kde.org> References: <201106070004.52120.ervin@kde.org> <201106062317.23854.aacid@kde.org> <201106070114.35706.ervin@kde.org> Message-ID: <201106070026.17380.aacid@kde.org> A Tuesday, June 07, 2011, Kevin Ottens va escriure: > On Tuesday 7 June 2011 00:17:23 Albert Astals Cid wrote: > > A Monday, June 06, 2011, Kevin Ottens va escriure: > > > Hello lists, > > > > > > Throughout this example we will refer to the following graph: > > > http://files.kde.org/ervin/platform11/kde-frameworks-dependencies-plan. > > > pd f > > > > Shall i read from this graph that we will not be providing translation > > support for solid, date and time, kauth, kgui and kwidgets (since it > > would mean a T1 component depending on another T1 component)? > > Well, obviously a Tier 1 framework would have to use tr() instead of i18n() > for its translation needs. Are we still going to use .po or you plan on us moving to Qt translation files? > AFAIK that shouldn't be a big issue as libsolid > is already in that situation. Yeah, and totally fails to follow KLocale setting of wheter to use KB, KiB, etc. > We're aware that our own translation system > provides more feature, but at the level of Tier 1 frameworks the user > messages should be simple enough to get away with using tr(). I disagree, time and date formatting is anything but simple. Albert > > Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ervin at kde.org Tue Jun 7 00:38:58 2011 From: ervin at kde.org (Kevin Ottens) Date: Tue, 7 Jun 2011 01:38:58 +0200 Subject: Intended organization of KDE Frameworks In-Reply-To: <201106070026.17380.aacid@kde.org> References: <201106070004.52120.ervin@kde.org> <201106070114.35706.ervin@kde.org> <201106070026.17380.aacid@kde.org> Message-ID: <201106070138.58971.ervin@kde.org> On Tuesday 7 June 2011 01:26:17 Albert Astals Cid wrote: > A Tuesday, June 07, 2011, Kevin Ottens va escriure: > > Well, obviously a Tier 1 framework would have to use tr() instead of > > i18n() for its translation needs. > > Are we still going to use .po or you plan on us moving to Qt translation > files? Well, I honestly don't know what awesome magic you used for libsolid, so for me it's "the same recipe". Note that it'll happen mostly for Tier 1 frameworks though. > > AFAIK that shouldn't be a big issue as libsolid > > is already in that situation. > > Yeah, and totally fails to follow KLocale setting of wheter to use KB, KiB, > etc. Right, however there's also a plan ATM to get the settings between KLocale and QLocale shared. John is working on that right now, so it depends a bit on the outcome, in any cases the situation is likely to improve on that particular point. > > We're aware that our own translation system > > provides more feature, but at the level of Tier 1 frameworks the user > > messages should be simple enough to get away with using tr(). > > I disagree, time and date formatting is anything but simple. If really needed it'll get into Tier 2 then, no big deal. Again, the graph presented is non exhaustive and makes some assumption about goals we set. If there's a blocker along the way we'll reevaluate, it's not meant to be read as done deal or set in stone. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mo85 at cornell.edu Tue Jun 7 00:41:15 2011 From: mo85 at cornell.edu (Maksim Orlovich) Date: Mon, 6 Jun 2011 19:41:15 -0400 Subject: Rules to be approved as part of KDE Frameworks In-Reply-To: <201106070106.02837.ervin@kde.org> References: <201106070106.02837.ervin@kde.org> Message-ID: > * all new features will be developed using the recommended git workflow > (pending publication; Cornelius is working on that one); > Those rules might seem like a strong departure from what we're used to. On > the other hand, if you look at them closely, they are merely making explicit > changes to our habits which already happened a while ago during the Qt 3 to > Qt 4 port These two things don't really go well together now, do they? From faure at kde.org Tue Jun 7 00:43:44 2011 From: faure at kde.org (David Faure) Date: Tue, 7 Jun 2011 01:43:44 +0200 Subject: Plan to transition to KDE Frameworks Message-ID: <201106070143.44615.faure@kde.org> Hi everyone, It's getting rather late here, so I'll skip introductions and get right to the point :-) Until 4.7 is branched, we keep fixing bugs in kdelibs 4, and work on trying to get the things into Qt 5 that we need -- about 20 KDE-related people will be going to the Qt Contributor Summit, that should help. Once the 4.7 branch is created, the plan is to do the following: - application developers can work in master as usual, no change there. - we create a new branch in kdelibs (say, "frameworks") for the work on splitting up kdelibs and reworking dependencies. Initially, this work is based on Qt 4. We don't need Qt 5 to reorganize our own code. - kdelibs in master is frozen. No work going on there. At most, "merging" the fixes from 4.7 branch. (No git bikeshedding please, when I say merging it can be either merge or cherry-pick, I don't care) The idea here is: people who are used to "get everything from master" can keep doing that, without hitting the lib-splitting breakage. But at the same time, we don't really want to apply bugfixes to three branches (4.7, master, frameworks). At least I'm too lazy for that, I think two branches is plenty already. :-) Dividing our efforts is never a good idea. So the kdelibs-master branch would be basically dead (no work going on there, no release from that code), until the frameworks branch is merged into it. To ease testing, kde-runtime will probably be branched at the same time, in order to have matching libs and runtime bits (and possibly to move together stuff that belongs together). Once the code is fully reorganized, we will move each library into a separate git repository. (technical git note: Olivier Goffart showed us a very cool trick with git graft which allows one to chain the history of a git module to another one, thereby preserving history when moving code between git modules). We are working on solutions to make it easier to manage split-up git repositories more easily, there is Alex Neundorf's current work on a cmake-based solution, and kdesrc-build's module-set feature. - at some point we switch to Qt 5, in order to test it and to be able to use the features that we might need from Qt. On that note: if you look at the dependencies plan PDF, most Qt Addons in Tier 1 are something that "should ideally be in Qt", or at least something that any Qt developer might want to use. So if we do get things into Qt, this diagram can change a bit with things moving down (which is good). The point is that the diagram currently assumes the worst, i.e. that we can't get anything into Qt; we'll see how that goes. - at that point, we create a frameworks branch for kdesupport modules in order to port them to Qt 5. - later on, we create a frameworks branch in kdepimlibs in order to split it and port it to Qt 5. This plan is only about KDE Frameworks. For the KDE Applications and Workspaces, nothing is decided yet, that is still to be discussed, for instance at Desktop Summit. There is no rush in doing that. This migration will be different from the previous migrations because the goal is to preserve source compatibility as much as possible. So there is no need to adapt the rest of the code while we make changes in the KDE Frameworks. This is why the rest of the code can be branched much later. -- David Faure, faure at kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). From aseigo at kde.org Tue Jun 7 00:48:48 2011 From: aseigo at kde.org (Aaron J. Seigo) Date: Tue, 07 Jun 2011 01:48:48 +0200 Subject: Releases of the thing that was KDE In-Reply-To: <2388cdc0-9c5c-4155-8bbb-ccfb99b3bcae@email.android.com> References: <201106061836.52654.kde@kitterman.com> <2388cdc0-9c5c-4155-8bbb-ccfb99b3bcae@email.android.com> Message-ID: <1689320.zcY1KZlAl2@freedom> On Monday, June 6, 2011 19:09:44 Scott Kitterman wrote: > Fair enough. It might be helpful if someone who knows what topics are yet to > come would provide a list. there has been one email by Sebas, and two by Kevin. there is one more that David Faure is about to send about the plan for the frameworks development process. there is one more from Cornelius about the git workflow we will be adopting which was referenced in one of Kevin's emails. in addition to this, there are a number of topics that are currently in "rough draft notes" stages that came out of the various breakout groups including: * Developer Story * Settings: KConfig, DConf, QSettings * Buildsystem, Packaging * Geolocation Services * Frameworks QA * Downstream Considerations * Collection of Qt libraries service these all need to be made presentable and clear over the coming days and shared with everyone in the community, just as we have done with the emails written so far... -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From aseigo at kde.org Tue Jun 7 01:00:20 2011 From: aseigo at kde.org (Aaron J. Seigo) Date: Tue, 07 Jun 2011 02:00:20 +0200 Subject: Rules to be approved as part of KDE Frameworks In-Reply-To: References: <201106070106.02837.ervin@kde.org> Message-ID: <3346093.0IkzdRRYhB@freedom> On Monday, June 6, 2011 19:41:15 Maksim Orlovich wrote: > > * all new features will be developed using the recommended git > > workflow > > > > (pending publication; Cornelius is working on that one); > > > > Those rules might seem like a strong departure from what we're used to. > > On the other hand, if you look at them closely, they are merely making > > explicit changes to our habits which already happened a while ago > > during the Qt 3 to Qt 4 port > > These two things don't really go well together now, do they? a documented git workflow is new, but needed. ditto with the tier/type concepts. the other items are as described in the second paragraph, however. is this problematic for you in some way? if so, can you clarify what that problem is so that we may understand and be able to address it? -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From nicolas.alvarez at gmail.com Tue Jun 7 01:07:26 2011 From: nicolas.alvarez at gmail.com (Nicolas Alvarez) Date: Mon, 06 Jun 2011 21:07:26 -0300 Subject: Releases of the thing that was KDE References: <201106061836.52654.kde@kitterman.com> Message-ID: Scott Kitterman wrote: > New thread as requested. > > I've been told on IRC that we will still have an integrated release of > what used to be KDE (I've no clue what to call it now since I think I read > KDE SC was deprecated). > > All I see in the messaging from the platform sprint seems to be about > further deconstruction and decentralization. > > The KDE 4.7 beta 1 tarballs are an inconsistent mess that clearly weren't > coherently thought out (don't get me started about modules thinking it'd > be a > great idea to split tarballs in 4.6.3). [to be clear, I'm not against > splitting, I'd just like it to be planned out and done consistently, once > so we don't have to redo packaging multiple times]. What module split tarballs in 4.6.3? I thought tarball layout remained fixed throughout 4.6. -- Nicolas (I read mailing lists through Gmane. Please don't Cc me on replies; it makes me get one message on my newsreader and another on email.) From shaun.reich at kdemail.net Tue Jun 7 05:07:04 2011 From: shaun.reich at kdemail.net (Shaun Reich) Date: Tue, 07 Jun 2011 04:07:04 -0000 Subject: Review Request: Fix possible memory and D-Bus connection leak in KStatusNotifierItem In-Reply-To: <20110606203819.25945.33626@vidsolbach.de> References: <20110606203819.25945.33626@vidsolbach.de> Message-ID: <20110607040704.10498.23485@vidsolbach.de> > On June 6, 2011, 8:38 p.m., Aaron J. Seigo wrote: > > i doubt this fix is correct. what looks more like is KStatusNotifierItemDBus::~KStatusNotifierItemDBus(). right now this is the implementation: > > > > m_dbus.unregisterService(m_service); > > > > and perhaps it should include: > > > > m_dbus.unregisterObject("/StatusNotifierItem", this); > > > > and perhaps even: > > > > m_dbus.disconnectFromBus(m_service); > > > > (though i expect the latter is done automatically when QDBusConnection is deleted? maybe not though...) actually, looks like ~QDBusConnection() won't close the connection. apparently disconnectFromBus does indeed need to be called explicitly. /me suddenly wonders how much code doesn't do this, if need be. - Shaun ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101527/#review3726 ----------------------------------------------------------- On June 6, 2011, 3:31 p.m., Christoph Feck wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101527/ > ----------------------------------------------------------- > > (Updated June 6, 2011, 3:31 p.m.) > > > Review request for kdelibs, Plasma and Marco Martin. > > > Summary > ------- > > According to bug 261180 there is a D-Bus connection leak in KStatusNotifierItem. This patch potentially fixes it, but I do not know how to test it. > > > This addresses bug 261180. > http://bugs.kde.org/show_bug.cgi?id=261180 > > > Diffs > ----- > > kdeui/notifications/kstatusnotifieritem.cpp c48ed50 > > Diff: http://git.reviewboard.kde.org/r/101527/diff > > > Testing > ------- > > > Thanks, > > Christoph > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgraesslin at kde.org Tue Jun 7 06:12:39 2011 From: mgraesslin at kde.org (Martin =?ISO-8859-1?Q?Gr=E4=DFlin?=) Date: Tue, 07 Jun 2011 07:12:39 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: References: <17911809.h6xGmj1gbX@freedom> <1335160.Fc7ClmKFtQ@martin-desktop> <20110606234647.2938c667@gmail.com> Message-ID: <1307423559.21187.3.camel@Nokia-N900-51-1> ----- Ursprüngliche Mitteilung ----- > On 6/6/11, Thomas Lübking wrote: > > Am Mon, 6 Jun 2011 17:08:24 -0400 > > schrieb Maksim Orlovich : > > > > > Why would wayland support have any effect on runtime dependency on > > > X11? > > > > http://groups.google.com/group/wayland-display-server/web/building-and-running-wayland > > Building mesa > > > > Wayland uses the mesa EGL stack, and all extensions required to run EGL > > on KMS are...... > > Sorry, my wording was poor: OK, wayland needs recent Mesa at runtime, > but I am not running Wayland; so why would I need to upgrade my mesa? It's not different to the current situation (and that's what I wanted to point out): With 4.7 there is a runtime requirement to Mesa 7.10 if you want to use the *optional* feauture of OpenGL compositing. With 4.8 there will be a runtime requirement to Mesa 7.11 if you want to use the *optional* feature of KWin being a Wayland server. It should not affect the runtime requirements for X11, but if Mesa 7.11 gets released before our 4.8 dependency freeze, we have to depend on it. Cheers Martin From simonpersson1 at gmail.com Mon Jun 6 09:46:04 2011 From: simonpersson1 at gmail.com (Simon Persson) Date: Mon, 06 Jun 2011 08:46:04 -0000 Subject: Review Request: Export the function isShiftAsModifierAllowed() from KKeySequenceWidget Message-ID: <20110606084604.19753.35399@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101515/ ----------------------------------------------------------- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpersson1 at gmail.com Mon Jun 6 12:02:01 2011 From: simonpersson1 at gmail.com (Simon Persson) Date: Mon, 06 Jun 2011 11:02:01 -0000 Subject: Review Request: Fix global shortcuts that needs shift key, like for example ctrl+% (ctrl+shift+5 on many keyboards) Message-ID: <20110606110201.27225.20279@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101520/ ----------------------------------------------------------- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpersson1 at gmail.com Mon Jun 6 12:24:17 2011 From: simonpersson1 at gmail.com (Simon Persson) Date: Mon, 06 Jun 2011 11:24:17 -0000 Subject: Review Request: Fix meta+shift+tab and similar global shortcuts. Message-ID: <20110606112417.28852.64923@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101523/ ----------------------------------------------------------- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From urban.widmark at gmail.com Mon Jun 6 20:48:25 2011 From: urban.widmark at gmail.com (Urban Widmark) Date: Mon, 06 Jun 2011 19:48:25 -0000 Subject: Review Request: KMainWindow::parseGeometry() fails to position with positive coordinates In-Reply-To: <20110606020444.5726.75909@vidsolbach.de> References: <20110606020444.5726.75909@vidsolbach.de> Message-ID: <20110606194825.23158.91261@vidsolbach.de> > On June 6, 2011, 2:04 a.m., David Faure wrote: > > Looks good overall, but I think I found a bug with negative coordinates: > > konqueror --geometry +500-100 > > gives me a window that xwininfo says is at "744x533+500-29", which doesn't match. > > > > I have no experience with this, but it seems to me that negative values are "the distance between the bottom of the window and the bottom of the desktop", while the code is trying to use that for the topleft corner of the window instead (i.e. distance between top of window and bottom of desktop)? > > When I increase the negative value (e.g. -150) nothing happens, then when I use -300 the window starts moving up. For negative positions it uses the window size to calculate the new window position. Y coordinate of -100 becomes desktop height - 100 - window height. The problem is that parseGeometry() is called from KMainWindowPrivate::init() before the application has had a chance to set a window size so the function will use a default size (I believe it is 640x480) if no size is given in the geometry string. So if the window is resized before shown you need to include that difference in the negative offset. Don't know about -29 (panel on the bottom and konqueror does not want to cover it?) or why you need to use as much as -300 to make the window move (konqueror initially sets the height to an even larger value?). This problem is listed under "Testing Done" (a bit cryptic I guess). The same behaviour exists before the patch, and seems more complicated to solve. When is an application supposed to have decided the window size it wants? Another option would be if QT understood negative window positions and could update as the window resizes... when googling for what qt does I stumbled on this patch to QTs handling of geometry: http://qt.gitorious.org/qt/qt/merge_requests/2623 If QT is doing geometry parsing should KDE use that instead of doing its own? That one is in QApplication and not QMainWindow though. That patch uses XSetWMNormalHints() to change how the window should grow. If resizing a window listens to those hints then that could fix negative positions. I'll have a look at that. - Urban ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101492/#review3702 ----------------------------------------------------------- On June 3, 2011, 10:09 p.m., Urban Widmark wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101492/ > ----------------------------------------------------------- > > (Updated June 3, 2011, 10:09 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > When an X geometry is given on the command line, parseGeometry() will, for positive positions, use geometry().x()/.y() instead of the x/y value parsed from the string. This causes positive positions to not work. > > For negative values the string values are used, but the w/h variables will be used uninitialized unless both a size and position are given. > > No direct bugs reported on this that I can find, but the odd position behavior is noted in some --geometry related bugs: > Comment #6, http://bugs.kde.org/show_bug.cgi?id=165355 > http://bugs.kde.org/show_bug.cgi?id=230663 > > > For the KMainWindow --geometry parsing to work for both size and position, the client application will have to call applyMainWindowSettings() or restoreWindowSize(). The parsing done by KMainWindowPrivate::init() will only set position. Not sure if that is good, as a user of the window I would expect it to use all of the --geometry data at the same time (either on creation or some later call). > > > Diffs > ----- > > kdeui/widgets/kmainwindow.cpp 1d27722 > > Diff: http://git.reviewboard.kde.org/r/101492/diff > > > Testing > ------- > > Using a KApplication program with a KMainWindow that also calls applyMainWindowSettings (keditbookmarks), positions verified using xwininfo: > keditbookmarks --geometry 400x300+100+200 > keditbookmarks --geometry 400x300-100+200 > keditbookmarks --geometry 400x300+100-200 > keditbookmarks --geometry 400x300-100+200 > keditbookmarks --geometry 400x300 > keditbookmarks --geometry +100+200 > keditbookmarks --geometry -400-300 > > Without patch all +coords are replaced by 0. > Negative positions do not account for window decorations as the size of those are not known. I suspect the user will have to adjust for that in their input. > Negative positions also has a problem that parseGeometry(false) is called before keditbookmarks has set a (default) size on the window, so it is 640x480. > > > Thanks, > > Urban > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adawit at kde.org Tue Jun 7 06:44:47 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Tue, 07 Jun 2011 05:44:47 -0000 Subject: Review Request: Fix possible memory and D-Bus connection leak in KStatusNotifierItem In-Reply-To: <20110606203819.25945.33626@vidsolbach.de> References: <20110606203819.25945.33626@vidsolbach.de> Message-ID: <20110607054447.13331.57734@vidsolbach.de> > On June 6, 2011, 8:38 p.m., Aaron J. Seigo wrote: > > i doubt this fix is correct. what looks more like is KStatusNotifierItemDBus::~KStatusNotifierItemDBus(). right now this is the implementation: > > > > m_dbus.unregisterService(m_service); > > > > and perhaps it should include: > > > > m_dbus.unregisterObject("/StatusNotifierItem", this); > > > > and perhaps even: > > > > m_dbus.disconnectFromBus(m_service); > > > > (though i expect the latter is done automatically when QDBusConnection is deleted? maybe not though...) > > Shaun Reich wrote: > actually, looks like ~QDBusConnection() won't close the connection. apparently disconnectFromBus does indeed need to be called explicitly. /me suddenly wonders how much code doesn't do this, if need be. Dunno if this class is using QDBusConnection::sessionBus(), but if it is then the disconnect is supposed to be automatic according to the sessionBus() API documentation. If indeed the disconnection is not occurring, then that might possibly explain the weird dbus related crashes reported in bug# 234484 as well. I hope that is not the case because I do not remember seeing anywhere where disconnectFromBus is called explicitly. - Dawit ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101527/#review3726 ----------------------------------------------------------- On June 6, 2011, 3:31 p.m., Christoph Feck wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101527/ > ----------------------------------------------------------- > > (Updated June 6, 2011, 3:31 p.m.) > > > Review request for kdelibs, Plasma and Marco Martin. > > > Summary > ------- > > According to bug 261180 there is a D-Bus connection leak in KStatusNotifierItem. This patch potentially fixes it, but I do not know how to test it. > > > This addresses bug 261180. > http://bugs.kde.org/show_bug.cgi?id=261180 > > > Diffs > ----- > > kdeui/notifications/kstatusnotifieritem.cpp c48ed50 > > Diff: http://git.reviewboard.kde.org/r/101527/diff > > > Testing > ------- > > > Thanks, > > Christoph > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcooksley at kde.org Tue Jun 7 06:51:32 2011 From: bcooksley at kde.org (Ben Cooksley) Date: Tue, 7 Jun 2011 17:51:32 +1200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <1307423559.21187.3.camel@Nokia-N900-51-1> References: <17911809.h6xGmj1gbX@freedom> <1335160.Fc7ClmKFtQ@martin-desktop> <20110606234647.2938c667@gmail.com> <1307423559.21187.3.camel@Nokia-N900-51-1> Message-ID: On Tue, Jun 7, 2011 at 5:12 PM, Martin Gräßlin wrote: > > ----- Ursprüngliche Mitteilung ----- >> On 6/6/11, Thomas Lübking wrote: >> > Am Mon, 6 Jun 2011 17:08:24 -0400 >> > schrieb Maksim Orlovich : >> > >> > > Why would wayland support have any effect on runtime dependency on >> > > X11? >> > >> > http://groups.google.com/group/wayland-display-server/web/building-and-running-wayland >> > Building mesa >> > >> > Wayland uses the mesa EGL stack, and all extensions required to run EGL >> > on KMS are...... >> >> Sorry, my wording was poor: OK, wayland needs recent Mesa at runtime, >> but I am not running Wayland; so why would I need to upgrade my mesa? > It's not different to the current situation (and that's what I wanted to point out): > With 4.7 there is a runtime requirement to Mesa 7.10 if you want to use the *optional* feauture of OpenGL compositing. > > With 4.8 there will be a runtime requirement to Mesa 7.11 if you want to use the *optional* feature of KWin being a Wayland server. I gather from this that X11 will be completely unaffected? Wanting to depend on unreleased software is unprecedented for a component of kde-workspace providing a commonly expected feature - and is something I find objectionable. Especially if the dependency offers no benefits to those of us whom recieve no benefit from the increase in dependencies. > > It should not affect the runtime requirements for X11, but if Mesa 7.11 gets released before our 4.8 dependency freeze, we have to depend on it. Can you please clarify what you mean by we *have* to depend on it? Does this mean which of the following: * CMake level check making KWin completely unavailable to people without Mesa 7.11 * Runtime level check making all compositing unavailable to people without Mesa 7.11 - regardless of whether it is X or Wayland * Runtime level check only concerning Wayland Either of options 1 and 2 are completely unacceptable under any circumstances - considering that people who will be developing for 4.8 will be doing so under distributions which ship 4.7 - which will probably only have Mesa 7.10. Compositing alters the way the window system operates and can expose bugs - and by imposing these dependencies you are inhibiting the ability of other developers to triage and fix bugs or other defects. > > Cheers > Martin > Regards, Ben From mgraesslin at kde.org Tue Jun 7 07:12:33 2011 From: mgraesslin at kde.org (=?UTF-8?Q?Martin_Gr=C3=A4=C3=9Flin?=) Date: Tue, 07 Jun 2011 08:12:33 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: References: <17911809.h6xGmj1gbX@freedom> <1335160.Fc7ClmKFtQ@martin-desktop> <20110606234647.2938c667@gmail.com> <1307423559.21187.3.camel@Nokia-N900-51-1> Message-ID: <7bed6c9370de4b55db0cffd35bc2028c@satellite.martin-graesslin.com> On Tue, 7 Jun 2011 17:51:32 +1200, Ben Cooksley wrote: >> It should not affect the runtime requirements for X11, but if Mesa >> 7.11 gets released before our 4.8 dependency freeze, we have to depend >> on it. > > Can you please clarify what you mean by we *have* to depend on it? > Does this mean which of the following: > * CMake level check making KWin completely unavailable to people > without Mesa 7.11 > * Runtime level check making all compositing unavailable to people > without Mesa 7.11 - regardless of whether it is X or Wayland > * Runtime level check only concerning Wayland None of those: Runtime check for users of Mesa with GLX. There is no check for Mesa with EGL or for users of NVIDIA or ATI blob. Though there are features not available on any of the drivers in any of the hardware/driver version combination > > Either of options 1 and 2 are completely unacceptable under any > circumstances - considering that people who will be developing for > 4.8 > will be doing so under distributions which ship 4.7 - which will > probably only have Mesa 7.10. With the current manpower and the shaky graphics stack around us we are not able to support more than one Mesa version. As the distributions are going to ship Mesa 7.11 together with 4.8 there is no way that we can continue to guarantee a working stack with Mesa 7.10, therefore we have to raise the requirement. The same I expect for 4.9 and so on. If someone wants to disagree on that, I want to see the increased manpower in KWin. Until that happens, it is a mood point to discuss it, as it is denying the reality. > > Compositing alters the way the window system operates and can expose > bugs - and by imposing these dependencies you are inhibiting the > ability of other developers to triage and fix bugs or other defects. We need bug reports for the latest Mesa release, not for the last. Nobody cares about the last release. We need *now* developers testing 4.7 with Mesa 7.11 as it might be that distributions will put those together and not the Mesa 7.10 we require. Cheers Martin From trueg at kde.org Tue Jun 7 07:21:02 2011 From: trueg at kde.org (=?ISO-8859-1?Q?Sebastian_Tr=FCg?=) Date: Tue, 07 Jun 2011 08:21:02 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <13788778.c49pUyIHfV@lothlorien> References: <5130765.7m7Pas7BAs@martin-desktop> <13788778.c49pUyIHfV@lothlorien> Message-ID: <4DEDC34E.3030006@kde.org> Just as a side-note on SDO: For me SDO is very close to the KDE development process. If I had my way everyone running KDE master would also use SDO master. But for some reason that would only be acceptable if SDO were in KDE's git... On 06/06/2011 06:53 PM, Thiago Macieira wrote: > On Monday, 6 de June de 2011 17:48:41 Martin Gräßlin wrote: >> Personal opinion: I think it is impossible to want to run the latest >> software around an old stack. The overall FOSS world is rolling release >> with everything depending on everything. I cannot see why you want to >> change that with a moratorium. > > I agree on that, but I disagree on the age of the "old stack". For example, > I'm running the Mandriva rolling-release right now and I can't compile kdepim > and kdepimlibs because they haven't packaged yet shared-desktop-ontologies > 0.7. That was released less than one month ago. > > I'd say that hard dependencies need to be at least a couple of months old, > unless there's a very good reason for doing otherwise. And in that case, it > should be announced in advance so that distributions and users can prepare > themselves. > > * Shared desktop ontologies (0.6.51 or higher) > > Desktop ontologies > Ontologies necessary for the Nepomuk semantic desktop. > > Download & date: > http://sourceforge.net/projects/oscaf/files/shared-desktop-ontologies/0.7/ > From inge at lysator.liu.se Tue Jun 7 07:39:58 2011 From: inge at lysator.liu.se (Inge Wallin) Date: Tue, 7 Jun 2011 08:39:58 +0200 Subject: Intended organization of KDE Frameworks In-Reply-To: <201106070004.52120.ervin@kde.org> References: <201106070004.52120.ervin@kde.org> Message-ID: <201106070839.58761.inge@lysator.liu.se> On Tuesday, June 07, 2011 00:04:41 Kevin Ottens wrote: > ... Very good start, although I can sympathize with the pains of the translators. Were there any translators at the sprint? > Throughout this example we will refer to the following graph: > http://files.kde.org/ervin/platform11/kde-frameworks-dependencies-plan.pdf May I suggest that everything with widgets in it is moved to another "Look & Feel + Consistency" box? In the figure I can see kwidgets, color widgets, jobs widgets and possibly kgui. The reason is that our technology is starting to be used in places where qwidgets aren't even used, and it makes zero sense to link to a library with widgets in them on e.g. a MeeGo smartphone. On the other hand, the dialogs and widgets implement a functionality that we would like to have available to those platforms (in many cases). This means that we would want to provide equivalent or similar dialog on other platforms that are consistent with that platform and HIG in question. So a well defined API that applications could use, and a well isolated way to include a set of implementations would be nice. We are dealing with exactly this type of problems in Calligra right now, where our tools are linked with the data shapes, but some parts of the tools don't make sense on e.g. touch screens. One example of that is docker windows. It would be a pity to build in another one of these hardcoded assumptions on the graphic environment now that we are doing this nice refactoring effort. > We will quickly present a few examples for some of the ten categories: > > * Tier 1, Functional Qt Addon: kcore > libkcore will be a new library adding a few features on top of libQtCore. > In particular, it will contain the job classes, handling of command line > arguments, text handling classes, file locking, and not much more. Because > of that, it will be fairly self contained and will depend only on > libQtCore granting it the Tier 1 and Functional labels. > > * Tier 2, Functional Qt Addon: kconfig > libkconfig will be a new library containing our good old KConfig* classes. > It uses QtCore, but also the file locking mechanisms provided by libkcore. > It brings no runtime payload. Because of that, it will be granted the Tier > 2 and Functional labels. > > * Tier 2, OS Integration: Window Management > The window management features of kdeui will be split out into their own > library. It will depend on libkgui and Qt, granting it the Tier 2 label. As > it provides integration with the OS which in particular might require a > runtime payload (although not in that particular case), it is granted the > OS Integration label. > > * Tier 3, Solution: KIO Widgets > The current libkio will be split in several parts, one containing the core > features, the one we're considering here will contain features like KRun > and the other widgets you might want to use with KIO Jobs. It will depend > on another Tier 3 framework (Services Traders) granting it the Tier 3 > label, it is then allowed to depend on Tier 1 frameworks like solid, or > Tier 2 like kconfig. Also, it is part of a complete stack, including KIO > Core and a runtime payload (klauncher + ioslaves), that's why it is > granted the Solution label. This is exactly what I'm talking about. -Inge > = Conclusion = > I hope this email will help clarify what we're aiming at with the KDE > Frameworks. We're confident it is a move for a clearer situation regarding > the dependencies of our frameworks. Also, it will hopefully give us a > framework (no pun intended!) to help us identify which ones can be > improved and made easier to use. > > Regards. From trueg at kde.org Tue Jun 7 07:41:58 2011 From: trueg at kde.org (=?ISO-8859-1?Q?Sebastian_Tr=FCg?=) Date: Tue, 07 Jun 2011 08:41:58 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: References: <17911809.h6xGmj1gbX@freedom> <1335160.Fc7ClmKFtQ@martin-desktop> Message-ID: <4DEDC836.1070005@kde.org> On 06/06/2011 10:51 PM, Ben Cooksley wrote: > On Tue, Jun 7, 2011 at 8:42 AM, Martin Gräßlin wrote: >> On Tuesday 07 June 2011 08:29:51 Ben Cooksley wrote: >>> Next KWin. It currently depends upon Mesa 7.10. I have a local revert >>> in a private local branch which reverts the dependency check code >>> within KWin to continue to allow me to use compositing. Even though I >>> have Mesa 7.8, I rarely experience KWin crashes - it has only crashed >>> once in the past 2 months. I use an Intel Ironlake based graphics. >>> This patch of mine works perfectly and does not cause any issues. >> KWin does *not* depend on Mesa 7.10! KWin does not have any build dependencies on Mesa. >> There is an optional build dependency on OpenGL and XComposite/XDamage. This all is optional! >> If you use Mesa drivers there is a runtime requirement for at least Mesa 7.10, whose reasons >> have been explained to you on plasma-devel. >> >> Given what you demand this is out of scope as it is not a build dependency. It is just that you >> don't get the latest features when not having the correct runtime dependency. I might add that >> using different drivers (NVIDIA or ATI blob as well as GLES/EGL Mesa drivers) do not have this >> runtime requirement. It is also still possible to use KWin with XRender or without compositing at >> all. Btw. patches to have an environment variable to overwrite all checks are welcome. >> >> Please also note that I will add a runtime requirement to Mesa 7.11 as I have here on my system >> the start of the Wayland port which will be in 4.8 and requires Mesa 7.11. > > Now that is absolutely overboard. OpenSUSE 11.4 isn't even 3 months > old. And has Mesa 7.10. You are effectively classifying a distribution > as unsuitable for trunk development. You are now depending on > components which aren't even in released distributions! > > (Note that having to live with a desktop without compositing isn't > exactly what I would call usable for the long run) IMHO it is out of the question to ask a developer to not implement a great new feature just because the dependancies are too young. In that case you should just stick with an older version of KDE itself. Whom who wants the bleeding edge of KDE might also need the bleeding edge of all the rest (in the worst case). Restricting ourselves will lead to branching and a lot of wasted time on ifdefs and cmake checks. This wasted time could otherwise be used to create great new features and fix bugs. Isn't this the way open-source software is supposed to work? Collaborate, depend on the work of others? Restricting ourselves to old versions (and as a developer anything released is old for me) means to restrict the power we have and undermines our very development model. Cheers, Sebastian >> >> Cheers >> Martin > > Regards, > Ben > From boud at valdyas.org Tue Jun 7 08:32:09 2011 From: boud at valdyas.org (Boudewijn Rempt) Date: Tue, 7 Jun 2011 09:32:09 +0200 Subject: Requested Moratorium on hard to build dependency bumps =?iso-8859-1?q?for=09KDE?= 5 In-Reply-To: <4DEDC836.1070005@kde.org> References: <4DEDC836.1070005@kde.org> Message-ID: <201106070932.09339.boud@valdyas.org> On Tuesday 07 June 2011 Jun, Sebastian Trüg wrote: > Restricting ourselves to old versions (and as a developer anything > released is old for me) means to restrict the power we have and > undermines our very development model. In my opinion, almost always needing the development version of e.g. GTK is what is keeping GIMP a project with hardly any contributors. But that's an application, not a framework. Still -- if you want to have a healthy project with many contributors, making it hard to develop by requiring lots of unpackaged isn't a good idea. -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org From aacid at kde.org Tue Jun 7 08:46:54 2011 From: aacid at kde.org (Albert Astals Cid) Date: Tue, 7 Jun 2011 08:46:54 +0100 Subject: Intended organization of KDE Frameworks In-Reply-To: <201106070138.58971.ervin@kde.org> References: <201106070004.52120.ervin@kde.org> <201106070026.17380.aacid@kde.org> <201106070138.58971.ervin@kde.org> Message-ID: <201106070846.54923.aacid@kde.org> A Tuesday, June 07, 2011, Kevin Ottens va escriure: > On Tuesday 7 June 2011 01:26:17 Albert Astals Cid wrote: > > A Tuesday, June 07, 2011, Kevin Ottens va escriure: > > > Well, obviously a Tier 1 framework would have to use tr() instead of > > > i18n() for its translation needs. > > > > Are we still going to use .po or you plan on us moving to Qt translation > > files? > > Well, I honestly don't know what awesome magic you used for libsolid, so > for me it's "the same recipe". Note that it'll happen mostly for Tier 1 > frameworks though. Unfortunately that is not possible. Right now Solid is translated using .po but that only works in KDE applications because you have a KGlobal+KLocale around that loads .mo files (compiled .po), hijacks Qt calls and maps them to the .mo contents. Without a KGlobal+KLocale around that will not work. This means that if you want Tier 1 frameworks to be translatable you need either to teach Qt to understand gettext files natively or to make Tier 1 frameworks use pure based Qt/Linguist solutions which does not fit either in what scripty is able to do neither in what our translators are used to. Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: From toma at kde.org Tue Jun 7 08:53:28 2011 From: toma at kde.org (Tom Albers) Date: Tue, 07 Jun 2011 07:53:28 -0000 (UTC) Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <4DEDC836.1070005@kde.org> References: <4DEDC836.1070005@kde.org> Message-ID: <960f9daf-52b4-4015-978b-51685f83fcf8@contact.kovoks.nl> ----- Original Message ----- > IMHO it is out of the question to ask a developer to not implement a > great new feature just because the dependancies are too young. I disagree completely. I would very much welcome a policy that states that you can only depend on stuff that is available in the newest release of Fedora & KUbuntu & other KDE friendly distro's. Toma From thiago at kde.org Tue Jun 7 09:01:32 2011 From: thiago at kde.org (Thiago Macieira) Date: Tue, 07 Jun 2011 10:01:32 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <960f9daf-52b4-4015-978b-51685f83fcf8@contact.kovoks.nl> References: <960f9daf-52b4-4015-978b-51685f83fcf8@contact.kovoks.nl> Message-ID: <28449363.aAYenlEMqx@lothlorien> On Tuesday, 7 de June de 2011 07:53:28 Tom Albers wrote: > ----- Original Message ----- > > > IMHO it is out of the question to ask a developer to not implement a > > great new feature just because the dependancies are too young. > > I disagree completely. I would very much welcome a policy that states that > you can only depend on stuff that is available in the newest release of > Fedora & KUbuntu & other KDE friendly distro's. Note that both options are possible. You can use newer versions if they are available and thus develop using features found in those newer versions. You just have to make sure it still compiles with older (packaged) versions. The minimum requirement should be a released version at least a couple of months old. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From neundorf at kde.org Tue Jun 7 09:13:12 2011 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 7 Jun 2011 10:13:12 +0200 Subject: Rules to be approved as part of KDE Frameworks In-Reply-To: <3346093.0IkzdRRYhB@freedom> References: <201106070106.02837.ervin@kde.org> <3346093.0IkzdRRYhB@freedom> Message-ID: <201106071013.12200.neundorf@kde.org> On Tuesday, June 07, 2011 02:00:20 AM Aaron J. Seigo wrote: > On Monday, June 6, 2011 19:41:15 Maksim Orlovich wrote: > > > * all new features will be developed using the recommended git > > > workflow > > > > > > (pending publication; Cornelius is working on that one); > > > > > > Those rules might seem like a strong departure from what we're used to. > > > On the other hand, if you look at them closely, they are merely making > > > explicit changes to our habits which already happened a while ago > > > during the Qt 3 to Qt 4 port > > > > These two things don't really go well together now, do they? > > a documented git workflow is new, but needed. Yes, yes, yes. 100 %. We really need that. For git newbies (like me) and to avoid total chaos. And so that it stays possible to contribute to any KDE projects without having to figure out for each single project how they prefer to use git and branches etc. Alex From neundorf at kde.org Tue Jun 7 09:14:43 2011 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 7 Jun 2011 10:14:43 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <4DEDC34E.3030006@kde.org> References: <13788778.c49pUyIHfV@lothlorien> <4DEDC34E.3030006@kde.org> Message-ID: <201106071014.43312.neundorf@kde.org> On Tuesday, June 07, 2011 08:21:02 AM Sebastian Trüg wrote: > Just as a side-note on SDO: For me SDO is very close to the KDE > development process. If I had my way everyone running KDE master would > also use SDO master. But for some reason that would only be acceptable > if SDO were in KDE's git... It could be integrated into a "virtual" kdesupport, independent from where it is hosted. doesn't kdesrc-build actually do this ? Alex From aseigo at kde.org Tue Jun 7 09:10:55 2011 From: aseigo at kde.org (Aaron J. Seigo) Date: Tue, 07 Jun 2011 08:10:55 -0000 Subject: Review Request: Export the function isShiftAsModifierAllowed() from KKeySequenceWidget In-Reply-To: <20110606084604.19753.35399@vidsolbach.de> References: <20110606084604.19753.35399@vidsolbach.de> Message-ID: <20110607081055.19111.4186@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101515/#review3736 ----------------------------------------------------------- both of the classes that need this are in the kdeui library, so there is no reason to export this symbol. it is not imho API that needs to or should be public. i'd instead recommend moving this to a private header, such as kglobalaccel_p.h and including that header in both of the .cpp classes that need it. - Aaron J. 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neundorf at kde.org Tue Jun 7 09:16:27 2011 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 7 Jun 2011 10:16:27 +0200 Subject: Requested Moratorium on hard to build dependency bumps =?iso-8859-1?q?for=09KDE?= 5 In-Reply-To: <201106070932.09339.boud@valdyas.org> References: <4DEDC836.1070005@kde.org> <201106070932.09339.boud@valdyas.org> Message-ID: <201106071016.28094.neundorf@kde.org> On Tuesday, June 07, 2011 09:32:09 AM Boudewijn Rempt wrote: > On Tuesday 07 June 2011 Jun, Sebastian Trüg wrote: > > Restricting ourselves to old versions (and as a developer anything > > released is old for me) means to restrict the power we have and > > undermines our very development model. > > In my opinion, almost always needing the development version of e.g. GTK is > what is keeping GIMP a project with hardly any contributors. But that's an > application, not a framework. Still -- if you want to have a healthy > project with many contributors, making it hard to develop by requiring > lots of unpackaged isn't a good idea. I fully agree. Alex From toma at kde.org Tue Jun 7 09:11:59 2011 From: toma at kde.org (Tom Albers) Date: Tue, 07 Jun 2011 08:11:59 -0000 (UTC) Subject: Rules to be approved as part of KDE Frameworks In-Reply-To: <201106071013.12200.neundorf@kde.org> References: <201106071013.12200.neundorf@kde.org> Message-ID: ----- Original Message ----- > On Tuesday, June 07, 2011 02:00:20 AM Aaron J. Seigo wrote: > > On Monday, June 6, 2011 19:41:15 Maksim Orlovich wrote: > > > > * all new features will be developed using the recommended git > > > > workflow > > > > > > > > (pending publication; Cornelius is working on that one); > > > > > > > > Those rules might seem like a strong departure from what we're > > > > used to. > > > > On the other hand, if you look at them closely, they are merely > > > > making > > > > explicit changes to our habits which already happened a while > > > > ago > > > > during the Qt 3 to Qt 4 port > > > > > > These two things don't really go well together now, do they? > > > > a documented git workflow is new, but needed. > > Yes, yes, yes. 100 %. We really need that. For git newbies (like me) > and to > avoid total chaos. And so that it stays possible to contribute to > any KDE > projects without having to figure out for each single project how > they prefer > to use git and branches etc. That's not what is happening. It's a workflow for the frameworks, the rest of KDE is invited to follow. So you still have to find out for each single project how they prefer to use git and branches. (afaics) Best, -- Tom Albers KDE Sysadmin From aseigo at kde.org Tue Jun 7 09:21:42 2011 From: aseigo at kde.org (Aaron J. Seigo) Date: Tue, 07 Jun 2011 10:21:42 +0200 Subject: Intended organization of KDE Frameworks In-Reply-To: <201106070839.58761.inge@lysator.liu.se> References: <201106070004.52120.ervin@kde.org> <201106070839.58761.inge@lysator.liu.se> Message-ID: <15383934.4ApBHEDaG3@freedom> On Tuesday, June 7, 2011 08:39:58 Inge Wallin wrote: > So a well defined API that applications could use, and a well isolated way > to include a set of implementations would be nice. We are dealing with the best way to make this happen is to create a concrete plan and propose it. for inspiration: at Platform 11, a couple of teams spent entire days going through every single class in kdelibs and entry in kde-runtime to catalog what is what. the results are on spreadsheets: https://spreadsheets.google.com/spreadsheet/ccc?key=0AhQ1BhQL6D9wdGpvOHN0N0xRZVBGU1c3ZmdiaXZORUE&hl=en_US&authkey=CKTcjdgP https://spreadsheets.google.com/spreadsheet/ccc?key=0Am2uzNh0KAtpdFVaRkMtMXZEcC00MEE0dzhrbWV2Nnc&hl=en_US&authkey=CI_3zNMC these were then used to build up answers that are workable and make some sense. it's work, but necessary work to turn a good ambition such as yours into a reality. we'll have a fair amount of time to do the actual work after 4.7 branches, but we need to have concrete plans so we know what we are trying to do. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From neundorf at kde.org Tue Jun 7 09:32:07 2011 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 7 Jun 2011 10:32:07 +0200 Subject: Rules to be approved as part of KDE Frameworks In-Reply-To: References: Message-ID: <201106071032.07682.neundorf@kde.org> On Tuesday, June 07, 2011 10:11:59 AM Tom Albers wrote: > ----- Original Message ----- > ... > > > a documented git workflow is new, but needed. > > > > Yes, yes, yes. 100 %. We really need that. For git newbies (like me) > > and to > > avoid total chaos. And so that it stays possible to contribute to > > any KDE > > projects without having to figure out for each single project how > > they prefer > > to use git and branches etc. > > That's not what is happening. It's a workflow for the frameworks, the rest > of KDE is invited to follow. I'd make that "the rest of KDE SC is strongly recommended to follow". For me, as having to work everywhere a bit from time to time, it is not manageble to figure out for each of the 50 or 100 repositories how these guys prefer to use git. This could be a thing which decides whether something wants to be in KDE SC or not. Alex From aseigo at kde.org Tue Jun 7 09:42:54 2011 From: aseigo at kde.org (Aaron J. Seigo) Date: Tue, 07 Jun 2011 10:42:54 +0200 Subject: Rules to be approved as part of KDE Frameworks In-Reply-To: References: Message-ID: <48447257.9dHMRPmJCD@freedom> On Tuesday, June 7, 2011 08:11:59 Tom Albers wrote: > That's not what is happening. It's a workflow for the frameworks, the rest > of KDE is invited to follow. So you still have to find out for each single > project how they prefer to use git and branches. (afaics) we're between a rock and a hard place. if we just say "You will all use this workflow starting NOW!" people will complain that they have not been involved in the process and are being told how to work. fair enough. if we say "Here's our recommendation and Frameworks and Workspaces will be using it, we recommend all other projects in KDE git also move to this workflow." then others will note that it still isn't consistent because we aren't mandating it. :) the workflow that will be proposed (i need to find Cornelius and get him to press the send key on that email! :) should be palatable for projects of all sizes. the workflow we will be using for Frameworks is not very complex, but it is more complex than needed for smaller projects (e.g. single apps with 1-2 developers) and so there is a small set (3 iirc) of workflow suggestions modeled on the one we will use for Frameworks but with some intermediary steps in the workflow taken out. once this proposal makes its way to k-c-d, i will be helping to get broad adoption of it throughout KDE and then we can have the best of both worlds: no project being forced to work a certain way without having been involved in the discussion, but still have consistency. it's a longer road, but one that i think is more fair and respectful of others. it would indeed be far easier, in terms of effort required, to just mandate something. probably wouldn't have great results though. :) -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From simonpersson1 at gmail.com Tue Jun 7 08:21:24 2011 From: simonpersson1 at gmail.com (Simon Persson) Date: Tue, 07 Jun 2011 07:21:24 -0000 Subject: Review Request: Allow use of shift together with multimedia keys in shortcuts Message-ID: <20110607072124.16510.84666@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101530/ ----------------------------------------------------------- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sputnick at quassel-irc.org Tue Jun 7 10:51:29 2011 From: sputnick at quassel-irc.org (Manuel "Sput" Nickschas) Date: Tue, 07 Jun 2011 11:51:29 +0200 Subject: Native gettext support for Qt (was: Intended organization of KDE Frameworks) In-Reply-To: <201106070846.54923.aacid@kde.org> References: <201106070004.52120.ervin@kde.org> <201106070138.58971.ervin@kde.org> <201106070846.54923.aacid@kde.org> Message-ID: <3657516.PegxoTencP@axion> On Tuesday 07 June 2011 08:46:54 Albert Astals Cid wrote: > This means that if you want Tier 1 frameworks to be translatable you need > either to teach Qt to understand gettext files natively or to make Tier 1 > frameworks use pure based Qt/Linguist solutions which does not fit either in > what scripty is able to do neither in what our translators are used to. Wouldn't that be a sane thing anyway? I never really understood why Qt needs to have its own, completely incompatible translation system while the rest of the world happily uses gettext. In Quassel, this has hurt us a lot because we cannot easily tap into existing translation teams and resources. As it turns out (and understandably so), translation teams like that of KDE have their established workflows centered around gettext, and are not too willing to start using Linguist or other tools to translate an application that is Qt- based. A while ago, we have tweaked Quassel's build system to accept .po files and generate .qm files at build time from those. But this is error-prone and requires tools (e.g. lrelease) that are not found on all systems by default. Still, offering gettext translations has significantly increased translator contributions for us... This whole situation is such a mess that we actually looked into taking KDE's i18n stuff and friends, and port it over to Qt (by way of deriving QTranslator), just to be able to reap the benefits of KDE's translation resources. Turned out that i18n() depends on too much of other kdelibs stuff to make that a feasible, maintainable option though. I really think one should look into the opportunity given to us by the move to Qt5 to bring native gettext support to Qt, and retire the old tr() system, or at least make it just another option. This would tremendously help Qt-based apps to get good localization support, and even more so applications like Quassel that can be built with and without KDE support. ~ Sputnick -- Manuel "Sputnick" Nickschas ("Sput" on Freenode) | (o< Member of the Quassel IRC Project - http://quassel-irc.org | //\ Come visit us in #quassel! | V_/_ From apaku at gmx.de Tue Jun 7 11:39:38 2011 From: apaku at gmx.de (Andreas Pakulat) Date: Tue, 7 Jun 2011 12:39:38 +0200 Subject: Native gettext support for Qt (was: Intended organization of KDE Frameworks) In-Reply-To: <3657516.PegxoTencP@axion> References: <201106070004.52120.ervin@kde.org> <201106070138.58971.ervin@kde.org> <201106070846.54923.aacid@kde.org> <3657516.PegxoTencP@axion> Message-ID: <20110607103938.GA5588@neo.apaku.dnsalias.org> On 07.06.11 11:51:29, Manuel "Sput" Nickschas wrote: > On Tuesday 07 June 2011 08:46:54 Albert Astals Cid wrote: > > > This means that if you want Tier 1 frameworks to be translatable you need > > either to teach Qt to understand gettext files natively or to make Tier 1 > > frameworks use pure based Qt/Linguist solutions which does not fit either in > > what scripty is able to do neither in what our translators are used to. > > Wouldn't that be a sane thing anyway? I never really understood why Qt needs > to have its own, completely incompatible translation system while the rest of > the world happily uses gettext. In Quassel, this has hurt us a lot because we > cannot easily tap into existing translation teams and resources. As it turns > out (and understandably so), translation teams like that of KDE have their > established workflows centered around gettext, and are not too willing to > start using Linguist or other tools to translate an application that is Qt- > based. One reason I guess is that gettext is only easily available on Linux/*nix, but at least on Windows and MacOSX is an unknown thing. So by having their own solution Qt apps work the same way on all platforms. Andreas From johnlayt at googlemail.com Tue Jun 7 11:41:29 2011 From: johnlayt at googlemail.com (John Layt) Date: Tue, 7 Jun 2011 11:41:29 +0100 Subject: Intended organization of KDE Frameworks In-Reply-To: <201106070138.58971.ervin@kde.org> References: <201106070004.52120.ervin@kde.org> <201106070026.17380.aacid@kde.org> <201106070138.58971.ervin@kde.org> Message-ID: <201106071141.29497.johnlayt@googlemail.com> On Tuesday 07 Jun 2011 00:38:58 Kevin Ottens wrote: > Right, however there's also a plan ATM to get the settings between KLocale > and QLocale shared. John is working on that right now, so it depends a bit > on the outcome, in any cases the situation is likely to improve on that > particular point. I'm drafting an email right now to set out some of my plans, but I'm well aware I need to sit down with Albert at Desktop Summit to discuss how translation fits into all this to make sure we lose none of the features we currently have. John. From johnlayt at googlemail.com Tue Jun 7 12:20:51 2011 From: johnlayt at googlemail.com (John Layt) Date: Tue, 7 Jun 2011 12:20:51 +0100 Subject: Native gettext support for Qt (was: Intended organization of KDE Frameworks) In-Reply-To: <3657516.PegxoTencP@axion> References: <201106070004.52120.ervin@kde.org> <201106070846.54923.aacid@kde.org> <3657516.PegxoTencP@axion> Message-ID: <201106071220.51715.johnlayt@googlemail.com> On Tuesday 07 Jun 2011 10:51:29 Manuel "Sput" Nickschas wrote: > On Tuesday 07 June 2011 08:46:54 Albert Astals Cid wrote: > > This means that if you want Tier 1 frameworks to be translatable you need > > either to teach Qt to understand gettext files natively or to make Tier 1 > > frameworks use pure based Qt/Linguist solutions which does not fit either > > in what scripty is able to do neither in what our translators are used > > to. > > Wouldn't that be a sane thing anyway? I never really understood why Qt > needs to have its own, completely incompatible translation system while > the rest of the world happily uses gettext. In Quassel, this has hurt us a > lot because we cannot easily tap into existing translation teams and > resources. As it turns out (and understandably so), translation teams like > that of KDE have their established workflows centered around gettext, and > are not too willing to start using Linguist or other tools to translate an > application that is Qt- based. > > A while ago, we have tweaked Quassel's build system to accept .po files and > generate .qm files at build time from those. But this is error-prone and > requires tools (e.g. lrelease) that are not found on all systems by > default. Still, offering gettext translations has significantly increased > translator contributions for us... > > This whole situation is such a mess that we actually looked into taking > KDE's i18n stuff and friends, and port it over to Qt (by way of deriving > QTranslator), just to be able to reap the benefits of KDE's translation > resources. Turned out that i18n() depends on too much of other kdelibs > stuff to make that a feasible, maintainable option though. > > I really think one should look into the opportunity given to us by the move > to Qt5 to bring native gettext support to Qt, and retire the old tr() > system, or at least make it just another option. This would tremendously > help Qt-based apps to get good localization support, and even more so > applications like Quassel that can be built with and without KDE support. > > ~ Sputnick We discussed translation briefly at Platform 11 and Qt moving to or supporting .po is something we really want to push for at QCS. I really hope we have some people knowledgable about translation at QCS able to argue the point, otherwise please let me know the key arguments in favour. As part of the whole modularisation discussion the idea was also floated that if Qt is unwilling to move to .po then our translation module could be an attractive option for other projects looking for a sane and fully featured transaltion solution. John. From thiago at kde.org Tue Jun 7 12:41:43 2011 From: thiago at kde.org (Thiago Macieira) Date: Tue, 07 Jun 2011 13:41:43 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <201106071014.43312.neundorf@kde.org> References: <4DEDC34E.3030006@kde.org> <201106071014.43312.neundorf@kde.org> Message-ID: <1517709.dzmYBMXKvy@lothlorien> On Tuesday, 7 de June de 2011 10:14:43 Alexander Neundorf wrote: > On Tuesday, June 07, 2011 08:21:02 AM Sebastian Trüg wrote: > > Just as a side-note on SDO: For me SDO is very close to the KDE > > development process. If I had my way everyone running KDE master would > > also use SDO master. But for some reason that would only be acceptable > > if SDO were in KDE's git... > > It could be integrated into a "virtual" kdesupport, independent from where > it is hosted. > doesn't kdesrc-build actually do this ? The part "shared-desktop" of the name seems to imply that it's not that close to the KDE development process. If they are so close to the KDE development process, why aren't they called "kde ontologies" instead? Otherwise, it looks like people from the other camp who name their technologies under generic names like Notifications or libwebkit and pretend that they are the official solution for everyone. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From kde at michael-jansen.biz Tue Jun 7 17:28:31 2011 From: kde at michael-jansen.biz (Michael Jansen) Date: Tue, 07 Jun 2011 16:28:31 -0000 Subject: Review Request: Fix global shortcuts that needs shift key, like for example ctrl+% (ctrl+shift+5 on many keyboards) In-Reply-To: <20110606110201.27225.20279@vidsolbach.de> References: <20110606110201.27225.20279@vidsolbach.de> Message-ID: <20110607162831.15300.51647@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101520/#review3751 ----------------------------------------------------------- Why don't you fix KKeyServer to return the correct results instead of fixing the wrong ones here? - Michael 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at michael-jansen.biz Tue Jun 7 17:31:44 2011 From: kde at michael-jansen.biz (Michael Jansen) Date: Tue, 07 Jun 2011 16:31:44 -0000 Subject: Review Request: Fix meta+shift+tab and similar global shortcuts. In-Reply-To: <20110606112417.28852.64923@vidsolbach.de> References: <20110606112417.28852.64923@vidsolbach.de> Message-ID: <20110607163144.15480.49305@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101523/#review3752 ----------------------------------------------------------- Looks good but i am wondering if it wouldn't be necessary to complain about a shortcut conflict if you try to register some shortcut with tab and the same one with backtab is already registered? If not we could get two conflicting shortcuts here. - Michael 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at michael-jansen.biz Tue Jun 7 17:33:57 2011 From: kde at michael-jansen.biz (Michael Jansen) Date: Tue, 07 Jun 2011 16:33:57 -0000 Subject: Review Request: Allow use of shift together with multimedia keys in shortcuts In-Reply-To: <20110607072124.16510.84666@vidsolbach.de> References: <20110607072124.16510.84666@vidsolbach.de> Message-ID: <20110607163357.15569.36610@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101530/#review3753 ----------------------------------------------------------- Ship it! I think that looks good. - Michael 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aacid at kde.org Tue Jun 7 18:57:22 2011 From: aacid at kde.org (Albert Astals Cid) Date: Tue, 7 Jun 2011 18:57:22 +0100 Subject: Native gettext support for Qt (was: Intended organization of KDE Frameworks) In-Reply-To: <201106071220.51715.johnlayt@googlemail.com> References: <201106070004.52120.ervin@kde.org> <3657516.PegxoTencP@axion> <201106071220.51715.johnlayt@googlemail.com> Message-ID: <201106071857.23049.aacid@kde.org> A Tuesday, June 07, 2011, John Layt va escriure: > We discussed translation briefly at Platform 11 and Qt moving to or > supporting .po is something we really want to push for at QCS. I really > hope we have some people knowledgable about translation at QCS able to > argue the point, otherwise please let me know the key arguments in favour. Not sure about other people knowledgable about translation but i won't be at QCS. Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpyne at kde.org Tue Jun 7 23:42:29 2011 From: mpyne at kde.org (Michael Pyne) Date: Tue, 07 Jun 2011 18:42:29 -0400 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <201106071014.43312.neundorf@kde.org> References: <4DEDC34E.3030006@kde.org> <201106071014.43312.neundorf@kde.org> Message-ID: <2314305.VcguKtLzyt@midna> On Tuesday, June 07, 2011 10:14:43 Alexander Neundorf wrote: > On Tuesday, June 07, 2011 08:21:02 AM Sebastian Trüg wrote: > > Just as a side-note on SDO: For me SDO is very close to the KDE > > development process. If I had my way everyone running KDE master would > > also use SDO master. But for some reason that would only be acceptable > > if SDO were in KDE's git... > > It could be integrated into a "virtual" kdesupport, independent from where > it is hosted. > doesn't kdesrc-build actually do this ? SDO is in the git-master kdesrc-buildrc-sample file (commented out). However, this was only when even I finally couldn't build KDE using system packages of SDO, on *Gentoo*. SDO is the first non-Qt/non-KDE project to be included in the kdesrc-build sample configuration, and I was semi-surprised that it even worked at all. Regards, - Michael Pyne -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mpyne at kde.org Tue Jun 7 23:48:20 2011 From: mpyne at kde.org (Michael Pyne) Date: Tue, 07 Jun 2011 18:48:20 -0400 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: References: <17911809.h6xGmj1gbX@freedom> Message-ID: <6901979.zu4Rl1ySJy@midna> On Tuesday, June 07, 2011 08:29:51 Ben Cooksley wrote: > First Phonon. > Phonon GStreamer - whilst installable, crashes applications on startup > - and is therefore unusable. This effectively removes the capability > to have multimedia playback using a KDE application. I have used Phonon GStreamer exclusively for aeons now... but without PulseAudio. It has only bitten me once in the 2-3 years I can remember using it exclusively. On the other hand, I only use JuK and the normal KDE notification sounds. YMMV, but I just wanted to throw out that it's possible to get phonon-gst to work, I'm not sure what would be happening different on your system though. Regards, - Michael Pyne -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From sitter at kde.org Wed Jun 8 00:25:20 2011 From: sitter at kde.org (Harald Sitter) Date: Wed, 8 Jun 2011 01:25:20 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: References: <5130765.7m7Pas7BAs@martin-desktop> <17911809.h6xGmj1gbX@freedom> Message-ID: On Mon, Jun 6, 2011 at 10:29 PM, Ben Cooksley wrote: > On Tue, Jun 7, 2011 at 8:06 AM, Aaron J. Seigo wrote: >> On Tuesday, June 7, 2011 06:19:52 Ben Cooksley wrote: >>> The Moratorium would extend to all components of the KDE SC >>> distribution. Hence kde-core-devel. >> >> imho this is impossible, for the reasons Martin noted. >> >>> The components affected by the Moratorium - namely the Kernel, X and >>> ALSA interfaces are not easy to build. For those of us on non-rolling >> >> can you provide an answer to Kevin's initial question, namely: what are the >> actual cases that triggered this concern? e.g. what currently relies on a >> recent kernel, X or alsa? > > I have two examples, Phonon and KWin. > > First Phonon. The Xine backend has now been deprecated, and has. > already broken in applications such as Amarok. The VLC backend gives > me terrible skipping. Apparently upgrading to a newer version of VLC > is needed to use it - but that depends on XCB 1.6. I only have 1.5. > Phonon GStreamer - whilst installable, crashes applications on startup > - and is therefore unusable. This effectively removes the capability > to have multimedia playback using a KDE application. > > I tried (unsuccessfully unfortunately) to backport some of the fixes > which would fix the skipping in Phonon VLC - but that didn't work. I fail to see how this supports the point of having a moratorium, as only ALSA would be affected whereas in the presented cases it would appear that it is more of a user space library issue. regards, Harald From nicolas.alvarez at gmail.com Wed Jun 8 02:39:15 2011 From: nicolas.alvarez at gmail.com (Nicolas Alvarez) Date: Tue, 07 Jun 2011 22:39:15 -0300 Subject: KConfigIniBackend::isWritable bug Message-ID: Hi, I'm trying to get kdelibs unit tests to run in a clean and headless environment (for automated testing). I'm starting an X server, dbus, and kdeinit by hand. Currently kded (started by kdeinit) is failing to start up if I'm running it for the first time and there is currently no ~/.kde directory. Specifically, it's showing a kdialog popup with 'Configuration file "/var/lib/buildbot/.kde/share/config/kdedrc" not writable.'. (I don't even see the popup because it's on the invisible Xvfb server). After some code-reading and debugging, I found the cause. kded checks if ~/.kde/share/config/kdedrc is writable via KConfigIniBackend::isWritable(). This function first checks if the file itself is writable using access() (well, KStandardDirs::checkAccess). Then there is this code: // The check might have failed because any of the containing dirs // did not exist. If the file does not exist, check if the deepest // existing dir is writable. if (!QFileInfo(filePath()).exists()) { QDir dir = QFileInfo(filePath()).absolutePath(); while (!dir.exists()) { if (!dir.cdUp()) { return false; } } return QFileInfo(dir.absolutePath()).isWritable(); } This code will never succeed for more than one level of directories: QDir::cdUp() requires an existing and readable parent directory! So it would only work in this case if ~/.kde/share already exists. What's the cleanest way to rewrite it? dir=dir.filePath("..")? -- Nicolas From trueg at kde.org Wed Jun 8 08:20:32 2011 From: trueg at kde.org (=?ISO-8859-1?Q?Sebastian_Tr=FCg?=) Date: Wed, 08 Jun 2011 09:20:32 +0200 Subject: Requested Moratorium on hard to build dependency bumps for KDE 5 In-Reply-To: <1517709.dzmYBMXKvy@lothlorien> References: <4DEDC34E.3030006@kde.org> <201106071014.43312.neundorf@kde.org> <1517709.dzmYBMXKvy@lothlorien> Message-ID: <4DEF22C0.3090504@kde.org> On 06/07/2011 01:41 PM, Thiago Macieira wrote: > On Tuesday, 7 de June de 2011 10:14:43 Alexander Neundorf wrote: >> On Tuesday, June 07, 2011 08:21:02 AM Sebastian Trüg wrote: >>> Just as a side-note on SDO: For me SDO is very close to the KDE >>> development process. If I had my way everyone running KDE master would >>> also use SDO master. But for some reason that would only be acceptable >>> if SDO were in KDE's git... >> >> It could be integrated into a "virtual" kdesupport, independent from where >> it is hosted. >> doesn't kdesrc-build actually do this ? > > The part "shared-desktop" of the name seems to imply that it's not that close > to the KDE development process. If they are so close to the KDE development > process, why aren't they called "kde ontologies" instead? SDO is intended to be shared between desktop frameworks and was actually started as a shared project between KDE and Ghome. Sadly Tracker uses their own fork of it and does not contribute the changes back (although they have claimed to be planning to do it for a long time). Renaming it would be a IMHO bad move now. It being close to the KDE development process simply stems from the fact that I maintain it and add features when I need them for KDE. So the reasons are simply of a practical nature. Cheers, Sebastian > Otherwise, it looks like people from the other camp who name their > technologies under generic names like Notifications or libwebkit and pretend > that they are the official solution for everyone. > From sommerluk at gmail.com Tue Jun 7 12:51:25 2011 From: sommerluk at gmail.com (Lukas Sommer) Date: Tue, 07 Jun 2011 11:51:25 -0000 Subject: Review Request: startkde.cmake should treat font dpi like kcontrol/krdb/krdb.cpp does In-Reply-To: <20110606021027.5880.94742@vidsolbach.de> References: <20110606021027.5880.94742@vidsolbach.de> Message-ID: <20110607115125.32034.72090@vidsolbach.de> > On June 6, 2011, 2:10 a.m., David Faure wrote: > > Looks good. Do you want me to commit this for you, or do you want to get a kde contributor account instead, to be able to commit this directly as well as future patches? :) It would be great to have a kde contributor account. (However, I will have to learn to work with GIT. :) - Lukas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101410/#review3703 ----------------------------------------------------------- On June 1, 2011, 10:54 a.m., Lukas Sommer wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101410/ > ----------------------------------------------------------- > > (Updated June 1, 2011, 10:54 a.m.) > > > Review request for KDE Base Apps, KDE Runtime and kdelibs. > > > Summary > ------- > > I've been experimenting a little bit with custom font dpi sizes in $HOME/.kde4/share/config/kcmfonts > > There, you can set custom font dpi value. Although the user interface (systemsettings/fonts) only provides 0 (don't force a dpi, use the system default instead), 96 and 120 as choice, in the config file you can put (manually) arbitrary values. This works mostly fine because kcontrol/krdb/krdb.cpp simply processes the dpi value of the config file "as is". > > However, startkde.cmake doesn't. It checks if the value is 96 or 120. If not, the value is ignored and the system default is used. > > Result: When you use e.g. 200 as dpi value and restart KDE, then KWin uses the default value (96 dpi on my system) for the window title, while the applications themself are displayed using 200 dpi. So the applications fonts are as big as desired, but the window title is too small. See the attached screenshot. This behaviour is inconsistent. startkde.cmake should follow the same police as kcontrol/krdb/krdb.cpp does. This patch fixes this. > > (The user interface could be adopted in another patch.) > > (Make this work would benefit people who need a high display resolution. Example: You connect your computer to your plasma tv and you want to be still be able to read the text although you are at a distance of 5 meters from the tv monitor. See also bug 272266) > > > This addresses bug 190489. > http://bugs.kde.org/show_bug.cgi?id=190489 > > > Diffs > ----- > > kcontrol/fonts/fonts.h 2c722d4 > kcontrol/fonts/fonts.cpp 0cd2666 > startkde.cmake dde9c23 > > Diff: http://git.reviewboard.kde.org/r/101410/diff > > > Testing > ------- > > I've applied the patch to my local /usr/bin/startkde file, and it works fine. > > > Screenshots > ----------- > > > http://git.reviewboard.kde.org/r/101410/s/171/ > > > Thanks, > > Lukas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpersson1 at gmail.com Wed Jun 8 05:05:49 2011 From: simonpersson1 at gmail.com (Simon Persson) Date: Wed, 08 Jun 2011 04:05:49 -0000 Subject: Review Request: Fix meta+shift+tab and similar global shortcuts. In-Reply-To: <20110607163144.15480.49305@vidsolbach.de> References: <20110607163144.15480.49305@vidsolbach.de> Message-ID: <20110608040549.21745.24389@vidsolbach.de> > On June 7, 2011, 4:31 p.m., Michael Jansen wrote: > > Looks good but i am wondering if it wouldn't be necessary to complain about a shortcut conflict if you try to register some shortcut with tab and the same one with backtab is already registered? If not we could get two conflicting shortcuts here. Yes, that could be a nice thing. Currently it is needed. But with this patch applied KWin can be changed and then I don't see a great need for it, as I said above.. the only way to get shortcuts that include backtab is to either do it from code (the default shortcut) or by manually editing config files. If I have some time I can look at it, but it will be a separate patch. Should I commit this? - Simon ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101523/#review3752 ----------------------------------------------------------- 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpersson1 at gmail.com Wed Jun 8 04:49:41 2011 From: simonpersson1 at gmail.com (Simon Persson) Date: Wed, 08 Jun 2011 03:49:41 -0000 Subject: Review Request: Fix global shortcuts that needs shift key, like for example ctrl+% (ctrl+shift+5 on many keyboards) In-Reply-To: <20110607162831.15300.51647@vidsolbach.de> References: <20110607162831.15300.51647@vidsolbach.de> Message-ID: <20110608034941.20743.42260@vidsolbach.de> > On June 7, 2011, 4:28 p.m., Michael Jansen wrote: > > Why don't you fix KKeyServer to return the correct results instead of fixing the wrong ones here? Yes, my first thought was to fix this by changing KKeyServer::keyQtToModX to add Shift to the modifiers if it is needed to get the symbol. This could be done using the (currently unused) function getModsRequired(uint sym) in kkeyserver_x11.cpp. But this is public API and I don't know what other users there are and what the expected behavior is, changing it to do add modifiers that were not there based on the behavior of some widget for entering shortcuts could be considered unexpected:) Same goes for KKeyServer::xEventToQt(), that would need to be changed to strip Shift modifier in the cases where KKeySequenceWidget has removed it. The positive thing about doing it this way would be that isShiftAsModifierAllowed() would not need to be exported, it could be in a private header as Aaron suggested in the other review request. - Simon ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101520/#review3751 ----------------------------------------------------------- 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at carewolf.com Wed Jun 8 12:41:22 2011 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Wed, 8 Jun 2011 13:41:22 +0200 Subject: Changing the defaults for HTTP ACCEPT, ACCEPT-LANGUAGE and USERAGENT headers In-Reply-To: References: Message-ID: <201106081341.22881.kde@carewolf.com> On Sunday 08 May 2011, Dawit A wrote: > In hopes of making Konqueror's default settings for the aforementioned > HTTP headers inline with other browsers, I want to change the default > settings for these three header as outlined below. > > ** Please note that this only affects the default! Each and every > application can tell the ioslave what to use through the KIO meta-data > system for each one of these parameters. > > USER-AGENT HEADER > ================= > OLD DEFAULT: Mozilla/5.0 (compatible; Konqueror/4.6; Linux) > KHTML/4.6.41 (like Gecko) > NEW DEFAULT: Mozilla/5.0 (X11) KHTML/4.6.41 (like Gecko) Konqueror/4.6 > > OLD Full: Mozilla/5.0 (compatible; Konqueror/4.6; Linux 2.6.31; > x86-64; en_US) KHTML/4.6.41 (like Gecko) > NEW Full: Mozilla/5.0 (X11; Linux 2.6.31 x86-64; en_US) KHTML/4.6.41 > (like Gecko) Konqueror/4.6 > > Looks good. I tried something similar two years ago, but didn't have the time to properly test it on enough websites. A few extra things I was changing: 1. Remove point release version for Linux and probably KDE, this is considered dangerous (can reveal a linux version with specific bugs to be exploited) 2. Add Webkit (or AppleWebKit?) besides Gecko. If I remember correctly I added a both Webkit and a webkit-version number indicating a minimum equivalent webkit version. This fixed a long range of websites that otherwise required UA-spoofing. In short the change means better support from websites that does not detect konqueror, but it could accidently ruin website that already detect konqueror. Regards `Allan From notmart at gmail.com Wed Jun 8 14:44:13 2011 From: notmart at gmail.com (Marco Martin) Date: Wed, 8 Jun 2011 15:44:13 +0200 Subject: [4.7 Beta1 blocker] plasma depending on kdelibs/experimental In-Reply-To: <5219360.MeOMRKhQCN@midna> References: <201105211108.53769.mueller@kde.org> <201105252158.13672.notmart@gmail.com> <5219360.MeOMRKhQCN@midna> Message-ID: <201106081544.14445.notmart@gmail.com> On Thursday 26 May 2011, Michael Pyne wrote: > On Wednesday, May 25, 2011 21:58:13 Marco Martin wrote: > > just a reminder on this: > > do we all agree it's a blocker? > > I would agree it's a blocker, kdelibs should not depend on KDE libraries > which don't also have a stable ABI. > > > and that statically including that library in libplasma would be a > > solution? > > Sounds like the best solution IMHO. > > > if so i can get it this weekend. > > Thanks! done Cheers, Marco Martin From illissius at gmail.com Wed Jun 8 17:34:14 2011 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Wed, 8 Jun 2011 18:34:14 +0200 Subject: Review Request: Fix meta+shift+tab and similar global shortcuts. In-Reply-To: <20110608040549.21745.24389@vidsolbach.de> References: <20110607163144.15480.49305@vidsolbach.de> <20110608040549.21745.24389@vidsolbach.de> Message-ID: On Wed, Jun 8, 2011 at 6:05 AM, Simon Persson wrote: > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101523/ > > On June 7th, 2011, 4:31 p.m., *Michael Jansen* wrote: > > Looks good but i am wondering if it wouldn't be necessary to complain about a shortcut conflict if you try to register some shortcut with tab and the same one with backtab is already registered? If not we could get two conflicting shortcuts here. > > Yes, that could be a nice thing. Currently it is needed. But with this patch applied KWin can be changed and then I don't see a great need for it, as I said above.. the only way to get shortcuts that include backtab is to either do it from code (the default shortcut) or by manually editing config files. > > What about users upgrading from older versions who have it stored in their config files? > If I have some time I can look at it, but it will be a separate patch. > > Should I commit this? > > > - Simon > > On June 6th, 2011, 11:24 a.m., Simon Persson wrote: > Review request for KDE Runtime and Michael Jansen. > By Simon Persson. > > *Updated June 6, 2011, 11:24 a.m.* > Description > > 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. > > Testing > > Tested using master branch, running in a Xephyr session. Switching between plasma activities with meta+shift+tab now works. > > *Bugs: * 174142 , 258467, > 261296 , 274006 > Diffs > > - kglobalaccel/globalshortcutcontext.cpp (fc2e6a6) > > View Diff > -- Work is punishment for failing to procrastinate effectively. -------------- next part -------------- An HTML attachment was scrubbed... URL: From faure at kde.org Wed Jun 8 17:21:04 2011 From: faure at kde.org (David Faure) Date: Wed, 08 Jun 2011 16:21:04 -0000 Subject: Review Request: startkde.cmake should treat font dpi like kcontrol/krdb/krdb.cpp does In-Reply-To: <20110606021027.5880.94742@vidsolbach.de> References: <20110606021027.5880.94742@vidsolbach.de> Message-ID: <20110608162104.28749.73488@vidsolbach.de> > On June 6, 2011, 2:10 a.m., David Faure wrote: > > Looks good. Do you want me to commit this for you, or do you want to get a kde contributor account instead, to be able to commit this directly as well as future patches? :) > > Lukas Sommer wrote: > It would be great to have a kde contributor account. (However, I will have to learn to work with GIT. :) See http://community.kde.org/Sysadmin/GitKdeOrgManual#How_to_get_read-write_developer_access - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101410/#review3703 ----------------------------------------------------------- On June 1, 2011, 10:54 a.m., Lukas Sommer wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101410/ > ----------------------------------------------------------- > > (Updated June 1, 2011, 10:54 a.m.) > > > Review request for KDE Base Apps, KDE Runtime and kdelibs. > > > Summary > ------- > > I've been experimenting a little bit with custom font dpi sizes in $HOME/.kde4/share/config/kcmfonts > > There, you can set custom font dpi value. Although the user interface (systemsettings/fonts) only provides 0 (don't force a dpi, use the system default instead), 96 and 120 as choice, in the config file you can put (manually) arbitrary values. This works mostly fine because kcontrol/krdb/krdb.cpp simply processes the dpi value of the config file "as is". > > However, startkde.cmake doesn't. It checks if the value is 96 or 120. If not, the value is ignored and the system default is used. > > Result: When you use e.g. 200 as dpi value and restart KDE, then KWin uses the default value (96 dpi on my system) for the window title, while the applications themself are displayed using 200 dpi. So the applications fonts are as big as desired, but the window title is too small. See the attached screenshot. This behaviour is inconsistent. startkde.cmake should follow the same police as kcontrol/krdb/krdb.cpp does. This patch fixes this. > > (The user interface could be adopted in another patch.) > > (Make this work would benefit people who need a high display resolution. Example: You connect your computer to your plasma tv and you want to be still be able to read the text although you are at a distance of 5 meters from the tv monitor. See also bug 272266) > > > This addresses bug 190489. > http://bugs.kde.org/show_bug.cgi?id=190489 > > > Diffs > ----- > > kcontrol/fonts/fonts.h 2c722d4 > kcontrol/fonts/fonts.cpp 0cd2666 > startkde.cmake dde9c23 > > Diff: http://git.reviewboard.kde.org/r/101410/diff > > > Testing > ------- > > I've applied the patch to my local /usr/bin/startkde file, and it works fine. > > > Screenshots > ----------- > > > http://git.reviewboard.kde.org/r/101410/s/171/ > > > Thanks, > > Lukas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Wed Jun 8 17:12:01 2011 From: null at kde.org (Commit Hook) Date: Wed, 08 Jun 2011 16:12:01 -0000 Subject: Review Request: Fix keypress stealing issue In-Reply-To: <20110602083815.1231.65203@vidsolbach.de> References: <20110602083815.1231.65203@vidsolbach.de> Message-ID: <20110608161201.28440.25366@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101491/#review3776 ----------------------------------------------------------- This review has been submitted with commit 18a232984b8414795aabfdbff4349053432b2a8b by Thomas Friedrichsmeier. - Commit On June 2, 2011, 8:38 a.m., Thomas Friedrichsmeier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101491/ > ----------------------------------------------------------- > > (Updated June 2, 2011, 8:38 a.m.) > > > Review request for kdelibs and David Faure. > > > Summary > ------- > > Shortcut context was not set correctly for the new "Find Text as You Type" action, which can result in the khtmlpart "stealing" '/'-keypresses from other widgets in the same main window. This patch would fix that in the most straight-forward fashion. However: > > a) I do wonder, why this is not simply set for *all* applicable actions (including those which do not have a shortcut set by default, but might have a user-configured shortcut!). I.e. something like > > foreach (QAction *action, actionCollection()->actions()) > { > action->setShortcutContext(Qt::WidgetWithChildrenShortcut); > } > > But perhaps I am overlooking something? > > b) This is sort of OT, but I could not help wondering: > I was pretty confused about the difference between Find... and Find Text as You Type. Since Find... really is find-as-you-type, too. Before I finally gathered it from the sources. May I suggest condensing the three actions > - Find... > - Find Text as You Type > - Find Links as You Type > to two actions > - Find Text (with default shortcuts Ctrl+F *and* '/') > - Find Links > > Regards > Thomas > > > Diffs > ----- > > khtml/khtml_part.cpp ec89b0c8083989afb52ebde714e1fe757ab2e387 > > Diff: http://git.reviewboard.kde.org/r/101491/diff > > > Testing > ------- > > > Thanks, > > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Wed Jun 8 17:12:00 2011 From: null at kde.org (Commit Hook) Date: Wed, 08 Jun 2011 16:12:00 -0000 Subject: Review Request: Fix keypress stealing issue In-Reply-To: <20110602083815.1231.65203@vidsolbach.de> References: <20110602083815.1231.65203@vidsolbach.de> Message-ID: <20110608161200.28398.53513@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101491/#review3775 ----------------------------------------------------------- This review has been submitted with commit ce405591dde09c3462c214d9f31350740ecea8c8 by Thomas Friedrichsmeier. - Commit On June 2, 2011, 8:38 a.m., Thomas Friedrichsmeier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101491/ > ----------------------------------------------------------- > > (Updated June 2, 2011, 8:38 a.m.) > > > Review request for kdelibs and David Faure. > > > Summary > ------- > > Shortcut context was not set correctly for the new "Find Text as You Type" action, which can result in the khtmlpart "stealing" '/'-keypresses from other widgets in the same main window. This patch would fix that in the most straight-forward fashion. However: > > a) I do wonder, why this is not simply set for *all* applicable actions (including those which do not have a shortcut set by default, but might have a user-configured shortcut!). I.e. something like > > foreach (QAction *action, actionCollection()->actions()) > { > action->setShortcutContext(Qt::WidgetWithChildrenShortcut); > } > > But perhaps I am overlooking something? > > b) This is sort of OT, but I could not help wondering: > I was pretty confused about the difference between Find... and Find Text as You Type. Since Find... really is find-as-you-type, too. Before I finally gathered it from the sources. May I suggest condensing the three actions > - Find... > - Find Text as You Type > - Find Links as You Type > to two actions > - Find Text (with default shortcuts Ctrl+F *and* '/') > - Find Links > > Regards > Thomas > > > Diffs > ----- > > khtml/khtml_part.cpp ec89b0c8083989afb52ebde714e1fe757ab2e387 > > Diff: http://git.reviewboard.kde.org/r/101491/diff > > > Testing > ------- > > > Thanks, > > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.friedrichsmeier at ruhr-uni-bochum.de Wed Jun 8 17:44:49 2011 From: thomas.friedrichsmeier at ruhr-uni-bochum.de (Thomas Friedrichsmeier) Date: 8 Jun 2011 18:44:49 +0200 Subject: Review Request: Fix keypress stealing issue In-Reply-To: <20110606021627.6041.39511@vidsolbach.de> References: <20110602083815.1231.65203@vidsolbach.de> <20110606021627.6041.39511@vidsolbach.de> Message-ID: <201106081844.55186.thomas.friedrichsmeier@ruhr-uni-bochum.de> On Monday 06 June 2011, David Faure wrote: > About the second question, here's my commit log for 60ae8626e917cb1f3: > > Re-route the old actions "Find Text as You Type" and "Find Links as You > Type" to the findbar. Remove them from the menu, since they are redundant > with "Find text", but kept two actions just for the shortcuts: > > '/' will still activate "find text (not just links)", but the shortcut > for "find links" is removed by default, advanced users will have to set > one again. Otherwise newbies would get confused after pressing the > shortcut (was single-quote) by mistake: Esc and Ctrl+F would still find in > links only. Yes, I had seen the commit message. > No strong opinion though, on whether it's really needed to keep the '/' > shortcut for compatibility. Let's email all KDE users and ask them... :-) Well, yes, that sounds like a good idea... Actually, my suggestion would have been to keep both shortcuts, and to change the behavior of "Find", rather than that of "Find Text as You Type". I.e. using the "Find"-shortcut would always reset the search mode to "Find in all text". But of course that definitely has potential for confusion, too, and I certainly don't care enough to steer any further into those troubled waters. Regards Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From schumacher at kde.org Wed Jun 8 18:03:01 2011 From: schumacher at kde.org (Cornelius Schumacher) Date: Wed, 8 Jun 2011 19:03:01 +0200 Subject: KDE git workflow Message-ID: <201106081903.01096.schumacher@kde.org> As you already know, we have discussed the git workflow for KDE at the Platform 11 sprint, and have come up with a recommendation. Please find the full text here: http://community.kde.org/KDE_Core/Platform_11/Git_Workflow The core ideas are that: * master is always kept in a stable state that is ready to be used for starting a release * development is happening in feature branches * for larger projects integration branches will be used for further stabilization and wider testing * changes going into master are going through a review process * releases are coming from release branches Please read the full text before commenting to get all details. This workflow will be adopted by some core modules, and is recommended for all KDE modules. It's flexible enough to be used by modules of different sizes and different requirements in terms of stability, so we hope it to be a reasonable fit for as many people as possible. Obviously we'll have to see how well it works and adapt it, if necessary, but it should be a good start. -- Cornelius Schumacher >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << From markg85 at gmail.com Wed Jun 8 19:48:30 2011 From: markg85 at gmail.com (Mark) Date: Wed, 8 Jun 2011 20:48:30 +0200 Subject: Native gettext support for Qt (was: Intended organization of KDE Frameworks) In-Reply-To: <201106071857.23049.aacid@kde.org> References: <201106070004.52120.ervin@kde.org> <3657516.PegxoTencP@axion> <201106071220.51715.johnlayt@googlemail.com> <201106071857.23049.aacid@kde.org> Message-ID: On Tue, Jun 7, 2011 at 7:57 PM, Albert Astals Cid wrote: > A Tuesday, June 07, 2011, John Layt va escriure: > > > We discussed translation briefly at Platform 11 and Qt moving to or > > > supporting .po is something we really want to push for at QCS. I really > > > hope we have some people knowledgable about translation at QCS able to > > > argue the point, otherwise please let me know the key arguments in > favour. > > > Not sure about other people knowledgable about translation but i won't be > at QCS. > > > Albert > Just a comment that might be of interest to some (just found this link): http://code.google.com/p/simple-gettext/ It also has a Qt wrapper.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnlayt at googlemail.com Wed Jun 8 20:27:27 2011 From: johnlayt at googlemail.com (John Layt) Date: Wed, 8 Jun 2011 20:27:27 +0100 Subject: Native gettext support for Qt (was: Intended organization of KDE Frameworks) In-Reply-To: <201106071857.23049.aacid@kde.org> References: <201106070004.52120.ervin@kde.org> <201106071220.51715.johnlayt@googlemail.com> <201106071857.23049.aacid@kde.org> Message-ID: <201106082027.27890.johnlayt@googlemail.com> On Tuesday 07 Jun 2011 18:57:22 Albert Astals Cid wrote: > A Tuesday, June 07, 2011, John Layt va escriure: > > We discussed translation briefly at Platform 11 and Qt moving to or > > supporting .po is something we really want to push for at QCS. I really > > hope we have some people knowledgable about translation at QCS able to > > argue the point, otherwise please let me know the key arguments in > > favour. > > Not sure about other people knowledgable about translation but i won't be > at QCS. > > Albert Looks like I have a crash course in gettext versus tr before the summit then :-( I'm pretty sure we can't convince them to drop tr entirely, but do you think it's feasible for Qt to support loading translations from both systems (obviously not both at the same time)? Cheers! John. From johnlayt at googlemail.com Wed Jun 8 20:27:59 2011 From: johnlayt at googlemail.com (John Layt) Date: Wed, 8 Jun 2011 20:27:59 +0100 Subject: Native gettext support for Qt (was: Intended organization of KDE Frameworks) In-Reply-To: References: <201106070004.52120.ervin@kde.org> <201106071857.23049.aacid@kde.org> Message-ID: <201106082028.00063.johnlayt@googlemail.com> On Wednesday 08 Jun 2011 19:48:30 Mark wrote: > Just a comment that might be of interest to some (just found this link): > http://code.google.com/p/simple-gettext/ > It also has a Qt wrapper.. Interesting, but not very active, GPL3 so not something that could be used in library code, and lacking all our cool advanced features. But just goes to show we're not the ony ones wanting gettext with Qt. John. From richmoore44 at gmail.com Wed Jun 8 21:12:22 2011 From: richmoore44 at gmail.com (Richard Moore) Date: Wed, 8 Jun 2011 21:12:22 +0100 Subject: SSL in KDE going forward Message-ID: Hi All, Right now, we have the opportunity to make sure that Qt's SSL classes offer us the facilities we need in KDE. I'll be attending the QCS and will most likely be working on the SSL stack at the time. If anyone knows anything that we need in KDE that's not currently offered (or even more importantly can't be added from the existing APIs) then now would be a good time to say. The stuff that is currently being looked at is all listed on the following wiki page: http://developer.qt.nokia.com/wiki/Improving_Qts_SSL_Support If you know something that is needed for KDE but isn't listed then let me know. Cheers Rich. ps. designing a new non-SSL based infrastructure for online transactions is out of scope.# From adawit at kde.org Wed Jun 8 21:24:18 2011 From: adawit at kde.org (Dawit A) Date: Wed, 8 Jun 2011 16:24:18 -0400 Subject: SSL in KDE going forward In-Reply-To: References: Message-ID: Would asking for client certficate authentication support be out of the scope or does Qt's SSL already support that ? Last I checked it did not and there is a pending but report about this against kio_http. See https://bugs.kde.org/show_bug.cgi?id=167668. On Wed, Jun 8, 2011 at 4:12 PM, Richard Moore wrote: > Hi All, > > Right now, we have the opportunity to make sure that Qt's SSL classes > offer us the facilities we need in KDE. I'll be attending the QCS and > will most likely be working on the SSL stack at the time. If anyone > knows anything that we need in KDE that's not currently offered (or > even more importantly can't be added from the existing APIs) then now > would be a good time to say. The stuff that is currently being looked > at is all listed on the following wiki page: > http://developer.qt.nokia.com/wiki/Improving_Qts_SSL_Support > > If you know something that is needed for KDE but isn't listed then let me know. > > Cheers > > Rich. > ps. designing a new non-SSL based infrastructure for online > transactions is out of scope.# From aacid at kde.org Wed Jun 8 21:29:05 2011 From: aacid at kde.org (Albert Astals Cid) Date: Wed, 8 Jun 2011 21:29:05 +0100 Subject: Native gettext support for Qt (was: Intended organization of KDE Frameworks) In-Reply-To: <201106082028.00063.johnlayt@googlemail.com> References: <201106070004.52120.ervin@kde.org> <201106082028.00063.johnlayt@googlemail.com> Message-ID: <201106082129.05560.aacid@kde.org> A Wednesday, June 08, 2011, John Layt va escriure: > On Wednesday 08 Jun 2011 19:48:30 Mark wrote: > > Just a comment that might be of interest to some (just found this link): > > http://code.google.com/p/simple-gettext/ > > It also has a Qt wrapper.. > > Interesting, but not very active, GPL3 so not something that could be used > in library code, and lacking all our cool advanced features. But just > goes to show we're not the ony ones wanting gettext with Qt. FWIW all our advanced features are not because of gettext use but because of our code on top of it. Albert > > John. From adawit at kde.org Thu Jun 9 03:13:57 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Thu, 09 Jun 2011 02:13:57 -0000 Subject: Review Request: Do now show invalid URL completion item for text with white spaces. Message-ID: <20110609021357.22100.46258@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101552/ ----------------------------------------------------------- Review request for KDE Base Apps. Summary ------- Attached patch prevents konqueror from providing invalid completion hint when the typed in text contains any kind of white space, e.g. typing "test " would show "http://test ". This addresses bug 129620. http://bugs.kde.org/show_bug.cgi?id=129620 Diffs ----- konqueror/src/konqmainwindow.cpp a309f48 Diff: http://git.reviewboard.kde.org/r/101552/diff Testing ------- Thanks, Dawit -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbeschow at cs.tu-berlin.de Thu Jun 9 08:06:10 2011 From: bbeschow at cs.tu-berlin.de (Bernhard Beschow) Date: Thu, 09 Jun 2011 07:06:10 -0000 Subject: Review Request: Use QDirIterator in KStandardDirs Message-ID: <20110609070610.30684.78618@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101554/ ----------------------------------------------------------- Review request for kdelibs, kdewin and David Faure. Summary ------- Increase portability of kdecore a tiny bit by making KStandardDirs use QDirIterator rater than platform-specific code. Diffs ----- kdecore/kernel/kstandarddirs.cpp ba90270 Diff: http://git.reviewboard.kde.org/r/101554/diff Testing ------- I'm running my platform 4.6 with this patch and haven't noticed any regressions yet. Thanks, Bernhard -------------- next part -------------- An HTML attachment was scrubbed... URL: From hasso at kde.org Thu Jun 9 08:16:53 2011 From: hasso at kde.org (Hasso Tepper) Date: Thu, 09 Jun 2011 10:16:53 +0300 Subject: SSL in KDE going forward In-Reply-To: References: Message-ID: <4DF07365.3020807@kde.org> On 08.06.11; 24. nädal 23:24, Dawit A wrote: > Would asking for client certficate authentication support be out of > the scope or does Qt's SSL already support that ? Last I checked it > did not and there is a pending but report about this against kio_http. > See https://bugs.kde.org/show_bug.cgi?id=167668. Which is in general showstopper for bigger stuff - PKCS#11 support. See https://bugs.kde.org/show_bug.cgi?id=116201. -- Hasso Tepper From adawit at kde.org Thu Jun 9 10:20:37 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Thu, 09 Jun 2011 09:20:37 -0000 Subject: Review Request: Show the correct url in Konqueror when switching to tabs after clearing location bar. Message-ID: <20110609092037.4463.44937@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101558/ ----------------------------------------------------------- Review request for KDE Base Apps. Summary ------- Show the correct url in Konqueror when switching to a new tab after clearing the url of the current tab. Right now if the location bar is cleared using the backspace key or the clear button before switching to another tab, the location bar will always be empty unless the views are reloaded. The second issue, not addressed by this patch, is use of the wrong url on reload. To see this problem simply 1.) Open two tabs, enter a URL in one and let it finish loading. 2.) Start changing the location bar url, but do not press return. 3.) Switch view to the first tab and switch back. 4.) Reload the page. The incorrect URL, newly typed and potentially invalid URL, will be used for the reload request. This issue is caused by a workaround for another bug (#54687) in KonqMainWindow::slotReload and requires its own fix. This addresses bug 187891. http://bugs.kde.org/show_bug.cgi?id=187891 Diffs ----- konqueror/src/konqmainwindow.cpp a309f48 Diff: http://git.reviewboard.kde.org/r/101558/diff Testing ------- Thanks, Dawit -------------- next part -------------- An HTML attachment was scrubbed... URL: From aseigo-RoXCvvDuEio at public.gmane.org Thu Jun 9 10:49:53 2011 From: aseigo-RoXCvvDuEio at public.gmane.org (Aaron J. Seigo) Date: Thu, 09 Jun 2011 09:49:53 -0000 Subject: Review Request: Use QDirIterator in KStandardDirs In-Reply-To: <20110609070610.30684.78618-vnjQvCq2Ar3oK6nBLMlh1Q@public.gmane.org> References: <20110609070610.30684.78618@vidsolbach.de> Message-ID: <20110609094953.5854.20574@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101554/#review3799 ----------------------------------------------------------- my biggest question with this change would be performance. QFileInfo is not fast, and to make matters "worse" this code in KStandardDirs influences start up speed. have you measured the performance after this change relative to before? with Qt5 this may become a moot issue with the changes coming in the QFile backends ... but i don't think it makes sense to introduce possible performance regressions on code that currently works. is there a platform for which the current code fails? - Aaron J. On June 9, 2011, 7:06 a.m., Bernhard Beschow wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101554/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 7:06 a.m.) > > > Review request for kdelibs, kdewin and David Faure. > > > Summary > ------- > > Increase portability of kdecore a tiny bit by making KStandardDirs use QDirIterator rater than platform-specific code. > > > Diffs > ----- > > kdecore/kernel/kstandarddirs.cpp ba90270 > > Diff: http://git.reviewboard.kde.org/r/101554/diff > > > Testing > ------- > > I'm running my platform 4.6 with this patch and haven't noticed any regressions yet. > > > Thanks, > > Bernhard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Kde-windows mailing list Kde-windows-RoXCvvDuEio at public.gmane.org https://mail.kde.org/mailman/listinfo/kde-windows From sebas at kde.org Thu Jun 9 12:22:32 2011 From: sebas at kde.org (Sebastian =?iso-8859-1?q?K=FCgler?=) Date: Thu, 9 Jun 2011 13:22:32 +0200 Subject: Releases of the thing that was KDE In-Reply-To: References: <201106061836.52654.kde@kitterman.com>

Message-ID: <201106091322.32543.sebas@kde.org> Hi Scott, On Tuesday, June 07, 2011 03:13:43 Scott Kitterman wrote: > It may be that there was more to the release implications of the git > transition than "we're sure it'll get figured out by people who actually > care about releases", but if there was it's not apparent to me. I don't think there was, which lead to the screw-ups. It is something we took as a central issue into the discussions during the platform11 sprint, so at least we learnt from that. The short answer to your question is: We will also release backwards- compabitle, monolithic tarballs. That process can largely be automated on our side. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 From kde at kitterman.com Thu Jun 9 13:12:58 2011 From: kde at kitterman.com (Scott Kitterman) Date: Thu, 9 Jun 2011 08:12:58 -0400 Subject: Releases of the thing that was KDE In-Reply-To: <201106091322.32543.sebas@kde.org> References: <201106061836.52654.kde@kitterman.com> <201106091322.32543.sebas@kde.org> Message-ID: <201106090812.59279.kde@kitterman.com> On Thursday, June 09, 2011 07:22:32 AM Sebastian Kügler wrote: > Hi Scott, > > On Tuesday, June 07, 2011 03:13:43 Scott Kitterman wrote: > > It may be that there was more to the release implications of the git > > transition than "we're sure it'll get figured out by people who actually > > care about releases", but if there was it's not apparent to me. > > I don't think there was, which lead to the screw-ups. It is something we > took as a central issue into the discussions during the platform11 sprint, > so at least we learnt from that. > > The short answer to your question is: We will also release backwards- > compabitle, monolithic tarballs. That process can largely be automated on > our side. That's good to know. Personally I think Kubuntu will want to modularize as much as upstream (we already split the monolithic tarballs into multiple binaries, so this is not news to us that splitting is good). I do think that the requirement to produce monolithic tarballs is useful as part of the discipline of releasing. It's a good forcing function to ensure the release contains an aligned set of 'sub-modules'. It would be good to know if there are any packages that were split for 4.7 beta 1 that have reconsidered this and will go back to just releasing the monolithic tarball? Scott K P.S. Added packager back as I think it's relevant. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << From djarvie at kde.org Thu Jun 9 13:50:59 2011 From: djarvie at kde.org (David Jarvie) Date: Thu, 9 Jun 2011 13:50:59 +0100 Subject: KDE git workflow In-Reply-To: <201106081903.01096.schumacher@kde.org> References: <201106081903.01096.schumacher@kde.org> Message-ID: On Wed, June 8, 2011 6:03 pm, Cornelius Schumacher wrote: > As you already know, we have discussed the git workflow for KDE at the > Platform 11 sprint, and have come up with a recommendation. Please find > the > full text here: http://community.kde.org/KDE_Core/Platform_11/Git_Workflow > > The core ideas are that: > * master is always kept in a stable state that is ready to be used for > starting a release > * development is happening in feature branches > * for larger projects integration branches will be used for further > stabilization and wider testing > * changes going into master are going through a review process > * releases are coming from release branches > > Please read the full text before commenting to get all details. > > This workflow will be adopted by some core modules, and is recommended for > all > KDE modules. It's flexible enough to be used by modules of different sizes > and different requirements in terms of stability, so we hope it to be a > reasonable > fit for as many people as possible. Obviously we'll have to see how well > it works and adapt it, if necessary, but it should be a good start. One side effect of using integration branches in what used to be kdelibs/kdepimlibs/kdebase is that new features aren't likely to be widely tested until later in the development cycle than previously. While they are in integration branches, only people who are particularly interested in those areas are likely to use them, and it's only once they eventually reach master that they will be widely used by developers. In one way, that's a good thing, since there should be less bugs encountered by those not directly involved. But the overall effect could be to slow down bug fixing of new features. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm From schumacher at kde.org Thu Jun 9 14:33:06 2011 From: schumacher at kde.org (Cornelius Schumacher) Date: Thu, 9 Jun 2011 15:33:06 +0200 Subject: KDE git workflow In-Reply-To: References: <201106081903.01096.schumacher@kde.org> Message-ID: <201106091533.06246.schumacher@kde.org> On Thursday 09 June 2011 David Jarvie wrote: > > One side effect of using integration branches in what used to be > kdelibs/kdepimlibs/kdebase is that new features aren't likely to be widely > tested until later in the development cycle than previously. While they > are in integration branches, only people who are particularly interested > in those areas are likely to use them, and it's only once they eventually > reach master that they will be widely used by developers. In one way, > that's a good thing, since there should be less bugs encountered by those > not directly involved. But the overall effect could be to slow down bug > fixing of new features. This is a valid concern and we actually discussed it at the sprint. One of the goals of integration branches indeed is to make new features available to a wider audience than just the developers who work on the features. To make this happen we need to make these branches visible, communicate what's going on in them, and advertise them to other developers and adventurous users. One project which does that successfully is the Kernel, so maybe we could do it in a similar way. We might have a "Aaron's branch" of Plasma with the latest Plasma features, or a "KDAB branch" of KDE PIM, which integrates the latest KDE PIM enterprise features, etc. We have some flexibility here, and it probably will take us a bit of time to find the right balance, but hopefully the model proves to be strong enough to accommodate our needs for stability as well as rapid bug fixing of new code. -- Cornelius Schumacher From mo85 at cornell.edu Thu Jun 9 14:57:31 2011 From: mo85 at cornell.edu (Maksim Orlovich) Date: Thu, 9 Jun 2011 09:57:31 -0400 Subject: KDE git workflow In-Reply-To: <201106091533.06246.schumacher@kde.org> References: <201106081903.01096.schumacher@kde.org> <201106091533.06246.schumacher@kde.org> Message-ID: > To make this happen we need to make these branches visible, communicate > what's > going on in them, and advertise them to other developers and adventurous > users. One project which does that successfully is the Kernel, so maybe we > could do it in a similar way. Will we have a single person review every single commit to master, too? > We might have a "Aaron's branch" of Plasma with > the latest Plasma features, or a "KDAB branch" of KDE PIM, which integrates > the latest KDE PIM enterprise features, etc. And what if there are multiple branches on the same module at the same time? Which one of these branches, or master (or release?) is going to get testing coverage? An alternative, of course, is to discourage use of branches if at all possible, and rather prefer a consistently working and stable master (which optionally then becomes the release, without further branching)... or at the very least not to disallow such methodology by fiat. Thanks, Maks From johnlayt at googlemail.com Thu Jun 9 15:31:42 2011 From: johnlayt at googlemail.com (John Layt) Date: Thu, 9 Jun 2011 15:31:42 +0100 Subject: KDE at the Qt Contributors Summit Message-ID: <201106091531.42998.johnlayt@googlemail.com> The Qt Contributors Summit [1] is happening Berlin from 16-18 June to discuss the future of Qt under Open Governance. Many members of the KDE community will be there either as direct representatives of KDE or on behalf of their employer. A rough estimate puts our presence at about 10% of the 200-250 attendees. We would like to co-ordinate our efforts at QtCS to ensure the best possible outcome for KDE and Qt. To help this we would like all KDE community members attending to list their name on the KDE at QtCS wiki page [2]. Please indicate if you are attending on behalf of another organisation and what your t-shirt size is. We will try arrange for KDE "Part of the Solution" t-shirts for everyone to wear to make the KDE presence as obvious as possible, but we understand that people with spilt loyalties will need to show their other colours as well. Apologies for the short notice, but could you please sign up by this Friday to enable the t-shirts to arrive in time. A number of session topics have already been proposed by KDE members, but feel free to propose any other topics you think may be needed [3]. We also want a KDE presence at every session to ensure our voice is heard, if there are sessions you think are important to KDE and will attend please list these on the wiki as well. One thing we would like to emphasise is that we are not looking to merge with Qt or to take Qt over or to force all our technology into Qt. We want to become an active and influential contributor to Qt to improve both Qt and KDE. With Open Governance and the modularisation of both the Qt and KDE Frameworks we believe we have a good model for achieving this. See you in Berlin! John. [1] http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki [2] http://community.kde.org/KDE_at_QCS [3] http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Topic_List From johnlayt at googlemail.com Thu Jun 9 16:50:50 2011 From: johnlayt at googlemail.com (John Layt) Date: Thu, 9 Jun 2011 16:50:50 +0100 Subject: KDE at the Qt Contributors Summit In-Reply-To: <201106091531.42998.johnlayt@googlemail.com> References: <201106091531.42998.johnlayt@googlemail.com> Message-ID: <201106091650.50854.johnlayt@googlemail.com> On Thursday 09 Jun 2011 15:31:42 John Layt wrote: > We would like to co-ordinate our efforts at QtCS to ensure the best > possible outcome for KDE and Qt. To help this we would like all KDE > community members attending to list their name on the KDE at QtCS wiki > page [2]. Please indicate if you are attending on behalf of another > organisation and what your t-shirt size is. It has been suggested we have a meet-up/dinner on the Wednesday night before the summit, please indicate on the wiki if you are able to attend by Monday and we'll book a suitable venue. Cheers! John. From nyblom at kde.org Thu Jun 9 17:13:37 2011 From: nyblom at kde.org (Torgny Nyblom) Date: Thu, 09 Jun 2011 18:13:37 +0200 Subject: KDE git workflow In-Reply-To: <201106081903.01096.schumacher@kde.org> References: <201106081903.01096.schumacher@kde.org> Message-ID: <1527980.SDeZO4t0TV@explosive.nyblom.org> On Wednesday 08 June 2011 19.03.01 Cornelius Schumacher wrote: > As you already know, we have discussed the git workflow for KDE at the > Platform 11 sprint, and have come up with a recommendation. Please find the > full text here: http://community.kde.org/KDE_Core/Platform_11/Git_Workflow """ Local branches are always rebased, remote branches never When developing in a local branch, changes should always be rebased before pushing them to the remote origin. This keeps a simple linear history. Rebasing can be thought of as applying changes as patches to the latest version of the code. In case of conflicts they need to be adapted. So developers always patch against the latest version of the code. Remote branches are shared by multiple people. Rebasing them causes different people to have different versions of history, which causes conflicts, inconsistent and hard to understand states. So remote branches should never be rebased. Merging them properly also reflects that development actually happened in a side line. """" This part I fully agree with, however later in the example section it seems like rebasing should be done prior to review. Is the examples correct? /Regards Torgny From schumacher at kde.org Thu Jun 9 17:22:10 2011 From: schumacher at kde.org (Cornelius Schumacher) Date: Thu, 9 Jun 2011 18:22:10 +0200 Subject: KDE git workflow In-Reply-To: References: <201106081903.01096.schumacher@kde.org> <201106091533.06246.schumacher@kde.org> Message-ID: <201106091822.10755.schumacher@kde.org> On Thursday 09 June 2011 Maksim Orlovich wrote: > > Will we have a single person review every single commit to master, too? We don't have formal rules about who reviews commits. That will be done by the developers and maintainers who care, just like it is done now. > > We might have a "Aaron's branch" of Plasma with > > the latest Plasma features, or a "KDAB branch" of KDE PIM, which > > integrates the latest KDE PIM enterprise features, etc. > > And what if there are multiple branches on the same module at the same > time? Which one of these branches, or master (or release?) is going to > get testing coverage? The idea is that, if there are multiple feature branches, the integration branch is used to collect them and get testing coverage and review there. > An alternative, of course, is to discourage use of branches if at all > possible, and rather > prefer a consistently working and stable master (which optionally then > becomes the release, without further branching)... or at the very > least not to disallow such methodology by fiat. For smaller or less central parts of KDE this actually might be a good procedure. For modules where many developers work, or where we need to make extra sure that they are work, like the libraries, we need more review. And discouraging branches at all is not a good policy, as at least there should be local branches for development of everything, which is non-trivial to integrate, otherwise a consistently working and stable master is impossible to achieve. The same for releasing. We need branches for that, so that master can continue to get feature development, while a branch is hardened for release. -- Cornelius Schumacher From mail at dipe.org Thu Jun 9 17:29:23 2011 From: mail at dipe.org (Sebastian Sauer) Date: Thu, 09 Jun 2011 16:29:23 -0000 Subject: Review Request: Fix crash in KDirLister Message-ID: <20110609162923.30569.79005@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101560/ ----------------------------------------------------------- Review request for kdelibs. Summary ------- Attached patch fixes a crash reported by gopalK, one of our Calligra at Windows heros. Backtrace (only one line); #0 KDirLister::Private::emitChanges (this=0x13332c70) at d:\kderoot\git\kdelibs\kio\kio\kdirlister.cpp:2155 The reason is that kDirListerCache->itemsForDir can return NULL. That is handled in all cases in that file except those two lines. The patch fixes it. p.s. whoever pressed "Ship It" please commit the patch for me and backport cause I didn't had the time to get my kdelibs+kdebase setup updated since the latest moves and renames. Thanks in advance :) Diffs ----- kio/kio/kdirlister.cpp d554723 Diff: http://git.reviewboard.kde.org/r/101560/diff Testing ------- Thanks, Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: From schumacher at kde.org Thu Jun 9 17:34:57 2011 From: schumacher at kde.org (Cornelius Schumacher) Date: Thu, 9 Jun 2011 18:34:57 +0200 Subject: KDE git workflow In-Reply-To: <1527980.SDeZO4t0TV@explosive.nyblom.org> References: <201106081903.01096.schumacher@kde.org> <1527980.SDeZO4t0TV@explosive.nyblom.org> Message-ID: <201106091834.57806.schumacher@kde.org> On Thursday 09 June 2011 Torgny Nyblom wrote: > > This part I fully agree with, however later in the example section it seems > like rebasing should be done prior to review. Is the examples correct? The examples need some reality check, ideally with detailed actual git commands. In general it's a good idea to rebase local branches, before you show them to others. How this will actually look like in terms of actual commands we still have to determine, especially also with regards to the review tool we'll use. For the current ReviewBoard based process we can probably do that now. Any takers for augmenting the examples with step-by-step instructions from the real world? -- Cornelius Schumacher From djarvie at kde.org Thu Jun 9 17:35:56 2011 From: djarvie at kde.org (David Jarvie) Date: Thu, 9 Jun 2011 17:35:56 +0100 Subject: KDE git workflow In-Reply-To: <201106091822.10755.schumacher@kde.org> References: <201106081903.01096.schumacher@kde.org> <201106091533.06246.schumacher@kde.org> <201106091822.10755.schumacher@kde.org> Message-ID: <0f3018e8709826aa6ddaa47e1c5b0199.squirrel@www.sensical.net> On Thu, June 9, 2011 5:22 pm, Cornelius Schumacher wrote: > On Thursday 09 June 2011 Maksim Orlovich wrote: >> >> And what if there are multiple branches on the same module at the same >> time? Which one of these branches, or master (or release?) is going to >> get testing coverage? > > The idea is that, if there are multiple feature branches, the integration > branch is used to collect them and get testing coverage and review there. In order to get good testing coverage, there should normally only be one integration branch per git module. Otherwise, testing coverage will be split between the competing integration branches. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm From schumacher at kde.org Thu Jun 9 17:39:53 2011 From: schumacher at kde.org (Cornelius Schumacher) Date: Thu, 9 Jun 2011 18:39:53 +0200 Subject: KDE git workflow In-Reply-To: <0f3018e8709826aa6ddaa47e1c5b0199.squirrel@www.sensical.net> References: <201106081903.01096.schumacher@kde.org> <201106091822.10755.schumacher@kde.org> <0f3018e8709826aa6ddaa47e1c5b0199.squirrel@www.sensical.net> Message-ID: <201106091839.53052.schumacher@kde.org> On Thursday 09 June 2011 David Jarvie wrote: > > In order to get good testing coverage, there should normally only be one > integration branch per git module. Otherwise, testing coverage will be > split between the competing integration branches. Right. -- Cornelius Schumacher From johnlayt at googlemail.com Thu Jun 9 17:56:54 2011 From: johnlayt at googlemail.com (John Layt) Date: Thu, 9 Jun 2011 17:56:54 +0100 Subject: KDE git workflow In-Reply-To: <201106091834.57806.schumacher@kde.org> References: <201106081903.01096.schumacher@kde.org> <1527980.SDeZO4t0TV@explosive.nyblom.org> <201106091834.57806.schumacher@kde.org> Message-ID: <201106091756.54428.johnlayt@googlemail.com> On Thursday 09 Jun 2011 17:34:57 Cornelius Schumacher wrote: > On Thursday 09 June 2011 Torgny Nyblom wrote: > > This part I fully agree with, however later in the example section it > > seems like rebasing should be done prior to review. Is the examples > > correct? > > The examples need some reality check, ideally with detailed actual git > commands. In general it's a good idea to rebase local branches, before you > show them to others. How this will actually look like in terms of actual > commands we still have to determine, especially also with regards to the > review tool we'll use. For the current ReviewBoard based process we can > probably do that now. Any takers for augmenting the examples with > step-by-step instructions from the real world? At Platform 11 I started a couple of detailed step-by-steps for new Git users which I'll try publish tomorrow. One workflow was a straight svn like process in master designed to be used for the first week or two of git use while they learn the basic commands, after which the dev would move onto the feature branch workflow. Besides the inconsistency that Torgey also found, the one part of the command flow I'm wondering about is whether for the simple workflow we tell them to push or merge their commits into master? John. From staniek-RoXCvvDuEio at public.gmane.org Thu Jun 9 19:49:14 2011 From: staniek-RoXCvvDuEio at public.gmane.org (=?utf-8?q?Jaros=C5=82aw_Staniek?=) Date: Thu, 09 Jun 2011 18:49:14 -0000 Subject: Review Request: Use QDirIterator in KStandardDirs In-Reply-To: <20110609094953.5854.20574-vnjQvCq2Ar3oK6nBLMlh1Q@public.gmane.org> References: <20110609094953.5854.20574@vidsolbach.de> Message-ID: <20110609184914.7563.30024@vidsolbach.de> > On June 9, 2011, 9:49 a.m., Aaron J. Seigo wrote: > > my biggest question with this change would be performance. QFileInfo is not fast, and to make matters "worse" this code in KStandardDirs influences start up speed. have you measured the performance after this change relative to before? > > > > with Qt5 this may become a moot issue with the changes coming in the QFile backends ... but i don't think it makes sense to introduce possible performance regressions on code that currently works. > > > > is there a platform for which the current code fails? > > Bernhard Beschow wrote: > I did the patch solely for simplicity and portability reasons, and perhaps (or hopefully) also in the Platform 11 spirit. :) After all, "outsourcing" platform-specific details to Qt wherever we can seems like a good idea to me, such that we can take advantage of new platforms much quicker. > > That said, I couldn't measure any performance difference when logging into a plasma session. In both cases, it takes ~13 secs for the wallpaper to appear, and ~30 secs until the KWallet password dialog appears. I understand the reasoning but the fact that you did not properly measure the differences shows such pieces of code would be better left untouched untill there is convincing data. KStandardDirs is critical place for KDE apps. IMHO simplifing such lower-level internal (tested!) code may not pay off. Thanks for your effort. - Jarosław ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101554/#review3799 ----------------------------------------------------------- On June 9, 2011, 7:06 a.m., Bernhard Beschow wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101554/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 7:06 a.m.) > > > Review request for kdelibs, kdewin and David Faure. > > > Summary > ------- > > Increase portability of kdecore a tiny bit by making KStandardDirs use QDirIterator rater than platform-specific code. > > > Diffs > ----- > > kdecore/kernel/kstandarddirs.cpp ba90270 > > Diff: http://git.reviewboard.kde.org/r/101554/diff > > > Testing > ------- > > I'm running my platform 4.6 with this patch and haven't noticed any regressions yet. > > > Thanks, > > Bernhard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Kde-windows mailing list Kde-windows-RoXCvvDuEio at public.gmane.org https://mail.kde.org/mailman/listinfo/kde-windows From richmoore44 at gmail.com Thu Jun 9 20:37:30 2011 From: richmoore44 at gmail.com (Richard Moore) Date: Thu, 9 Jun 2011 20:37:30 +0100 Subject: SSL in KDE going forward In-Reply-To: <4DF07365.3020807@kde.org> References: <4DF07365.3020807@kde.org> Message-ID: On Thu, Jun 9, 2011 at 8:16 AM, Hasso Tepper wrote: > On 08.06.11; 24. nädal 23:24, Dawit A wrote: >> Would asking for client certficate authentication support be out of >> the scope or does Qt's SSL already support that ? Last I checked it >> did not and there is a pending but report about this against kio_http. >> See https://bugs.kde.org/show_bug.cgi?id=167668. > > Which is in general showstopper for bigger stuff - PKCS#11 support. See > https://bugs.kde.org/show_bug.cgi?id=116201. What about the current support for client certificates is insufficient? Rich. From richmoore44 at gmail.com Thu Jun 9 20:48:50 2011 From: richmoore44 at gmail.com (Richard Moore) Date: Thu, 9 Jun 2011 20:48:50 +0100 Subject: SSL in KDE going forward In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 9:24 PM, Dawit A wrote: > Would asking for client certficate authentication support be out of > the scope or does Qt's SSL already support that ? Last I checked it > did not and there is a pending but report about this against kio_http. > See https://bugs.kde.org/show_bug.cgi?id=167668. When did you check? It's been supported for a long time, see http://doc.qt.nokia.com/latest/qsslsocket.html#setLocalCertificate Cheers Rich. From schumacher at kde.org Thu Jun 9 22:32:57 2011 From: schumacher at kde.org (Cornelius Schumacher) Date: Thu, 9 Jun 2011 23:32:57 +0200 Subject: KDE git workflow In-Reply-To: <201106091756.54428.johnlayt@googlemail.com> References: <201106081903.01096.schumacher@kde.org> <201106091834.57806.schumacher@kde.org> <201106091756.54428.johnlayt@googlemail.com> Message-ID: <201106092332.57671.schumacher@kde.org> On Thursday 09 June 2011 John Layt wrote: > > Besides the inconsistency that > Torgey also found, the one part of the command flow I'm wondering about is > whether for the simple workflow we tell them to push or merge their > commits into master? If it's a local branch, rebase the branch, merge it to master, and then push it. This will give linear history. It should be equivalent to working in master, rebasing on pull and just pushing, but it's cleaner and safer to do the development in a branch. If it's a remote branch, just merge it and push it. In general it's a good idea to do a "git pull --rebase", when pulling as this doesn't create merge commits with local changes, which can clutter up the history. -- Cornelius Schumacher From aseigo at kde.org Thu Jun 9 23:15:21 2011 From: aseigo at kde.org (Aaron J. Seigo) Date: Fri, 10 Jun 2011 00:15:21 +0200 Subject: KDE git workflow In-Reply-To: References: <201106081903.01096.schumacher@kde.org> Message-ID: <14087876.TDR9vp27Rn@freedom> On Thursday, June 9, 2011 13:50:59 David Jarvie wrote: > One side effect of using integration branches in what used to be > kdelibs/kdepimlibs/kdebase is that new features aren't likely to be widely > tested until later in the development cycle than previously. features should not remain in integration branches for overly long. if they are of such low quality that even in integration problems arise, then there is little reason to inflict them on a wider audience. at the same time, integration must not become a place where new code piles up and piles up until a release nears, leading to code drops into master at odd intervals. this means that there is some discipline required by those who tend the integration branches. > While they > are in integration branches, only people who are particularly interested > in those areas are likely to use them, and it's only once they eventually > reach master that they will be widely used by developers. which is actually good. once a feature is deemed stable enough by those of us who stay on the truly bleeding edge, they can fall into master. this means master should be much more reliable and we can realistically get more people running straight from master without it doing nasty things to their system. iow, by having a reservoir where new things land before they spill over into master, we can get more people using master and therefore ultimately more people testing things. we've noticed in plasma development, whether it is in libs, runtime or workspace, that new features often land with obvious shortcomings (though often not obvious to the original developer) which the core team quickly take care of. at that point the feature is ready for broader testing, and before that it's a waste of everyone's time and trust. because they enter prematurely into master, we limit the number of people willing to run master, and for good reason. > In one way, > that's a good thing, since there should be less bugs encountered by those > not directly involved. exactly.. > But the overall effect could be to slow down bug fixing of new features. not if there is a reasonable flow from feature branch -> integration -> master and not if we increase the # of people who also run master. right now, we get too many reports only after betas start rolling, when all sorts of features have landed over the course of a couple of months, and right now there is little way for the core team to test feature branches without harming master. as Cornelius mentioned, we discussed this at the Platform 11 meeting as it is something we were also concerned about. imho as long as we are aware of why we are doing this and what we need to avoid doing in the process, we'll be ok :) -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bcooksley at kde.org Fri Jun 10 02:55:01 2011 From: bcooksley at kde.org (Ben Cooksley) Date: Fri, 10 Jun 2011 13:55:01 +1200 Subject: KDE git workflow In-Reply-To: <201106092332.57671.schumacher@kde.org> References: <201106081903.01096.schumacher@kde.org> <201106091834.57806.schumacher@kde.org> <201106091756.54428.johnlayt@googlemail.com> <201106092332.57671.schumacher@kde.org> Message-ID: On Fri, Jun 10, 2011 at 9:32 AM, Cornelius Schumacher wrote: > On Thursday 09 June 2011 John Layt wrote: >> >> Besides the inconsistency that >> Torgey also found, the one part of the command flow I'm wondering about is >> whether for the simple workflow we tell them to push or merge their >> commits into master? > > If it's a local branch, rebase the branch, merge it to master, and then push > it. This will give linear history. It should be equivalent to working in > master, rebasing on pull and just pushing, but it's cleaner and safer to do > the development in a branch. > > If it's a remote branch, just merge it and push it. > > In general it's a good idea to do a "git pull --rebase", when pulling as this > doesn't create merge commits with local changes, which can clutter up the > history. I guess I need not say that you need to be *very* careful when doing this? You should do this prior to performing the merge, but never after. Just do a standard pull after that - otherwise it will rebase the entire merge. > > -- > Cornelius Schumacher > Regards, Ben Cooksley KDE Sysadmin From bradh at frogmouth.net Fri Jun 10 06:04:16 2011 From: bradh at frogmouth.net (Brad Hards) Date: Fri, 10 Jun 2011 15:04:16 +1000 Subject: SSL in KDE going forward In-Reply-To: References: Message-ID: <201106101504.16682.bradh@frogmouth.net> On Thu, 9 Jun 2011 06:12:22 AM Richard Moore wrote: > http://developer.qt.nokia.com/wiki/Improving_Qts_SSL_Support Looks fairly complete to me. I'm not sure renegotiation info is all that niche, but its all a matter of perspective. > If you know something that is needed for KDE but isn't listed then let me > know. I don't know about "needed", but an open-ended API for handling the underlying API plus TLS extensions (i.e. the rest of RFC4366) might be useful. I haven't really thought this through, but things along the lines of - is this capability / extension supported? - here is some key/value pair (or set of pairs) - can I have the value for this key (or set of keys) While thinking about this, it occurred to me that perhaps SSL (or TLS) is not the only question in this area. Does KDE also need other auth support (I know about the NTLM stuff, and Thiago has indicated that there is planned support for Kerberos: http://bugreports.qt.nokia.com/browse/QTBUG-1538), but maybe the smart people can figure out a generalised approach to authentication? > ps. designing a new non-SSL based infrastructure for online > transactions is out of scope.# wuss :-) Brad From hasso at kde.org Fri Jun 10 07:40:40 2011 From: hasso at kde.org (Hasso Tepper) Date: Fri, 10 Jun 2011 09:40:40 +0300 Subject: SSL in KDE going forward In-Reply-To: References: <4DF07365.3020807@kde.org> Message-ID: <4DF1BC68.3000000@kde.org> On 09.06.11; 24. nädal 22:37, Richard Moore wrote: > On Thu, Jun 9, 2011 at 8:16 AM, Hasso Tepper wrote: >> Which is in general showstopper for bigger stuff - PKCS#11 support. See >> https://bugs.kde.org/show_bug.cgi?id=116201. > > What about the current support for client certificates is insufficient? https://bugs.kde.org/show_bug.cgi?id=116201#c26 "But mainly, it will *NOT* allow smartcard integration as its private key is forced to be exportable." Is this solved now as well? -- Hasso Tepper From bbeschow at cs.tu-berlin.de Thu Jun 9 16:05:47 2011 From: bbeschow at cs.tu-berlin.de (Bernhard Beschow) Date: Thu, 09 Jun 2011 15:05:47 -0000 Subject: Review Request: Use QDirIterator in KStandardDirs In-Reply-To: <20110609094953.5854.20574@vidsolbach.de> References: <20110609094953.5854.20574@vidsolbach.de> Message-ID: <20110609150547.23678.13858@vidsolbach.de> > On June 9, 2011, 9:49 a.m., Aaron J. Seigo wrote: > > my biggest question with this change would be performance. QFileInfo is not fast, and to make matters "worse" this code in KStandardDirs influences start up speed. have you measured the performance after this change relative to before? > > > > with Qt5 this may become a moot issue with the changes coming in the QFile backends ... but i don't think it makes sense to introduce possible performance regressions on code that currently works. > > > > is there a platform for which the current code fails? I did the patch solely for simplicity and portability reasons, and perhaps (or hopefully) also in the Platform 11 spirit. :) After all, "outsourcing" platform-specific details to Qt wherever we can seems like a good idea to me, such that we can take advantage of new platforms much quicker. That said, I couldn't measure any performance difference when logging into a plasma session. In both cases, it takes ~13 secs for the wallpaper to appear, and ~30 secs until the KWallet password dialog appears. - Bernhard ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101554/#review3799 ----------------------------------------------------------- On June 9, 2011, 7:06 a.m., Bernhard Beschow wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101554/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 7:06 a.m.) > > > Review request for kdelibs, kdewin and David Faure. > > > Summary > ------- > > Increase portability of kdecore a tiny bit by making KStandardDirs use QDirIterator rater than platform-specific code. > > > Diffs > ----- > > kdecore/kernel/kstandarddirs.cpp ba90270 > > Diff: http://git.reviewboard.kde.org/r/101554/diff > > > Testing > ------- > > I'm running my platform 4.6 with this patch and haven't noticed any regressions yet. > > > Thanks, > > Bernhard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at rusu.info Thu Jun 9 22:20:19 2011 From: kde at rusu.info (Valentin Rusu) Date: Thu, 09 Jun 2011 21:20:19 -0000 Subject: Review Request: Fix crash in KDirLister In-Reply-To: <20110609162923.30569.79005@vidsolbach.de> References: <20110609162923.30569.79005@vidsolbach.de> Message-ID: <20110609212019.14475.71397@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101560/#review3810 ----------------------------------------------------------- Ship it! I checked kdirlister.cpp and itemsForDir truely can return NULL, so the patch seems OK to me - Valentin On June 9, 2011, 4:29 p.m., Sebastian Sauer wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101560/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 4:29 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > Attached patch fixes a crash reported by gopalK, one of our Calligra at Windows heros. > > Backtrace (only one line); > #0 KDirLister::Private::emitChanges (this=0x13332c70) > at d:\kderoot\git\kdelibs\kio\kio\kdirlister.cpp:2155 > > The reason is that kDirListerCache->itemsForDir can return NULL. That is handled in all cases in that file except those two lines. The patch fixes it. > > p.s. whoever pressed "Ship It" please commit the patch for me and backport cause I didn't had the time to get my kdelibs+kdebase setup updated since the latest moves and renames. Thanks in advance :) > > > Diffs > ----- > > kio/kio/kdirlister.cpp d554723 > > Diff: http://git.reviewboard.kde.org/r/101560/diff > > > Testing > ------- > > > Thanks, > > Sebastian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Fri Jun 10 08:30:37 2011 From: null at kde.org (Commit Hook) Date: Fri, 10 Jun 2011 07:30:37 -0000 Subject: Review Request: Fix crash in KDirLister In-Reply-To: <20110609162923.30569.79005@vidsolbach.de> References: <20110609162923.30569.79005@vidsolbach.de> Message-ID: <20110610073037.6683.7840@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101560/#review3811 ----------------------------------------------------------- This review has been submitted with commit 4fad3a34f76d33906e018b42ee909877cea0ef2c by Aaron Seigo. - Commit On June 9, 2011, 4:29 p.m., Sebastian Sauer wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101560/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 4:29 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > Attached patch fixes a crash reported by gopalK, one of our Calligra at Windows heros. > > Backtrace (only one line); > #0 KDirLister::Private::emitChanges (this=0x13332c70) > at d:\kderoot\git\kdelibs\kio\kio\kdirlister.cpp:2155 > > The reason is that kDirListerCache->itemsForDir can return NULL. That is handled in all cases in that file except those two lines. The patch fixes it. > > p.s. whoever pressed "Ship It" please commit the patch for me and backport cause I didn't had the time to get my kdelibs+kdebase setup updated since the latest moves and renames. Thanks in advance :) > > > Diffs > ----- > > kio/kio/kdirlister.cpp d554723 > > Diff: http://git.reviewboard.kde.org/r/101560/diff > > > Testing > ------- > > > Thanks, > > Sebastian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Fri Jun 10 08:30:41 2011 From: null at kde.org (Commit Hook) Date: Fri, 10 Jun 2011 07:30:41 -0000 Subject: Review Request: Fix crash in KDirLister In-Reply-To: <20110609162923.30569.79005@vidsolbach.de> References: <20110609162923.30569.79005@vidsolbach.de> Message-ID: <20110610073041.6730.58328@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101560/#review3812 ----------------------------------------------------------- This review has been submitted with commit 1931e645e53458e522cce9c93154489e8c66a875 by Aaron Seigo. - Commit On June 9, 2011, 4:29 p.m., Sebastian Sauer wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101560/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 4:29 p.m.) > > > Review request for kdelibs. > > > Summary > ------- > > Attached patch fixes a crash reported by gopalK, one of our Calligra at Windows heros. > > Backtrace (only one line); > #0 KDirLister::Private::emitChanges (this=0x13332c70) > at d:\kderoot\git\kdelibs\kio\kio\kdirlister.cpp:2155 > > The reason is that kDirListerCache->itemsForDir can return NULL. That is handled in all cases in that file except those two lines. The patch fixes it. > > p.s. whoever pressed "Ship It" please commit the patch for me and backport cause I didn't had the time to get my kdelibs+kdebase setup updated since the latest moves and renames. Thanks in advance :) > > > Diffs > ----- > > kio/kio/kdirlister.cpp d554723 > > Diff: http://git.reviewboard.kde.org/r/101560/diff > > > Testing > ------- > > > Thanks, > > Sebastian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richmoore44 at gmail.com Fri Jun 10 12:41:55 2011 From: richmoore44 at gmail.com (Richard Moore) Date: Fri, 10 Jun 2011 12:41:55 +0100 Subject: SSL in KDE going forward In-Reply-To: <4DF1BC68.3000000@kde.org> References: <4DF07365.3020807@kde.org> <4DF1BC68.3000000@kde.org> Message-ID: On Fri, Jun 10, 2011 at 7:40 AM, Hasso Tepper wrote: > On 09.06.11; 24. nädal 22:37, Richard Moore wrote: >> On Thu, Jun 9, 2011 at 8:16 AM, Hasso Tepper wrote: >>> Which is in general showstopper for bigger stuff - PKCS#11 support. See >>> https://bugs.kde.org/show_bug.cgi?id=116201. >> >> What about the current support for client certificates is insufficient? > > https://bugs.kde.org/show_bug.cgi?id=116201#c26 > > "But mainly, it will *NOT* allow smartcard integration as its private > key is forced to be exportable." This is completely unclear. > > Is this solved now as well? Haven't a clue what you're even asking for! Rich. From null at kde.org Fri Jun 10 13:11:27 2011 From: null at kde.org (Commit Hook) Date: Fri, 10 Jun 2011 12:11:27 -0000 Subject: Review Request: Enable per event icons in KNotify In-Reply-To: <20110529204430.617.1287@vidsolbach.de> References: <20110529204430.617.1287@vidsolbach.de> Message-ID: <20110610121127.16798.24821@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101470/#review3815 ----------------------------------------------------------- This review has been submitted with commit 7ca5c34257847d0eba38923df062c572ced900f7 by Martin Klapetek. - Commit On May 29, 2011, 8:44 p.m., Martin Klapetek wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101470/ > ----------------------------------------------------------- > > (Updated May 29, 2011, 8:44 p.m.) > > > Review request for KDE Runtime and Plasma. > > > Summary > ------- > > This patch enables to specify different icon for every event in notifyrc file. Example: > [Event/telepathyError] > IconName=dialog-error > > [Event/telepathyInfo] > IconName=dialog-information > > If there's no such key in [Event/..] section, it looks for the icon in [Global]. > > > Diffs > ----- > > knotify/notifybypopup.cpp 36c3039 > > Diff: http://git.reviewboard.kde.org/r/101470/diff > > > Testing > ------- > > Testing was done by afiestas at #kde-devel. Works ok. > > > Thanks, > > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gladhorn at kde.org Fri Jun 10 15:06:41 2011 From: gladhorn at kde.org (Frederik Gladhorn) Date: Fri, 10 Jun 2011 16:06:41 +0200 Subject: KDE at the Qt Contributors Summit In-Reply-To: <201106091531.42998.johnlayt@googlemail.com> References: <201106091531.42998.johnlayt@googlemail.com> Message-ID: <201106101606.41237.gladhorn@kde.org> Hi, this is for attendants of the Qt Contributors Summit. Make sure that all the info from the KDE wiki pages is also on the dev net wiki! In other words: take your session proposal and put it into the schedule. All topics should be listed here: http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Topic_List and have a slot reserved here: http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Schedule The earlier you do it, the better the slots you get! Cheers Frederik From mat69 at gmx.net Fri Jun 10 20:38:14 2011 From: mat69 at gmx.net (Matthias Fuchs) Date: Fri, 10 Jun 2011 19:38:14 -0000 Subject: Review Request: Adds KIconLoader::drawOverlays which allows to draw overlays on any pixmap. Message-ID: <20110610193814.5283.22335@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101569/ ----------------------------------------------------------- Review request for kdelibs, David Faure and Michael Pyne. Summary ------- This method uses KIconLoaderPrivate::drawOverlays which is also modified by this patch, to take both width and height of the pixmaps into consideration. I plan to utilize this method both in the Dolphin Information Panel and in KFilePreviewGenerator. Diffs ----- kdeui/icons/kiconloader.h c29c12e kdeui/icons/kiconloader.cpp bcb7b69 Diff: http://git.reviewboard.kde.org/r/101569/diff Testing ------- Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From mat69 at gmx.net Fri Jun 10 20:42:56 2011 From: mat69 at gmx.net (Matthias Fuchs) Date: Fri, 10 Jun 2011 19:42:56 -0000 Subject: Review Request: Draw overlays even for previews. Message-ID: <20110610194256.6459.12500@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101570/ ----------------------------------------------------------- Review request for kdelibs, David Faure and Peter Penz. Summary ------- This way it is easier to recognise links to images etc. This addresses bug 190579. http://bugs.kde.org/show_bug.cgi?id=190579 Diffs ----- kfile/kfilepreviewgenerator.cpp 216dd7e Diff: http://git.reviewboard.kde.org/r/101570/diff Testing ------- Screenshots ----------- http://git.reviewboard.kde.org/r/101570/s/179/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From mat69 at gmx.net Fri Jun 10 20:46:06 2011 From: mat69 at gmx.net (Matthias Fuchs) Date: Fri, 10 Jun 2011 19:46:06 -0000 Subject: Review Request: Draw overlays even for previews. In-Reply-To: <20110610194256.6459.12500@vidsolbach.de> References: <20110610194256.6459.12500@vidsolbach.de> Message-ID: <20110610194606.6558.45242@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101570/ ----------------------------------------------------------- (Updated June 10, 2011, 7:46 p.m.) Review request for kdelibs, David Faure and Peter Penz. Summary (updated) ------- This way it is easier to recognise links to images etc. Depends on https://git.reviewboard.kde.org/r/101569/ This addresses bug 190579. http://bugs.kde.org/show_bug.cgi?id=190579 Diffs ----- kfile/kfilepreviewgenerator.cpp 216dd7e Diff: http://git.reviewboard.kde.org/r/101570/diff Testing ------- Screenshots ----------- http://git.reviewboard.kde.org/r/101570/s/179/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From mat69 at gmx.net Fri Jun 10 20:52:12 2011 From: mat69 at gmx.net (Matthias Fuchs) Date: Fri, 10 Jun 2011 19:52:12 -0000 Subject: Review Request: Show icon overlays in the Informationen Panel. Message-ID: <20110610195212.7502.28636@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101573/ ----------------------------------------------------------- Review request for KDE Base Apps and Peter Penz. Summary ------- Depends on https://git.reviewboard.kde.org/r/101569/ This addresses bug 190579. http://bugs.kde.org/show_bug.cgi?id=190579 Diffs ----- dolphin/src/panels/information/informationpanelcontent.cpp 77a6232 Diff: http://git.reviewboard.kde.org/r/101573/diff Testing ------- Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From adawit at kde.org Fri Jun 10 21:27:22 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Fri, 10 Jun 2011 20:27:22 -0000 Subject: Review Request: kshorturifilter plugin code clean up and minor speed up... Message-ID: <20110610202722.11145.42388@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101576/ ----------------------------------------------------------- Review request for KDE Runtime. Summary ------- The attached patch does the following: - Removes the regular expression check for IP addresses since QUrl/KUrl now correctly parse almost all short url addresses. This should speeds things up a little. - Creates the remaining QRegExp checks once instead of on demand. - Uses KUser for username name and directory shortcuts, e.g ~/. - Adds unit tests for IPv6 URLs. Diffs ----- kurifilter-plugins/shorturi/kshorturifilter.h 30bd686 kurifilter-plugins/shorturi/kshorturifilter.cpp 78ca7ca kurifilter-plugins/tests/kurifiltertest.cpp f2354d8 Diff: http://git.reviewboard.kde.org/r/101576/diff Testing ------- Thanks, Dawit -------------- next part -------------- An HTML attachment was scrubbed... URL: From adawit at kde.org Fri Jun 10 21:34:12 2011 From: adawit at kde.org (Dawit Alemayehu) Date: Fri, 10 Jun 2011 20:34:12 -0000 Subject: Review Request: Use the port number in the filename when caching favicons Message-ID: <20110610203412.11904.61859@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101577/ ----------------------------------------------------------- Review request for KDE Base Apps. Summary ------- The attached patch uses the port number of a favicon's url when creating its local cache name. This helps distinguish two severs running on the same host as pointed out in the bug report listed above. This addresses bug 124482. http://bugs.kde.org/show_bug.cgi?id=124482 Diffs ----- lib/konq/favicons/favicons.cpp 8ba9258 Diff: http://git.reviewboard.kde.org/r/101577/diff Testing ------- Thanks, Dawit -------------- next part -------------- An HTML attachment was scrubbed... URL: From mat69 at gmx.net Fri Jun 10 23:11:14 2011 From: mat69 at gmx.net (Matthias Fuchs) Date: Fri, 10 Jun 2011 22:11:14 -0000 Subject: Review Request: Return the url of the view instead of the url of the url navigator. Message-ID: <20110610221114.17608.90358@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101580/ ----------------------------------------------------------- Review request for KDE Base Apps and Peter Penz. Summary ------- That way if a wrong protocol had been entered the currently watched directory will be returned. This addresses bug 274890. http://bugs.kde.org/show_bug.cgi?id=274890 Diffs ----- dolphin/src/dolphinviewcontainer.cpp 1042ece Diff: http://git.reviewboard.kde.org/r/101580/diff Testing ------- Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.penz19 at gmail.com Fri Jun 10 23:21:40 2011 From: peter.penz19 at gmail.com (Peter Penz) Date: Fri, 10 Jun 2011 22:21:40 -0000 Subject: Review Request: Draw overlays even for previews. In-Reply-To: <20110610194606.6558.45242@vidsolbach.de> References: <20110610194606.6558.45242@vidsolbach.de> Message-ID: <20110610222140.18012.55055@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101570/#review3831 ----------------------------------------------------------- Ship it! Looks fine, please commit! - Peter On June 10, 2011, 7:46 p.m., Matthias Fuchs wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101570/ > ----------------------------------------------------------- > > (Updated June 10, 2011, 7:46 p.m.) > > > Review request for kdelibs, David Faure and Peter Penz. > > > Summary > ------- > > This way it is easier to recognise links to images etc. > Depends on https://git.reviewboard.kde.org/r/101569/ > > > This addresses bug 190579. > http://bugs.kde.org/show_bug.cgi?id=190579 > > > Diffs > ----- > > kfile/kfilepreviewgenerator.cpp 216dd7e > > Diff: http://git.reviewboard.kde.org/r/101570/diff > > > Testing > ------- > > > Screenshots > ----------- > > > http://git.reviewboard.kde.org/r/101570/s/179/ > > > Thanks, > > Matthias > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.penz19 at gmail.com Fri Jun 10 23:23:40 2011 From: peter.penz19 at gmail.com (Peter Penz) Date: Fri, 10 Jun 2011 22:23:40 -0000 Subject: Review Request: Show icon overlays in the Informationen Panel. In-Reply-To: <20110610195212.7502.28636@vidsolbach.de> References: <20110610195212.7502.28636@vidsolbach.de> Message-ID: <20110610222340.18093.81286@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101573/#review3832 ----------------------------------------------------------- Ship it! Thanks for the patch! Please commit if the kdelibs-patch is pushed on Monday. - Peter On June 10, 2011, 7:52 p.m., Matthias Fuchs wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101573/ > ----------------------------------------------------------- > > (Updated June 10, 2011, 7:52 p.m.) > > > Review request for KDE Base Apps and Peter Penz. > > > Summary > ------- > > Depends on https://git.reviewboard.kde.org/r/101569/ > > > This addresses bug 190579. > http://bugs.kde.org/show_bug.cgi?id=190579 > > > Diffs > ----- > > dolphin/src/panels/information/informationpanelcontent.cpp 77a6232 > > Diff: http://git.reviewboard.kde.org/r/101573/diff > > > Testing > ------- > > > Thanks, > > Matthias > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.penz19 at gmail.com Fri Jun 10 23:26:05 2011 From: peter.penz19 at gmail.com (Peter Penz) Date: Fri, 10 Jun 2011 22:26:05 -0000 Subject: Review Request: Return the url of the view instead of the url of the url navigator. In-Reply-To: <20110610221114.17608.90358@vidsolbach.de> References: <20110610221114.17608.90358@vidsolbach.de> Message-ID: <20110610222605.18155.71355@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101580/#review3833 ----------------------------------------------------------- Ship it! Ah, very nice corner case :-) Patch is fine, thanks! - Peter On June 10, 2011, 10:11 p.m., Matthias Fuchs wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101580/ > ----------------------------------------------------------- > > (Updated June 10, 2011, 10:11 p.m.) > > > Review request for KDE Base Apps and Peter Penz. > > > Summary > ------- > > That way if a wrong protocol had been entered the currently watched directory will be returned. > > > This addresses bug 274890. > http://bugs.kde.org/show_bug.cgi?id=274890 > > > Diffs > ----- > > dolphin/src/dolphinviewcontainer.cpp 1042ece > > Diff: http://git.reviewboard.kde.org/r/101580/diff > > > Testing > ------- > > > Thanks, > > Matthias > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Fri Jun 10 23:28:48 2011 From: null at kde.org (Commit Hook) Date: Fri, 10 Jun 2011 22:28:48 -0000 Subject: Review Request: Return the url of the view instead of the url of the url navigator. In-Reply-To: <20110610221114.17608.90358@vidsolbach.de> References: <20110610221114.17608.90358@vidsolbach.de> Message-ID: <20110610222848.18252.88511@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101580/#review3834 ----------------------------------------------------------- This review has been submitted with commit 7c85b6206b76c434738ff6a5d2379a1c7d58fdb7 by Matthias Fuchs. - Commit On June 10, 2011, 10:11 p.m., Matthias Fuchs wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101580/ > ----------------------------------------------------------- > > (Updated June 10, 2011, 10:11 p.m.) > > > Review request for KDE Base Apps and Peter Penz. > > > Summary > ------- > > That way if a wrong protocol had been entered the currently watched directory will be returned. > > > This addresses bug 274890. > http://bugs.kde.org/show_bug.cgi?id=274890 > > > Diffs > ----- > > dolphin/src/dolphinviewcontainer.cpp 1042ece > > Diff: http://git.reviewboard.kde.org/r/101580/diff > > > Testing > ------- > > > Thanks, > > Matthias > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From null at kde.org Fri Jun 10 23:32:50 2011 From: null at kde.org (Commit Hook) Date: Fri, 10 Jun 2011 22:32:50 -0000 Subject: Review Request: Return the url of the view instead of the url of the url navigator. In-Reply-To: <20110610221114.17608.90358@vidsolbach.de> References: <20110610221114.17608.90358@vidsolbach.de> Message-ID: <20110610223250.18368.48392@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101580/#review3835 ----------------------------------------------------------- This review has been submitted with commit 1a6201cbcd9367fdd357a89a396f32796aa71e55 by Matthias Fuchs. - Commit On June 10, 2011, 10:11 p.m., Matthias Fuchs wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101580/ > ----------------------------------------------------------- > > (Updated June 10, 2011, 10:11 p.m.) > > > Review request for KDE Base Apps and Peter Penz. > > > Summary > ------- > > That way if a wrong protocol had been entered the currently watched directory will be returned. > > > This addresses bug 274890. > http://bugs.kde.org/show_bug.cgi?id=274890 > > > Diffs > ----- > > dolphin/src/dolphinviewcontainer.cpp 1042ece > > Diff: http://git.reviewboard.kde.org/r/101580/diff > > > Testing > ------- > > > Thanks, > > Matthias > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arne_bab at web.de Fri Jun 10 23:33:52 2011 From: arne_bab at web.de (Arne Babenhauserheide) Date: Sat, 11 Jun 2011 00:33:52 +0200 Subject: Modularization and other languages' bindings (was: The Future of our Frameworks) In-Reply-To: <1798456.Lx7osU5OF4@leon.lan> References: <21091853.laQfrAgJOr@marvin.vizzzion.net> <1798456.Lx7osU5OF4@leon.lan> Message-ID: <2016688.6h3BMUqLCp@fluss> On Monday 06 June 2011 21:05:41 Luca Beltrame wrote: > In data Monday 06 June 2011 19:26:38, Sebastian Kügler ha scritto: > > (I took the liberty of adding kde-bindings to the CC of tihs specific topic) > > > We want to make it possible to use our frameworks in Qt projects without > > significant additional dependencies. This means: > The reason is simple: those too contribute to lowering the barrier of entry > for developers, especially the audience that has not a C++ programming > background. If things are adjusted (without breaking things), it would be a > perfect opportunity to involve the bindings people in the process. Having i.e. PyKDE more modular would be great for me, too. I love using it, and it would be useful to have a way to distribute it with a simple app in a nice and lean binary (if that still exists, I’m sorry for the noise…) - or to be able to tell a GNU/Linux distritution that I need only KUniqeApplication and IconLoader and have it install only a small subset of PyKDE. Best wishes, Arne -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: -------------- next part -------------- _______________________________________________ Kde-bindings mailing list Kde-bindings at kde.org https://mail.kde.org/mailman/listinfo/kde-bindings From null at kde.org Fri Jun 10 23:39:16 2011 From: null at kde.org (Commit Hook) Date: Fri, 10 Jun 2011 22:39:16 -0000 Subject: Review Request: Use the port number in the filename when caching favicons In-Reply-To: <20110610203412.11904.61859@vidsolbach.de> References: <20110610203412.11904.61859@vidsolbach.de> Message-ID: <20110610223916.18543.4573@vidsolbach.de> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101577/#review3836 ----------------------------------------------------------- This review has been submitted with commit aaa3b61edc4cdeaf67c8a3d6a0eacbd15e044469 by Dawit Alemayehu. - Commit On June 10, 2011, 8:34 p.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101577/ > ----------------------------------------------------------- > > (Updated June 10, 2011, 8:34 p.m.) > > > Review request for KDE Base Apps. > > > Summary > ------- > > The attached patch uses the port number of a favicon's url when creating its local cache name. This helps distinguish two severs running on the same host as pointed out in the bug report listed above. > > > This addresses bug 124482. > http://bugs.kde.org/show_bug.cgi?id=124482 > > > Diffs > ----- > > lib/konq/favicons/favicons.cpp 8ba9258 > > Diff: http://git.reviewboard.kde.org/r/101577/diff > > > Testing > ------- > > > Thanks, > > Dawit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: