Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Wednesday, November 9, 2011 23:44:21 Andrea Diamantini wrote: 4.x is where I'm living/fighting/coding/writing now. for apps and workspaces, that is perfect. we don't want to disrupt app and workspace development while we get kdelibs prepped for the next major release. I'm sorry to say, in my mind next version of kdelibs is 4.8. your mind is wrong. whatever the version number might end up saying (probably to keep packagers and users from confusion) it'll be the 4.7 code base with continued bug fixes applied :) And it will be based on the upcoming (not yet released) Qt 4.8. sure; but this is a non-relevant detail. Thinking about frameworks without having yet a decent idea of what will be Qt5 is impossible for me. actually, Qt5 is irrelevant to most of the work that needs to be done in frameworks. we can, and are, working against Qt4 right now. most of the work is modularization and modernization (while preserving source compatibility) we are merging some things upstream into Qt5, and the things that are merged upstream are going into a small temporary library call libinqt (lib in qt ;). when Qt5 arrives, that library will go away and we will be able to move to basing frameworks on Qt5. between now and then there is a lot of work on the modularization and modernization work. for instance, Sune's proposal to improve KNotification requires absolutely nothing from Qt5. having that done before Qt5 arrives would actually be a bonus as we wouldn't have to juggle too many different kinds of changes at once. i do recognize that there is not enough documented plans and direction for frameworks 5. there are a handful of wiki pages but they do not contain enough information; too much of that still resides in the heads of just a few people. to help address that, i'm hosting an irc meeting in a couple weeks with people currently working on frameworks 5 with the aim of pulling together clearly documented goals, tasks and milestones. the date has not been fixed yet, once it is i will announce it here as well so interested parties can join. i hope that with further documentation and clairty of goals that others will be able to see how they can get involved with frameworks and why now is a good time to do so. -- 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: I have ALL MOUSE BUTTONS WORKING for xcb and xlib :)) on qt5
On Wednesday, November 9, 2011 15:41:17 Rick Stockton wrote: 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. very nice; does this mean it's been merged into qt5 already or that the code exists and is waiting to be merged into qt5 master? either way, nice work and very cool to see this start from i want more mouse buttons ... how do we get that to happen? to an actual implementation! -- 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: Fix crash on statusbarextension destruction
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103098/#review8079 --- Ship it! Yep, looks good. - David Faure On Nov. 9, 2011, 9:40 p.m., Andras Mantia wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103098/ --- (Updated Nov. 9, 2011, 9:40 p.m.) 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
Re: Review Request: Fix crash on statusbarextension destruction
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103098/#review8080 --- This review has been submitted with commit 999eac446a49e6126df04aa8717f95e6aef136fc by Andras Mantia to branch KDE/4.7. - Commit Hook On Nov. 9, 2011, 9:40 p.m., Andras Mantia wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103098/ --- (Updated Nov. 9, 2011, 9:40 p.m.) 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
Re: I have ALL MOUSE BUTTONS WORKING for xcb and xlib :)) on qt5
On Thu, Nov 10, 2011 at 12:41 AM, Rick Stockton rickstock...@reno-computerhelp.com wrote: 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? Great to hear! This will really improve Qt and KDE a lot. Thank you very much for all of your work. -Todd
Re: Review Request: Make the tab group Xproperty accessable via NETWinInfo
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103099/#review8082 --- I would like to see this in kdelibs 4.8. It is a rather minor change and should be fine for 4.7 as well. But I don't know what's the state for additions to kdelibs currently... - Martin Gräßlin On Nov. 9, 2011, 10:15 p.m., Anton Kreuzkamp wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103099/ --- (Updated Nov. 9, 2011, 10:15 p.m.) Review request for kdelibs and Martin Gräßlin. Description --- For KWin 4.8 Windows grouped using kwin's window tabbing feature, tell the world outside kwin in which group they are, using an XProperty. This patch makes this XProperty accessable via NETWinInfo. I hope it will be possible to integrate it into the 4.7 branch for KDE r4.8. Diffs - kdeui/windowmanagement/netwm.h c64a0a5 kdeui/windowmanagement/netwm.cpp cf28339 kdeui/windowmanagement/netwm_def.h 1482bca kdeui/windowmanagement/netwm_p.h d7f4599 Diff: http://git.reviewboard.kde.org/r/103099/diff/diff Testing --- Tested with the methods/signals, tabGroup() and windowChanged(). Everything I tested works. Thanks, Anton Kreuzkamp
Re: Review Request: Make the tab group Xproperty accessable via NETWinInfo
On Nov. 10, 2011, 10:02 a.m., Martin Gräßlin wrote: I would like to see this in kdelibs 4.8. It is a rather minor change and should be fine for 4.7 as well. But I don't know what's the state for additions to kdelibs currently... The freeze is today, which means it has to go in today. - Christoph --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103099/#review8082 --- On Nov. 9, 2011, 10:15 p.m., Anton Kreuzkamp wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103099/ --- (Updated Nov. 9, 2011, 10:15 p.m.) Review request for kdelibs and Martin Gräßlin. Description --- For KWin 4.8 Windows grouped using kwin's window tabbing feature, tell the world outside kwin in which group they are, using an XProperty. This patch makes this XProperty accessable via NETWinInfo. I hope it will be possible to integrate it into the 4.7 branch for KDE r4.8. Diffs - kdeui/windowmanagement/netwm.h c64a0a5 kdeui/windowmanagement/netwm.cpp cf28339 kdeui/windowmanagement/netwm_def.h 1482bca kdeui/windowmanagement/netwm_p.h d7f4599 Diff: http://git.reviewboard.kde.org/r/103099/diff/diff Testing --- Tested with the methods/signals, tabGroup() and windowChanged(). Everything I tested works. Thanks, Anton Kreuzkamp
Re: Review Request: Make the tab group Xproperty accessable via NETWinInfo
On Nov. 10, 2011, 10:02 a.m., Martin Gräßlin wrote: I would like to see this in kdelibs 4.8. It is a rather minor change and should be fine for 4.7 as well. But I don't know what's the state for additions to kdelibs currently... Christoph Feck wrote: The freeze is today, which means it has to go in today. this is a new feature. it is not needed to address any functionality bugs. so it belongs in frameworks, not the KDE/4.7 branch. (and yes, i'm aware of the good things we can do with this feature in workspace code :) - Aaron J. --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103099/#review8082 --- On Nov. 9, 2011, 10:15 p.m., Anton Kreuzkamp wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103099/ --- (Updated Nov. 9, 2011, 10:15 p.m.) Review request for kdelibs and Martin Gräßlin. Description --- For KWin 4.8 Windows grouped using kwin's window tabbing feature, tell the world outside kwin in which group they are, using an XProperty. This patch makes this XProperty accessable via NETWinInfo. I hope it will be possible to integrate it into the 4.7 branch for KDE r4.8. Diffs - kdeui/windowmanagement/netwm.h c64a0a5 kdeui/windowmanagement/netwm.cpp cf28339 kdeui/windowmanagement/netwm_def.h 1482bca kdeui/windowmanagement/netwm_p.h d7f4599 Diff: http://git.reviewboard.kde.org/r/103099/diff/diff Testing --- Tested with the methods/signals, tabGroup() and windowChanged(). Everything I tested works. Thanks, Anton Kreuzkamp
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. Florian Eßer wrote: 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. w/o having looked at the expanded code, this applies to all value changes, so they should all be connected _after_ the initial values have been loaded. (to be more annoying: setConfigDirty should actually compare the present configuration with the demanded configuration and update the UI respectively) - Thomas --- 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: Make the tab group Xproperty accessable via NETWinInfo
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103099/ --- Review request for kdelibs and Martin Gräßlin. Description --- For KWin 4.8 Windows grouped using kwin's window tabbing feature, tell the world outside kwin in which group they are, using an XProperty. This patch makes this XProperty accessable via NETWinInfo. I hope it will be possible to integrate it into the 4.7 branch for KDE r4.8. Diffs - kdeui/windowmanagement/netwm.h c64a0a5 kdeui/windowmanagement/netwm.cpp cf28339 kdeui/windowmanagement/netwm_def.h 1482bca kdeui/windowmanagement/netwm_p.h d7f4599 Diff: http://git.reviewboard.kde.org/r/103099/diff/diff Testing --- Tested with the methods/signals, tabGroup() and windowChanged(). Everything I tested works. Thanks, Anton Kreuzkamp
Re: Review Request: Make mouse cursor size configurable
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101701/#review8071 --- This review has been submitted with commit 617b08f5f6652bb9d918abc963954723caca59d2 by Lukas Sommer to branch master. - Commit Hook 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: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Thursday 10 November 2011 10:14:58 Aaron J. Seigo wrote: On Wednesday, November 9, 2011 23:44:21 Andrea Diamantini wrote: And it will be based on the upcoming (not yet released) Qt 4.8. sure; but this is a non-relevant detail. Indeed... Thinking about frameworks without having yet a decent idea of what will be Qt5 is impossible for me. Qt5 is nearing feature freeze, and there is a pretty decent idea of what it will be like. If I remember correctly, the release of 5.0 is currently planned for Spring 2012, around April. That is not far in the future, and we're not talking vaporware here. Mostly, it's going to be source compatible (save some easily scriptable changes like header/class renaming), the merging of QtMobility into Qt proper (probably irrelevant for most of KDE), and modularization (again, irrelevant from KDE's perspective when it comes to source compatibility and porting). There's also the switch to QtQuick2, which also is irrelevant to most of KDE. This is not going to be like the Qt3 - Qt4 transition which required major rewrites for consumers. In fact, those of us already working with Qt5 feel right at home. At least for me it doesn't feel any different than developing for Qt4. actually, Qt5 is irrelevant to most of the work that needs to be done in frameworks. we can, and are, working against Qt4 right now. most of the work is modularization and modernization (while preserving source compatibility) we are merging some things upstream into Qt5, and the things that are merged upstream are going into a small temporary library call libinqt (lib in qt ;). when Qt5 arrives, that library will go away and we will be able to move to basing frameworks on Qt5. between now and then there is a lot of work on the modularization and modernization work. That is in fact the major part of the frameworks effort, as I understand it. And it is important to identify, separate and port the things that should go from kdelibs into Qt5 *now*, as things that require BIC or even source changes need to be done before Qt's feature freeze, i.e. before 2012. If that deadline is missed, there won't be another opportunity for the lifetime of Qt5. Thus, the more people now helping with modularizing kdelibs and upstreaming whatever makes sense to upstream, the better. At least from the perspective of someone who would love to see useful KDE technologies as a part of the Qt framework, to easily use it even on platforms that still don't support KDE deployment easily :) for instance, Sune's proposal to improve KNotification requires absolutely nothing from Qt5. having that done before Qt5 arrives would actually be a bonus as we wouldn't have to juggle too many different kinds of changes at once. And the actual porting to Qt5 won't require much effort or time then, I'd expect. Maybe on the build system side, but certainly not on the code side. Even less so for the things sitting on top of Frameworks. BR, ~ Sput -- Manuel Sputnick Nickschas (Sput on Freenode) | (o Member of the Quassel IRC Project - http://quassel-irc.org| //\ Come visit us in #quassel!| V_/_
Re: Introducing components, how to
On Wednesday 09 November 2011, Ivan Čukić wrote: [Components-platform] name=touch something Sune just noted to me.. maybe an environment variable would be better to chose this? As on override? For that, I'd say +1, otherwise -1 :) i added KDE_PLASMA_COMPONENTS_PLATFORM and documented it on http://techbase.kde.org/KDE_System_Administration/Environment_Variables if set, it overrides the configuration value -- Marco Martin
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
2011/11/10 Aaron J. Seigo ase...@kde.org On Wednesday, November 9, 2011 23:44:21 Andrea Diamantini wrote: 4.x is where I'm living/fighting/coding/writing now. for apps and workspaces, that is perfect. we don't want to disrupt app and workspace development while we get kdelibs prepped for the next major release. I'm sorry to say, in my mind next version of kdelibs is 4.8. your mind is wrong. whatever the version number might end up saying (probably to keep packagers and users from confusion) it'll be the 4.7 code base with continued bug fixes applied :) And it will be based on the upcoming (not yet released) Qt 4.8. sure; but this is a non-relevant detail. Thinking about frameworks without having yet a decent idea of what will be Qt5 is impossible for me. actually, Qt5 is irrelevant to most of the work that needs to be done in frameworks. we can, and are, working against Qt4 right now. most of the work is modularization and modernization (while preserving source compatibility) Ok, stupid question then. Why aren't we releasing this as kdelibs 4.8? we are merging some things upstream into Qt5, and the things that are merged upstream are going into a small temporary library call libinqt (lib in qt ;). when Qt5 arrives, that library will go away and we will be able to move to basing frameworks on Qt5. between now and then there is a lot of work on the modularization and modernization work. for instance, Sune's proposal to improve KNotification requires absolutely nothing from Qt5. having that done before Qt5 arrives would actually be a bonus as we wouldn't have to juggle too many different kinds of changes at once. i do recognize that there is not enough documented plans and direction for frameworks 5. there are a handful of wiki pages but they do not contain enough information; too much of that still resides in the heads of just a few people. to help address that, i'm hosting an irc meeting in a couple weeks with people currently working on frameworks 5 with the aim of pulling together clearly documented goals, tasks and milestones. the date has not been fixed yet, once it is i will announce it here as well so interested parties can join. i hope that with further documentation and clairty of goals that others will be able to see how they can get involved with frameworks and why now is a good time to do so. I hope that, too :) -- 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: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
Am Thu, 10 Nov 2011 16:54:33 +0100 schrieb andrea diamantini adj...@gmail.com: 2011/11/10 Aaron J. Seigo ase...@kde.org actually, Qt5 is irrelevant to most of the work that needs to be done in frameworks. we can, and are, working against Qt4 right now. most of the work is modularization and modernization (while preserving source compatibility) Ok, stupid question then. Why aren't we releasing this as kdelibs 4.8? Stupidly assumed answer ABI Cheers, Thomas
Fwd: [Bug 286298] New: Please move ksecrets repo from kdereview to KDE Utils
FYI Original Message Subject: [Bug 286298] New: Please move ksecrets repo from kdereview to KDE Utils Date: Thu, 10 Nov 2011 20:46:40 + From: Valentin Rusu k...@rusu.info Reply-To: bug-cont...@bugs.kde.org To: k...@rusu.info https://bugs.kde.org/show_bug.cgi?id=286298 Summary: Please move ksecrets repo from kdereview to KDE Utils Product: sysadmin Version: unspecified Platform: unspecified OS/Version: All Status: NEW Severity: normal Priority: NOR Component: git AssignedTo: sysad...@kde.org ReportedBy: k...@rusu.info CC: tsdg...@terra.es, d...@vidsolbach.de, nicolas.alva...@gmail.com Hello, In preparation for the upcoming release, please move kdereview/ksecrets to kdeutil module Thanks, Valentin -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
Preparing to move ksecretsserviced to kde-runtime
Hello Olivier, Now that the KSecretsService API joined kdelibs, branch 4.7, I'm now preparing to move the ksecretsserviced from the playground to kde-runtime. The review request was posted several days ago @kde-core-devel. Cheers, -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
[discussion] KSecretsService API location
Hello, I just pushed the new API to kdelibs and kdepepo (Christoph Feck) has an IRC inquiry I find right. This new API's location was initially guided by the KWallet API location, that is kdeui. Is this location right ? It's easy for me to move it now, after next release (6 months) it will be more difficult. Possible locations might be: 1. kdelibs/kdecore/ksecretsservice 2. kdelibs/kutils/ksecretsservice Any thoughts? -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [discussion] KSecretsService API location
On Thursday 10 November 2011, Valentin Rusu wrote: Hello, I just pushed the new API to kdelibs and kdepepo (Christoph Feck) has an IRC inquiry I find right. This new API's location was initially guided by the KWallet API location, that is kdeui. Is this location right ? It's easy for me to move it now, after next release (6 months) it will be more difficult. Possible locations might be: 1. kdelibs/kdecore/ksecretsservice 2. kdelibs/kutils/ksecretsservice Any thoughts? It depends on its dependencies... ;-) So, does it depend on stuff from kdeui ? Alex
Re: [discussion] KSecretsService API location
On 11/10/2011 10:30 PM, Alexander Neundorf wrote: On Thursday 10 November 2011, Valentin Rusu wrote: Hello, I just pushed the new API to kdelibs and kdepepo (Christoph Feck) has an IRC inquiry I find right. This new API's location was initially guided by the KWallet API location, that is kdeui. Is this location right ? It's easy for me to move it now, after next release (6 months) it will be more difficult. Possible locations might be: 1. kdelibs/kdecore/ksecretsservice 2. kdelibs/kutils/ksecretsservice Any thoughts? It depends on its dependencies... ;-) So, does it depend on stuff from kdeui ? No dependency on kdeui. However, the daemon which this API calls over the dbus pops some password dialogs. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: Review Request: Make the tab group Xproperty accessable via NETWinInfo
On Nov. 10, 2011, 10:02 a.m., Martin Gräßlin wrote: I would like to see this in kdelibs 4.8. It is a rather minor change and should be fine for 4.7 as well. But I don't know what's the state for additions to kdelibs currently... Christoph Feck wrote: The freeze is today, which means it has to go in today. Aaron J. Seigo wrote: this is a new feature. it is not needed to address any functionality bugs. so it belongs in frameworks, not the KDE/4.7 branch. (and yes, i'm aware of the good things we can do with this feature in workspace code :) Anton Kreuzkamp wrote: That would mean, it'd have to wait for Frameworks5, right? Aaron J. Seigo wrote: it means you could add it to the frameworks branch right now, no particular need to wait from a devel perspective. we can create a branch in kde-workspace for freamworks work. something i need to do for libplasma2 porting anyways. Anton Kreuzkamp wrote: If I push it only to frameworks, it couldn't be used in Workspaces 4.8, could it? no; this is a price we pay for getting kdelibs ready for Qt5 without ending up in a tailspin/loop like we did with 4.0's effort. so a short term annoyance for a big mid-term gain. - Aaron J. --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103099/#review8082 --- On Nov. 9, 2011, 10:15 p.m., Anton Kreuzkamp wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103099/ --- (Updated Nov. 9, 2011, 10:15 p.m.) Review request for kdelibs and Martin Gräßlin. Description --- For KWin 4.8 Windows grouped using kwin's window tabbing feature, tell the world outside kwin in which group they are, using an XProperty. This patch makes this XProperty accessable via NETWinInfo. I hope it will be possible to integrate it into the 4.7 branch for KDE r4.8. Diffs - kdeui/windowmanagement/netwm.h c64a0a5 kdeui/windowmanagement/netwm.cpp cf28339 kdeui/windowmanagement/netwm_def.h 1482bca kdeui/windowmanagement/netwm_p.h d7f4599 Diff: http://git.reviewboard.kde.org/r/103099/diff/diff Testing --- Tested with the methods/signals, tabGroup() and windowChanged(). Everything I tested works. Thanks, Anton Kreuzkamp
Review Request: [kio_sftp] Implement SlaveBase::copy to make file upload/download faster
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103109/ --- Review request for KDE Runtime and Andreas Schneider. Description --- The attached patch: - Implements SlaveBase::copy so that copying to and from the local filesystem is optimized. This makes the common use case of uploading and downloading to and from the local file system much much faster. - Sends the correct mime-type information when download a file from remote server. Diffs - kioslave/sftp/kio_sftp.h c937e2e kioslave/sftp/kio_sftp.cpp adc918a kioslave/sftp/sftp.protocol 696647d Diff: http://git.reviewboard.kde.org/r/103109/diff/diff Testing --- - Upload a large file from local file system to sftp server, cancel while still in progress and redo the upload. - Download a large file from sftp server to file system, cancel while still in progress and redo the download. - Repeat steps #1 and #2 with a list of files instead of just one large file. - Repeat the above steps after disabling Mark partially uploaded files. Thanks, Dawit Alemayehu
[announce] KSecretsService into it's way to be released
Hello, Please be informed that KSecretsService components were included into the main repositories as follows: *kdelibs/kdeui/ksecretsservice* API intented for the applications. Will replace KWallet API. commit id before was 6b6af2d3889ecd53ce1aa1a00b1befcbc244610c *kdelibs/kdeui/util/kwallet.cpp Depending on configuration, it uses the new API to go through KSecretsService *kde-runtime* Received the ksecretsserviced code formerly in playground/ksecretservice/daemon Commit id before was 6b6af2d3889ecd53ce1aa1a00b1befcbc244610c *ksecrets* Pending move to kde-utils Contains some utilities related to KSecretsService I'll prepare more documentation on techbase and community for this. Looking forward for the bug reports :-) PS: youpi! -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [discussion] KSecretsService API location
On Thursday, 10 de November de 2011 22.30.18, Valentin Rusu wrote: Hello, I just pushed the new API to kdelibs and kdepepo (Christoph Feck) has an IRC inquiry I find right. This new API's location was initially guided by the KWallet API location, that is kdeui. Is this location right ? It's easy for me to move it now, after next release (6 months) it will be more difficult. Possible locations might be: 1. kdelibs/kdecore/ksecretsservice 2. kdelibs/kutils/ksecretsservice Put it somewhere outside of kdelibs. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: [announce] KSecretsService into it's way to be released
On Friday, 11 de November de 2011 00.26.23, Valentin Rusu wrote: Hello, Please be informed that KSecretsService components were included into the main repositories as follows: *kdelibs/kdeui/ksecretsservice* API intented for the applications. Will replace KWallet API. commit id before was Please undo this. See the discussion on kdelibs 4.8. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Request: remove libkactivites from kdelibs (in experimental/)
Aaron J. Seigo wrote: On Monday, November 7, 2011 16:35:57 Albert Astals Cid wrote: Maybe we should really resurrect the existence of a master 4.8? unecessary imho, and runs the extreme danger of repeating the 3-4 debacle with kdelibs where people just keep working on the stable release and don't care enough for the next important release of libs. You cannot really FORCE volunteers to work on what you want them to work on. Preventing them from working on what THEY want to work on will just lead to them moving their work elsewhere, e.g.: * separate git repositories (which in fact is exactly what you are doing with libkactivities! Talk about hypocrisy…), * distro patches (which you keep complaining about, yet it is exactly what the frozen master debacle is leading to), * maybe even an outright fork like Trinity (of KDE 3) or MATE (of GNOME 2). (But don't get me wrong, I'm NOT interested in keeping 4.x alive for ages, I'm just interested in 4.x NOW because 5.0 isn't anywhere near ready, even when we're just talking about the libraries/frameworks, let alone when we actually consider applications and/or workspaces building on the new libraries/frameworks. And I believe that most, if not all, people interested in 4.x work right now are in that boat, I doubt 4.x is going to suscite anywhere near the amount of long-term nostalgia 3.x did. We WILL eventually work on 5.x. Just not NOW.) In addition, this situation might actually push some contributors NOT to work with you on 5.0 material. I can tell you that your refusal to get my libplasma PackageKit work into 4.8 definitely did demotivate me from doing any work on the 5.0 version. So you achieve exactly the opposite of what you're trying to achieve. That said, considering the 4.8 release schedule, it is now really too late to reopen kdelibs 4.8 for feature development anyway. :-( It should have been done when I originally asked for it a month ago (or even better, it should never have been closed down in the first place!). Kevin Kofler
