Review Request: KMessageWidget: Adapt height to text changes
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101272/ --- Review request for kdelibs and Aurélien Gâteau. Summary --- When there is a long or wrapping text, the text is cut off. This patch fixes that. Diffs - kdeui/widgets/kmessagewidget.cpp 212ea0d Diff: http://git.reviewboard.kde.org/r/101272/diff Testing --- Screenshots --- http://git.reviewboard.kde.org/r/101272/s/154/ http://git.reviewboard.kde.org/r/101272/s/155/ Thanks, Matthias
Re: Season of KDE project on speed optimization
On Friday, April 29, 2011 14:55:01 Markus Slopianka wrote: Am Freitag 29 April 2011, 12:52:18 schrieb Lydia Pintscher: Aaditya applied for a Season of KDE slot. He wants to work on speed optimization. Do we have a nice project for him? Depends what he finds slow. A possibility would be to either help the Platform modulation effort to cut down dependencies (if helping hands are still needed there). Another could be to reduce the number of dependencies that are loaded during startup (if he finds startup slow). A third possibility would be to utilize kdelibs-mobile for desktop use and maybe work downstream in OBS to offer a SC based on kdelibs-mobile. Profiles are not meant to be used that way. They're cutting out features that might already be on a given platform or don't make sense for mobile and embedded use cases at all, but these features are still needed by many applications. There is no magic silver bullet :) That said, I think startup performance would be a very nice project, with high impact. The way to go here would to use bootchart and a profiler to find out where most of the time is spent, and then making that code faster. Should be quite fun :) Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: saving/restoring session in kded module
On Friday 29 April 2011, Andriy Rysin wrote: Well saving layouts is most useful if the switcher is in per-application mode (I guess even more when in per window but hat mode currently can't save layouts as it uses wid for the key which is transient). If you restore your session (and thus windows) it makes sense to remember which layouts they had. But if you prefer to start with a clean sheet (empty session) then saving layouts may be a bit too imposing on the user. OK, your kded module is a bit special since it's related to the windows opened by other applications. So I can see the sense in restoring settings only when the session should be restored. But I think this is really specific to keyboard layout switcher, I can't see how this would ever apply to another kded module. For this reason I don't think this belongs in KDEDModule. Although one may argue that in per-application mode you always prefer same layout for particular app irregardless whether you restore your windows/apps or not. Yeah, there's that too :) On the implementation side if we don't honor the restore session option then new methods in KDEDModule won't add much - you can just save in destructor and restore in constructor. Well, developers of kded module won't understand the difference and will just use this for saving settings, if they see these methods, while in fact in most cases a simple KConfig would be simpler/better. getSessionStoreDir() might be useful in any case though. I can't see how. E.g. the cookierserver kded module should save into its kconfig file (say kcookiejarrc), not into a window-manager session file. Same for the SSL certificates module, same for the password server, the timezone module, and so on. They are all about data, not about adding information to windows from other processes, which is the only case where restore windows from last session matters. = AFAICS these methods are useful for only one module, and in addition their implementation is... well, there's no better solution but it looks ugly, so I'd rather not generalize the use of this, unless it's really needed. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
Re: Review kdelibs whiting/fixQByteArrays
Em Monday, 2 de May de 2011, às 14:59:02, David Faure escreveu: +[...] XInternAtom( disp, QByteArray( QByteArray( msg_type_P ) + _BEGIN ) ); Ah it's because XInternAtom takes a const char*, so in theory this should even be QByteArray( QByteArray( msg_type_P ) + _BEGIN ).constData() You can also write: (QByteArray( msg_type_P ) + _BEGIN).constData(); ... Another one: - envs QString::fromLatin1( QByteArray(DISPLAY=) + dpystring ); +envs QString::fromLatin1( QByteArray(QByteArray(DISPLAY=) + dpystring) ); Same: QString::fromLatin1((QByteArray(DISPLAY=) + dpystring).constData()); This will make one copy less. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
QPixmap::handle(): Pixmap is not an X11 class pixmap
since updating to kubuntu 11.04 I am getting this message while KApplication is created, but only if I use raster or opengl as graphics system: kpat --graphicssystem raster QPixmap::handle(): Pixmap is not an X11 class pixmap this seems to happen with all KDE programs. Any idea? kdelibs 4.6.2 qt 4.7.2 -- Wolfgang
Re: QPixmap::handle(): Pixmap is not an X11 class pixmap
On Monday 02 May 2011 16:15:42 Wolfgang Rohdewald wrote: since updating to kubuntu 11.04 I am getting this message while KApplication is created, but only if I use raster or opengl as graphics system: kpat --graphicssystem raster QPixmap::handle(): Pixmap is not an X11 class pixmap this seems to happen with all KDE programs. Any idea? kdelibs 4.6.2 qt 4.7.2 I remember a recent discussion in #qt-labs about this, and I think it has already been fixed in Qt 4.8 branch. The issue, if I understood the discussion correctly, is that even while you are setting a non X11 backend, it is still possible for applications to create an X11 native QPixmap via the fromX11Pixmap() function, but the checks in Qt forgot that case. Those checks were added to make sure applications don't try to access the underlying X11 pixmap so that changing the default backend to raster (or opengl) is possible for a future version of Qt. In other words, you likely don't need to worry about that warning, unless your application breaks because of it. On the other hand, I am highly interested why kpat tries to use X11 pixmaps at all. Adding kde-games-devel. Christoph Feck (kdepepo)
Re: QPixmap::handle(): Pixmap is not an X11 class pixmap
Le 05/02/2011 04:33 PM, Christoph Feck a écrit : On Monday 02 May 2011 16:15:42 Wolfgang Rohdewald wrote: since updating to kubuntu 11.04 I am getting this message while KApplication is created, but only if I use raster or opengl as graphics system: kpat --graphicssystem raster QPixmap::handle(): Pixmap is not an X11 class pixmap this seems to happen with all KDE programs. Any idea? kdelibs 4.6.2 qt 4.7.2 What's the widget style you are using ? I remember a recent discussion in #qt-labs about this, and I think it has already been fixed in Qt 4.8 branch. The issue, if I understood the discussion correctly, is that even while you are setting a non X11 backend, it is still possible for applications to create an X11 native QPixmap via the fromX11Pixmap() function, but the checks in Qt forgot that case. Those checks were added to make sure applications don't try to access the underlying X11 pixmap so that changing the default backend to raster (or opengl) is possible for a future version of Qt. In other words, you likely don't need to worry about that warning, unless your application breaks because of it. On the other hand, I am highly interested why kpat tries to use X11 pixmaps at all. Adding kde-games-devel. Christoph Feck (kdepepo)
Re: QPixmap::handle(): Pixmap is not an X11 class pixmap
Em Monday, 2 de May de 2011, às 16:15:42, Wolfgang Rohdewald escreveu: since updating to kubuntu 11.04 I am getting this message while KApplication is created, but only if I use raster or opengl as graphics system: kpat --graphicssystem raster QPixmap::handle(): Pixmap is not an X11 class pixmap this seems to happen with all KDE programs. Any idea? It's caused by your using of the raster graphics system. The warning was removed in Qt 4.8. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Review kdelibs whiting/fixQByteArrays
Le Monday 02 May 2011, David Faure a écrit : Another one: - envs QString::fromLatin1( QByteArray(DISPLAY=) + dpystring ); +envs QString::fromLatin1( QByteArray(QByteArray(DISPLAY=) + dpystring) ); Should be QLatin1String(DISPLAY=) + QLatin1String(dpystring) (Assuming dpystring is char*) Is this still because QString::fromLatin1( const QByteArray ) is missing, so it has to cast to const char* here too? Olivier, wouldn't it make sense to have such an overload? (It would save a strlen, too). Yes, maybe QString::fromLatin1(const QByteArray) would make sens But it might brake source compatibility if the call becomes ambiguous. The reason why we brake source compatibility with QT_USE_FAST_OPERATOR_PLUS is because this one was not documented. But maybe the new operator should only be enabled if QT_USE_FAST_OPERATOR_PLUS is defined to 2 or something.
Re: Review Request: Add KMessageWidget, an alternative to KMessageBox
On May 1, 2011, 10:14 a.m., Hugo Pereira Da Costa wrote: Hello Aurelien, Though I have nothing to say against the current design of your kmessagebox widget, something I miss in your implementation is the possibility for a widget style to override/replace your rendering. I can indeed imagine some styles (not oxygen though) for which your design might not integrate that well, notably skulpture for which all widgets have square corners, that won't match your nice rounded one. There is a mechanism to register custom style primitives that widget styles may or may not support, and for your custom widget to test whether the style supports the new primitive or not, allowing it to fallback to its own rendering, when not supported. I think it would be nice for your widget (and other 'custom' widgets that you'd plan to implement) to use this mechanism, for better future integration. kdeui/kdelibs/kcapacitybar implements this mechanism (the widget appears in the statusbar of dolphin to give the available space on a given device), and oxygen (as well as bespin) actually uses it to render the capacity bar as a regular progress bar, instead of the default implementation (which you can see by using any style but oxygen, or bespin, e.g. plastique). Tell me that you think, and also if needed I can help implementing if you agree with the above but are short of time to work on it. Cheers, Hugo Aaron J. Seigo wrote: note that this widget exposes a bug in oxygen style where when fading between two strings in a QLabel, the background is not updated. so when the text changes as well as the background color, the old background color remains. this is easily seen if you run kmessagewidgetdemo from kdeexamples/kmessagewidget/ and switch between the Information and Positive messages. Hugo Pereira Da Costa wrote: Thanks Aaron. Its now fixed (in a temporary way) in trunk. Note: I've been planing to re-implement the label text transition for a looong time now, in a much more robust way, to avoid these kind of issues -that occur elsewhere in kde- ... But have not found time so far :( Aurélien Gâteau wrote: @Hugo: Interesting, I didn't know about this mechanism. I will be quite busy for the upcoming two weeks so if you feel like implementing it, feel free to (btw: I don't get the nice capacity bar in Dolphin anymore, just a progress bar, is it normal?) @Aaron: I was able to reproduce this bug for a while when the content widget was hidden away by moving it (0, content-height()). Strangely enough changing the code to move it to (0, -content-height()) fixed it for me. Aurélien: btw: I don't get the nice capacity bar in Dolphin anymore, just a progress bar, is it normal? Yes its normal. Its precisely what the styling mechanism allowed us to do. We (that is: Nuno, I, and some others) felt that the default implementation provided by Dolphin, although nice, had some polishing issues, and did not integrate well with Oxygen, so we re-implemented it in oxygen, and after some more discussion with Nuno, we figured that rather than implementing a new UI element with different rendering for just this purpose, we'd better just reuse the progress bar element, which which achieves just the same goal. - Hugo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101249/#review3002 --- On April 30, 2011, 1:10 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101249/ --- (Updated April 30, 2011, 1:10 p.m.) Review request for kdelibs. Summary --- KMessageWidget is a new widget which can be considered as a less intrusive alternative for KMessageBox. It was designed during KDE UX sprint 2011 ( http://community.kde.org/Sprints/UX2011/KMessageWidget ). The class documentation should make it clear how and when it can be used. This widget could be used by: - Browsers to implement their remember password widgets (Konqueror, Rekonq...) - Forms to provide feedback on validation errors - Bluedevil KCM to replace its custom No Bluetooth adapter have been found message widget - Nepomuk/Strigi KCM to indicate status of their services - Gwenview to replace its custom save bar - ... I still have a few additions in mind for the API but it is already usable and since we are freezing I think it can be merged in master in its current state. I assume it will still be possible to extend the API a bit before kdelibs 4.7 freezes for good. I also wrote an example program in the kdeexample repository (
Re: Season of KDE project on speed optimization
On Mon, May 2, 2011 at 1:39 PM, Sebastian Kügler se...@kde.org wrote: On Friday, April 29, 2011 14:55:01 Markus Slopianka wrote: Am Freitag 29 April 2011, 12:52:18 schrieb Lydia Pintscher: Aaditya applied for a Season of KDE slot. He wants to work on speed optimization. Do we have a nice project for him? Depends what he finds slow. A possibility would be to either help the Platform modulation effort to cut down dependencies (if helping hands are still needed there). Another could be to reduce the number of dependencies that are loaded during startup (if he finds startup slow). A third possibility would be to utilize kdelibs-mobile for desktop use and maybe work downstream in OBS to offer a SC based on kdelibs-mobile. Profiles are not meant to be used that way. They're cutting out features that might already be on a given platform or don't make sense for mobile and embedded use cases at all, but these features are still needed by many applications. There is no magic silver bullet :) That said, I think startup performance would be a very nice project, with high impact. The way to go here would to use bootchart and a profiler to find out where most of the time is spent, and then making that code faster. Should be quite fun :) Cheers, -- sebas Note, that some work on this was done last Season of KDE (http://dot.kde.org/2010/12/29/season-kde-2010) by Yuvraj Tomar. It would be worth trying to build upon whatever he did, so that we're not duplicating work. Especially if he has written any useful profiling tools. David Edmundson http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-soc-mentor mailing list kde-soc-men...@kde.org https://mail.kde.org/mailman/listinfo/kde-soc-mentor
Re: Review Request: KMessageWidget: Adapt height to text changes
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101272/#review3074 --- kdeui/widgets/kmessagewidget.cpp http://git.reviewboard.kde.org/r/101272/#comment2623 Some extra checks needed here. Sometimes I am getting this warning: QWidget::setMinimumSize: Negative sizes (0,-1) are not possible QWidget::setMaximumSize: Negative sizes (16777215,-1) are not possible - Jarosław On May 2, 2011, 12:35 p.m., Matthias Fuchs wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101272/ --- (Updated May 2, 2011, 12:35 p.m.) Review request for kdelibs and Aurélien Gâteau. Summary --- When there is a long or wrapping text, the text is cut off. This patch fixes that. Diffs - kdeui/widgets/kmessagewidget.cpp 212ea0d Diff: http://git.reviewboard.kde.org/r/101272/diff Testing --- Screenshots --- http://git.reviewboard.kde.org/r/101272/s/154/ http://git.reviewboard.kde.org/r/101272/s/155/ Thanks, Matthias
Re: Review Request: Fix compile of KIO with KDE_ENABLE_FINAL enabled.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101277/#review3075 --- Looks ok I think. Alex - Alexander On May 2, 2011, 7:26 p.m., Nicolas Alvarez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101277/ --- (Updated May 2, 2011, 7:26 p.m.) Review request for kdelibs. Summary --- kdelibs compilation is broken with KDE4_ENABLE_FINAL turned ON. The first problem is in kio, where there's two file-static functions with the same name (isLocalRequest) and slightly different code. This patch fixes kio compilation by moving the two isLocalRequest functions into the corresponding private classes. Diffs - kio/kio/accessmanager.cpp 03b75898b0fcc6b47518fde8a8b3afc23a1a677f kio/kio/accessmanagerreply_p.h 408b5331c999633f4f5d603a70cb419678249a7e kio/kio/accessmanagerreply_p.cpp ccc7474799734b91112d70dc81945b8fe9b9f96c Diff: http://git.reviewboard.kde.org/r/101277/diff Testing --- Compilation of kdelibs/kio with and without final. Didn't try installing or running. Other parts of kdelibs still don't work with final. Thanks, Nicolas
Re: Review Request: Fix compile of KIO with KDE_ENABLE_FINAL enabled.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101277/#review3076 --- Instead of doing all that, please rename the local static function in accessmanagerreply_p.cpp to isLocalResource(...) and be done with it. kio/kio/accessmanager.cpp http://git.reviewboard.kde.org/r/101277/#comment2624 Can you also remove this trailing space while you are at it ? Thanks. - Dawit On May 2, 2011, 7:26 p.m., Nicolas Alvarez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101277/ --- (Updated May 2, 2011, 7:26 p.m.) Review request for kdelibs. Summary --- kdelibs compilation is broken with KDE4_ENABLE_FINAL turned ON. The first problem is in kio, where there's two file-static functions with the same name (isLocalRequest) and slightly different code. This patch fixes kio compilation by moving the two isLocalRequest functions into the corresponding private classes. Diffs - kio/kio/accessmanager.cpp 03b75898b0fcc6b47518fde8a8b3afc23a1a677f kio/kio/accessmanagerreply_p.h 408b5331c999633f4f5d603a70cb419678249a7e kio/kio/accessmanagerreply_p.cpp ccc7474799734b91112d70dc81945b8fe9b9f96c Diff: http://git.reviewboard.kde.org/r/101277/diff Testing --- Compilation of kdelibs/kio with and without final. Didn't try installing or running. Other parts of kdelibs still don't work with final. Thanks, Nicolas
Re: Review Request: Fix compile of KIO with KDE_ENABLE_FINAL enabled.
On May 2, 2011, 8:26 p.m., Dawit Alemayehu wrote: Instead of doing all that, please rename the local static function in accessmanagerreply_p.cpp to isLocalResource(...) and be done with it. So the one checking for scheme==data should remain isLocalRequest, and the one not checking for data should be isLocalResource? I don't really understand those names; maybe the functions need doxygen even if they're static :) - Nicolas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101277/#review3076 --- On May 2, 2011, 7:26 p.m., Nicolas Alvarez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101277/ --- (Updated May 2, 2011, 7:26 p.m.) Review request for kdelibs. Summary --- kdelibs compilation is broken with KDE4_ENABLE_FINAL turned ON. The first problem is in kio, where there's two file-static functions with the same name (isLocalRequest) and slightly different code. This patch fixes kio compilation by moving the two isLocalRequest functions into the corresponding private classes. Diffs - kio/kio/accessmanager.cpp 03b75898b0fcc6b47518fde8a8b3afc23a1a677f kio/kio/accessmanagerreply_p.h 408b5331c999633f4f5d603a70cb419678249a7e kio/kio/accessmanagerreply_p.cpp ccc7474799734b91112d70dc81945b8fe9b9f96c Diff: http://git.reviewboard.kde.org/r/101277/diff Testing --- Compilation of kdelibs/kio with and without final. Didn't try installing or running. Other parts of kdelibs still don't work with final. Thanks, Nicolas
Re: Review Request: Fix compile of KIO with KDE_ENABLE_FINAL enabled.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101277/ --- (Updated May 2, 2011, 9:34 p.m.) Review request for kdelibs. Changes --- Rewrite according to Dawit's suggestion. Summary (updated) --- kdelibs compilation is broken with KDE4_ENABLE_FINAL turned ON. The first problem is in kio, where there's two file-static functions with the same name (isLocalRequest) and slightly different code. Fixed by renaming one of the functions. Diffs (updated) - kio/kio/accessmanagerreply_p.cpp ccc7474799734b91112d70dc81945b8fe9b9f96c Diff: http://git.reviewboard.kde.org/r/101277/diff Testing --- Compilation of kdelibs/kio with and without final. Didn't try installing or running. Other parts of kdelibs still don't work with final. Thanks, Nicolas
