Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Wednesday, November 9, 2011 01:22:54 Dawit A wrote: That is fine for the kdelibs portion, but what do you suggest be done with the kde-baseapps portion of the patch ? Wait until 4.8 gets branched ? creating a frameworks branch in kde-baseapps may be a solution; we'll likely want to branch during porting, and if we don't (for whatever reason) then we can easily merge such a branch into master at that point. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Review Request: Make mouse cursor size configurable
On Nov. 9, 2011, 6:48 a.m., Fredrik Höglund wrote: kcontrol/input/xcursor/cursortheme.cpp, line 119 http://git.reviewboard.kde.org/r/101701/diff/2/?file=33417#file33417line119 Scaling a pixmap is more expensive than scaling an image. Internally it involves converting the pixmap back to an image, scaling it, and then converting the image back to a pixmap. This is not a major issue, but it's the reason the image was scaled before it was converted to a pixmap. The problem is that I can't drop createIcon(int size) because I need it on other places. So I would either have to copy the code to createIcon() or change the return type of createIcon to QImage. Maybe we can leave this for a later revision? On Nov. 9, 2011, 6:48 a.m., Fredrik Höglund wrote: kcontrol/input/xcursor/cursortheme.h, line 80 http://git.reviewboard.kde.org/r/101701/diff/2/?file=33416#file33416line80 I'm having trouble working out if changing the default from -1 to 0 is an unrelated change or not. The implementation now treats not only -1 as default value (=resolution dependend) but every value = 0. This is important because 0 also means resolutin dependend. I think it would make no difference to leave the header as is, but I changed the header because this makes clear that 0 is not a valid size. - Lukas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101701/#review8036 --- On Sept. 2, 2011, 4:40 p.m., Lukas Sommer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101701/ --- (Updated Sept. 2, 2011, 4:40 p.m.) Review request for KDE Base Apps, KDE Runtime, kdelibs, and Christoph Feck. Description --- X11 mouse cursor themes can contain cursors in multiple sizes, making them pseudo-scalable. It is yet possible in KDE to configure manually the mouse cursor size (editing kcminput.rc). However, the GUI of the corresponding KControl module didn't provide support to change this. This patch add support for changing the mouse cursor size to the GUI. This are mostly GUI related changes. The underlying data structure XCursorTheme did yet provide support for choosing different sizes and only needed some adjustments. This addresses bug 90444. http://bugs.kde.org/show_bug.cgi?id=90444 Diffs - kcontrol/input/xcursor/cursortheme.h 586ccba kcontrol/input/xcursor/cursortheme.cpp 92abea5 kcontrol/input/xcursor/legacytheme.h 846bf9b kcontrol/input/xcursor/previewwidget.h f4d2c4e kcontrol/input/xcursor/previewwidget.cpp 3c264fc kcontrol/input/xcursor/themepage.h 38ca893 kcontrol/input/xcursor/themepage.cpp 6c9f29a kcontrol/input/xcursor/themepage.ui 2e38054 kcontrol/input/xcursor/xcursortheme.h b474086 kcontrol/input/xcursor/xcursortheme.cpp 2ecb9ba Diff: http://git.reviewboard.kde.org/r/101701/diff/diff Testing --- Tested locally. Works fine for me. Also when using non-standard font DPI values. Screenshots --- http://git.reviewboard.kde.org/r/101701/s/248/ Thanks, Lukas Sommer
Re: Review Request: Make mouse cursor size configurable
On Nov. 9, 2011, 6:48 a.m., Fredrik Höglund wrote: Sorry for not finding the time to follow up on this until now. The new design is not quite what I had in mind, but given that the freeze is tomorrow I'm fine with including it in 4.8. I have given the code a quick look over, and I don't see any show stoppers, although I have some nitpicks below. You should also add yourself to the list of copyrights. When I come home from university in 9 hours, I will do this. I hope I'll be in time... What is about https://git.reviewboard.kde.org/r/102524/, can we ship this simultanly? - Lukas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101701/#review8036 --- On Sept. 2, 2011, 4:40 p.m., Lukas Sommer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101701/ --- (Updated Sept. 2, 2011, 4:40 p.m.) Review request for KDE Base Apps, KDE Runtime, kdelibs, and Christoph Feck. Description --- X11 mouse cursor themes can contain cursors in multiple sizes, making them pseudo-scalable. It is yet possible in KDE to configure manually the mouse cursor size (editing kcminput.rc). However, the GUI of the corresponding KControl module didn't provide support to change this. This patch add support for changing the mouse cursor size to the GUI. This are mostly GUI related changes. The underlying data structure XCursorTheme did yet provide support for choosing different sizes and only needed some adjustments. This addresses bug 90444. http://bugs.kde.org/show_bug.cgi?id=90444 Diffs - kcontrol/input/xcursor/cursortheme.h 586ccba kcontrol/input/xcursor/cursortheme.cpp 92abea5 kcontrol/input/xcursor/legacytheme.h 846bf9b kcontrol/input/xcursor/previewwidget.h f4d2c4e kcontrol/input/xcursor/previewwidget.cpp 3c264fc kcontrol/input/xcursor/themepage.h 38ca893 kcontrol/input/xcursor/themepage.cpp 6c9f29a kcontrol/input/xcursor/themepage.ui 2e38054 kcontrol/input/xcursor/xcursortheme.h b474086 kcontrol/input/xcursor/xcursortheme.cpp 2ecb9ba Diff: http://git.reviewboard.kde.org/r/101701/diff/diff Testing --- Tested locally. Works fine for me. Also when using non-standard font DPI values. Screenshots --- http://git.reviewboard.kde.org/r/101701/s/248/ Thanks, Lukas Sommer
Re: Request: remove libkactivites from kdelibs (in experimental/)
On Friday, November 4, 2011 23:05:28 Aaron J. Seigo wrote: we currently have libkactivities in kdelibs/experimental. due to upcoming changs and frameworks 5 development, it has been moved into its own git repository: kactivities. unless there are any further objections, here is what i plan to do after the release of 4.7.4 on December 6 (so as not to disrupt 4.7 releases): kdelibs: in KDE/4.7 branch: * remove the contents of kdelibs/experimental/libkactivities * put a README in its place stating what happend so people can easily know what to do now that it is gone in frameworks branch: * merge those changes, then delete the libkactivities directory altogether in that branch kde-workspace: * merge my libkactivities branch into master -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
I think that every app using cookies would like to have this patch merged ASAP, expecially browsers. This will help/fix/improve features like private browsing and so on. So please don't let us wait for the big Universe reordering to have it. :) 2011/11/8 Aaron J. Seigo ase...@kde.org On Monday, November 7, 2011 19:32:15 Dawit A wrote: Well this is over a month too late, but I have a enhancement change for kcookiejar that needs to go into kdelibs/kioslave for KDE 4.8. The patch has actually been pending for a merge since KDE 4.6. See https://bugs.kde.org/show_bug.cgi?id=54300. ... Right. The patch simply moves the idea of session cookies from being a global configuration option to a site specific option. That is it gets rid of the all or nothing approach currently employed. That gives the user a lot more control of how they deal with cookies. can you explain why it must go into 4.8? it's been waiting since 4.6, and i didn't find a description of what requires it in 4.8 ... as far as i can see, it's a feature enhancement that isn't strictly required by anything (though it is very nice to have indeed), so it should go into the frameworks branch. -- 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
Re: Re: Review request for KSecretsService components
A Dimarts, 8 de novembre de 2011, Valentin Rusu vàreu escriure: Hello Again, The freeze will come in less thant two days now and I'd like to know if anyone reviewed these components. Thanks, On 10/31/2011 11:48 PM, Valentin Rusu wrote: Hello, Please be advised three repostories need review before integration into the next release: 1. /kdereview/ksecretservice 2. kdelibs branch ksecretsservice 3. /kdereview/ksecrets *1. /kdereview/ksecretservice* The first one has several subdirectories. The only relevant one is the daemon subdirectory. Other directories contents was already moved to other repositories (see below). This daemon directory contains the sources of the future kde-runtime/ksecretsserviced It needs testing but it's quite usable. *2. kdelibs branch ksecretsservice* kdelibs/kdeui/ksecretsservice This is the API KDE applications will be supposed to use instead of KWallet class. Tools listed below already use this API. This is scary, last time i used kwallet, i had to add a single line, and now there are like a billion of classes? Or is this API for more complex apps like kwalletmanager? My comments on the kdelibs API: - ksecretsservice/ksecretsservicecodec.h * Seems to be installed but has no documentation at all * Uses references for output parameters when KDE/Qt usually uses pointers * Does not use d-pointers thus maintaining ABI is going to be difficult - ksecretsservice/ksecretsservicecollection.h * I miss a note saying who belongs the ownsership of all those job that come as result of the getters. Do I have to delete them? * createItem falls in the let's use a bool instead of an enum because it just have two values trap for the replace parameter * There are a few of spacing glitches, e.g. const QVariantMap collectionProperties = QVariantMap(), const WId promptParentWindowId =0 ); * There are a few not implemented signals - ksecretsservice/ksecretsservicedbustypes.h Contains a plain struct and some inline functions, what if those have to change? - ksecretsservice/ksecretsserviceitem.h * Same question about ownership of jobs - ksecretsservice/ksecretsserviceitemjobs.h * Without having at all a clue on what it is used for, i miss a note saying to who belongs the ownership of the SecretItem passed to the constructor and returned in the secretItem() function, i.e. do i have to delete it myself? * SecretItemJob does not have a d-pointer * void finished( ItemJobError, const QString msg =); should probably be void finished( ItemJobError, const QString msg = QString()); - ksecretsservice/ksecretsservicesecret.h Is installed and has no documentation Albert kdelibs/kdeui/util/kwallet.cpp Contains code depending on a configuration flag that directs calls to ksecretsserviced instead of kwalletd, via the new API. *3. /kdereview/ksecrets* Contains several tools in a less or more mature state: a. kwl2kss - tool to import kwallet files to ksecretsservice, b. ksecrets - tool to list the contents of a ksecretsservice collection (e.g. wallet), c. kio - KIO slave in a just started state, intended to show collections in konqueror or dolphin, d. secretsync - this was the tool I initially wanted to do for KWallet, but drought me into ksecretsservice :-) It's half way implemented. The mandatory components for next release would be 1, 2, 3 (a, b), the others may wait, but releasing them may cause no harm if communication is done right (I'll take care of that). Thanks for your comments (any comments), -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Wednesday, November 9, 2011 15:28:48 andrea diamantini wrote: I think that every app using cookies would like to have this patch merged ASAP, expecially browsers. This will help/fix/improve features like private browsing and so on. So please don't let us wait for the big Universe reordering to have it. :) help us make the big universe reording happen and everyone will get these kinds of changes sooner. frameworks needs to happen. to happen, it needs people working on it. if we continue to allow ourselves to work on 4.x instead well, the math is simple. the problem here is that people do not yet consider frameworks to be the next version of kdelibs. it has not yet sunk in that, yes, indeed kdelibs 4.x is done. bug fixes are welcome and encouraged, of course, and are merged into frameworks. but we need to shift into a mindset where framework _is_ the next version of kdelibs. not something for someone else to work on and give us in some far distant undetermined future, but for us to work on so we can have it sooner rather than later. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Wednesday 09 November 2011, Aaron J. Seigo wrote: On Wednesday, November 9, 2011 15:28:48 andrea diamantini wrote: I think that every app using cookies would like to have this patch merged ASAP, expecially browsers. This will help/fix/improve features like private browsing and so on. So please don't let us wait for the big Universe reordering to have it. :) help us make the big universe reording happen and everyone will get these kinds of changes sooner. frameworks needs to happen. to happen, it needs people working on it. if we continue to allow ourselves to work on 4.x instead well, the math is simple. the problem here is that people do not yet consider frameworks to be the next version of kdelibs. it has not yet sunk in that, yes, indeed kdelibs 4.x is done. bug fixes are welcome and encouraged, of course, and are merged into frameworks. but we need to shift into a mindset where framework _is_ the next version of kdelibs. not something for someone else to work on and give us in some far distant undetermined future, but for us to work on so we can have it sooner rather than later. But it will be not before Qt 5.0. Personally, I don't have a problem if not too many people work on the frameworks yet, since the cmake stuff for frameworks is not yet done by far. And things will still change there. This is easier if there are not that many people there yet. Alex
Review Request: kcm_randr: Fix for Bug 264070 - Cannot apply screen position changes
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103093/ --- Review request for KDE Base Apps, Solid and Alex Fiestas. Description --- Adds the missing connections for absolutePosX and absolutePosY. This addresses bug 264070. http://bugs.kde.org/show_bug.cgi?id=264070 Diffs - kcontrol/randr/outputconfig.cpp 9595811 Diff: http://git.reviewboard.kde.org/r/103093/diff/diff Testing --- compiled it locally, replaced my Kubuntu's /usr/lib/kde4/kcm_randr.so with the self-compiled one -- works! Thanks, Florian Eßer
Re: Review Request: KActivities requires Soprano 2.7 to compile
On Nov. 7, 2011, 3:56 p.m., Ralf Jung wrote: Any comment on this? The patch looks trivial, but I am still new to all this so I'd prefer if someone could confirm that KActivites can and should actually require Soprano 2.7. Aaron J. Seigo wrote: it builds here with 2.6.51. so 2.7 is not required, but perhaps some patch level version of 2.6. in any case, this CMakeLists.txt file should not be requiring 2.7 as it isn't actually required. Okay, I will then discard this request. I do not have the time currently to investigate what exact patchlevel is required, and when I look at it during the next semester break, probably nobody will be using anything below soprano 2.7 ;-) - Ralf --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102893/#review7993 --- On Oct. 16, 2011, 10:29 a.m., Ralf Jung wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102893/ --- (Updated Oct. 16, 2011, 10:29 a.m.) Review request for kdelibs. Description --- I tried compiling KActivities with Soprano 2.6 installed, which resulted in compile errors. After upgrading to Soprano 2.7, these were fixed. I assume this means that KActivities actually requires Soprano 2.7? If that's the case, IMHO attached patch should be applied to detect that at cmake-time. (I also hope this is the right list, there is no kactivities group in reviewboard) Diffs - service/CMakeLists.txt 5489b6b Diff: http://git.reviewboard.kde.org/r/102893/diff/diff Testing --- compile-tested Thanks, Ralf Jung
Re: Review Request: facePerm is a KDM option, unrelated to the user setting his face (for other apps)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102799/#review8055 --- This review has been submitted with commit f7ce3a513baef8479f76c6a9ad7809268a2ab32d by Ralf Jung to branch master. - Commit Hook On Oct. 12, 2011, 4:55 p.m., Ralf Jung wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102799/ --- (Updated Oct. 12, 2011, 4:55 p.m.) Review request for KDE Base Apps. Description --- Currently, the User account password KCM refuses to change the user image if KDM is set up not to use user images. That however does not make much sense, all this applet does is writing the image to ~/.face.icon, which the user can do manually anyway. The fact that KDM might or might not actually display this image in the user selection is unrelated, as KDM is not even the only user of this file: Plasma Kickoff displays it, and maybe more apps use it (GDM uses a different file, though) This patch therefore removes the check for the KDM settings and makes the KCM simply manage the .face.icon file. It does not fall back to the system default if the user image does not exist, as Plasma Kickoff does not do that either. The patch also adds a button in the Change face dialogue to remove the user image, to make it possible to go back to the default state again. After changing the image, the user still has to log off and on again for Plasma to use it - Plasma would have to somehow listen to changes to that file. I don't know if that is desired. This addresses bug 183245. http://bugs.kde.org/show_bug.cgi?id=183245 Diffs - kdepasswd/kcm/main.h 320126f kdepasswd/kcm/main.cpp 5ce1961 Diff: http://git.reviewboard.kde.org/r/102799/diff/diff Testing --- Compiled and verified that the KCM now behaves as desired. Thanks, Ralf Jung
Introducing components, how to
Hi all, sending here as well after plasma-devel and active there is still some work to do, but the components are almost done in their final structure (good for the upcoming freeze, ehehe :) components are imported with: import org.kde.plasma.components regardless of the platform we're in. We have at the moment 37 widgets in the touch profile, 35 in the normal one, tried to follow the standard api as much as possible even tough with some little deviations (especially where it was too unbearably ugly :p) As for documentation, of course any help will always be welcome :p If you are writing an application, just use kdeclarative, and the proper import paths will be setted. to see what component is available, just take a look at the qmldir file in the source directory of kde-runtime kde-runtime/plasma/declarativeimports/plasmacomponents/qml/ or kde- runtime/plasma/declarativeimports/plasmacomponents/platformcomponents/touch/ now, two things: Q: why checking qmldir? A: not all files are available, the ones not shown there are private api Q: what are those two folders? A: hardware specific components: the plasma QtComponents are targeted to two things: * Plasma Desktop widgets * Plasma Active widgets and applications (for desktop applications, we can only wait to see whatever it happens with desktop components but is way too early to know ;) When writing a widget, an application etc, just use import org.kde.plasma.components, the proper one is decided by the kdeclarativerc file, if it has [Components-platform] name=touch for packagers: in plasma active among the default files this kdeclarativerc has to be installed the imports in platformcomponents/touch will override the standard one, actually giving a series of touch optimized widgets. only a few that needed have different implementations, the other ones are duplicated by being installed 2 times by cmake some of the differences: * Buttons and lineedits don't have mouseover effects * by default scrollbars behave like scroll decorators on touch * scrolldecorators are installed only on touch (provided just for compatibility, use scrollbar instead, it behaves the right way(tm) ;)) * sectionscroller looks like the iphone addressbook scroller on touch, like a scrollbar on desktop * Window is *not* provided on desktop: in desktop widgets makes really no sense * QueryDialog uses a KDialog on desktop, on touch uses qml items and is in a Plasma::Dialog * the same way, Menu/ContextMenu is a QMenu on desktop, while is a more plasma looking thing on touch this architecture is going to be final once released in 4.8 (at least until frameworks5), so speak now or forever shut up :p Cheers, Marco Martin
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Wednesday, November 9, 2011 17:53:58 Alexander Neundorf wrote: But it will be not before Qt 5.0. the question is how long after, and the best answer is as little delay as possible. Qt 5.0 is scheduled for some time in 2012. Personally, I don't have a problem if not too many people work on the personally, i do. there is lots of work to be done that doesn't require waiting on the build system changes. if we serialize on build system - modularize - modernize where needed we'll be lucky to have something out for 2014, forget 2012. to remind us of history: remember how some figured we might just skip doing a 3.4 release? then we recanted (and that time for good reasons, as Qt4 was a rocky path) and did a 3.4 .. and then 3.5 .. and then lots of 3.5.x releases with fewer good reasons to do so, slowing down development of the 4.x series. i know i sound like a broken record here: we should learn from the past rather than repeat 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 signature.asc Description: This is a digitally signed message part.
Re: Review Request: kcm_randr: Fix for Bug 264070 - Cannot apply screen position changes
On Nov. 9, 2011, 8:50 p.m., Christoph Feck wrote: It's already fixed, at least in master. The patch is wrong, too, because that signal doesn't exists in QSpinBox. Looks like you did not test it :) Sorry, I failed reading, forget what I wrote. Still, I suggest to use 'valueChanged' signal, otherwise simply clicking and leaving the spinbox will flag a change. - Christoph --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103093/#review8062 --- On Nov. 9, 2011, 4:50 p.m., Florian Eßer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103093/ --- (Updated Nov. 9, 2011, 4:50 p.m.) Review request for KDE Base Apps, Solid and Alex Fiestas. Description --- Adds the missing connections for absolutePosX and absolutePosY. This addresses bug 264070. http://bugs.kde.org/show_bug.cgi?id=264070 Diffs - kcontrol/randr/outputconfig.cpp 9595811 Diff: http://git.reviewboard.kde.org/r/103093/diff/diff Testing --- compiled it locally, replaced my Kubuntu's /usr/lib/kde4/kcm_randr.so with the self-compiled one -- works! Thanks, Florian Eßer
Review Request: Fix crash on statusbarextension destruction
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103098/ --- Review request for kdelibs. Description --- With master, Qt 4.8 and kwebkitpart recently I run into crashes when I close tabs holding web pages inside akregator. With the patch, it doesn't crash (as it doesn't try to access parent() from the destructor). The BT is here: Application: Akregator (akregator), signal: Segmentation fault [Current thread is 1 (Thread 0x7f8eebe5f760 (LWP 17084))] Thread 4 (Thread 0x7f8ecb314700 (LWP 17090)): #0 0x7f8ee4c336f9 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7f8ee4eef649 in QWaitConditionPrivate::wait (this=0x1956ec0, time=3) at thread/qwaitcondition_unix.cpp:84 #2 0x7f8ee4eef40d in QWaitCondition::wait (this=0x19ba150, mutex=0x19ba148, time=3) at thread/qwaitcondition_unix.cpp:158 #3 0x7f8ee4edd285 in QThreadPoolThread::run (this=0x19b5810) at concurrent/qthreadpool.cpp:141 #4 0x7f8ee4eee0b6 in QThreadPrivate::start (arg=0x19b5810) at thread/qthread_unix.cpp:298 #5 0x7f8ecd69a9e3 in ?? () from /usr/X11R6/lib64/libGL.so.1 #6 0x7f8ee4c2ea3f in start_thread () from /lib64/libpthread.so.0 #7 0x7f8ee3c7366d in clone () from /lib64/libc.so.6 #8 0x in ?? () Thread 3 (Thread 0x7f8ec968f700 (LWP 17109)): #0 0x7f8ee4c3338c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7f8ed31d8321 in WTF::TCMalloc_PageHeap::scavengerThread() () from //opt/qt4/lib/libQtWebKit.so.4 #2 0x7f8ed31d78dc in WTF::TCMalloc_PageHeap::runScavengerThread(void*) () from //opt/qt4/lib/libQtWebKit.so.4 #3 0x7f8ecd69a9e3 in ?? () from /usr/X11R6/lib64/libGL.so.1 #4 0x7f8ee4c2ea3f in start_thread () from /lib64/libpthread.so.0 #5 0x7f8ee3c7366d in clone () from /lib64/libc.so.6 #6 0x in ?? () Thread 2 (Thread 0x7f8ec86d7700 (LWP 17110)): #0 0xff600177 in ?? () #1 0x7fff885ff7a1 in ?? () #2 0x7f8eddf122b3 in clock_gettime () from /lib64/librt.so.1 #3 0x7f8ee4f5be26 in do_gettime (sec=0x7f8ec86d6948, frac=0x7f8ec86d6940) at tools/qelapsedtimer_unix.cpp:123 #4 0x7f8ee4f5be82 in qt_gettime () at tools/qelapsedtimer_unix.cpp:140 #5 0x7f8ee50602de in QTimerInfoList::updateCurrentTime (this=0x7193730) at kernel/qeventdispatcher_unix.cpp:343 #6 0x7f8ee5060792 in QTimerInfoList::timerWait (this=0x7193730, tm=...) at kernel/qeventdispatcher_unix.cpp:450 #7 0x7f8ee505cfd4 in timerSourcePrepareHelper (src=0x71936d0, timeout=0x7f8ec86d6acc) at kernel/qeventdispatcher_glib.cpp:136 #8 0x7f8ee505d28d in idleTimerSourcePrepare (source=0x71a3110, timeout=0x7f8ec86d6acc) at kernel/qeventdispatcher_glib.cpp:216 #9 0x7f8eddc61087 in g_main_context_prepare () from /lib64/libglib-2.0.so.0 #10 0x7f8eddc61fa9 in ?? () from /lib64/libglib-2.0.so.0 #11 0x7f8eddc62650 in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #12 0x7f8ee505dd14 in QEventDispatcherGlib::processEvents (this=0x6833680, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #13 0x7f8ee501e9ae in QEventLoop::processEvents (this=0x7f8ec86d6cf0, flags=...) at kernel/qeventloop.cpp:149 #14 0x7f8ee501eb38 in QEventLoop::exec (this=0x7f8ec86d6cf0, flags=...) at kernel/qeventloop.cpp:204 #15 0x7f8ee4eeb731 in QThread::exec (this=0x6995320) at thread/qthread.cpp:501 #16 0x7f8ee4eeb8d0 in QThread::run (this=0x6995320) at thread/qthread.cpp:568 #17 0x7f8ee4eee0b6 in QThreadPrivate::start (arg=0x6995320) at thread/qthread_unix.cpp:298 #18 0x7f8ecd69a9e3 in ?? () from /usr/X11R6/lib64/libGL.so.1 #19 0x7f8ee4c2ea3f in start_thread () from /lib64/libpthread.so.0 #20 0x7f8ee3c7366d in clone () from /lib64/libc.so.6 #21 0x in ?? () Thread 1 (Thread 0x7f8eebe5f760 (LWP 17084)): [KCrash Handler] #6 0x in ?? () #7 0x7f8eeba82873 in KParts::StatusBarExtension::statusBar (this=0x6c243a0) at /encrypted/home/andris/development/sources/kde-trunk/kdelibs/kparts/statusbarextension.cpp:149 #8 0x7f8eeba82544 in KParts::StatusBarExtension::~StatusBarExtension (this=0x6c243a0, __in_chrg=value optimized out) at /encrypted/home/andris/development/sources/kde-trunk/kdelibs/kparts/statusbarextension.cpp:99 #9 0x7f8eeba8266a in KParts::StatusBarExtension::~StatusBarExtension (this=0x6c243a0, __in_chrg=value optimized out) at /encrypted/home/andris/development/sources/kde-trunk/kdelibs/kparts/statusbarextension.cpp:110 #10 0x7f8ee503b650 in QObjectPrivate::deleteChildren (this=0x5d966c0) at kernel/qobject.cpp:1907 #11 0x7f8ee5039d4f in QObject::~QObject (this=0x19cfb90, __in_chrg=value optimized out) at kernel/qobject.cpp:926 #12 0x7f8eeba5fbf0 in KParts::Part::~Part (this=0x19cfb90, __vtt_parm=0x7f8ec98e4950,
Re: Review Request: kcm_randr: Fix for Bug 264070 - Cannot apply screen position changes
On Nov. 9, 2011, 8:50 p.m., Christoph Feck wrote: It's already fixed, at least in master. The patch is wrong, too, because that signal doesn't exists in QSpinBox. Looks like you did not test it :) Christoph Feck wrote: Sorry, I failed reading, forget what I wrote. Still, I suggest to use 'valueChanged' signal, otherwise simply clicking and leaving the spinbox will flag a change. The signal comes from QAbstractSpinBox. As I wrote in http://bugs.kde.org/show_bug.cgi?id=264070 , the problem with valueChanged is that just opening the screen settings will flag a change, which is even worse than clicking and leaving. I guess valueChanged() gets triggered when the spin boxes are initialized to their default values. - Florian --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103093/#review8062 --- On Nov. 9, 2011, 4:50 p.m., Florian Eßer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103093/ --- (Updated Nov. 9, 2011, 4:50 p.m.) Review request for KDE Base Apps, Solid and Alex Fiestas. Description --- Adds the missing connections for absolutePosX and absolutePosY. This addresses bug 264070. http://bugs.kde.org/show_bug.cgi?id=264070 Diffs - kcontrol/randr/outputconfig.cpp 9595811 Diff: http://git.reviewboard.kde.org/r/103093/diff/diff Testing --- compiled it locally, replaced my Kubuntu's /usr/lib/kde4/kcm_randr.so with the self-compiled one -- works! Thanks, Florian Eßer
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Wednesday 09 November 2011 16:45:55 Aaron J. Seigo wrote: On Wednesday, November 9, 2011 15:28:48 andrea diamantini wrote: I think that every app using cookies would like to have this patch merged ASAP, expecially browsers. This will help/fix/improve features like private browsing and so on. So please don't let us wait for the big Universe reordering to have it. :) help us make the big universe reording happen and everyone will get these kinds of changes sooner. frameworks needs to happen. to happen, it needs people working on it. if we continue to allow ourselves to work on 4.x instead well, the math is simple. the problem here is that people do not yet consider frameworks to be the next version of kdelibs. it has not yet sunk in that, yes, indeed kdelibs 4.x is done. bug fixes are welcome and encouraged, of course, and are merged into frameworks. but we need to shift into a mindset where framework _is_ the next version of kdelibs. not something for someone else to work on and give us in some far distant undetermined future, but for us to work on so we can have it sooner rather than later. 4.x is where I'm living/fighting/coding/writing now. I'm sorry to say, in my mind next version of kdelibs is 4.8. And it will be based on the upcoming (not yet released) Qt 4.8. Thinking about frameworks without having yet a decent idea of what will be Qt5 is impossible for me. But probably it's me, because I usually start coding after 10pm... -- Andrea Diamantini, adjam GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F rekonq project WEB: http://rekonq.kde.org IRC: rekonq@freenode
I have ALL MOUSE BUTTONS WORKING for xcb and xlib :)) on qt5
My thanks to you, MGrasslin, Aaron, Todd rme, and Thiago for coaching me towards this achievement. The new code is small, and VERY simple. We have no API changes (at least, not yet--- we should implement a mouse button mask "getter" as a new feature, but that's for later in the 5.x series. It won't have any BC issues.) I will need to write doco of the new Qt::MouseButton values, and others will need to translate that material. My "qt5_MouseButtonTester" is a QTextEdit window, with Mouse events (Click/Release/DoubleClick) extended to show some qDebug() on the parent console. Basically, it's an "xev" program for Mouse Buttons in Qt. This tester, on Qt::MouseButton events, translates the button value back into the raw X11 number. I verified the button locations on my mouse to be correct, using xev itself. My mouse has "only" 14 buttons, plus the tilt wheel, for a total of 18. I know that the Razr 'Naga' has even more, but it's too small for my hand. (And the one I've got cost me enough money, already.) The logic works for up to 31 "button numbers", with 4-7 taken for the four possible directions of wheel motion. Just for fun, here's my output from clicking the buttons in order. I did perform a few DoubleClick events during the test: rick@x2:~/qt_projects/qt5_MouseButtonTester qt5_MouseButtonTester No platform plugin argument was specified, defaulting to "xcb". Successfully connected to display :0 Information of screen 346: width.: 1920 height: 1200 depth.: 24 white pixel...: ff black pixel...: 0 Running window manager: KWin MousePress: button 1 MouseRelease: MousePress: button 2 MouseRelease: MousePress: button 3 Mouse Wheel Event: UP Mouse Wheel Event: DOWN Mouse Wheel Event: LEFT Mouse Wheel Event: RIGHT MousePress: button 8 MouseRelease: MousePress: button 9 MouseRelease: Mouse DoubleClick: MousePress: button 10 MouseRelease: MousePress: button 11 MouseRelease: Mouse DoubleClick: MousePress: button 12 MouseRelease: MousePress: button 13 MouseRelease: Mouse DoubleClick: MousePress: button 14 MouseRelease: rick@x2:~/qt_projects/qt5_MouseButtonTester xlib runs the same, as far as my mouse buttons are concerned. But the App Window fails to repaint when I move it, or when I resize it. I'll SWAG that we've got an issue there, not the fault of kwin 4.6.5. (I can try running it from another User in which my desktop is fresh kwin 4.8-pre from GIT, if you think that the WM should be getting the blame for this behavior. Let me know on that, thanks. - - - - - FILES CHANGED: qnamespace.h: (The expanded enum/flags is prerequisite for all other code changes). DOCO IS NEEDED, I can write it in En-US. qguiapplication.cpp: (This contains a redundant check on button numbers being passed up from plugins. I made a one-line change, upping the high-limit to be 'Qt::Button31'.) qxlibwindow.cpp, qxcbwindow: (I added cases to the ev-button 'switch' block, for all of the new buttons. In this file, and qxcbwindow.cpp, I also eliminated an unnecessary multiply in the calculation of 'delta' -- simply setting values 120 : -120 as the hard-coded results of the "?" operator (rather than multiplying 120 * ? 1: -1). Should we do them all as one update, or do xlib first -- and add the more widely used xcb as a separate update, after the first one is found NOT to cause regression test failures over the next weekend? (BTW, I don't know how to do the Git Clone and Request procedure, and I'm a slow learner-- it would REALLY be better if I simply emailed these files to you.) Changes are public domain, of course - I think that I've already certified acceptance of the Qt license exceptions for my Contributions. - - - - - - - Now, for Wayland: I can create alternate UserIDs on my PC, of course. But the plugin fails to compile, issuing the following message: . -o qwaylandinputdevice.o qwaylandinputdevice.cpp qwaylandinputdevice.cpp:527:1: error: too many initializers for const wl_input_device_listener make: *** [qwaylandinputdevice.o] Error 1 Not a missing library or header, my hand-edit of the Makefile was correct. I suspect that this results from my use of a fresh 'Pull' of Wayland, per the README instructions. I don't have time for this one (and I'm a slow learner), can you or another 'Grandmaster' take care of it?
Re: Review request for KSecretsService components
Hello Albert, Thanks for the thourough review. On 11/09/2011 03:26 PM, Albert Astals Cid wrote: A Dimarts, 8 de novembre de 2011, Valentin Rusu vàreu escriure: Hello Again, The freeze will come in less thant two days now and I'd like to know if anyone reviewed these components. Thanks, On 10/31/2011 11:48 PM, Valentin Rusu wrote: Hello, Please be advised three repostories need review before integration into the next release: 1. /kdereview/ksecretservice 2. kdelibs branch ksecretsservice 3. /kdereview/ksecrets *1. /kdereview/ksecretservice* The first one has several subdirectories. The only relevant one is the daemon subdirectory. Other directories contents was already moved to other repositories (see below). This daemon directory contains the sources of the future kde-runtime/ksecretsserviced It needs testing but it's quite usable. *2. kdelibs branch ksecretsservice* kdelibs/kdeui/ksecretsservice This is the API KDE applications will be supposed to use instead of KWallet class. Tools listed below already use this API. This is scary, last time i used kwallet, i had to add a single line, and now there are like a billion of classes? Welcome to the asynchronous jobs world. I had the same opinion at start. And, to be honest, that's why it takes so long to implement, as I'm not working on it only during my spare time. Or is this API for more complex apps like kwalletmanager? Well, the secrets service infrastructure, specified with GNOME's Stef Walter is intended to do more things thant KWallet was. For instance, the KWallet API won't let me do the synchronization tool I wanted without significant improvement. My comments on the kdelibs API: - ksecretsservice/ksecretsservicecodec.h * Seems to be installed but has no documentation at all It's indeed installed but it's an @internal class - I added the appropriate documentation. * Uses references for output parameters when KDE/Qt usually uses pointers * Does not use d-pointers thus maintaining ABI is going to be difficult Once again, it's an internal class, no breakage risk here as I'll maintain the API and the daemon together. - ksecretsservice/ksecretsservicecollection.h * I miss a note saying who belongs the ownsership of all those job that come as result of the getters. Do I have to delete them? Oh, I thought that'll not be needed. Usually jobs autodelete themselves. Note added. * createItem falls in the let's use a bool instead of an enum because it just have two values trap for the replace parameter Well, I don't agree. When presenting a new item to the collection, you should specify to replace existing item or not. Yes/No is boolean for me. * There are a few of spacing glitches, e.g. const QVariantMap collectionProperties = QVariantMap(), const WIdpromptParentWindowId =0 ); Added a space before the 0. * There are a few not implemented signals Yes, but they'll not be done before tommorrow, unfortunately. - ksecretsservice/ksecretsservicedbustypes.h Contains a plain struct and some inline functions, what if those have to change? Marked as @internal - ksecretsservice/ksecretsserviceitem.h * Same question about ownership of jobs Same note added. - ksecretsservice/ksecretsserviceitemjobs.h * Without having at all a clue on what it is used for, i miss a note saying to who belongs the ownership of the SecretItem passed to the constructor and returned in the secretItem() function, i.e. do i have to delete it myself? This class was marked as @internal and corresponding comment was added. * SecretItemJob does not have a d-pointer Oops! Added. * void finished( ItemJobError, const QString msg =); should probably be void finished( ItemJobError, const QString msg = QString()); Right! - ksecretsservice/ksecretsservicesecret.h Is installed and has no documentation Documentation added. Albert kdelibs/kdeui/util/kwallet.cpp Contains code depending on a configuration flag that directs calls to ksecretsserviced instead of kwalletd, via the new API. *3. /kdereview/ksecrets* Contains several tools in a less or more mature state: a. kwl2kss - tool to import kwallet files to ksecretsservice, b. ksecrets - tool to list the contents of a ksecretsservice collection (e.g. wallet), c. kio - KIO slave in a just started state, intended to show collections in konqueror or dolphin, d. secretsync - this was the tool I initially wanted to do for KWallet, but drought me into ksecretsservice :-) It's half way implemented. The mandatory components for next release would be 1, 2, 3 (a, b), the others may wait, but releasing them may cause no harm if communication is done right (I'll take care of that). Thanks for your comments (any comments), -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement) -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: Re: Review request for KSecretsService components
A Dijous, 10 de novembre de 2011, Valentin Rusu vàreu escriure: Hello Albert, Thanks for the thourough review. On 11/09/2011 03:26 PM, Albert Astals Cid wrote: This is scary, last time i used kwallet, i had to add a single line, and now there are like a billion of classes? Welcome to the asynchronous jobs world. I had the same opinion at start. And, to be honest, that's why it takes so long to implement, as I'm not working on it only during my spare time. Are you saying you don't have anything as simple as this in the new API? QString walletName = KWallet::Wallet::NetworkWallet(); KWallet::Wallet *wallet = KWallet::Wallet::openWallet(walletName, parentwid); if ( !wallet-hasFolder( KPdf ) ) wallet-createFolder( KPdf ); wallet-setFolder( KPdf ); wallet-readPassword( walletKey, retrievedPass ) * createItem falls in the let's use a bool instead of an enum because it just have two values trap for the replace parameter Well, I don't agree. When presenting a new item to the collection, you should specify to replace existing item or not. Yes/No is boolean for me. That is the problem, that a boolean is Yes/No, and then you end up with a call that says foo-createItem(label, attributes, mySecret, false); And it seems you do not want to create the item :D while foo-createItem(label, attributes, mySecret, DoNotReplace); is much more obvious. More on my side at http://wiki.qt-project.org/API_Design_Principles#The_Boolean_Parameter_Trap and http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html Of course that is a minor thing and won't complain too much if you decide to disagree with me ;-) Albert
Re: Review request for KSecretsService components
On 11/10/2011 12:48 AM, Albert Astals Cid wrote: A Dijous, 10 de novembre de 2011, Valentin Rusu vàreu escriure: Hello Albert, Thanks for the thourough review. On 11/09/2011 03:26 PM, Albert Astals Cid wrote: This is scary, last time i used kwallet, i had to add a single line, and now there are like a billion of classes? Welcome to the asynchronous jobs world. I had the same opinion at start. And, to be honest, that's why it takes so long to implement, as I'm not working on it only during my spare time. Are you saying you don't have anything as simple as this in the new API? QString walletName = KWallet::Wallet::NetworkWallet(); KWallet::Wallet *wallet = KWallet::Wallet::openWallet(walletName, parentwid); if ( !wallet-hasFolder( KPdf ) ) wallet-createFolder( KPdf ); wallet-setFolder( KPdf ); wallet-readPassword( walletKey, retrievedPass ) Yes, your code isn't asynchrounous ! (boo) Well, I don't fully agree with this point of view, but in Randa they managed to convince me about the benefits. Take a look inside kwallet.cpp class to see how this new API should be used. Another example is the ksecrets API inside kdereview/ksecrets repository. * createItem falls in the let's use a bool instead of an enum because it just have two values trap for the replace parameter Well, I don't agree. When presenting a new item to the collection, you should specify to replace existing item or not. Yes/No is boolean for me. That is the problem, that a boolean is Yes/No, and then you end up with a call that says foo-createItem(label, attributes, mySecret, false); And it seems you do not want to create the item :D while foo-createItem(label, attributes, mySecret, DoNotReplace); is much more obvious. More on my side at http://wiki.qt-project.org/API_Design_Principles#The_Boolean_Parameter_Trap and http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html Ok, I see. I'll change that. Of course that is a minor thing and won't complain too much if you decide to disagree with me ;-) Albert -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: Review request for KSecretsService components
On 11/10/2011 01:00 AM, Valentin Rusu wrote: On 11/10/2011 12:48 AM, Albert Astals Cid wrote: * createItem falls in the let's use a bool instead of an enum because it just have two values trap for the replace parameter Well, I don't agree. When presenting a new item to the collection, you should specify to replace existing item or not. Yes/No is boolean for me. That is the problem, that a boolean is Yes/No, and then you end up with a call that says foo-createItem(label, attributes, mySecret, false); And it seems you do not want to create the item :D while foo-createItem(label, attributes, mySecret, DoNotReplace); is much more obvious. More on my side at http://wiki.qt-project.org/API_Design_Principles#The_Boolean_Parameter_Trap and http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html Ok, I see. I'll change that. Well, In fact I changed my mind, as the enum must be a member of Collection class, but required to be used in the create job and nested enums cannot be forward declared. So that'll require to move the enum outside of the Collection class, leading to even uglier code. So I'll stay with the boolean, wich also corresponds to the freedesktop.org dbus interfaces spec, btw. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: Re: Review request for KSecretsService components
A Dijous, 10 de novembre de 2011, Valentin Rusu vàreu escriure: On 11/10/2011 12:48 AM, Albert Astals Cid wrote: A Dijous, 10 de novembre de 2011, Valentin Rusu vàreu escriure: Hello Albert, Thanks for the thourough review. On 11/09/2011 03:26 PM, Albert Astals Cid wrote: This is scary, last time i used kwallet, i had to add a single line, and now there are like a billion of classes? Welcome to the asynchronous jobs world. I had the same opinion at start. And, to be honest, that's why it takes so long to implement, as I'm not working on it only during my spare time. Are you saying you don't have anything as simple as this in the new API? QString walletName = KWallet::Wallet::NetworkWallet(); KWallet::Wallet *wallet = KWallet::Wallet::openWallet(walletName, parentwid); if ( !wallet-hasFolder( KPdf ) ) wallet-createFolder( KPdf ); wallet-setFolder( KPdf ); wallet-readPassword( walletKey, retrievedPass ) Yes, your code isn't asynchrounous ! (boo) Yeah well, kparts gives you virtual bool openUrl( const KUrl url ); With that signature you are forced to either use synchronous code or create a nested event loop, pick your poison. Well, I don't fully agree with this point of view, but in Randa they managed to convince me about the benefits. Take a look inside kwallet.cpp class to see how this new API should be used. Another example is the ksecrets API inside kdereview/ksecrets repository. This answer makes me really scared in that it is not going to be 5 lines :-/ Ok, now i've looked at the API and I am not sure i like it, particulary nonQtlike seems the way of searching things by passing a map with a key/value structure of what you want to find. I can see that it is very flexible, but string based api end up with people writing key instead of Key and they lose days debugging why it fails. Also i'm a bit confused about the docu of SearchCollectionItemsJob * searchItems( const StringStringMap attributes ); it says * KSecretsService uses overall the following standard attributes: * Label : item's or collection's label so i understand that Label is the only key of the map that you can use, and then the example says * StrinStringMap attrs; * attrs[Key] = ; and uses Key ? Does this mean Key is a valid attribute too and should be documented? Or should it say Label? Or i totally misunderstood the documentation? Also note it says StrinStringMap, missing g. Albert
Review Request: Provide extra options for date keyword display in KDateComboBox
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103103/ --- Review request for kdelibs and John Layt. Description --- KDateComboBox provides the option to display a list of date keywords with the date picker popup. These keywords currently show dates in the past, present and future, together with a no date item. The no date item is a particular problem since not only is it redundant - since there is already a button in the line edit to clear the date value - but I suspect that many applications will not accept a blank date as valid input. This patch adds two new enum values to allow applications to select which of these date keywords are displayed: one enum value shows the no date item which is now not shown by default, and another enum value hides dates in the past. Currently in KAlarm, which I maintain, the display of date keywords is disabled because dates in the past and blank dates are not valid values to enter, and it would be confusing to users to offer them as options. This patch will make it possible to display only present and future date keywords, which will enable it to make use of date keywords. Diffs - kdeui/widgets/kdatecombobox.h 63bf52f kdeui/widgets/kdatecombobox.cpp fc239bc Diff: http://git.reviewboard.kde.org/r/103103/diff/diff Testing --- Tested in KAlarm. Thanks, David Jarvie
Re: Re: Review request for KSecretsService components
A Dijous, 10 de novembre de 2011, Valentin Rusu vàreu escriure: On 11/10/2011 01:00 AM, Valentin Rusu wrote: On 11/10/2011 12:48 AM, Albert Astals Cid wrote: * createItem falls in the let's use a bool instead of an enum because it just have two values trap for the replace parameter Well, I don't agree. When presenting a new item to the collection, you should specify to replace existing item or not. Yes/No is boolean for me. That is the problem, that a boolean is Yes/No, and then you end up with a call that says foo-createItem(label, attributes, mySecret, false); And it seems you do not want to create the item :D while foo-createItem(label, attributes, mySecret, DoNotReplace); is much more obvious. More on my side at http://wiki.qt-project.org/API_Design_Principles#The_Boolean_Parameter _Trap and http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html Ok, I see. I'll change that. Well, In fact I changed my mind, as the enum must be a member of Collection class, but required to be used in the create job and nested enums cannot be forward declared. So that'll require to move the enum outside of the Collection class, leading to even uglier code. There is a solution for this, the CreateCollectionItemJob constructor should accept a CreateCollectionItemJobPrivate instead of all the params (since i understand it does not make sense for me creating one directly and I will only get one thought Collection::createItem (reason to make it private too?)). This way you do not need a replace member in the constructor since Collection passes the CreateCollectionItemJobPrivate directly. Probably the same argument for making the constructor private for all the other jobs applies too. Albert So I'll stay with the boolean, wich also corresponds to the freedesktop.org dbus interfaces spec, btw. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
