Re: kde_file.h vs POSIX headers vs qplatformdefs.h
Le vendredi 9 août 2013 21:54:10 David Faure a écrit : On Thursday 08 August 2013 16:56:23 Aurélien Gâteau wrote: Hi, I started working on a kdelibs cleanup task: Make use of qplatformdefs.h definitions instead of using the POSIX versions directly. Partly revert that commit, that would port to QFile::Permissions: b03e81a61311ae1b64b0d37415477f9c08fe6142 I have a few questions however: 1. I am not exactly sure what partly revert that commit means. Port back from QFile::Permissions to mode_t given that mode_t is available in win32-msvc*/qplatformdefs.h (not everywhere, but in the places where the above commits did a half job at porting from mode_t to QFile::Permissions). QFile::Permissions is more limited (no suid bits) and having to convert between mode_t and QFile::Permissions is just extra work. The portability issue however is that S_ISDIR(mode) isn't provided on Windows, only (mode QT_STAT_DIR). Same for S_ISREG: mode QT_STAT_REG. OK, will do this then. Actually, I am wondering if porting to qplatformdefs is the highest priority: the fact we are using POSIX functions right now does not prevent splitting, does it? No splitting, no, but it prevents releasing if we use the wrong types in public headers (then we can't change that later on). Turns out mode_t is OK, but e.g. time_t isn't (hence the porting to QDateTime). Makes sense. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 112079: Add utility function to paint icon overlays
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112079/ --- Review request for KDE Frameworks. Description --- As this was rejected from QIcon, I decided to implement it in frameworks. The idea is new private icon engine (KOverlayIconEngine), which paints the overlays itself, and then an utility function in KIconUtils:: namespace, which takes the base icon and the overlay icons as parameters and constructs new QIcon using KOverlayIconEngine. As QPixmapIconEngine (QIcon default) is private in Qt and couldn't be simply extended, the KOverlayIconEngine simply forwards the calls to QIcon, which then forwards those calls internally to QPixmapIconEngine (QIcon is really mostly just a wrapper around an engine). There are two functions QIcon KIconUtils::kIconAddOverlay(const QIcon icon, const QIcon overlay, Qt::Corner position); and QIcon KIconUtils::kIconAddOverlay(const QIcon icon, QHashQt::Corner, QIcon overlays); The first one serves for single overlay icon, the second one is then for multiple overlays, requires the QHash to be built up before passing though. Diffs - staging/kguiaddons/src/CMakeLists.txt fc8941a staging/kguiaddons/src/util/qiconoverlay.h PRE-CREATION staging/kguiaddons/src/util/qiconoverlay.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112079/diff/ Testing --- I have a small testing app with 3 QLabels, testing both ::paint() and ::pixmap() methods, all works \o/ I'm thinking about bundling the app with kguiaddons and/or additionally creating a unittest for it (I have one for Qt already), but I'll do that later as I'm off to vacation and I'd like to get comments for the code. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Main Toolbar/Toolbar in QToolBar
On Tuesday 13 August 2013 15:33:59 Àlex Fiestas wrote: On Tuesday 13 August 2013 15:05:46 Christoph Feck wrote: On Tuesday 13 August 2013 14:00:37 Àlex Fiestas wrote: Effectively a Main Toolbar is usually a toolbar that is a child of QMainWindow while a ToolBar is a toolbar who's parent is another QWidget. A secondary toolbar is every toolbar not called the Main Toolbar. For example in Konqueror, the Extra Toolbar or Bookmark Toolbar. So they are also children of QMainWindow. Yes, that's why I said effectively Can't see the relation with the word effectively :-) , of course there are exceptions but we can't move all these logic to Qt. These aren't exceptions. The definition of Main Toolbar was that it's the first mainwindow toolbar. You can't call other-than-first exceptions, they are very valid toolbars, just not main :) Your code with a cast is wrong. Only one mainwindow toolbar is the main toolbar. The reason is that one might want large icons and text-under-icons to make the main toolbar very intuitive, but still if the app has 5 more toolbars, there's no room for such settings on the other toolbars, so they would be small icons only. A bit of an easy mode vs advanced mode split, in a way. Applications needing this, will continue using XML-GUI or implement the logic by hand, I don't think there is something we can add to Qt to make this easier. The logic can't be in QToolBar itself, indeed. Which leaves the following options: * style hints as you suggested * magic in kstyle (but not just a cast...) * XMLGUI itself could inject the settings into the toolbars, possibly. It already does to a large extent, maybe just not the defaults or something (didn't read that code in many years). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112037: Replace most instances of KFileDialog with QFileDialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112037/ --- (Updated Aug. 14, 2013, 12:20 p.m.) Review request for KDE Frameworks. Description --- KFileDialog is deprecated in favor of QFileDialog. The original intention was to completely replace the former with the latter and move KFileDialog to kde4support. kdelibs cleanup task: Move KFileDialog to kde4support once the QUrl static methods are in Qt (see the 5.1 epic) Unfortunately, it turned out that KEncodingFileDialog inherits from KFileDialog, and is still used in a bunch of places, making the complete removal of KFileDialog impractical. With this all uses of KFileDialog are removed, except for KEncodingFileDialog. Diffs (updated) - kfile/kdirselectdialog.cpp dcbcc4cf743bad17cfa520def611445ceb31eb21 kio/kfile/kfiledialog.h 216dcc8b41e3a9027b2a94b307d6c6374ee53c51 kio/kfile/kpropertiesdialog.cpp 995e962353a09e40f627f2db60ce831b46b6a414 kio/kfile/kurlrequester.h bb111271b6d6b7b1fd66a4b5f13d9f0aa499289f kio/kfile/kurlrequester.cpp 523ae7a3bec64a3d997a255899cb15a8fdc5689e kio/kfile/kurlrequesterdialog.h 2e515b23060748e632cc96eed4a2305f67ebb40e kio/kfile/kurlrequesterdialog.cpp b0afd16388dab56b0a1127dd6e8921476196f234 kio/kssl/kcm/cacertificatespage.cpp 8b35c2a73f0f2caa3e385568d32428fdbb00bba4 kparts/browserrun.cpp ff3a5fd1220cf0be3c8775cf97f204f3a26300d0 kross/ui/view.cpp 51f31c5bc247d385c685cf91a94c48a0ed855532 Diff: http://git.reviewboard.kde.org/r/112037/diff/ Testing --- Does not break any tests. Thanks, Teo Mrnjavac ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Requiring qtbase from a few days ago
Hi there everybody! Tomorrow (If nobody objects) I will push some changes that require this commit in qtbase: 0ace3112137b78cf7d150e9974e69ccfe6838533 The changes I will push are: https://git.reviewboard.kde.org/r/109527/ https://git.reviewboard.kde.org/r/109526/ And then Aleix will move kglobalsettings to kdesupport :) Cheers ! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Main Toolbar/Toolbar in QToolBar
On Wednesday 14 August 2013 13:58:44 you wrote: , of course there are exceptions but we can't move all these logic to Qt. These aren't exceptions. The definition of Main Toolbar was that it's the first mainwindow toolbar. You can't call other-than-first exceptions, they are very valid toolbars, just not main :) Your code with a cast is wrong. Only one mainwindow toolbar is the main toolbar. The reason is that one might want large icons and text-under-icons to make the main toolbar very intuitive, but still if the app has 5 more toolbars, there's no room for such settings on the other toolbars, so they would be small icons only. A bit of an easy mode vs advanced mode split, in a way. Applications needing this, will continue using XML-GUI or implement the logic by hand, I don't think there is something we can add to Qt to make this easier. The logic can't be in QToolBar itself, indeed. Which leaves the following options: * style hints as you suggested * magic in kstyle (but not just a cast...) * XMLGUI itself could inject the settings into the toolbars, possibly. It already does to a large extent, maybe just not the defaults or something (didn't read that code in many years). Yeah... apparently my assumption was wrong. So what we need is instead is a way of flagging/marking a QToolBar as a Main Toolbar so our Style can do its magic, no? Any idea of how to do this? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Main Toolbar/Toolbar in QToolBar
On Wednesday 14 August 2013 16:06:07 Àlex Fiestas wrote: On Wednesday 14 August 2013 13:58:44 you wrote: , of course there are exceptions but we can't move all these logic to Qt. These aren't exceptions. The definition of Main Toolbar was that it's the first mainwindow toolbar. You can't call other-than-first exceptions, they are very valid toolbars, just not main :) Your code with a cast is wrong. Only one mainwindow toolbar is the main toolbar. The reason is that one might want large icons and text-under-icons to make the main toolbar very intuitive, but still if the app has 5 more toolbars, there's no room for such settings on the other toolbars, so they would be small icons only. A bit of an easy mode vs advanced mode split, in a way. Applications needing this, will continue using XML-GUI or implement the logic by hand, I don't think there is something we can add to Qt to make this easier. The logic can't be in QToolBar itself, indeed. Which leaves the following options: * style hints as you suggested * magic in kstyle (but not just a cast...) * XMLGUI itself could inject the settings into the toolbars, possibly. It already does to a large extent, maybe just not the defaults or something (didn't read that code in many years). Yeah... apparently my assumption was wrong. So what we need is instead is a way of flagging/marking a QToolBar as a Main Toolbar so our Style can do its magic, no? Any idea of how to do this? Dynamic properties come to my mind. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Main Toolbar/Toolbar in QToolBar
Le mercredi 14 août 2013 16:06:07 Àlex Fiestas a écrit : On Wednesday 14 August 2013 13:58:44 you wrote: , of course there are exceptions but we can't move all these logic to Qt. These aren't exceptions. The definition of Main Toolbar was that it's the first mainwindow toolbar. You can't call other-than-first exceptions, they are very valid toolbars, just not main :) Your code with a cast is wrong. Only one mainwindow toolbar is the main toolbar. The reason is that one might want large icons and text-under-icons to make the main toolbar very intuitive, but still if the app has 5 more toolbars, there's no room for such settings on the other toolbars, so they would be small icons only. A bit of an easy mode vs advanced mode split, in a way. Applications needing this, will continue using XML-GUI or implement the logic by hand, I don't think there is something we can add to Qt to make this easier. The logic can't be in QToolBar itself, indeed. Which leaves the following options: * style hints as you suggested * magic in kstyle (but not just a cast...) * XMLGUI itself could inject the settings into the toolbars, possibly. It already does to a large extent, maybe just not the defaults or something (didn't read that code in many years). Yeah... apparently my assumption was wrong. So what we need is instead is a way of flagging/marking a QToolBar as a Main Toolbar so our Style can do its magic, no? A dynamic property would work, the question is which code would be responsible for setting it. KMainWindow and/or KXmlGuiWindow could do it, but that would keep the Qt vs KDE application distinction, since a QMainWindow based-app would not get it. On the other hand it prevents breaking Qt applications like Scribus, so maybe it's better this way. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112037: Replace most instances of KFileDialog with QFileDialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112037/#review37766 --- kio/kfile/kurlrequester.h http://git.reviewboard.kde.org/r/112037/#comment27969 Shouldn't it be filter? - Kevin Ottens On Aug. 14, 2013, 12:20 p.m., Teo Mrnjavac wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112037/ --- (Updated Aug. 14, 2013, 12:20 p.m.) Review request for KDE Frameworks. Description --- KFileDialog is deprecated in favor of QFileDialog. The original intention was to completely replace the former with the latter and move KFileDialog to kde4support. kdelibs cleanup task: Move KFileDialog to kde4support once the QUrl static methods are in Qt (see the 5.1 epic) Unfortunately, it turned out that KEncodingFileDialog inherits from KFileDialog, and is still used in a bunch of places, making the complete removal of KFileDialog impractical. With this all uses of KFileDialog are removed, except for KEncodingFileDialog. Diffs - kfile/kdirselectdialog.cpp dcbcc4cf743bad17cfa520def611445ceb31eb21 kio/kfile/kfiledialog.h 216dcc8b41e3a9027b2a94b307d6c6374ee53c51 kio/kfile/kpropertiesdialog.cpp 995e962353a09e40f627f2db60ce831b46b6a414 kio/kfile/kurlrequester.h bb111271b6d6b7b1fd66a4b5f13d9f0aa499289f kio/kfile/kurlrequester.cpp 523ae7a3bec64a3d997a255899cb15a8fdc5689e kio/kfile/kurlrequesterdialog.h 2e515b23060748e632cc96eed4a2305f67ebb40e kio/kfile/kurlrequesterdialog.cpp b0afd16388dab56b0a1127dd6e8921476196f234 kio/kssl/kcm/cacertificatespage.cpp 8b35c2a73f0f2caa3e385568d32428fdbb00bba4 kparts/browserrun.cpp ff3a5fd1220cf0be3c8775cf97f204f3a26300d0 kross/ui/view.cpp 51f31c5bc247d385c685cf91a94c48a0ed855532 Diff: http://git.reviewboard.kde.org/r/112037/diff/ Testing --- Does not break any tests. Thanks, Teo Mrnjavac ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112079: Add utility function to paint icon overlays
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112079/#review37765 --- staging/kguiaddons/src/util/qiconoverlay.h http://git.reviewboard.kde.org/r/112079/#comment27976 Since the methods are in a KIconUtils namespace, maybe their name can be simplified to addOverlay()? staging/kguiaddons/src/util/qiconoverlay.h http://git.reviewboard.kde.org/r/112079/#comment27975 The QHash should be passed as a const-ref staging/kguiaddons/src/util/qiconoverlay.cpp http://git.reviewboard.kde.org/r/112079/#comment27964 Qt doc says you should inherit from QIconEngineV2 instead staging/kguiaddons/src/util/qiconoverlay.cpp http://git.reviewboard.kde.org/r/112079/#comment27970 Maybe mark this method as Q_DECL_OVERRIDE now that we can use it? staging/kguiaddons/src/util/qiconoverlay.cpp http://git.reviewboard.kde.org/r/112079/#comment27971 Q_DECL_OVERRIDE as well if you change the class to inherit from QIconEngineV2 staging/kguiaddons/src/util/qiconoverlay.cpp http://git.reviewboard.kde.org/r/112079/#comment27965 Should be const staging/kguiaddons/src/util/qiconoverlay.cpp http://git.reviewboard.kde.org/r/112079/#comment27972 Q_DECL_OVERRIDE staging/kguiaddons/src/util/qiconoverlay.cpp http://git.reviewboard.kde.org/r/112079/#comment27973 Q_DECL_OVERRIDE staging/kguiaddons/src/util/qiconoverlay.cpp http://git.reviewboard.kde.org/r/112079/#comment27974 Q_DECL_OVERRIDE staging/kguiaddons/src/util/qiconoverlay.cpp http://git.reviewboard.kde.org/r/112079/#comment27967 Maybe prefix member vars with m_? (I think it is part of kdelibs coding style) staging/kguiaddons/src/util/qiconoverlay.cpp http://git.reviewboard.kde.org/r/112079/#comment27968 ditto - Aurélien Gâteau On Aug. 14, 2013, 12:49 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112079/ --- (Updated Aug. 14, 2013, 12:49 p.m.) Review request for KDE Frameworks. Description --- As this was rejected from QIcon, I decided to implement it in frameworks. The idea is new private icon engine (KOverlayIconEngine), which paints the overlays itself, and then an utility function in KIconUtils:: namespace, which takes the base icon and the overlay icons as parameters and constructs new QIcon using KOverlayIconEngine. As QPixmapIconEngine (QIcon default) is private in Qt and couldn't be simply extended, the KOverlayIconEngine simply forwards the calls to QIcon, which then forwards those calls internally to QPixmapIconEngine (QIcon is really mostly just a wrapper around an engine). There are two functions QIcon KIconUtils::kIconAddOverlay(const QIcon icon, const QIcon overlay, Qt::Corner position); and QIcon KIconUtils::kIconAddOverlay(const QIcon icon, QHashQt::Corner, QIcon overlays); The first one serves for single overlay icon, the second one is then for multiple overlays, requires the QHash to be built up before passing though. Diffs - staging/kguiaddons/src/CMakeLists.txt fc8941a staging/kguiaddons/src/util/qiconoverlay.h PRE-CREATION staging/kguiaddons/src/util/qiconoverlay.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112079/diff/ Testing --- I have a small testing app with 3 QLabels, testing both ::paint() and ::pixmap() methods, all works \o/ I'm thinking about bundling the app with kguiaddons and/or additionally creating a unittest for it (I have one for Qt already), but I'll do that later as I'm off to vacation and I'd like to get comments for the code. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Main Toolbar/Toolbar in QToolBar
On Wednesday 14 August 2013 16:45:50 Aurélien Gâteau wrote: Le mercredi 14 août 2013 16:06:07 Àlex Fiestas a écrit : On Wednesday 14 August 2013 13:58:44 you wrote: , of course there are exceptions but we can't move all these logic to Qt. These aren't exceptions. The definition of Main Toolbar was that it's the first mainwindow toolbar. You can't call other-than-first exceptions, they are very valid toolbars, just not main :) Your code with a cast is wrong. Only one mainwindow toolbar is the main toolbar. The reason is that one might want large icons and text-under-icons to make the main toolbar very intuitive, but still if the app has 5 more toolbars, there's no room for such settings on the other toolbars, so they would be small icons only. A bit of an easy mode vs advanced mode split, in a way. Applications needing this, will continue using XML-GUI or implement the logic by hand, I don't think there is something we can add to Qt to make this easier. The logic can't be in QToolBar itself, indeed. Which leaves the following options: * style hints as you suggested * magic in kstyle (but not just a cast...) * XMLGUI itself could inject the settings into the toolbars, possibly. It already does to a large extent, maybe just not the defaults or something (didn't read that code in many years). Yeah... apparently my assumption was wrong. So what we need is instead is a way of flagging/marking a QToolBar as a Main Toolbar so our Style can do its magic, no? A dynamic property would work, the question is which code would be responsible for setting it. KMainWindow and/or KXmlGuiWindow could do it, but that would keep the Qt vs KDE application distinction, since a QMainWindow based-app would not get it. On the other hand it prevents breaking Qt applications like Scribus, so maybe it's better this way. Note that anything which involves XmlGui doesn't cut it as... well... XmlGui contains KToolBar anyway. :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Main Toolbar/Toolbar in QToolBar
On Wednesday 14 August 2013 17:25:15 Kevin Ottens wrote: On Wednesday 14 August 2013 16:45:50 Aurélien Gâteau wrote: Le mercredi 14 août 2013 16:06:07 Àlex Fiestas a écrit : On Wednesday 14 August 2013 13:58:44 you wrote: , of course there are exceptions but we can't move all these logic to Qt. These aren't exceptions. The definition of Main Toolbar was that it's the first mainwindow toolbar. You can't call other-than-first exceptions, they are very valid toolbars, just not main :) Your code with a cast is wrong. Only one mainwindow toolbar is the main toolbar. The reason is that one might want large icons and text-under-icons to make the main toolbar very intuitive, but still if the app has 5 more toolbars, there's no room for such settings on the other toolbars, so they would be small icons only. A bit of an easy mode vs advanced mode split, in a way. Applications needing this, will continue using XML-GUI or implement the logic by hand, I don't think there is something we can add to Qt to make this easier. The logic can't be in QToolBar itself, indeed. Which leaves the following options: * style hints as you suggested * magic in kstyle (but not just a cast...) * XMLGUI itself could inject the settings into the toolbars, possibly. It already does to a large extent, maybe just not the defaults or something (didn't read that code in many years). Yeah... apparently my assumption was wrong. So what we need is instead is a way of flagging/marking a QToolBar as a Main Toolbar so our Style can do its magic, no? A dynamic property would work, the question is which code would be responsible for setting it. KMainWindow and/or KXmlGuiWindow could do it, but that would keep the Qt vs KDE application distinction, since a QMainWindow based-app would not get it. On the other hand it prevents breaking Qt applications like Scribus, so maybe it's better this way. Note that anything which involves XmlGui doesn't cut it as... well... XmlGui contains KToolBar anyway. :-) Actually makes me wonder what we're trying to solve... Let me try to summarize the situation for my own understanding (stop me where I'm wrong): * Current code uses KToolBar; * Code using KToolBar follow our settings properly (has access to all necessary dependencies); * Code using QToolBar doesn't follow our settings; * We can't force our settings on random QToolBar, but code using those is outside the port to KF5 code, that would be new code from our point of view; * In QToolBar using code, developers can choose to use Qt::ToolButtonFollowStyle so that the toolbar follow our settings properly (except for the main/regular toolbar distinction). Is it me or we just need a method in KWidgetsAddons to declare which toolbar of a window is the main one? That choice is obviously in the hands of the application developer, And that would be used only in new client code. All other toolbars to be considered regular ones. Alternatively to a dynamic property that could be a static property on QToolBar... but that requires patching Qt and I suspect it wouldn't go in. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Main Toolbar/Toolbar in QToolBar
So, after looking one last time into QWidget/QToolBar the only thing we can do is use dynamic properties so that's what I will do. Since using a dynamic Property is only a good enough solution, but not excellent I'm going to wait until tomorrow to implement this just in case somebody else comes up with a better solution. Cheers ! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112079: Add utility function to paint icon overlays
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112079/#review37774 --- Forgot one thing: file names should be renamed to not start with q. Maybe kiconoverlay.*? - Aurélien Gâteau On Aug. 14, 2013, 12:49 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112079/ --- (Updated Aug. 14, 2013, 12:49 p.m.) Review request for KDE Frameworks. Description --- As this was rejected from QIcon, I decided to implement it in frameworks. The idea is new private icon engine (KOverlayIconEngine), which paints the overlays itself, and then an utility function in KIconUtils:: namespace, which takes the base icon and the overlay icons as parameters and constructs new QIcon using KOverlayIconEngine. As QPixmapIconEngine (QIcon default) is private in Qt and couldn't be simply extended, the KOverlayIconEngine simply forwards the calls to QIcon, which then forwards those calls internally to QPixmapIconEngine (QIcon is really mostly just a wrapper around an engine). There are two functions QIcon KIconUtils::kIconAddOverlay(const QIcon icon, const QIcon overlay, Qt::Corner position); and QIcon KIconUtils::kIconAddOverlay(const QIcon icon, QHashQt::Corner, QIcon overlays); The first one serves for single overlay icon, the second one is then for multiple overlays, requires the QHash to be built up before passing though. Diffs - staging/kguiaddons/src/CMakeLists.txt fc8941a staging/kguiaddons/src/util/qiconoverlay.h PRE-CREATION staging/kguiaddons/src/util/qiconoverlay.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112079/diff/ Testing --- I have a small testing app with 3 QLabels, testing both ::paint() and ::pixmap() methods, all works \o/ I'm thinking about bundling the app with kguiaddons and/or additionally creating a unittest for it (I have one for Qt already), but I'll do that later as I'm off to vacation and I'd like to get comments for the code. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Main Toolbar/Toolbar in QToolBar
On Wednesday 14 August 2013 17:33:26 Kevin Ottens wrote: Is it me or we just need a method in KWidgetsAddons to declare which toolbar of a window is the main one? That choice is obviously in the hands of the application developer, And that would be used only in new client code. All other toolbars to be considered regular ones. Sounds good, with the assumption that XMLGUI would call this automatically, so for 99% of the KDE apps, nothing would change. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Main Toolbar/Toolbar in QToolBar
On Wednesday 14 August 2013 18:27:30 David Faure wrote: On Wednesday 14 August 2013 17:33:26 Kevin Ottens wrote: Is it me or we just need a method in KWidgetsAddons to declare which toolbar of a window is the main one? That choice is obviously in the hands of the application developer, And that would be used only in new client code. All other toolbars to be considered regular ones. Sounds good, with the assumption that XMLGUI would call this automatically, so for 99% of the KDE apps, nothing would change. So that, I will add the property plus the magic in KStyle/oxygenstyle/qpa and look into KWidgetsAddons to add api for it. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Requiring qtbase from a few days ago
El Dimecres, 14 d'agost de 2013, a les 05:54:36, Àlex Fiestas va escriure: Hi there everybody! Tomorrow (If nobody objects) I will push some changes that require this commit in qtbase: 0ace3112137b78cf7d150e9974e69ccfe6838533 The changes I will push are: https://git.reviewboard.kde.org/r/109527/ https://git.reviewboard.kde.org/r/109526/ And then Aleix will move kglobalsettings to kdesupport :) Isn't the rule to just require stuff that is part of qt5.git ? Cheers, Albert Cheers ! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Requiring qtbase from a few days ago
On Wednesday 14 August 2013 22:51:18 Albert Astals Cid wrote: El Dimecres, 14 d'agost de 2013, a les 05:54:36, Àlex Fiestas va escriure: Tomorrow (If nobody objects) I will push some changes that require this commit in qtbase: 0ace3112137b78cf7d150e9974e69ccfe6838533 The changes I will push are: https://git.reviewboard.kde.org/r/109527/ https://git.reviewboard.kde.org/r/109526/ And then Aleix will move kglobalsettings to kdesupport :) Isn't the rule to just require stuff that is part of qt5.git ? Yes, but it just got in recently so we try to give a bit of time to people so they can catch up and upgrade their qt5 first. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 109527: Use QStyle::styleHint(SH_Widget_Animate) instead of KGlobalSettings::graphicEffectLevel
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109527/#review37815 --- Shouldn't most if not all the files where you removed the KGlobalSettings use also have the #include directive for the class removed? I see surprisingly none of that. staging/kde4support/src/kdeui/kfadewidgeteffect.cpp http://git.reviewboard.kde.org/r/109527/#comment27999 No need to touch kde4support, kglobalsettings will move there anyway. - Kevin Ottens On Aug. 13, 2013, 6:33 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109527/ --- (Updated Aug. 13, 2013, 6:33 p.m.) Review request for KDE Frameworks. Description --- Port to the incoming (hopefully) styleHint SH_Widget_Animate Diffs - kio/kfile/kimagefilepreview.cpp a9f3e61 kio/kio/kfileitemdelegate.cpp e0c7d7e staging/kcompletion/src/klineedit_p.h e318009 staging/kde4support/src/kdeui/kfadewidgeteffect.cpp e182a1b staging/xmlgui/src/kmainwindow.cpp 2125d84 tier1/kwidgetsaddons/src/kmessagewidget.cpp a4f9975 Diff: http://git.reviewboard.kde.org/r/109527/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 109526: Implement SH_Widget_Animate in KStyle
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109526/#review37816 --- Ship it! Ship It! - Kevin Ottens On Aug. 13, 2013, 6:07 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109526/ --- (Updated Aug. 13, 2013, 6:07 p.m.) Review request for KDE Frameworks. Description --- Implement SH_Widget_Animate in KStyle using the configuration we already have in kdeglobal. I have NOT implemented detailed information about animations because after all this year only NoEffect and SimpleAnimation are used (kglobalsettings.cpp GraphicEffect), so what we want is a YES or NO instead of how much animation is required. There is NO use of GradientEffects or ComplexAnimationEffects in all kdelibs or kde (grepped 204 repositories in KDE) Review depends on: https://codereview.qt-project.org/#change,51166 Diffs - staging/frameworkintegration/src/kstyle/kstyle.cpp 375bcac Diff: http://git.reviewboard.kde.org/r/109526/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
