Re: Replacement for KMimeType::isBinaryData?
On Wednesday 29 October 2014 00:30:04 Kevin Funk wrote: Heya, I didn't find a suitable replacement for KMimeType::isBinaryData in KF5. Is there some? http://lxr.kde.org/ident?v=kf5-qt5_i=isBinaryData_remember=1 shows exactly two users of this function. Worth considering upstreaming to Qt? Well, you tell me :) Upstreaming requires providing use cases for it, so tell me what your use case is. Looking at the implementation of the function, I fear that it is hard to prove that it's correct and useful. It only checks the first 32 bytes of the file, so it's not like this could become a QByteArray method as I first thought when you talked about upstreaming it (e.g. QByteArray::isText(), isPrintable() or isBinaryData()) It would have to stay file-specific, i.e. in QMimeType. Then, there are non-printable characters outside of the 0-31 range, so this method is rather isBinaryData - true means it is, false means we don't know, maybe it is. That makes me uneasy about the usefulness of the method. It is there because XDG shared-mime-info specifies this is what we should fallback to, in the absence of a known extension or a known file content, to choose between a fallback to text/plain and a fallback to application/octet- stream, but it's really an imperfect heuristic. I'm not sure we want more code depending on that imperfect heuristic, by making it public API again. Which goes back to -- what's your use case for it :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Compile KF5 into Docker
Hi, as you know, building KF5 from source may not be an easy task, due to build dependencies which may or may not be available for your distro. That's why I started to compile KF5 into a Docker container. This way you can keep your main system clean, and avoid to install a lot of *-dev packages. I would like to share a set of Dockerfiles which will build an image with all the necessary build dependencies already installed. Also, it may be easier for newcomers to compile KF5 using this system, and to start contributing more easily. Here is the repo : https://github.com/Mathux/docker-kdesrc-build Thanks ! Regards. -- Mathieu Tarral ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121792: Make KAboutData::setupCommandLine call addHelpOption and addVersionOption
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121792/ --- (Updated gen. 4, 2015, 11:43 a.m.) Review request for KDE Frameworks. Changes --- Fine tune docu Repository: kcoreaddons Description --- It's something we used to do somewhere in kdelibs4 so people don't expect them to have to call this stuff manually. Also gives us some consistency. Diffs (updated) - src/lib/kaboutdata.h 5564dab src/lib/kaboutdata.cpp f8d5e30 Diff: https://git.reviewboard.kde.org/r/121792/diff/ Testing --- Ran one of my apps, now i have help and version. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121792: Make KAboutData::setupCommandLine call addHelpOption and addVersionOption
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121792/#review73061 --- Ship it! Ship It! - David Faure On Jan. 4, 2015, 11:43 a.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121792/ --- (Updated Jan. 4, 2015, 11:43 a.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- It's something we used to do somewhere in kdelibs4 so people don't expect them to have to call this stuff manually. Also gives us some consistency. Diffs - src/lib/kaboutdata.h 5564dab src/lib/kaboutdata.cpp f8d5e30 Diff: https://git.reviewboard.kde.org/r/121792/diff/ Testing --- Ran one of my apps, now i have help and version. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Why so many QStyles
On Thursday 02 October 2014 22:10:05 Hugo Pereira Da Costa wrote: In Qt5 this seems not to be true anymore and I've seen up to 6 QStyle running concurently for a single Kate Window, increasing to 13 when opening 'open file' dialog, decreasing back to 6 when closing it, etc. Is this a known feature ? Will this stay ? I'm surprised that nobody has thought of running the app in gdb and putting a breakpoint on the QStyle constructor, to answer these questions with actual facts. So here I come. gdb kate start b 'QStyle::QStyle' c 1) first QStyle is created by the QApp initialization. 2) second QStyle is KLineEditStyle, a proxy style used by KLineEdit But I suppose your question is about OxygenStyle instances, not other styles, right? Ah, but then 3) the first time the lineedit calls style(), qproxystyle.cpp does 100│ if (!baseStyle) // Use application desktop style 101├baseStyle = QStyleFactory::create(QApplicationPrivate::desktopStyleKey()); So it creates another instance of the main widget style (e.g. oxygen or breeze), as the base style for the proxy. BTW the code in Qt4 is the same, it's just that KLineEdit wasn't using QProxyStyle but rather KdeUiProxyStyle. This patch for kcompletion.git works around the issue by setting the base style for the proxystyle to be the existing app style, rather than creating a new one. diff --git a/src/klineedit_p.h b/src/klineedit_p.h index 0be32ba..cf63e09 100644 --- a/src/klineedit_p.h +++ b/src/klineedit_p.h @@ -29,6 +29,7 @@ #include QPropertyAnimation #include QIcon #include QProxyStyle +#include QApplication class KCompletionBox; class LineEditUrlDropEventFilter; @@ -186,7 +187,7 @@ class KLineEditStyle : public QProxyStyle Q_OBJECT public: KLineEditStyle(QStyle *style) -: QProxyStyle(), +: QProxyStyle(qApp-style()), m_overlap(0), m_subStyle(style), m_sentinel(false) This leads me to the following thoughts: 1) I'm not sure why QProxyStyle defaults to creating another instance of the app style rather than using the existing one. Maybe J-P Nurmi knows? Cc'ed. 2) I can't think of a reason against passing qApp-style() to the KLineEditStyle ctor; the rest of the code in QProxyStyle::ensureBaseStyle is about the -style cmdline override (which qApp-style() honours too). 3) In any case, Qt creates multiple instances of widget styles, AFAICS, in many places. So yes, your style should be ready for that. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Friday 19 December 2014 17:46:07 šumski wrote: On Thursday 18 of December 2014 20:15:52 Martin Klapetek wrote: On Wed, Dec 17, 2014 at 9:11 PM, šumski hrvoje.sen...@gmail.com wrote: Hi, i've checked your clone, and what new requirements will that bring, and if the CMakeLists there are accurate, that will create a problem. We will have a dependency circle between kglobalaccel, kinit, kio and kxmlgui. Bah, I think you're correct. Basically the only link in this dep circle is KBookmarks using KActionCollection from xmlgui if I'm reading it correctly. If this is removed, then I think the circle would be gone. KIO requires both KBookmarks and KXMLGui, so i am not sure how changing something in KBookmarks only would change the cycle... One possible solution, but no idea would that be OK, is to make the kglobalaccel 'regular' executable, instead of a kdeinit one... That's definitely an option, it only makes a difference in terms of startup time, for one daemon we can do without the kdeinit optimization, if it solves a circular dependency. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : kcoreaddons_master_qt5 #189
See http://build.kde.org/job/kcoreaddons_master_qt5/189/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Why so many QStyles
On Sunday 04 January 2015 13:51:15 David Faure wrote: 2) I can't think of a reason against passing qApp-style() to the KLineEditStyle ctor; the rest of the code in QProxyStyle::ensureBaseStyle is about the -style cmdline override (which qApp-style() honours too). More testing gives a very good reason against doing that... Ownership of style is transferred to QProxyStyle. ==2384==at 0x4C2A601: operator delete(void*) (vg_replace_malloc.c:510) ==2384==by 0x1E07D5DB: Breeze::Style::~Style() (breezestyle.cpp:200) ==2384==by 0xC6335BB: QObjectPrivate::deleteChildren() (qobject.cpp:1935) ==2384==by 0xC631CF7: QObject::~QObject() (qobject.cpp:1028) ==2384==by 0xB3092BF: QStyle::~QStyle() (qstyle.cpp:420) ==2384==by 0xB315CDD: QCommonStyle::~QCommonStyle() (qcommonstyle.cpp:131) ==2384==by 0xB34563F: QProxyStyle::~QProxyStyle() (qproxystyle.cpp:151) ==2384==by 0x7FF262F: KLineEditStyle::~KLineEditStyle() (in /d/kde/inst/kde_frameworks/lib64/libKF5Completion.so.5.6.0) ==2384==by 0x7FF265F: KLineEditStyle::~KLineEditStyle() (klineedit_p.h:185) ==2384==by 0x7FE768F: KLineEditPrivate::~KLineEditPrivate() (klineedit.cpp:51) ==2384==by 0x7FF19FA: QScopedPointerDeleterKLineEditPrivate::cleanup(KLineEditPrivate*) (qscopedpointer.h:62) ==2384==by 0x7FF12A2: QScopedPointerKLineEditPrivate, QScopedPointerDeleterKLineEditPrivate ::~QScopedPointer() (qscopedpointer.h:109) ==2384==by 0x7FE8107: KLineEdit::~KLineEdit() (klineedit.cpp:202) And QProxyStyle::setBaseStyle transfers ownership too. So clearly the intent is that a separate widget style instance is used as the base for every proxy style. I'm not sure why, but that's what we'll have to work with. [OTOH I wonder if KLineEdit couldn't keep its proxy style as a singleton, so that only one instance of it is created, this would at least keep instances down a bit. But it has some state (data members) so maybe this isn't possible]. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : kcoreaddons_stable_qt5 #27
See http://build.kde.org/job/kcoreaddons_stable_qt5/27/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121828: Bring back Please use http://bugs.kde.org to report bugs.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121828/ --- Review request for KDE Frameworks. Repository: kcoreaddons Description --- Brought back from kdelibs code. Diffs - src/lib/kaboutdata.cpp 0c711e3 Diff: https://git.reviewboard.kde.org/r/121828/diff/ Testing --- Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121828: Bring back Please use http://bugs.kde.org to report bugs.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121828/#review73066 --- Ship it! Ah, this was in kcmdlineparser, I see. src/lib/kaboutdata.cpp https://git.reviewboard.kde.org/r/121828/#comment50831 no space before () - David Faure On Jan. 4, 2015, 2:01 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121828/ --- (Updated Jan. 4, 2015, 2:01 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Brought back from kdelibs code. Diffs - src/lib/kaboutdata.cpp 0c711e3 Diff: https://git.reviewboard.kde.org/r/121828/diff/ Testing --- Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121828: Bring back Please use http://bugs.kde.org to report bugs.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121828/ --- (Updated Jan. 4, 2015, 2:36 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcoreaddons Description --- Brought back from kdelibs code. Diffs - src/lib/kaboutdata.cpp 0c711e3 Diff: https://git.reviewboard.kde.org/r/121828/diff/ Testing --- Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121833: add reviewboardrc, targets kdeframeworks and plasma groups
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121833/ --- Review request for KDE Frameworks and Plasma. Repository: kpackage Description --- add reviewbaordrc, targets kdeframeworks and plasma groups Diffs - .reviewboardrc PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121833/diff/ Testing --- made this here review request Thanks, Harald Sitter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121834: rename kpackagetool manpage to kpackagetool5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121834/ --- Review request for KDE Frameworks and Plasma. Repository: kpackage Description --- this aligns the manpage name to the binary name. also adjusted all references to the binary to use the 5 suffix. Diffs - docs/kpackagetool/CMakeLists.txt 346982d97340e94846a7c9ddebddb260a694b40a docs/kpackagetool/man-kpackagetool.1.docbook 8f6fe5a198329528692d3edf30ea5d4e36932872 Diff: https://git.reviewboard.kde.org/r/121834/diff/ Testing --- make install make test man kpackagetool5; all good Thanks, Harald Sitter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Why so many QStyles
On 01/04/2015 02:54 PM, David Faure wrote: On Sunday 04 January 2015 13:51:15 David Faure wrote: 2) I can't think of a reason against passing qApp-style() to the KLineEditStyle ctor; the rest of the code in QProxyStyle::ensureBaseStyle is about the -style cmdline override (which qApp-style() honours too). More testing gives a very good reason against doing that... Ownership of style is transferred to QProxyStyle. ==2384==at 0x4C2A601: operator delete(void*) (vg_replace_malloc.c:510) ==2384==by 0x1E07D5DB: Breeze::Style::~Style() (breezestyle.cpp:200) ==2384==by 0xC6335BB: QObjectPrivate::deleteChildren() (qobject.cpp:1935) ==2384==by 0xC631CF7: QObject::~QObject() (qobject.cpp:1028) ==2384==by 0xB3092BF: QStyle::~QStyle() (qstyle.cpp:420) ==2384==by 0xB315CDD: QCommonStyle::~QCommonStyle() (qcommonstyle.cpp:131) ==2384==by 0xB34563F: QProxyStyle::~QProxyStyle() (qproxystyle.cpp:151) ==2384==by 0x7FF262F: KLineEditStyle::~KLineEditStyle() (in /d/kde/inst/kde_frameworks/lib64/libKF5Completion.so.5.6.0) ==2384==by 0x7FF265F: KLineEditStyle::~KLineEditStyle() (klineedit_p.h:185) ==2384==by 0x7FE768F: KLineEditPrivate::~KLineEditPrivate() (klineedit.cpp:51) ==2384==by 0x7FF19FA: QScopedPointerDeleterKLineEditPrivate::cleanup(KLineEditPrivate*) (qscopedpointer.h:62) ==2384==by 0x7FF12A2: QScopedPointerKLineEditPrivate, QScopedPointerDeleterKLineEditPrivate ::~QScopedPointer() (qscopedpointer.h:109) ==2384==by 0x7FE8107: KLineEdit::~KLineEdit() (klineedit.cpp:202) And QProxyStyle::setBaseStyle transfers ownership too. So clearly the intent is that a separate widget style instance is used as the base for every proxy style. I'm not sure why, but that's what we'll have to work with. [OTOH I wonder if KLineEdit couldn't keep its proxy style as a singleton, so that only one instance of it is created, this would at least keep instances down a bit. But it has some state (data members) so maybe this isn't possible]. Hi David, many thanks for the investigation. (reason I did not use gdb is that it is broken on my setup). I'll work on sharing more things between difference instances of QStyle for both breeze and (more importantly) oxygen. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121833: add reviewboardrc, targets kdeframeworks and plasma groups
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121833/#review73077 --- Ship it! Ship It! - Jeremy Whiting On Jan. 4, 2015, 8:19 a.m., Harald Sitter wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121833/ --- (Updated Jan. 4, 2015, 8:19 a.m.) Review request for KDE Frameworks and Plasma. Repository: kpackage Description --- add reviewbaordrc, targets kdeframeworks and plasma groups Diffs - .reviewboardrc PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121833/diff/ Testing --- made this here review request Thanks, Harald Sitter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121833: add reviewboardrc, targets kdeframeworks and plasma groups
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121833/ --- (Updated Jan. 4, 2015, 3:37 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: kpackage Description --- add reviewbaordrc, targets kdeframeworks and plasma groups Diffs - .reviewboardrc PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121833/diff/ Testing --- made this here review request Thanks, Harald Sitter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121836: remove autotests/dynamictreemodel.h
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121836/ --- Review request for KDE Frameworks and Plasma. Repository: kpackage Description --- it is - unused - substantially older than the version qt ships apparently - from a pre-release - missing all the files mentioned in the license header of the file Diffs - autotests/dynamictreemodel.h 283d6ed3f938c5d7d69504ced36e11e437d2aaad Diff: https://git.reviewboard.kde.org/r/121836/diff/ Testing --- make install test; all good Thanks, Harald Sitter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121471: Port KDirSelectDialog to QFileDialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121471/#review73086 --- Just like we have KFileWidget for an embeddable file-selection-widget, we could very well have a KDirSelectWidget for an embeddable dir-selection-widget. The code is currently in frameworkintegration/src/platformtheme/kdirselectdialog.cpp (and duplicated in kdelibs4support). I think it would be a valid solution to extract a widget out of it and put it in kio/src/filewidgets. The design should match KFileWidget as much as possible. - David Faure On Dec. 17, 2014, 11:58 a.m., Jan Grulich wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121471/ --- (Updated Dec. 17, 2014, 11:58 a.m.) Review request for KDE Frameworks, Bhushan Shah, David Faure, Lukáš Tinkl, and Laurent Montel. Repository: ark Description --- I ported KDirSelectDialog to QFileDialog to get rid of kdelibs4support in ExtractionDialog, but I run into one problem. This dialog needs to add additional config widget, this is possible with using setExtension(widget) or directly accessing layout and adding this widget directly to the layout. Problem is that both options work only when I don't use native file dialog, not mentioning that setExtension() is obsoleted and accesing directly to layout of QFileDialog relies on knowning internal implementation in Qt so if they change it, i.e they switch to another layout then QGridLayout, then it will be broken again. I also tried to implement own QFileDialog using KFileWidget, but problem is that KFileWidget works only for files and I need to select a directory. You can set option to display just directories, but selecting directories is unfortunately ignored. I'm open to a better solution, but I've spent quite a lot of time trying to find it, but unfortunately without any succe ss. Diffs - app/batchextract.cpp 9480e99 kerfuffle/extractiondialog.h 5907403 kerfuffle/extractiondialog.cpp f602861 part/part.cpp 82d6f9c Diff: https://git.reviewboard.kde.org/r/121471/diff/ Testing --- Thanks, Jan Grulich ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kcoreaddons_stable_qt5 #25
See http://build.kde.org/job/kcoreaddons_stable_qt5/25/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kcoreaddons_master_qt5 #187
See http://build.kde.org/job/kcoreaddons_master_qt5/187/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121792: Make KAboutData::setupCommandLine call addHelpOption and addVersionOption
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121792/#review73054 --- src/lib/kaboutdata.h https://git.reviewboard.kde.org/r/121792/#comment50827 It *adds* the option, rather than *setting* it. - David Faure On Jan. 3, 2015, 9:36 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121792/ --- (Updated Jan. 3, 2015, 9:36 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- It's something we used to do somewhere in kdelibs4 so people don't expect them to have to call this stuff manually. Also gives us some consistency. Diffs - src/lib/kaboutdata.h 5564dab src/lib/kaboutdata.cpp f8d5e30 Diff: https://git.reviewboard.kde.org/r/121792/diff/ Testing --- Ran one of my apps, now i have help and version. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Baloo Framework - License Exception
On Tuesday 16 December 2014 14:02:18 Sebastian Kügler wrote: - If it's effectively GPL-licensed, it should not be a proper Framework I would like to challenge this reasoning. It seems to me that the premise is: * we need baloo * baloo currently needs Xapian * Xapian is GPL * the architecture we have now is that libraries coming from the KDE community are released together as KDE Frameworks, with an effort (greater than before) on making these libraries useful and useable outside the KDE community. (BTW that effort is bearing fruit, I'm visiting a company in 2 weeks who is going to use KIO in an embedded-linux product) From these facts, a reasonable (IMHO) conclusion is that: * we can release baloo as a framework, as long as we indicate clearly in its documentation that baloo is effectively GPL due to Xapian. Let me try to make a pro/con list... Releasing baloo as a framework: + gives it an automatic and painfree release schedule + simplifies version numbering (KMyApp depends on KF 5.7 rather than KMyApp depends on baloo 1.2 and KF 5.7) + makes it more consistent with the other frameworks (*apart* from the license), in terms of everything (naming, installed files, qmake support, etc.). This can be done in baloo as a separate library too (in fact that's the current situation), but then what do we have? It looks like a framework, it smells like a framework, it quacks like a framework, but it's released separately? That's a distinction that will not even appear to users (app developers). Not releasing baloo as a framework: + makes it simpler to say all frameworks can be used under the LGPL Are we going to shoot ourselves in the foot (= making our lives more complicated, by having a dependency that works differently from the other dependencies and has to be released separately) just so that we can say all frameworks are LGPL ? Finally, note that releasing baloo as a framework doesn't contradict https://techbase.kde.org/Policies/Licensing_Policy, which says the source files [of baloo] should be LGPL. They are. It's Xapian that isn't. (What we should avoid is to use baloo from other frameworks, but that's a fact whether or not baloo itself is a framework or a separate lib.) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kapidox] src: Workaround broken metadata in the NetworkManager-Qt Framework which broke all Frameworks API generation on api.kde.org.
On Monday 29 December 2014 10:10:53 Ben Cooksley wrote: Git commit 6843f218411db3dba8d5fb53a578564dcb67d50e by Ben Cooksley. Committed on 29/12/2014 at 10:10. Pushed by bcooksley into branch 'master'. Workaround broken metadata in the NetworkManager-Qt Framework which broke all Frameworks API generation on api.kde.org. Do you have more details about what the issue was? It seems related to the platforms key. Does this fix it? diff --git a/metainfo.yaml b/metainfo.yaml index 01cd3f6..b53dc64 100644 --- a/metainfo.yaml +++ b/metainfo.yaml @@ -4,7 +4,7 @@ tier: 1 type: integration platforms: - name: Linux -- note: Functional only with running NetworkManager + note: Functional only with running NetworkManager portingAid: false deprecated: false release: true -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kapidox] src: Workaround broken metadata in the NetworkManager-Qt Framework which broke all Frameworks API generation on api.kde.org.
On Sun, Jan 4, 2015 at 11:25 PM, David Faure fa...@kde.org wrote: On Monday 29 December 2014 10:10:53 Ben Cooksley wrote: Git commit 6843f218411db3dba8d5fb53a578564dcb67d50e by Ben Cooksley. Committed on 29/12/2014 at 10:10. Pushed by bcooksley into branch 'master'. Workaround broken metadata in the NetworkManager-Qt Framework which broke all Frameworks API generation on api.kde.org. Do you have more details about what the issue was? It seems related to the platforms key. Does this fix it? I can't test at the moment, but I would hazard a guess based on the errors I saw that your patch below would fix the issue. Only way to know for sure would be to revert my commit to kapidox and apply your patch to NetworkManager-Qt. Thanks, Ben diff --git a/metainfo.yaml b/metainfo.yaml index 01cd3f6..b53dc64 100644 --- a/metainfo.yaml +++ b/metainfo.yaml @@ -4,7 +4,7 @@ tier: 1 type: integration platforms: - name: Linux -- note: Functional only with running NetworkManager + note: Functional only with running NetworkManager portingAid: false deprecated: false release: true -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: QSP patch ( was KF5 Update Meeting Minutes 2014-w28 )
Oxygen+Qt5 has inherited the spaciousness of breeze, which if you ask me it does not make sense, i'd expect Oxygen+Qt5 and Oxygen+Qt4 to be the same visually. Cheers, Albert El Diumenge, 4 de gener de 2015, a les 17:14:45, Andrius da Costa Ribas va escriure: I refrain from calling win9x ugly... Personally I don't see much difference (in terms of space used) between oxygen and breeze: [image: Imagem inline 1] (in order: oxygen, breeze, windows, windowsvista, fusion) Cheers, Andrius. 2015-01-04 7:36 GMT-02:00 Hugo Pereira Da Costa hugo.pere...@free.fr: On 01/04/2015 02:27 AM, Andrius da Costa Ribas wrote: Oops, you're right! Let me amend what I said: We default to oxygen style in KDE4 when available (hadn't checked yet what changed in KF5 regarding default style). In KF5 there is some issue with plugin loading (in general, not just for styles), I do have both oxygen and breeze, but apps still load using windowsvista (native-ish) style. This issue is only with KDE apps, as Qt assistant works with either style, using -style oxygen, -style breeze or -style fusion dolphin-kf5 (windowsvista style - the only style it loads by now): [image: Imagem inline 2] dolphin-kde4 (oxygen): [image: Imagem inline 3] Qt5 Assistant (with breeze): [image: Imagem inline 4] Qt5 Assistant (with oxygen): [image: Imagem inline 5] Cheers, Andrius. 2015-01-03 22:25 GMT-02:00 Nicolás Alvarez nicolas.alva...@gmail.com: 2015-01-03 11:04 GMT-03:00 René J.V. rjvber...@gmail.com: On Saturday January 03 2015 11:53:48 Andrius da Costa Ribas wrote: Regarding oxygen, we'd probably change it later into breeze. My advice: don't, it's ugly and way too spacious ;) Then again, oxygen5 is, too. Off-topic side remark: I don't think that insulting the work of other people on a public mailing list, especially when the said other people subscribe to this very list, is neither constructive nor polite. I would appreciate if you could refrain. You could, instead, if not already done, join the discussion for instance at https://forum.kde.org/viewtopic.php?f=285t=123561sid=b507047d27e63472a10 7116143b9c873 . Regards, Hugo Oxygen works fine (Qt fallbacks to ugly win9x when it's not available). Not to Fusion? And so you don't get updating glitches in pull-down menus like we do with KDE4 on Mac? Good for you (and maybe we won't either with Qt/KF5 ...) I don't know what you two are talking about. The patch sets the *icon* theme to Oxygen, not the widget style. -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing listKde-frameworks-devel@kde.orghttps://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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: QSP patch ( was KF5 Update Meeting Minutes 2014-w28 )
Oxygen+Qt5 has inherited the spaciousness of breeze, which if you ask me it does not make sense, i'd expect Oxygen+Qt5 and Oxygen+Qt4 to be the same +1 -- Cheerio, Ivan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Opinions on KIO Slave side sorting? Possible GSoC project?
Hi, I was reading back an mailing list thread i started about half a year ago [1]. Later on in that thread Aaron suggested a cool idea of slave side sorting [2]. At that time i found it cool, but didn't really see a need for it. Dolphin is doing a fine job at sorting anyway, so why would we bother moving it to the KIO side. Well, a good reason for moving it to the KIO side just became apparent to me when looking at this RR [3]. Sorting is already quite complex in Dolphin. Adding in QCollator while also using threads makes it a bit more nasty since a QCollator object per thread is required (hence the RR). Sure, the end result (and Dolphin is probably going to move there) is to use QCollatorSortKey which will make sorting quite a bit faster [4] and remove a QCollator requirement, but it won't be any cleaner. Quite the opposite, It will be more complicated due to the bookkeeping required to use QCollatorSortKey. All this sorting stuff is quite complicated and only available in Dolphin. Other people would need to duplicate it's efforts for the same results. That and considering that KIO is a framework that can be used by external (non KDE) parties made me think that having slave side sorting might be a very good thing to have. It would allow for performance optimizations that everyone can use and allows every KIO user to easily add sorting. It would completely remove a need for Dolphin to have sorting and would greatly simplify code that uses KIO. When sorting moves to KIO, then grouping should also move to KIO imho. The goal with this mail is to see if there is a need for slave side sorting and how this should be used by applications wanting to use it. If there is a demand for this then i'd like to propose to make this a GSoC project where i volunteer to be a co-mentor. I look forward to your opinions. Best regards, Mark [1] http://mail.kde.org/pipermail/kde-frameworks-devel/2014-May/015782.html [2] http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016341.html [3] https://git.reviewboard.kde.org/r/121817/ [4] http://kdeblog.mageprojects.com/2014/07/06/natural-string-sorting-an-in-depth-analysis/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Baloo Framework - License Exception
El Diumenge, 4 de gener de 2015, a les 11:23:49, David Faure va escriure: On Tuesday 16 December 2014 14:02:18 Sebastian Kügler wrote: - If it's effectively GPL-licensed, it should not be a proper Framework I would like to challenge this reasoning. It seems to me that the premise is: * we need baloo * baloo currently needs Xapian * Xapian is GPL * the architecture we have now is that libraries coming from the KDE community are released together as KDE Frameworks, with an effort (greater than before) on making these libraries useful and useable outside the KDE community. (BTW that effort is bearing fruit, I'm visiting a company in 2 weeks who is going to use KIO in an embedded-linux product) From these facts, a reasonable (IMHO) conclusion is that: * we can release baloo as a framework, as long as we indicate clearly in its documentation that baloo is effectively GPL due to Xapian. Let me try to make a pro/con list... Releasing baloo as a framework: + gives it an automatic and painfree release schedule + simplifies version numbering (KMyApp depends on KF 5.7 rather than KMyApp depends on baloo 1.2 and KF 5.7) + makes it more consistent with the other frameworks (*apart* from the license), in terms of everything (naming, installed files, qmake support, etc.). This can be done in baloo as a separate library too (in fact that's the current situation), but then what do we have? It looks like a framework, it smells like a framework, it quacks like a framework, but it's released separately? That's a distinction that will not even appear to users (app developers). Not releasing baloo as a framework: + makes it simpler to say all frameworks can be used under the LGPL Are we going to shoot ourselves in the foot (= making our lives more complicated, by having a dependency that works differently from the other dependencies and has to be released separately) just so that we can say all frameworks are LGPL ? Finally, note that releasing baloo as a framework doesn't contradict https://techbase.kde.org/Policies/Licensing_Policy, which says the source files [of baloo] should be LGPL. They are. It's Xapian that isn't. (What we should avoid is to use baloo from other frameworks, but that's a fact whether or not baloo itself is a framework or a separate lib.) FWIW I agree with David (as i already said so in my previous email in this thread). Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[kapidox] src: Revert Workaround broken metadata in the NetworkManager-Qt Framework which broke all Frameworks API generation on api.kde.org.
Git commit 60ead7ae60b420f67ffed9c26d4646c343aa4601 by Ben Cooksley.
Committed on 04/01/2015 at 21:10.
Pushed by bcooksley into branch 'master'.
Revert Workaround broken metadata in the NetworkManager-Qt Framework which
broke all Frameworks API generation on api.kde.org.
This reverts commit 6843f218411db3dba8d5fb53a578564dcb67d50e.
CCMAIL: kde-frameworks-devel@kde.org
M +0-3src/kgenframeworksapidox
http://commits.kde.org/kapidox/60ead7ae60b420f67ffed9c26d4646c343aa4601
diff --git a/src/kgenframeworksapidox b/src/kgenframeworksapidox
index 7a0e237..4b2d36f 100755
--- a/src/kgenframeworksapidox
+++ b/src/kgenframeworksapidox
@@ -107,9 +107,6 @@ def process_toplevel_html_file(outputfile, doxdatadir,
tiers, title,
logging.warning('{} framework lacks platform
definitions'.format(fw['fancyname']))
fw['platforms'] = [dict(name=PLATFORM_UNKNOWN)]
-# In case the metadata is bad, we don't want to die so clean it up
first
-fw['platforms'] = [x for x in fw['platforms'] if 'name' in x]
-
platform_lst = [x['name'] for x in fw['platforms'] if x['name']
not in (PLATFORM_ALL, PLATFORM_UNKNOWN)]
available_platforms.update(set(platform_lst))
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121834: rename kpackagetool manpage to kpackagetool5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121834/#review73097 --- The file in the patch is marked as removed instead of renamed! Did you forget to git add the file? - Aleix Pol Gonzalez On Jan. 4, 2015, 3:21 p.m., Harald Sitter wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121834/ --- (Updated Jan. 4, 2015, 3:21 p.m.) Review request for KDE Frameworks and Plasma. Repository: kpackage Description --- this aligns the manpage name to the binary name. also adjusted all references to the binary to use the 5 suffix. Diffs - docs/kpackagetool/CMakeLists.txt 346982d97340e94846a7c9ddebddb260a694b40a docs/kpackagetool/man-kpackagetool.1.docbook 8f6fe5a198329528692d3edf30ea5d4e36932872 Diff: https://git.reviewboard.kde.org/r/121834/diff/ Testing --- make install make test man kpackagetool5; all good Thanks, Harald Sitter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Compile KF5 into Docker
On Sun, Jan 4, 2015 at 1:46 AM, Mathieu Tarral mathieu.tar...@gmail.com wrote: Hi, as you know, building KF5 from source may not be an easy task, due to build dependencies which may or may not be available for your distro. That's why I started to compile KF5 into a Docker container. This way you can keep your main system clean, and avoid to install a lot of *-dev packages. I would like to share a set of Dockerfiles which will build an image with all the necessary build dependencies already installed. Also, it may be easier for newcomers to compile KF5 using this system, and to start contributing more easily. Here is the repo : https://github.com/Mathux/docker-kdesrc-build Thanks ! Regards. -- Mathieu Tarral ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi Mathieu! This looks really cool! Looking forward to your progress, would love to be able to use this to let our future developers easily get started! Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121836: remove autotests/dynamictreemodel.h
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121836/#review73098 --- Ship it! Ship It! - Aleix Pol Gonzalez On Jan. 4, 2015, 3:51 p.m., Harald Sitter wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121836/ --- (Updated Jan. 4, 2015, 3:51 p.m.) Review request for KDE Frameworks and Plasma. Repository: kpackage Description --- it is - unused - substantially older than the version qt ships apparently - from a pre-release - missing all the files mentioned in the license header of the file Diffs - autotests/dynamictreemodel.h 283d6ed3f938c5d7d69504ced36e11e437d2aaad Diff: https://git.reviewboard.kde.org/r/121836/diff/ Testing --- make install test; all good Thanks, Harald Sitter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121836: remove autotests/dynamictreemodel.h
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121836/ --- (Updated Jan. 5, 2015, 1 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: kpackage Description --- it is - unused - substantially older than the version qt ships apparently - from a pre-release - missing all the files mentioned in the license header of the file Diffs - autotests/dynamictreemodel.h 283d6ed3f938c5d7d69504ced36e11e437d2aaad Diff: https://git.reviewboard.kde.org/r/121836/diff/ Testing --- make install test; all good Thanks, Harald Sitter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121834: rename kpackagetool manpage to kpackagetool5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121834/ --- (Updated Jan. 5, 2015, 12:59 a.m.) Review request for KDE Frameworks and Plasma. Changes --- git add ftw Repository: kpackage Description --- this aligns the manpage name to the binary name. also adjusted all references to the binary to use the 5 suffix. Diffs (updated) - docs/kpackagetool/CMakeLists.txt 346982d97340e94846a7c9ddebddb260a694b40a docs/kpackagetool/man-kpackagetool.1.docbook 8f6fe5a198329528692d3edf30ea5d4e36932872 Diff: https://git.reviewboard.kde.org/r/121834/diff/ Testing --- make install make test man kpackagetool5; all good Thanks, Harald Sitter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121834: rename kpackagetool manpage to kpackagetool5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121834/#review73105 --- Ship it! Ship It! - Aleix Pol Gonzalez On Jan. 5, 2015, 12:59 a.m., Harald Sitter wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121834/ --- (Updated Jan. 5, 2015, 12:59 a.m.) Review request for KDE Frameworks and Plasma. Repository: kpackage Description --- this aligns the manpage name to the binary name. also adjusted all references to the binary to use the 5 suffix. Diffs - docs/kpackagetool/CMakeLists.txt 346982d97340e94846a7c9ddebddb260a694b40a docs/kpackagetool/man-kpackagetool.1.docbook 8f6fe5a198329528692d3edf30ea5d4e36932872 Diff: https://git.reviewboard.kde.org/r/121834/diff/ Testing --- make install make test man kpackagetool5; all good Thanks, Harald Sitter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121834: rename kpackagetool manpage to kpackagetool5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121834/ --- (Updated Jan. 5, 2015, 1:20 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: kpackage Description --- this aligns the manpage name to the binary name. also adjusted all references to the binary to use the 5 suffix. Diffs - docs/kpackagetool/CMakeLists.txt 346982d97340e94846a7c9ddebddb260a694b40a docs/kpackagetool/man-kpackagetool.1.docbook 8f6fe5a198329528692d3edf30ea5d4e36932872 Diff: https://git.reviewboard.kde.org/r/121834/diff/ Testing --- make install make test man kpackagetool5; all good Thanks, Harald Sitter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
