Re: KConfig issues prevent compiling KDE applications under Windows
On 1 February 2017 at 14:34, David Faure <fa...@kde.org> wrote: > On mardi 31 janvier 2017 07:58:15 CET Jasem Mutlaq wrote: > > Hello, > > > > KConfig used to work perfectly fine under Windows. I recently tried to > > compile KStars under Windows 10 (64bit) with MSVC 2015 and Qt 5.8 using > > Craft, but encountered an issue as explained in this bug report: > > > > https://bugs.kde.org/show_bug.cgi?id= > > 375654 <https://bugs.kde.org/show_bug.cgi?id=375654> > > > > I talked with Craft maintainers (Hannah et al) and they told me this was > an > > issue from KConfig side, not Craft. Can someone please look into this and > > fix it as it our release is dependent on this. > > KF5ConfigCore.lib(KF5ConfigCore.dll) : error LNK2005: "public: class > QMap KEntryKey,struct KEntry>::iterator __cdecl KEntryMap::findEntry(class > QByteArray const &,class QByteArray const &,class QFlags KEntryMap::SearchFlag>)" (?findEntry@KEntryMap@@QEAA?AVite > rator@?$QMap@UKEntryKey@@UKEntryAEBVQByteArray@@0V? > $QFlags@W4SearchFlag@KEntryMap@Z) > already defined in kconfigdata.cpp.obj > > Thanks MSVC for a very readable error message as always ;) > > One note though: this is a failure to link a unittest, your release isn't > blocked, you can just disable the building of unittests in kconfig. > > The double definition can be explained, the unittest links to KF5ConfigCore > and then also compiles in ../src/core/kconfigdata.cpp because that class > is not > exported. Hi, Apparently it is since eab822e20620 (Jan 15). The bug #375654 does not seem to provide version info but the fix isn't just released, right? CC'd Stephen Kelly. I don't see much to blame MSVS for here, even the message is rather clear: the binary being linked (not compiled) already contains the symbol. I'd avoid hacks such as (kconfig/autotests/CMakeLists.txt): set(kentrymaptest_SRCS kentrymaptest.cpp ../src/core/kconfigdata.cpp) Now since eab822e20620 the class is exported and all the other symbols are inline so the hack isn't needed. Anyone, feel free make a general fix. PS: The topic isn't linker-dependent, just the Microsoft's linker demonstrated consequences of the hack. Going further for quality, exporting just for test is suboptimal so it's a good practice to export only for tests this way by using special macros: Calligra for many years: https://api.kde.org/bundled-ap ps-api/calligra-apidocs/libs/main/html/komain__export_8h_source.html KDb: https://cgit.kde.org/kdb.git/tree/src/config-kdb.h.cmake#n43 I'd recommend this not just for frameworks (or do we have this in ECM already?). Obviously CMake's generate_export_header() does not support it but IMHO it would. Then the extra cmake conditions would not be needed. So maybe that would be even better fix for KConfigData tests. > This is something we do in quite a number of other places too, > always for autotests. > > kde-windows people, if you confirm there is no way to make this work > (some linker flag maybe?), then I do see one solution: the one used by Qt > (and > konqueror), which is an export macro that only exports the class when > compilation of autotests is enabled. See konqueror/src/konqprivate_expo > rt.h > for an example. > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: breeze-icons and the symlink business
On 2 February 2017 at 00:49, Harald Sitter <sit...@kde.org> wrote:
> hola
>
> breeze-icons uses lots of symlinks. Unfortunately, ever so often our
> icon designers make a mistake and create a bad symlink. To mitigate
> this I added a bunch of tests making sure everything is nice and
> dandy.
>
> In the mean parts of the build were changed to not tolerate broken
> symlinks. While I don't really have a problem with that in of itself,
> the code largely simply ignores the possibility of broken symlinks and
> fails with the most shitty error messages you could think of. Given
> our artists are not software engineers they are having a hard time
> figuring out what is going on. And TBH, I too had to stat files to get
> to the bottom of the errors. This is a fairly shit situation as on the
> one hand we want lovely icons and on the other hand the people working
> on the icons can't understand what needs fixing without having to find
> a developer they aren't too afraid of to talk to.
>
> This really needs fixing.
>
> Notably offenders I had a fight with today:
>
>
> # breeze-validate-svg (introduced by Jos)
>
> This is a bash script running xmllint.
>
> ## Problem 1: Sources
>
> The custom target sets `SOURCES ${SVGS}` this has no notable advantage
> other than making the svgs show up in an IDE, it does however mean
> that cmake will try to inspect them (as a build tool does when they
> get told something is a source) and then falls flat on the face when
> it encounters a broken symlink as it now can't determine the source
> type resulting in this lovely error
>
> ```
> 21:39:07 CMake Error at CMakeLists.txt:70 (add_custom_target):
> 21:39:07 Cannot find source file:
> 21:39:07
> 21:39:07 /home/jenkins/sources/breeze-icons/kf5-qt5/icons-dark/
> categories/32/applications-other.svg
> ```
>
> ## Problem 2: The code
>
> The bash code in of itself runs find with -exec on xmllint. Problem
> being that if the symlink is broken xmllint will (rightfully) complain
>
> ```
> warning: failed to load external entity
> "./icons-dark/categories/32/applications-other.svg"
> ```
>
> While that is much better than the earlier problem it's still plenty
> unobvious what the underlying cause for this is. Supposedly the script
> should skip bogus symlinks.
>
> ## Problem 3: Oh but really
>
> This isn't really related to the issue of bad symlink handling:
>
> - apparently this didn't get a review. why ever would this not get a
> review?
> - this should be a test and only run when testing is enabled
> - when xmllint is not present it should report this in some form or
> fashion during the test run so one knows linting is not done
> - it should record its complaints via ctest so jenkins can display them
> properly
> - I fail to appreciate the reason this needs to depend on bash (versus
> sh, or well, neither)
>
> ## Fix Suggestion
>
> - don't needlesly set SOURCE
> - don't pass bad paths to xmllint
> - deal with stuff in problem 3
>
>
> # RCC generation (introduced by Gleb, enabled by Jaroslaw)
>
> This is a bunch of cmake rigging and helper binaries to assemble the
> icons into an rcc.
>
> ## Problem
>
> `cmake -E copy_directory` is used to copy the src tree of the themes
> into the build dir from which the resource file gets assembled. I am
> guessing copy_directory does not preserver, but resolve symlinks
> because it greets us with the ever so opaque error:
>
> ```
> Error copying directory from
> "/home/me/src/git/breeze-icons/icons-dark" to
> "/home/me/src/git/breeze-icons/build/icon
> s-dark/res".
> ```
>
> ## Fix Suggestion
>
> This is slightly less trivial since the rcc/qrc helpers seem to depend
> on resolved symlinks, so I am guessing a way to deal with this would
> be to use cmake's `file(COPY...)` instead of copy_directory and then
> have another helper run through the directories to flatten out the
> symlinks (dropping broken symlinks).
>
>
Thanks for so detailed research, Harald.
For the problem #3 I am wondering why the copying should be performed at
all if a
symlink is invalid. If I understand correctly, how about checking the
symlinks first and if there are no issues, copying which will go OK?
That's assuming the symlinks check is not a part of autotests but the
actual build.
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
Re: To C++11 or not?
On 14 November 2016 at 10:45, Martin Gräßlin <mgraess...@kde.org> wrote: > Hi framework devs, > > recently we started to see the first patches for frameworks to silence > warnings for not used features of C++11. In particular to add override to > methods of inheriting classes. > > Now I find this weird from the perspective of our C++ requirements. On the > one side we say that we are not allowed to use these features to still > support non-C++11 compilers on the other side we see that compilers already > generate warnings if you don't use the C++11 features. > > In that particular case I do not think that > > Q_DECL_OVERRIDE is a solution. It's an ugly hack and for the frameworks I > maintain I gave a -2 on the review. I think this needs a general solution > of either not adding or adding override, but not the Qt hack. > > I think this is a sign that we need to move on. We cannot continue with > the state we are in. It's too much a hassle for developers: > * false-positive compile warnings > * no way to check which features are allowed or not > * no warnings if a not allowed feature is used > * no CI system in place to ensure our rules > > Given that I want to suggest that we remove all compiler restrictions and > allow the full feature set of C++11. If someone still thinks we need to > support the compilers not supporting C++11, I would like to see a plan on > how we can improve the developer story, especially how to address the last > two points in my list above. > > Opinions? > +1 I think it's time to move on for non-KF5 repos as well just to be consistent. Mayb a hint on kde-devel or a blog entry could help with that. PS: TODO: update the requirements at https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 and remove the suggestion to use Q_DECL_OVERRIDE. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: ABI break checking in frameworks
On 26 October 2016 at 23:54, Albert Astals Cid <aa...@kde.org> wrote: > > > > Does anyone have other ideas or thoughts on it? > > Three things: - the Qt project has own solution for the checks, maybe worth looking - try to convert the compiler-specific decorated symbols to some uniform notation and compare just that - add support for ignoring some errors (per line) and check them differently -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: C++11 & friends
On 12 September 2016 at 09:10, Jaroslaw Staniek <stan...@kde.org> wrote: > > > On 12 September 2016 at 08:04, Kevin Funk <kf...@kde.org> wrote: > >> On Sunday, 11 September 2016 03:21:21 CEST Dominik Haumann wrote: >> > Hi all, >> > >> > I just saw a commit by Volker turning nullptr into Q_NULLPTR with the >> > comment that Visual Studio 2012 does not support nullptr. >> > >> > While this change is trivial for obvious reasons, do we really need to >> do >> > that? >> >> I don't think so. >> >> nullptr is actually supported since VS2010 [1]. >> >> Some other remark: I think noone's using anything below VS2015 for >> testing KDE >> on Windows anyway. I'm expecting compilation to be broken on earlier >> versions >> of VS. >> > > I am not only testing but also using/depend on 2013, which has quite some > C++11 features already. The builds of KF5 just work (this is not a CI, this > is building from time to time). Sometimes patching is needed here and there > because of completely unnecessary - for my context - dependency of > kdoctools. Things improved here in 2016 anyway. > > If not for other reasons, please note that people may depend on < 2015 > because some other component is not supported on 2015 or because od the > boss'/customer's request. > > I think fixing on a 'beeding edge' compiler may be not the best > strategy, yet I see no reason to be much less flexible in this regard than > Qt is. > That said, I'd be OK to set coding standard to use nullptr and override keywords directly without macros as these are both supported since 2012. > >> >> Cheers, >> Kevin >> >> [1] http://en.cppreference.com/w/cpp/compiler_support for evidence >> >> > I am raising this question especially since KTextEditor seems to use >> > 'nullptr' in several locations now for several releases - and noone >> > complained. >> > >> > Are we supposed to turn nullptr in KTextEditor also into nullptr, or >> > can we take the liberty and ditch Q_NULLPTR completely for all >> > frameworks? >> > >> > Same also applies to 'override'. >> > >> > Best, >> > Dominik >> >> >> -- >> Kevin Funk | kf...@kde.org | http://kfunk.org > > > > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: C++11 & friends
On 12 September 2016 at 08:04, Kevin Funk <kf...@kde.org> wrote: > On Sunday, 11 September 2016 03:21:21 CEST Dominik Haumann wrote: > > Hi all, > > > > I just saw a commit by Volker turning nullptr into Q_NULLPTR with the > > comment that Visual Studio 2012 does not support nullptr. > > > > While this change is trivial for obvious reasons, do we really need to do > > that? > > I don't think so. > > nullptr is actually supported since VS2010 [1]. > > Some other remark: I think noone's using anything below VS2015 for testing > KDE > on Windows anyway. I'm expecting compilation to be broken on earlier > versions > of VS. > I am not only testing but also using/depend on 2013, which has quite some C++11 features already. The builds of KF5 just work (this is not a CI, this is building from time to time). Sometimes patching is needed here and there because of completely unnecessary - for my context - dependency of kdoctools. Things improved here in 2016 anyway. If not for other reasons, please note that people may depend on < 2015 because some other component is not supported on 2015 or because od the boss'/customer's request. I think fixing on a 'beeding edge' compiler may be not the best strategy, yet I see no reason to be much less flexible in this regard than Qt is. > > Cheers, > Kevin > > [1] http://en.cppreference.com/w/cpp/compiler_support for evidence > > > I am raising this question especially since KTextEditor seems to use > > 'nullptr' in several locations now for several releases - and noone > > complained. > > > > Are we supposed to turn nullptr in KTextEditor also into nullptr, or > > can we take the liberty and ditch Q_NULLPTR completely for all > > frameworks? > > > > Same also applies to 'override'. > > > > Best, > > Dominik > > > -- > Kevin Funk | kf...@kde.org | http://kfunk.org -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Review Request 128283: Add checksums tab to the properties dialog
readAll() is problematic, why to potentially fill all the ram completely, thus removing cache? Such approaches can degrade overall plasma's performance. Posted from a phone. On Sunday, 26 June 2016, Elvis Angelaccio <elvis.angelac...@kdemail.net> wrote: > This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128283/ > Review request for KDE Frameworks, KDE Usability and David Faure. > By Elvis Angelaccio. > > Updated June 26, 2016, 10:34 a.m. > > Changes > > Implementation of the new layout. Checksums are cached to avoid duplicated computations. > > Repository: kio > > Description > > This patch adds a Checksums tab in the properties dialog, where the user can retrieve and verify the most popular checksum algorithms (md5, sha1 and sha256). > > To simplify the implementation, the checksums are computed as soon as the user opens the dialog. This can take a while if the file is huge (in particular with sha256), but the computation happens in another thread and in practice this should not be a performance problem. > > The tab is available only for readable local files (no simlinks) and only when there is a single selection. > > Please note that some of the labels in the screenshots are clipped due to a bug in breeze: https://bugs.kde.org/show_bug.cgi?id=364426 > > Testing > > Check whether the computed values match the values from md5sum, sha1sum, sha256sum. > Check whether the line edits get a green background if the computed and expected values match. > Check whether the line edits get a red background if the computed and expected values differ. > > Diffs (updated) > > src/widgets/CMakeLists.txt (f906577) > src/widgets/checksumswidget.ui (PRE-CREATION) > src/widgets/kpropertiesdialog.cpp (d0a2faa) > src/widgets/kpropertiesdialog_p.h (c01554e) > > View Diff > > File Attachments (updated) > > Default dialog > Expected checksum is ok > Expected checksum doesn't match > MD5 ready to be shared -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: LGPL for Breeze QStyle and qtquickcontrols?
On 6 June 2016 at 13:04, Martin Graesslin <mgraess...@kde.org> wrote: > On Monday, June 6, 2016 12:17:11 PM CEST Jaroslaw Staniek wrote: > > On 30 May 2016 at 17:11, Michael Pyne <mp...@kde.org> wrote: > > > On Mon, May 30, 2016 14:42:43 Martin Graesslin wrote: > > > > On Saturday, May 28, 2016 11:24:52 PM CEST Michael Pyne wrote: > > > > > On Sat, May 28, 2016 14:53:54 Jaroslaw Staniek wrote: > > > > > > All in all, If nobody just noted an issue with the licensing > above > > > > > > maybe > > > > > > > > > nobody tried to place/distribute a non-GPL software on top of > > > > > > Plasma? > > > > > > That > > > > > > would be the worst news of all to me. > > > > > > > > > > > > Please speak up someone else because it's a matter of KDE, not > just > > > > > > a > > > > > > single desktop shell. Maybe some voting fits here. > > > > > > > > > > I've only been able to keep track of the margins of the thread but > I > > > > > > will > > > > > > > > admit that it seems surprising that we would use code licensing as > a > > > > > > means > > > > > > > > to either enforce the exclusiveness of Plasma's artwork above and > > > > > > beyond > > > > > > > > the existing license for the artwork, or to prevent applications > > > > > > running > > > > > > > > on > > > > > KDE frameworks (but outside of Plasma) from supplying an > alternative > > > > > KDE-authored QStyle. > > > > > > > > heh, that's certainly not the case here. This is not trying to force > our > > > > style to be only used in Plasma. That would be a ridiculous stance > from > > > > > > my > > > > > > > side. > > > > > > > > I want to have my code stay GPL. I don't think that the breeze code > > > > > > needs to > > > > > > > be licenced in a way that it can be copied into 3rd party > applications. > > > > That's all. It has nothing to do with enforcing anything, it's just > > > > about > > > > > > > > > > > > t > > > > > > he > > > > > > actual implementation should stay GPL in my opinion. > > > > > > Alright, my apologies for misunderstanding and then misrepresenting > your > > > position. Certainly > > > > > > code licensing is every developer's choice to make, and > > > I'm not sure of better ways than what you're doing to avoid third-party > > > apps > > > from easily cloning the code behind the style (even if it means more > > > difficulty for non-GPL KDE apps outside of Plasma). > > > > > > Please let me repeat (and cover this and any potential similar cases in > > the future): this blocking avoids *any* reuse for non-GPL code no matter > if > > via copying or linking (either via private APIs, eventually framework-ify > > that _if_ it pays off). It's hard to assume Martin did not > read/understand > > my explanation of the use cases and the technicals. > > > > Since when LGPL (versus GPL) decrease code reuse? Conversely, GPL means > > less chance for collaborating on shared code. > > If you really want to be able to reuse the code as one wishes it needs to > be > MIT/BSD licensed. Otherwise it's just working for your personal use case > that > your LGPL based application (or whatever) can use it. > > Making the code LGPL won't fix the "problem" of not reusing the code. I'm > not > open to discuss changing the licence away from GPL due to that. LGPL won't > solve the problem and BSD style license I'm not comfortable with. > > If the code were a library (which it isn't) LGPL could be an option. But it > isn't and nobody wants to turn it into a library. It's a mood point. > > Sorry to having to deny your relicence request. I want my code > contributions > to be GPL by default, LGPL is for me already a hard exception which must > have > strong understandable reasons (like a library one wants to use, which > breeze > isn't). > > Btw. I'm very unhappy with the level of pressure you are exposing here by > bringing it up again and again. > I am done with that then -- I was one who also worked a bit on debugging the lib code, like many others do. I'd be happy to see th
Re: LGPL for Breeze QStyle and qtquickcontrols?
On 30 May 2016 at 17:11, Michael Pyne <mp...@kde.org> wrote: > On Mon, May 30, 2016 14:42:43 Martin Graesslin wrote: > > On Saturday, May 28, 2016 11:24:52 PM CEST Michael Pyne wrote: > > > On Sat, May 28, 2016 14:53:54 Jaroslaw Staniek wrote: > > > > All in all, If nobody just noted an issue with the licensing above > maybe > > > > nobody tried to place/distribute a non-GPL software on top of Plasma? > > > > That > > > > would be the worst news of all to me. > > > > > > > > Please speak up someone else because it's a matter of KDE, not just a > > > > single desktop shell. Maybe some voting fits here. > > > > > > I've only been able to keep track of the margins of the thread but I > will > > > admit that it seems surprising that we would use code licensing as a > means > > > to either enforce the exclusiveness of Plasma's artwork above and > beyond > > > the existing license for the artwork, or to prevent applications > running > > > on > > > KDE frameworks (but outside of Plasma) from supplying an alternative > > > KDE-authored QStyle. > > > > heh, that's certainly not the case here. This is not trying to force our > > style to be only used in Plasma. That would be a ridiculous stance from > my > > side. > > > > I want to have my code stay GPL. I don't think that the breeze code > needs to > > be licenced in a way that it can be copied into 3rd party applications. > > That's all. It has nothing to do with enforcing anything, it's just about > > > > > t > > he > > actual implementation should stay GPL in my opinion. > > Alright, my apologies for misunderstanding and then misrepresenting your > position. Certainly > > code licensing is every developer's choice to make, and > I'm not sure of better ways than what you're doing to avoid third-party > apps > from easily cloning the code behind the style (even if it means more > difficulty for non-GPL KDE apps outside of Plasma). > Please let me repeat (and cover this and any potential similar cases in the future): this blocking avoids *any* reuse for non-GPL code no matter if via copying or linking (either via private APIs, eventually framework-ify that _if_ it pays off). It's hard to assume Martin did not read/understand my explanation of the use cases and the technicals. Since when LGPL (versus GPL) decrease code reuse? Conversely, GPL means less chance for collaborating on shared code. I also fail to see reasoning for not collaborating -- "the actual implementation should stay GPL in my opinion" is not a reason, it's another saying "veto" by one (partial) copyright holder. I'd say, let's not call the apparent overlook regarding licensing an informed decision. That's opinion. Similarly superficial is associating "being part of Plasma" with "being non-LGPL". Equally well authors of the icons would go GPL -- why is that different? Because actually that would be a blocker for applications? That's exactly the case with the QStyle too. This complements the current issue that was barely commented here, that the Breeze style is non-consumable by GPL-incompatible software. "If it looks like a duck and quacks like a duck, it's a duck". If it looks like a lib (has APIs), is consumed like a lib (it is), has sharable code, it's a lib. Technicals aside. This also affects the legal layer, the license obligations: (non-GPL)-incompatibility. Putting it differently: if the intent was to make the style consumable by non-GPL apps, state it in the license by making a proper choice. Code licensing is every developer's choice to make but (away from his sandbox) the responsibility of maintainer is bigger and responsibility of shared code author is even bigger. There's no place for arbitrary private non-discussed choices, like this: the style in non-linkable while the icons are made into the frameworks. Even the division made between the icons and style is arbitrary one and superficial because implementation details should not be a major factor here. Icons are not C++/QML, the style is here, while in the software world there are technologies that keep these both parts of look as one consistent or inseparable piece. Let me finally state that many of the KDE frameworks started as a private code, however with unblocked on the road to being libraries by LGPL-ing in the early days. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: LGPL for Breeze QStyle and qtquickcontrols?
On 23 May 2016 at 09:38, Martin Graesslin <mgraess...@kde.org> wrote: > On Sunday, May 22, 2016 12:22:28 AM CEST Jaroslaw Staniek wrote: > > So we, in KDE, lack LGPL style code for our de-facto official look and > feel. > > This is the crucial point. Breeze is not the de-facto official look and > feel of > KDE. It's the look and feel of Plasma. This is playing a word game here. > Applications shouldn't use it. > Because? Who says so? That would be the first SDK that suggest claims. And that's the only open source style I have around with such clause. With all respect to the original authors (I spent time for bugfixing too), things go WRONG if we didn't collect requirements (ability to run non-GPL apps under Plasma) and started coding. Relicensing is a clean and simple means to undo this mistake. Earlier -- better. We were all the time correct with licensing -- I mentioned KDElibs4 before. Let's see how it went in KDE3 (Plastik, Highcolor, etc.): https://websvn.kde.org/branches/KDE/3.5/kdelibs/ I started contributions in 2003. These were times when usage of the styles by non-GPL apps were assumed. At the same time before LGPL-izing, Qt had non-GPL exception what allowed to use Qt's styles with non-GPL apps. Everything was clear and Qt app development was no more closed than Visual Basic and a bit more closed than GTK+. After LGPL-izing, Qt styles went all LGPL because obviously otherwise plugins linking to symbols would make the user's code GPL. > Applications of course can use it as much as they want. Nobody is going to > forbid it. But the fact that they use it, doesn't make it the de-facto > official > look and feel and doesn't mean that we have to licence the style as LGPL. > For now the _license_ forbids it. No distributed app can contain GPL-incompatible part or plugin. If I had to produce no matter what type of GPL plugin, a style plugin, SQL plugin, image format - I am spreading the virality of GPL in all the uses. That's also what are the dual licensing businesses are about, don't we see? > I stay where I am: I am not agreeing to having my code in Breeze (and > Oxygen) > being relicensed to LGPL. I don't see a need for it, I think GPL is the > right > choice for that code. > It would not matter as much as what's the right choice for KDE as a product in the route to success comparable with competing products. If we think strategically, code is our byproduct. In another (internal) contributor's thread we just started to discuss marketing of KDE and that nobody knows what's what in the twisted architecture. Compulsive modularization (or limiting licensing) can degrade products I am afraid. How is it important to someone who wants to, say, sell a calculator app that is runing on top of Plasma when all she gets from us is "GPL-compatibility is good choice for your calculator". This is not going well. I was _this_ close to a blog entry about default Plasma installations not allowing non-GPL applications. But why to have another Akonadi-like rant. There are always solutions. Now I see that maybe it's better to switch to a breeze-fied fusion style (LGPL). All in all, If nobody just noted an issue with the licensing above maybe nobody tried to place/distribute a non-GPL software on top of Plasma? That would be the worst news of all to me. Please speak up someone else because it's a matter of KDE, not just a single desktop shell. Maybe some voting fits here. Cheers -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Can we have a headersclean check for frameworks?
Hi Maybe what I am using in three frameworks is useful: kdb.git/autotests/headers. On 11 May 2016 at 22:51, Stephen Kelly <steve...@gmail.com> wrote: > Hi, > > Qt has a headersclean utility which runs each header through the compiler > on > its own. That verifies that it doesn't cause certain warnings, can compile > in the presence of certain Qt defines, and includes or forward declares > everything it should. > > We don't have such a thing in KF5, but as shown by > > https://quickgit.kde.org/?p=kconfigwidgets.git=commitdiff=2900814b > > we would benefit from it. > > Does anyone want to try to implement it (or borrow the Qt implementation) > and integrate it? > > We can probably add it to ECM and run it as part of the build of > frameworks. > > Thanks, > > Steve. > > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: LGPL for Breeze QStyle and qtquickcontrols?
On 18 May 2016 at 17:51, Martin Graesslin <mgraess...@kde.org> wrote: > On Wednesday, May 18, 2016 12:41:49 PM CEST Jaroslaw Staniek wrote: > > On 17 May 2016 at 20:38, Martin Graesslin <mgraess...@kde.org> wrote: > > > On Tuesday, May 17, 2016 6:23:10 PM CEST Jaroslaw Staniek wrote: > > > > > If you show me why it needs to be a framework and I agree with it, > > > > > I might be willing to consider to allow to relicense the code I > wrote > > > > > > for > > > > > > > > it. > > > > > > > > There's no request to make it framework from me. LGPLing Breeze does > not > > > > automatically add obligation to create and maintain a framweork. > > > > > > Especially > > > > > > > that there are not widely declared use cases. It's just a way to get > the > > > > same what was legal in the times of Oxygen and KDElibs 4. > > > > > > Yes exactly! If you would present me reasons why it should become a > > > framework > > > I might see a need for it to have it LGPL. That is something I > currently > > > don't > > > see. Thus I don't see a reason to change it to LGPL. > > > > But there's no rule in KDE that LGPL code needs to form frameworks. > > No need to switch the topic... Adding a framework is a lot of > > responsibility I am aware of and I don't request more work from others. > > We had an agreement within KDE organization that there's not even rule > > that KDE projects have to use C++ or Qt. People can implement things in > > HTML or C# or Java. Unless licenses stay against it but I see no reason > why > > would be that. > > > > > Similar I don't relicense KWin to LGPL, just because there might be a > > > reason > > > later on. When we split out code from KWin to KWayland we did the > > > relicense > > > as needed. > > > > You see, authors have the benefit of re-licensing when _they_ need. > > I am not the author and have to face unusual extensive testing of my > > reasoning. > > You are asking me as a copyright holder whether I agree to a relicense. You > have to convince me. To me the default licence is GPLv3+. Everything else > means an exception to my personal view. You have to provide really good > reasons to make me agree that this is needed. > > So far I have not seen them. It is more a wishy-washy about you want to use > some code. That's not a reasoning. Explain why you need it and explain it > that > makes sense with our overall KDE vision about > > applications not being part of > Plasma and depending on Plasma. Especially: how do you want to achieve it > without making applications depend on Plasma, which is nothing we want. > Copy > code? No way, for that I'm not going to agree to relicense. > > Martin, "Depending on plasma" is a term at the level of deployment. It addresses requirements that may be important to someone but not to the entire mankind. Not every software title is developed by operating in the scope of term that you're referring to. I am sharing examples below. With all due respect I don't want to even discuss using licenses as a tool/weapon to dictate deployment, scope of use, etc. And whether all desktop applications that use Breeze style and icons to display something (not necessarily QWidgets) must be part of Plasma -- which so far isn't official component/subsystem of Windows or OS X. So how a KDE app on Windows has to be part of Plasma is not clear to me. Then the KDE Vision and copying, good that you're asking because there's some exercise. The KDE Vision is orthogonal to something even stronger than copying: _forking_ projects, even without "convincing" or explaining original authors. And these projects can be part of KDE exactly the way the original is. So Plasma (design and icons - SVG code) has been copied multiple times already out of KDE, what includes a copy for GTK+ apps and LibreOffice apps. The Breeze style has been copied to the LGPLized GTK+ style. I don't need to add that none of such apps mention Plasma or even KDE. And most users of popular KDE apps such as Krita wouldn't even know what _kind_ of term Plasma is if we ask them. You know, most of these users are on Windows. I am not trying to devalue Plasma by saying this but to show that in the entire population there are various interests. Then, creating an Android or iOS package is ultimately also copying. Creating Windows/Mac installers of pro apps is very interesting exercise in copying and picking versions of components that are needed and work together. Suddenly you become developer and packager, something not very often practices on Linux.
Re: LGPL for Breeze QStyle and qtquickcontrols?
On 17 May 2016 at 20:38, Martin Graesslin <mgraess...@kde.org> wrote: > On Tuesday, May 17, 2016 6:23:10 PM CEST Jaroslaw Staniek wrote: > > > If you show me why it needs to be a framework and I agree with it, > > > I might be willing to consider to allow to relicense the code I wrote > for > > > it. > > > > There's no request to make it framework from me. LGPLing Breeze does not > > automatically add obligation to create and maintain a framweork. > Especially > > that there are not widely declared use cases. It's just a way to get the > > same what was legal in the times of Oxygen and KDElibs 4. > > Yes exactly! If you would present me reasons why it should become a > framework > I might see a need for it to have it LGPL. That is something I currently > don't > see. Thus I don't see a reason to change it to LGPL. > But there's no rule in KDE that LGPL code needs to form frameworks. No need to switch the topic... Adding a framework is a lot of responsibility I am aware of and I don't request more work from others. We had an agreement within KDE organization that there's not even rule that KDE projects have to use C++ or Qt. People can implement things in HTML or C# or Java. Unless licenses stay against it but I see no reason why would be that. > > Similar I don't relicense KWin to LGPL, just because there might be a > reason > later on. When we split out code from KWin to KWayland we did the > relicense > as needed. > You see, authors have the benefit of re-licensing when _they_ need. I am not the author and have to face unusual extensive testing of my reasoning. You're free to do that but that sounds oppressive. From the KF5 perspective I am the "customer", framework authors would have to listen to in some real world. > > > Why on the icons and not on style? (See also below) > > I have apps/libs that hard-depend on breeze style. (not just the > > implementation, on the design) > > Example reason: because for my requirements it works better with the > icons > > and for example Windows 95 or Windows 7 style does not. Or I hav code > that > > does not link to QWidget and still needs to paint/print something that is > > desinged in Breeze style. > > Are that made up examples? If you want to use a QStyle in an application > not > using QWidgets you have lost already. > It would be better not experiencing one KDE contributor patronising other KDE contributor. it would be more proactive to hear "I don't see this use case maybe because I don't work on such software but I trust you and I am happy with more FOSS working together". > > > Bottom line, IIRC there are no KDE applications anymore. You can't > predict > > what OS / UX the _Qt_ apps will be used on. So author of applications are > > perfectly free to target other OSes than just the Plasma-based ones. > > We want KDE applications to integrate with the OSes style and not force the > Plasma style on apps in e.g. GNOME. We don't want apps to force the breeze > style. > > You can't stop that with restrictions but with a great architecture. I have different approach now and licensing won't stop that, it will just just cost more and ultimately would be uglier. Inclusive attitude instead we-they and licensing can be the cheapest solution and investment for the future. > > > > > > > Icons are part of the KF5 product [1] which does not mean libraries > > > > > > depend > > > > > > > on them > > > > https://www.kde.org/announcements/kde-frameworks-5.22.0.php > > > > (well I believe as a product they depend but that's out-of-the box > level > > > > thinking not belonging here) > > > > > > libraries do depend on icons. Otherwise there wouldn't be efforts on > how > > > to > > > package all required icons in the case of Android. > > > > Very good, so similarly, I am packaging the breeze style for desktop > OSes > > that lack Breeze QStyle. And like on Android, for these OSes the style > is > > defined/decided at the application's level. And I have chosen Breeze > style > > and icons and using that assumption while developing custom widgets (a > hell > > of work for even for one style when QStyle is a stalled API now). > > So you are porting part of Plasma to other OSes. That's great! Though > doesn't > mean that Plasma should relicense code. > No... I don't port a desktop experience. My universe in this case is the application, that's not unusual in the real world. Many apps used nowadays (mobile, web) do so I don't see why this should be prohibited. I am cherry picking to mak
Re: LGPL for Breeze QStyle and qtquickcontrols?
On 17 May 2016 at 20:48, Hugo Pereira Da Costa < hugo.pereira.da.co...@gmail.com> wrote: > Hi, > > [snip] > >> >> Architecturally, the eventual solution would be that breeze.git becomes >> layered, and routines beyond what QStyle defines are provided by an LGPL >> lib. It worked with libOxygen that is LGPL. >> The reason for liboxygen was that part of Oxygen was also used by KWin >> decoration. We fixed that by moving the decorations together with the >> style >> into one repository. >> > liboxygen was also there to take care of code shared between the style and > the decoration, but internal only, no headers exported, no so version, no > abi, api stability guaranty of any kind. I have no clue how this could be > used by the external world in any way. > It is, I explained it a bit. But anyway it's FOSS so explaining was not needed. I am not implementing frameworks or plasma so I am not obligated to rules or habits expressed here. > > Personally I think liboxygen was rather a hack and an annoyance. >> > based on the above, I was seeing it as a "private" library, needed to > avoid code duplication and ease maintenance between two parts of oxygen. > As for the licensing of such a thing, no clue, but again, I never intended > it to be re-used by any other code. Like above, do you agree it to be reused or not. I am not asking if you intend to use it, I am asking if you are OK/open with others using the code in other FOSS code. > > >> Especially that QStyle is >>> mostly just maintained. "Use QStyle and plugins" sounds almost like "use >>> X >>> "protocol instead of DWD"... >>> Going LGPL is a first step for this being even considered as a task by a >>> KDE contributor. Without that the easiest thing is to work downstream >>> forking^w copying the design and such. >>> >>> The request is about the freedom to use of the code from of the breeze >>>>> style in LGPL code freely opening freedom for experimentation and >>>>> >>>> progress. >>>> >>>> The design (by VDG) is free to use (LGPL I think), why wouldn't the >>>>> implementation be free-to-link? >>>>> >>>> I repeat again: I object to a relicense of code I have written to GPL in >>>> the >>>> case of Breeze and Oxygen. >>>> >>> I see much of oxygen >>> >>> is BSD-like and LGPL of the change happened in with the Breeze. >>> >> I have here a file open oxygenstyleplugin.cpp which is licensed as GPL >> v2+. >> Thus the whole thing is licensed GPLv2+. Why the code is inconsistent >> licensed >> I do not know. >> > > Probably me copying code around without caring much. I would agree to > re-license all the part I wrote to GPL v2+. > > Cool but that was not my question . I asked to relicense to LGPL so I don't need to reimplement the same bits of style for non-QStyle code. Or reuse artwork from GTK+. best, > > Hugo > > > >> Again what's wrong for you with libOxygen that is LGPL? >>> >> liboxygen is not lgpl licensed. Look for example at >> liboxygen/liboxygen.h. It >> has a GPLv2+ header, thus is GPLv2+ >> >> >>> >>> PS: If our tech was HTML and Qt Quick only, our styles would be LGPL >>>>> clearly as these would be actually scripts and graphic/style files. Why >>>>> would we have inferior situation just because we happen to use >>>>> compilers? >>>>> >>>> I don't see what that has to do with it. >>>> >>> It means that styles for HTML and Qt Quick _and_ GTK+ Breze style have >>> freedoms that Breeze actually lack just because the licensing choice. >>> And >>> that may or may not be a missed opportunity. >>> >> I just checked the folder qtquickcontrols - those files are unfortunately >> not >> licensed at all. This is clearly wrong. >> >> Concerning GTK+ Breeze style: the COPYING.lib says it's LGPL. So you also >> cannot just take parts of it. Though the individual files are lacking a >> copyright header. >> >> Cheers >> Martin >> > > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: LGPL for Breeze QStyle and qtquickcontrols?
On 17 May 2016 at 15:02, Martin Graesslin <mgraess...@kde.org> wrote: > On Tuesday, May 17, 2016 2:21:43 PM CEST Jaroslaw Staniek wrote: > > On 9 May 2016 at 07:53, Martin Graesslin <mgraess...@kde.org> wrote: > > > On Saturday, May 7, 2016 10:10:50 PM CEST Jaroslaw Staniek wrote: > > > > Hi, > > > > Is relicensing Breeze QStyle to LGPL from GPL for possible and > > > > > > acceptable? > > > > > > > I've found cases when bits of the code beyond QStyle/KStyle API need > > > > to be reused. One example is: custom widgets. > > > > If we're considering Breeze QStyle as implementation of certain > > > > artwork, and KDE artwork in general would be LGPL also for > > > > consistency. > > > > For example wallpapers, icons are LGPL. > > > > > > > > Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now, > > > > it's not clear in breeze.git. The same question here: can it be LGPL > > > > or BSD? > > > > > > > > Bottom line is: if we want to popularise our frameworks in the > outside > > > > world... > > > > > > I fail to follow you why Breeze QStyle should be a framework. No > framework > > > should depend on it, Breeze QStyle is a plugin and it's only getting > > > loaded by > > > either setting an env variable manually or using the Plasma QPT plugin > > > which > > > is not in Frameworks either. > > > > Not only KF5 is LGPL. Also other libraries and also parts of individual > > apps. > > And there are also libraries which are GPL. E.g. kwineffects or > kscreenlocker > library. > > > BTW: The latter help to create frameworks in the future (picking GPL too > > early kills the idea). > > No it doesn't. It just means that one needs to get everybody to agree on > the > relicense. LGPL decided earlier than later helps to avoid such threads. KStyle's origins are internals of KDE3. > If you show me why it needs to be a framework and I agree with it, > I might be willing to consider to allow to relicense the code I wrote for > it. > There's no request to make it framework from me. LGPLing Breeze does not automatically add obligation to create and maintain a framweork. Especially that there are not widely declared use cases. It's just a way to get the same what was legal in the times of Oxygen and KDElibs 4. Above app the license obligations of *GPL do not include explaining use cases for the code. But my friendly attitude shows that I am sharing some of the boring details with you below... > > > > > > Anyway on the question of whether to relicense to LGPL you should ask > the > > > copyright holders and I doubt you found them here on frameworks-devel > as > > > Breeze is not a framework. I'm one of the copyright holders and as I > don't > > > understand why you want it relicensed I would not agree to it. I think > GPL > > > is > > > the proper license for our workspace components. > > > > I'd like more explanation to know if you disagree just for the sake... > > of course not! > > > Don't you agree with LGPL for breeze or oxygen icons? > > We have applications which depend on breeze and oxygen icons. That's why we > moved them to frameworks. Applications depend on it, LGPL is the proper > license. > Why on the icons and not on style? (See also below) I have apps/libs that hard-depend on breeze style. (not just the implementation, on the design) Example reason: because for my requirements it works better with the icons and for example Windows 95 or Windows 7 style does not. Or I hav code that does not link to QWidget and still needs to paint/print something that is desinged in Breeze style. > > The style though is part of Plasma Workspace and as that should follow the > licensing of Plasma components which is GPL. This also applies to many > libraries in Plasma. > > > > > Styles are in *the same* group. > > > > > > They make-our-user-experience. > > They make up the user-experience of Plasma. Not of the applications. > "application s tyles do not make the user experience of app but icons for some reason define the apps" seems arbitrary choice and just a "current" state of things. Bottom line, IIRC there are no KDE applications anymore. You can't predict what OS / UX the _Qt_ apps will be used on. So author of applications are perfectly free to target other OSes than just the Plasma-based ones. > > > > Icons are part of the KF5 product [1] which does not mean libraries > depend > > on them &
Re: LGPL for Breeze QStyle and qtquickcontrols?
On 9 May 2016 at 07:53, Martin Graesslin <mgraess...@kde.org> wrote: > On Saturday, May 7, 2016 10:10:50 PM CEST Jaroslaw Staniek wrote: > > Hi, > > Is relicensing Breeze QStyle to LGPL from GPL for possible and > acceptable? > > I've found cases when bits of the code beyond QStyle/KStyle API need > > to be reused. One example is: custom widgets. > > If we're considering Breeze QStyle as implementation of certain > > artwork, and KDE artwork in general would be LGPL also for > > consistency. > > For example wallpapers, icons are LGPL. > > > > Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now, > > it's not clear in breeze.git. The same question here: can it be LGPL > > or BSD? > > > > Bottom line is: if we want to popularise our frameworks in the outside > > world... > > I fail to follow you why Breeze QStyle should be a framework. No framework > should depend on it, Breeze QStyle is a plugin and it's only getting > loaded by > either setting an env variable manually or using the Plasma QPT plugin > which > is not in Frameworks either. > Not only KF5 is LGPL. Also other libraries and also parts of individual apps. BTW: The latter help to create frameworks in the future (picking GPL too early kills the idea). > > Anyway on the question of whether to relicense to LGPL you should ask the > copyright holders and I doubt you found them here on frameworks-devel as > Breeze is not a framework. I'm one of the copyright holders and as I don't > understand why you want it relicensed I would not agree to it. I think GPL > is > the proper license for our workspace components. > > I'd like more explanation to know if you disagree just for the sake... Don't you agree with LGPL for breeze or oxygen icons? Styles are in *the same* group. They make-our-user-experience. Icons are part of the KF5 product [1] which does not mean libraries depend on them https://www.kde.org/announcements/kde-frameworks-5.22.0.php (well I believe as a product they depend but that's out-of-the box level thinking not belonging here) Do you then agree with relicensing after my explanations here and in the other email? The request is about the freedom to use of the code from of the breeze style in LGPL code freely opening freedom for experimentation and progress. The design (by VDG) is free to use (LGPL I think), why wouldn't the implementation be free-to-link? PS: If our tech was HTML and Qt Quick only, our styles would be LGPL clearly as these would be actually scripts and graphic/style files. Why would we have inferior situation just because we happen to use compilers? > Cheers > Martin > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: LGPL for Breeze QStyle and qtquickcontrols?
On Monday, 9 May 2016, Martin Graesslin <mgraess...@kde.org> wrote: > On Saturday, May 7, 2016 10:10:50 PM CEST Jaroslaw Staniek wrote: >> Hi, >> Is relicensing Breeze QStyle to LGPL from GPL for possible and acceptable? >> I've found cases when bits of the code beyond QStyle/KStyle API need >> to be reused. One example is: custom widgets. >> If we're considering Breeze QStyle as implementation of certain >> artwork, and KDE artwork in general would be LGPL also for >> consistency. >> For example wallpapers, icons are LGPL. >> >> Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now, >> it's not clear in breeze.git. The same question here: can it be LGPL >> or BSD? >> >> Bottom line is: if we want to popularise our frameworks in the outside >> world... > > I fail to follow you why Breeze QStyle should be a framework. No framework > should depend on it, Breeze QStyle is a plugin and it's only getting loaded by > either setting an env variable manually or using the Plasma QPT plugin which > is not in Frameworks either. Sorry for wrong selection of email. If someone is interested in a us case for apps I am sharing it below. I am saying certain *apps* can depend on the code that is not exported via the plugin interface. Such usage makes the code more like lib than a self contained plugin for QStyle. I am not saying that modern styling is a subject possible to design/distribute as a framework. Rather copy-paste is the ultimate way as we know in Qt Quick world. In the optimistic case -- a set of primitive painting functions. Hence the LGPL can be useful. > > Anyway on the question of whether to relicense to LGPL you should ask the > copyright holders and I doubt you found them here on frameworks-devel as > Breeze is not a framework. I'm one of the copyright holders and as I don't > understand why you want it relicensed I would not agree to it. I think GPL is > the proper license for our workspace components. > > Cheers > Martin -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
LGPL for Breeze QStyle and qtquickcontrols?
Hi, Is relicensing Breeze QStyle to LGPL from GPL for possible and acceptable? I've found cases when bits of the code beyond QStyle/KStyle API need to be reused. One example is: custom widgets. If we're considering Breeze QStyle as implementation of certain artwork, and KDE artwork in general would be LGPL also for consistency. For example wallpapers, icons are LGPL. Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now, it's not clear in breeze.git. The same question here: can it be LGPL or BSD? Bottom line is: if we want to popularise our frameworks in the outside world... -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Equivalent of KDE::version*()?
On 29 September 2015 at 09:32, David Faure <fa...@kde.org> wrote: > On Monday 15 June 2015 22:23:17 Jaroslaw Staniek wrote: > > Hi, > > One would need a need runtime version information of particular kf5 > > libraries -- in addition to version with which the software has been > > built. > > > > It seems that mostly Plasma and KActivities have equivalent of runtime > > version information. > > I am not looking build-time *_version.h files generated (with > > *_VERSION_* macros) but something like > > plasma-framework/src/plasma/version.h. > > > > Attica is a good exception here, I cannot spot anything else. > > > > PS: Maybe the code can be generated? > > What would this be useful for? Working around bugs? > Sorry, late reply... As a last resort, yes. But the original though is to know the version(s) when collecting feedback/support information (Kexi does it per user demand as a part of its QA). My plan was rather not to have bugs in the first place :-) > Yeah yeah, I know ;) > > If there's usefulness in this, we could generate some code indeed > (ECM to the rescue once more...). > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RCC for icons - update: Re: Icons installed by apps
Update:
Full (light) breeze.rcc theme file can be squashed to 5MiB using SVG
optimizer SVGO, in a similar way to what Aleix's script does (
https://quickgit.kde.org/?p=breeze-icons.git=commit=8a31ac8ac105) :)
Good job, Aleix.
On 8 March 2016 at 23:56, Jaroslaw Staniek <stan...@kde.org> wrote:
>
> Hi, published a patch for Kexi with rough explanation and list of features:
>
> https://phabricator.kde.org/D1092
>
>
>
> On 7 March 2016 at 17:52, Jaroslaw Staniek <stan...@kde.org> wrote:
>
>>
>> On 7 March 2016 at 17:29, Jaroslaw Staniek <stan...@kde.org> wrote:
>>
>>>
>>> On 7 March 2016 at 13:05, Kåre Särs <kare.s...@iki.fi> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Monday, March 07, 2016 12:41:52 PM Jaroslaw Staniek wrote:
>>>> > >
>>>> > > Thanks, it works on Windows (no platform theme).
>>>> > > How to make it work on Linux too (KF5 5.19.0, Qt 5.5.1), i.e. I'd
>>>> like
>>>> > > to have only used icons from the .rcc regardless of availability of
>>>> > > FrameworkIntegrationPlugin.so KDEPlatformTheme.so?
>>>> > >
>>>> > > We're talking about this code:
>>>> > >
>>>> > > https://quickgit.kde.org/?p=kate.git=blob=icons.h
>>>> > >
>>>> > > As soon as QResource::registerResource("breeze.rcc") is called,
>>>> ":/icons"
>>>> > > is
>>>> > > appended to the theme search path (checked using
>>>> > > QIcon::themeSearchPaths()).
>>>> > >
>>>> > > There's a line QIcon::setThemeSearchPaths(QStringList() <<
>>>> > > QStringLiteral(":/icons")).
>>>> > >
>>>> > > - When I have this line enabled and I have no
>>>> > > FrameworkIntegrationPlugin.so & KDEPlatformTheme.so installed, no
>>>> icons
>>>> > > are
>>>> > > available at all
>>>>
>>>> Notice that the setThemeSearchPaths() call _replaces_ any previous
>>>> search
>>>> paths. Is this your problem?
>>>>
>>>>
>>>>
>>> No.. but I got it sorted out after reading QIconTheme::QIconTheme and
>>> alike and re-reading the "The name should correspond to a directory name in
>>> the themeSearchPath() containing an index.theme file describing it's
>>> contents" sentence of QIcon::setThemeName docs :)
>>>
>>
>>
>> PS: If someone wants to experiment (I hear it's the case for KDevelop),
>> here is the
>> Breeze icons resource: http://kexi-project.org/tmp/breeze.rcc.bz2
>>
>> For reference, Kexi icons: http://kexi-project.org/tmp/kexi_breeze.rcc.
>> bz2
>> And recent commit that supports it all on Linux and Windows:
>> https://quickgit.kde.org/?p=scratch%2Fstaniek%2Fkexi3.git
>>
>>
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
>
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RCC for icons - update: Re: Icons installed by apps
Hi, published a patch for Kexi with rough explanation and list of features:
https://phabricator.kde.org/D1092
On 7 March 2016 at 17:52, Jaroslaw Staniek <stan...@kde.org> wrote:
>
> On 7 March 2016 at 17:29, Jaroslaw Staniek <stan...@kde.org> wrote:
>
>>
>> On 7 March 2016 at 13:05, Kåre Särs <kare.s...@iki.fi> wrote:
>>
>>> Hi,
>>>
>>> On Monday, March 07, 2016 12:41:52 PM Jaroslaw Staniek wrote:
>>> > >
>>> > > Thanks, it works on Windows (no platform theme).
>>> > > How to make it work on Linux too (KF5 5.19.0, Qt 5.5.1), i.e. I'd
>>> like
>>> > > to have only used icons from the .rcc regardless of availability of
>>> > > FrameworkIntegrationPlugin.so KDEPlatformTheme.so?
>>> > >
>>> > > We're talking about this code:
>>> > >
>>> > > https://quickgit.kde.org/?p=kate.git=blob=icons.h
>>> > >
>>> > > As soon as QResource::registerResource("breeze.rcc") is called,
>>> ":/icons"
>>> > > is
>>> > > appended to the theme search path (checked using
>>> > > QIcon::themeSearchPaths()).
>>> > >
>>> > > There's a line QIcon::setThemeSearchPaths(QStringList() <<
>>> > > QStringLiteral(":/icons")).
>>> > >
>>> > > - When I have this line enabled and I have no
>>> > > FrameworkIntegrationPlugin.so & KDEPlatformTheme.so installed, no
>>> icons
>>> > > are
>>> > > available at all
>>>
>>> Notice that the setThemeSearchPaths() call _replaces_ any previous search
>>> paths. Is this your problem?
>>>
>>>
>>>
>> No.. but I got it sorted out after reading QIconTheme::QIconTheme and
>> alike and re-reading the "The name should correspond to a directory name in
>> the themeSearchPath() containing an index.theme file describing it's
>> contents" sentence of QIcon::setThemeName docs :)
>>
>
>
> PS: If someone wants to experiment (I hear it's the case for KDevelop),
> here is the
> Breeze icons resource: http://kexi-project.org/tmp/breeze.rcc.bz2
>
> For reference, Kexi icons: http://kexi-project.org/tmp/kexi_breeze.rcc.bz2
> And recent commit that supports it all on Linux and Windows:
> https://quickgit.kde.org/?p=scratch%2Fstaniek%2Fkexi3.git
>
>
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RCC for icons - update: Re: Icons installed by apps
On 7 March 2016 at 17:29, Jaroslaw Staniek <stan...@kde.org> wrote:
>
> On 7 March 2016 at 13:05, Kåre Särs <kare.s...@iki.fi> wrote:
>
>> Hi,
>>
>> On Monday, March 07, 2016 12:41:52 PM Jaroslaw Staniek wrote:
>> > >
>> > > Thanks, it works on Windows (no platform theme).
>> > > How to make it work on Linux too (KF5 5.19.0, Qt 5.5.1), i.e. I'd
>> like
>> > > to have only used icons from the .rcc regardless of availability of
>> > > FrameworkIntegrationPlugin.so KDEPlatformTheme.so?
>> > >
>> > > We're talking about this code:
>> > >
>> > > https://quickgit.kde.org/?p=kate.git=blob=icons.h
>> > >
>> > > As soon as QResource::registerResource("breeze.rcc") is called,
>> ":/icons"
>> > > is
>> > > appended to the theme search path (checked using
>> > > QIcon::themeSearchPaths()).
>> > >
>> > > There's a line QIcon::setThemeSearchPaths(QStringList() <<
>> > > QStringLiteral(":/icons")).
>> > >
>> > > - When I have this line enabled and I have no
>> > > FrameworkIntegrationPlugin.so & KDEPlatformTheme.so installed, no
>> icons
>> > > are
>> > > available at all
>>
>> Notice that the setThemeSearchPaths() call _replaces_ any previous search
>> paths. Is this your problem?
>>
>>
>>
> No.. but I got it sorted out after reading QIconTheme::QIconTheme and
> alike and re-reading the "The name should correspond to a directory name in
> the themeSearchPath() containing an index.theme file describing it's
> contents" sentence of QIcon::setThemeName docs :)
>
PS: If someone wants to experiment (I hear it's the case for KDevelop),
here is the
Breeze icons resource: http://kexi-project.org/tmp/breeze.rcc.bz2
For reference, Kexi icons: http://kexi-project.org/tmp/kexi_breeze.rcc.bz2
And recent commit that supports it all on Linux and Windows:
https://quickgit.kde.org/?p=scratch%2Fstaniek%2Fkexi3.git
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RCC for icons - update: Re: Icons installed by apps
On 7 March 2016 at 14:45, René J.V. <rjvber...@gmail.com> wrote: > On Monday March 07 2016 12:41:52 Jaroslaw Staniek wrote: > > BTW, am I right that using a builtin binary rcc icon set could make you > lose in terms of memory (RAM) footprint overhead what you gain in terms of > disk space overhead? > Dsk optimization is not the goal, that would be Enlightenment-like optimization :) The thing is, as an average Qt dev, if I had to develop and distribute a 5 cpp files-long lib or app, self-contained (not packaged), I wouldn't like to add 5970 (and counting) icon files to it to just display 3 icons or so. I would probably copy the needed icons into a subdir, maybe even rename them, move around, etc. Disclaimer: we're not 'average' Qt devs with all consequences but my dream is that the two extremes can be closer. I've been doing the copying myself for non-FOSS or non-mainstream FOSS code. So any improvement like having a single breeze.rcc file is more than good solution IMHO. In other words, we're not distributing movies in a form of N jpeg files, one per frame, we're using dedicated container. So here it is, a dedicated container for icons. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RCC for icons - update: Re: Icons installed by apps
On 7 March 2016 at 13:05, Kåre Särs <kare.s...@iki.fi> wrote:
> Hi,
>
> On Monday, March 07, 2016 12:41:52 PM Jaroslaw Staniek wrote:
> > >
> > > Thanks, it works on Windows (no platform theme).
> > > How to make it work on Linux too (KF5 5.19.0, Qt 5.5.1), i.e. I'd
> like
> > > to have only used icons from the .rcc regardless of availability of
> > > FrameworkIntegrationPlugin.so KDEPlatformTheme.so?
> > >
> > > We're talking about this code:
> > >
> > > https://quickgit.kde.org/?p=kate.git=blob=icons.h
> > >
> > > As soon as QResource::registerResource("breeze.rcc") is called,
> ":/icons"
> > > is
> > > appended to the theme search path (checked using
> > > QIcon::themeSearchPaths()).
> > >
> > > There's a line QIcon::setThemeSearchPaths(QStringList() <<
> > > QStringLiteral(":/icons")).
> > >
> > > - When I have this line enabled and I have no
> > > FrameworkIntegrationPlugin.so & KDEPlatformTheme.so installed, no icons
> > > are
> > > available at all
>
> Notice that the setThemeSearchPaths() call _replaces_ any previous search
> paths. Is this your problem?
>
>
>
No.. but I got it sorted out after reading QIconTheme::QIconTheme and
alike and re-reading the "The name should correspond to a directory name in
the themeSearchPath() containing an index.theme file describing it's
contents" sentence of QIcon::setThemeName docs :)
I was tricked by the fact that on Windows qrc files with these paths work:
./icons/actions/16/code-block.svg
./icons/actions/16/code-class.svg
etc.
And not on Linux. No idea why. Here I needed:
./icons/breeze/actions/16/code-block.svg
./icons/breeze/actions/16/code-class.svg
Of course also, otherwise the theme is marked as invalid
./icons/breeze/index.theme
(needed once; if you have the index.theme accessible from breeze.rcc, you
can add an extra application-defined .rcc without index.theme and new icons
will just be "added" to the theme. Looks like useful thing for plugins for
example, shipped completely separate from distros, and maybe not even
packaged. Just make sure you don't use any new subdirs that are are not
defined by the index file (I guess).
Now useful thing would be to have option to generate breeze.rcc directly in
breeze-icons.git, so apps can find breeze.rcc at configure time, e.g. using
FindBreezeIcons.cmake.
Thanks, sorry for the noise. All the relevant recipes would end up in a
howto and/or cmake scripts.
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RCC for icons - update: Re: Icons installed by apps
Real data for a single Kexi start + opening a single document on Linux, SSD:
strace kexi 2>&1 | grep ^stat | wc -l
1. Traditional icon files: 78k calls
2. .rcc icon files: 11k calls, starts ~14% faster
And for #2 there are still a few thousands of lookups
(*/icons/hicolor/16x16/devices etc.) for icons probably at KF5 and KIO
level and alike - they can be reduced only if traditional icon files are
uninstalled or installed away from the default search path.
Each stat() on Windows would take more time.
On 7 March 2016 at 15:53, Jaroslaw Staniek <stan...@kde.org> wrote:
>
>
> On 7 March 2016 at 14:45, René J.V. <rjvber...@gmail.com> wrote:
>
>> On Monday March 07 2016 12:41:52 Jaroslaw Staniek wrote:
>> >I am trying to use app-defined icons through QIcon::fromTheme() in Kexi.
>>
>> That sounds inherently wrong unless the application adds icons to
>> specific themes. Icons that are specific to an application are (almost) by
>> definition not part of a theme, so expecting QIcon::fromTheme() to return
>> them seems a bit of a misunderstanding.
>>
>
> I am using the icons theme infra for this. Alternative would be to
> duplicate the code to achieve exactly the same. QIcon(filename) does not
> even support multiple sizes; you need to code this. Note how a Kate plugin
> I mentioned above uses hardcoded
> ":/katesql/pics/16-actions-sql-field-pk.png" file.
> Please also note I am not mixing breeze theme and app's breeze icons. They
> are separated.
>
>
>> >Without that I'd have to duplicate logic of icon themes just to make
>> QIcon::fromTheme() work cross-platform.
>>
>> Why? Why not do as Kate and use QIcon(":/icon-from-rcc") instead of
>> QIcon::fromTheme() for app-specific icons that should be independent of the
>> user's icon theme choice, and ::fromTheme() for those icons that are
>> supposed to reflect his/her choice of theme?
>>
>
> Because I am not reflecting the choice in Kexi's icons. The only that are
> produced (takes weeks) and referenced in docs are the breeze ones. Anyone
> is free to start project aimed at supporting another theme. This is a
> switch in philosophy to boost the quality, and I accept you may disagree.
> But how icons are packaged distributed should reflect the development
> process and priorities of the app project.
>
>
>>
>> I don't think there's any need whatsoever to duplicate (reimplement) the
>> logic of icon themes. AFAIK, QIcon::fromTheme() will work anywhere once you
>> define an icon theme search path and the expected icon theme is installed
>> somewhere in that path.
>>
>> BTW, am I right that using a builtin binary rcc icon set could make you
>> lose in terms of memory (RAM) footprint overhead what you gain in terms of
>> disk space overhead?
>>
>
> With all due respect. Dunno. I am writing this email in a 2GiB large
> email client (GMail in Firefox).
> With thousands of cached icons and copies of jQuery. We're still super
> light.
>
> As David Faure said not once here, technically we just don't have KDE apps
> anymore. We have Qt apps. We can't assume themes are installed, properly
> installed, or caching is in place. Optimizations is the 1% remaining thing.
> I know no user who abandons software because of such things. Mac had
> universal binaries for years, with interesting growth in size. FatELF,
> application containers, all these are approaches that spend a few bytes in
> exchange for convenience, security, etc.
>
> My kexi_breeze.rcc is 184
> k an full (unoptimized) breeze.rcc is 14M compressed 35MiB fully
> uncompressed, while my wallpapers on just 2 screens are 18M compressed,
> ~120MiB in graphics RAM. And many of the icon file take >=4096 bytes
> despite being 2048 bytes large.
> I guess you also know that random-accessed files are mmapped and read on
> demand. Though I bet a 14M file will be read-ahead on any todays system.
>
> 2016 calling :) The resource files are easily handled in my years-old
> smartphone, so...
>
> There's nearly zero stat() calls for icons discovery instead of thousands
> per (even tiny) app.
> And packagers can easily package breeze.rcc (I'd recommend this in a
> README.PACKAGERS file).
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/j
Re: RCC for icons - update: Re: Icons installed by apps
On 7 March 2016 at 14:45, René J.V. <rjvber...@gmail.com> wrote:
> On Monday March 07 2016 12:41:52 Jaroslaw Staniek wrote:
> >I am trying to use app-defined icons through QIcon::fromTheme() in Kexi.
>
> That sounds inherently wrong unless the application adds icons to specific
> themes. Icons that are specific to an application are (almost) by
> definition not part of a theme, so expecting QIcon::fromTheme() to return
> them seems a bit of a misunderstanding.
>
I am using the icons theme infra for this. Alternative would be to
duplicate the code to achieve exactly the same. QIcon(filename) does not
even support multiple sizes; you need to code this. Note how a Kate plugin
I mentioned above uses hardcoded
":/katesql/pics/16-actions-sql-field-pk.png" file.
Please also note I am not mixing breeze theme and app's breeze icons. They
are separated.
> >Without that I'd have to duplicate logic of icon themes just to make
> QIcon::fromTheme() work cross-platform.
>
> Why? Why not do as Kate and use QIcon(":/icon-from-rcc") instead of
> QIcon::fromTheme() for app-specific icons that should be independent of the
> user's icon theme choice, and ::fromTheme() for those icons that are
> supposed to reflect his/her choice of theme?
>
Because I am not reflecting the choice in Kexi's icons. The only that are
produced (takes weeks) and referenced in docs are the breeze ones. Anyone
is free to start project aimed at supporting another theme. This is a
switch in philosophy to boost the quality, and I accept you may disagree.
But how icons are packaged distributed should reflect the development
process and priorities of the app project.
>
> I don't think there's any need whatsoever to duplicate (reimplement) the
> logic of icon themes. AFAIK, QIcon::fromTheme() will work anywhere once you
> define an icon theme search path and the expected icon theme is installed
> somewhere in that path.
>
> BTW, am I right that using a builtin binary rcc icon set could make you
> lose in terms of memory (RAM) footprint overhead what you gain in terms of
> disk space overhead?
>
With all due respect. Dunno. I am writing this email in a 2GiB large email
client (GMail in Firefox).
With thousands of cached icons and copies of jQuery. We're still super
light.
As David Faure said not once here, technically we just don't have KDE apps
anymore. We have Qt apps. We can't assume themes are installed, properly
installed, or caching is in place. Optimizations is the 1% remaining thing.
I know no user who abandons software because of such things. Mac had
universal binaries for years, with interesting growth in size. FatELF,
application containers, all these are approaches that spend a few bytes in
exchange for convenience, security, etc.
My kexi_breeze.rcc is 184
k an full (unoptimized) breeze.rcc is 14M compressed 35MiB fully
uncompressed, while my wallpapers on just 2 screens are 18M compressed,
~120MiB in graphics RAM. And many of the icon file take >=4096 bytes
despite being 2048 bytes large.
I guess you also know that random-accessed files are mmapped and read on
demand. Though I bet a 14M file will be read-ahead on any todays system.
2016 calling :) The resource files are easily handled in my years-old
smartphone, so...
There's nearly zero stat() calls for icons discovery instead of thousands
per (even tiny) app.
And packagers can easily package breeze.rcc (I'd recommend this in a
README.PACKAGERS file).
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RCC for icons - update: Re: Icons installed by apps
On 7 March 2016 at 10:46, Jaroslaw Staniek <stan...@kde.org> wrote: > > > On 18 February 2016 at 18:25, Kåre Särs <kare.s...@iki.fi> wrote: > >> On Thursday, February 18, 2016 02:51:58 PM René J.V. Bertin wrote: >> > On Thursday February 18 2016 13:55:18 Jaroslaw Staniek wrote: >> > >>> > since QIcon::fromTheme() apaprently isn't able to find app icons. >> > >> > Care to explain? QIcon::fromTheme() doesn't find anything "out of the >> box" >> > on OS X (and I presume on MS Windows), but that is only because no theme >> > search path is set on those platforms. When you add the standard XDG >> icon >> > repository to the icon search path on OS X, even "pure" Qt5 application >> > will start showing icons all over if you have an icon theme installed -- >> > including in widgets that should not have icons according to the HIG. >> Also >> > on OS X, fromTheme() will only return the application icon (as in the >> icon >> > shown in the Finder) if the current theme defines that same icon for the >> > calling application, and the theme search path is set of course. In all >> > other cases it will not, because the application icon is not defined >> > through a theme on OS X (nor is it on MS Windows, I presume). >> > >> I think the solution with a packaged breeze icons resource working >> > >> out-of-the box could be a good (lightweight) addition for non-Plasma >> > >> (non-Linux?) users of KF5, to popularize KF5. They grab the icons >> package >> > >> > Popularise, with Breeze "art"work? O:-) >> > Anyway, I don't think "grabbing an icon package" will work on OS X, >> not if >> > you want to create standalone app bundles which by definition contain >> > everything they need. >> > >> and icons just work without thousands of files, caching, etc. 'One >> in a >> > >> million' would of these users would be interested in theming. >> > >> > I'd up that estimate if we're still talking about Breeze icons here O:-) >> > >> > >> PS2: I have been beaten by situations such as KToolBar setting 0-size >> > >> icons by default. >> > >> > Partly this is because almost no KF5 code uses the fallback argument of >> > QIcon::fromTheme() explicitly, which means that the function returns an >> > empty icon if the search fails. In particular, statements like >> > >> > app->setWindowIcon(QIcon::fromTheme(programName)) >> > >> > should read >> > >> > app->setWindowIcon(QIcon::fromTheme(programName, app->windowIcon())) >> > >> > >> This is in a Windows env where no themes are (properly) installed. >> If the >> > >> rcc-based solution is in use I would imagine that ideally all the KF5 >> > >> code >> > >> detects this somehow and would not look for xdg standard themes >> through >> > >> the >> > >> classic KIconLoader but silently adapt so the rcc resource works >> great. >> > >> Just a dream. >> > >> > If your rcc resource corresponds to the resource mentioned in the >> > QIcon::fromTheme() documentation (I think that talks about "qrc") and >> if I >> > interpret that documentation correctly then yes, code using that >> function >> > will find icons from the rcc/qrc "builtin" resource over those in xdg >> > themes (if the XDG icon repository is even in the icon theme search >> path). >> > >>> What I don't know however is whether artists consider that these >> icons >> > >>> should be themeable... >> > >> > I think icon artists will consider that you should touch their icons >> (for >> > theming or anything else). They will probably also consider that their >> > icons are the "best" but they really should also consider it a right for >> > anyone to use other icons ;) >> > >> >> The breeze.rcc file way is actually how Christoph solved it in Kate for >> Windows and OSX. We create an .rcc file from the breeze icons and at >> start-up >> we search for the file in QStandardPaths::DataLocation and if the file is >> found we load it with registerResource() and add ":/icons" to the >> themeSearchPaths. (kate.git/icons.h) >> >> Christoph also added ":/icons" to the search path in kicontheme so that >> xmlgui >> toolb
Re: RCC for icons - update: Re: Icons installed by apps
On 18 February 2016 at 18:25, Kåre Särs <kare.s...@iki.fi> wrote: > On Thursday, February 18, 2016 02:51:58 PM René J.V. Bertin wrote: > > On Thursday February 18 2016 13:55:18 Jaroslaw Staniek wrote: > > >>> > since QIcon::fromTheme() apaprently isn't able to find app icons. > > > > Care to explain? QIcon::fromTheme() doesn't find anything "out of the > box" > > on OS X (and I presume on MS Windows), but that is only because no theme > > search path is set on those platforms. When you add the standard XDG icon > > repository to the icon search path on OS X, even "pure" Qt5 application > > will start showing icons all over if you have an icon theme installed -- > > including in widgets that should not have icons according to the HIG. > Also > > on OS X, fromTheme() will only return the application icon (as in the > icon > > shown in the Finder) if the current theme defines that same icon for the > > calling application, and the theme search path is set of course. In all > > other cases it will not, because the application icon is not defined > > through a theme on OS X (nor is it on MS Windows, I presume). > > >> I think the solution with a packaged breeze icons resource working > > >> out-of-the box could be a good (lightweight) addition for non-Plasma > > >> (non-Linux?) users of KF5, to popularize KF5. They grab the icons > package > > > > Popularise, with Breeze "art"work? O:-) > > Anyway, I don't think "grabbing an icon package" will work on OS X, not > if > > you want to create standalone app bundles which by definition contain > > everything they need. > > >> and icons just work without thousands of files, caching, etc. 'One in > a > > >> million' would of these users would be interested in theming. > > > > I'd up that estimate if we're still talking about Breeze icons here O:-) > > > > >> PS2: I have been beaten by situations such as KToolBar setting 0-size > > >> icons by default. > > > > Partly this is because almost no KF5 code uses the fallback argument of > > QIcon::fromTheme() explicitly, which means that the function returns an > > empty icon if the search fails. In particular, statements like > > > > app->setWindowIcon(QIcon::fromTheme(programName)) > > > > should read > > > > app->setWindowIcon(QIcon::fromTheme(programName, app->windowIcon())) > > > > >> This is in a Windows env where no themes are (properly) installed. If > the > > >> rcc-based solution is in use I would imagine that ideally all the KF5 > > >> code > > >> detects this somehow and would not look for xdg standard themes > through > > >> the > > >> classic KIconLoader but silently adapt so the rcc resource works > great. > > >> Just a dream. > > > > If your rcc resource corresponds to the resource mentioned in the > > QIcon::fromTheme() documentation (I think that talks about "qrc") and if > I > > interpret that documentation correctly then yes, code using that function > > will find icons from the rcc/qrc "builtin" resource over those in xdg > > themes (if the XDG icon repository is even in the icon theme search > path). > > >>> What I don't know however is whether artists consider that these > icons > > >>> should be themeable... > > > > I think icon artists will consider that you should touch their icons (for > > theming or anything else). They will probably also consider that their > > icons are the "best" but they really should also consider it a right for > > anyone to use other icons ;) > > > > The breeze.rcc file way is actually how Christoph solved it in Kate for > Windows and OSX. We create an .rcc file from the breeze icons and at > start-up > we search for the file in QStandardPaths::DataLocation and if the file is > found we load it with registerResource() and add ":/icons" to the > themeSearchPaths. (kate.git/icons.h) > > Christoph also added ":/icons" to the search path in kicontheme so that > xmlgui > toolbars and friends also get the icons from the .rcc file. > > We get all the same icons as on Linux neatly in one file :) > Thanks, it works on Windows (no platform theme). How to make it work on Linux too (KF5 5.19.0, Qt 5.5.1), i.e. I'd like to have only used icons from the .rcc regardless of availability of FrameworkIntegrationPlugin.so KDEPlatformTheme.so? We're talking about this code: https://quickgit.kde.org/?p=kate.git=blob=icons.h
Re: RCC for icons - update: Re: Icons installed by apps
On 18 February 2016 at 18:25, Kåre Särs <kare.s...@iki.fi> wrote: > On Thursday, February 18, 2016 02:51:58 PM René J.V. Bertin wrote: > > On Thursday February 18 2016 13:55:18 Jaroslaw Staniek wrote: > > >>> > since QIcon::fromTheme() apaprently isn't able to find app icons. > > > > Care to explain? QIcon::fromTheme() doesn't find anything "out of the > box" > > on OS X (and I presume on MS Windows), but that is only because no theme > > search path is set on those platforms. When you add the standard XDG icon > > repository to the icon search path on OS X, even "pure" Qt5 application > > will start showing icons all over if you have an icon theme installed -- > > including in widgets that should not have icons according to the HIG. > Also > > on OS X, fromTheme() will only return the application icon (as in the > icon > > shown in the Finder) if the current theme defines that same icon for the > > calling application, and the theme search path is set of course. In all > > other cases it will not, because the application icon is not defined > > through a theme on OS X (nor is it on MS Windows, I presume). > > >> I think the solution with a packaged breeze icons resource working > > >> out-of-the box could be a good (lightweight) addition for non-Plasma > > >> (non-Linux?) users of KF5, to popularize KF5. They grab the icons > package > > > > Popularise, with Breeze "art"work? O:-) > > Anyway, I don't think "grabbing an icon package" will work on OS X, not > if > > you want to create standalone app bundles which by definition contain > > everything they need. > > >> and icons just work without thousands of files, caching, etc. 'One in > a > > >> million' would of these users would be interested in theming. > > > > I'd up that estimate if we're still talking about Breeze icons here O:-) > > > > >> PS2: I have been beaten by situations such as KToolBar setting 0-size > > >> icons by default. > > > > Partly this is because almost no KF5 code uses the fallback argument of > > QIcon::fromTheme() explicitly, which means that the function returns an > > empty icon if the search fails. In particular, statements like > > > > app->setWindowIcon(QIcon::fromTheme(programName)) > > > > should read > > > > app->setWindowIcon(QIcon::fromTheme(programName, app->windowIcon())) > > > > >> This is in a Windows env where no themes are (properly) installed. If > the > > >> rcc-based solution is in use I would imagine that ideally all the KF5 > > >> code > > >> detects this somehow and would not look for xdg standard themes > through > > >> the > > >> classic KIconLoader but silently adapt so the rcc resource works > great. > > >> Just a dream. > > > > If your rcc resource corresponds to the resource mentioned in the > > QIcon::fromTheme() documentation (I think that talks about "qrc") and if > I > > interpret that documentation correctly then yes, code using that function > > will find icons from the rcc/qrc "builtin" resource over those in xdg > > themes (if the XDG icon repository is even in the icon theme search > path). > > >>> What I don't know however is whether artists consider that these > icons > > >>> should be themeable... > > > > I think icon artists will consider that you should touch their icons (for > > theming or anything else). They will probably also consider that their > > icons are the "best" but they really should also consider it a right for > > anyone to use other icons ;) > > > > The breeze.rcc file way is actually how Christoph solved it in Kate for > Windows and OSX. We create an .rcc file from the breeze icons and at > start-up > we search for the file in QStandardPaths::DataLocation and if the file is > found we load it with registerResource() and add ":/icons" to the > themeSearchPaths. (kate.git/icons.h) > > Christoph also added ":/icons" to the search path in kicontheme so that > xmlgui > toolbars and friends also get the icons from the .rcc file. > > We get all the same icons as on Linux neatly in one file :) > > breesze's symlinks was a problem on windows, but I created a small > application > to replace the symlinked files with an alias pointing to the target file -> > smaller .rcc file :) > Thanks for reminding this, Kåre! I went this way and started with manual creation of rcc on Windows. Then I've added s
Re: Review Request 127122: [Kate] Back/Forward mouse buttons
On Saturday, 20 February 2016, Anthony Fieroni <bvb...@abv.bg> wrote: > This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127122/ > Review request for Kate and KDE Frameworks. > By Anthony Fieroni. > Repository: kate > > Description > > Show prev/next tab on mouse back/forward buttons > > Testing > > I have a mindless idea to assign KStandardAction::Back/Forward to mouse buttons back/forward in kxmlgui. It looks wrong, but will be usefull for all KDE apps. > > Diffs > > kate/katemainwindow.h (ece0db8) > kate/katemainwindow.cpp (d2459da) > > View Diff Hi Anthony. In theory it's consistent change but please reconsider these default. I bought that 11 button cm storm mouse. Such gaming mices when used outside of games have habit to accidentally trigger back/forward buttons when you are not extra careful with your touch. X11 just have the keys mapped by default. This made Firefox unusable to me unless I remap the keys at system level. I'd imagine that most users will not know how to do it and frustration would come back to us. And very few users need/want to go back from keyboard to mouse in order to switch between documents. Those that want that can easily find the option. IMHO. We have excellent shortcut config dialogs. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RCC for icons - update: Re: Icons installed by apps
On 18 February 2016 at 14:51, René J.V. <rjvber...@gmail.com> wrote: > On Thursday February 18 2016 13:55:18 Jaroslaw Staniek wrote: > > >>> > since QIcon::fromTheme() apaprently isn't able to find app icons. > > Care to explain? QIcon::fromTheme() doesn't find anything "out of the box" > on OS X (and I presume on MS Windows), but that is only because no theme > search path is set on those platforms. When you add the standard XDG icon > repository to the icon search path on OS X, even "pure" Qt5 application > will start showing icons all over if you have an icon theme installed -- > including in widgets that should not have icons according to the HIG. > Sure but we all agree that outside of desktops adjusted for the taste of geeks XDG isn't part of these OSes. I don't plan to bundle shared theme dir or support that for users by default. I'd leave that to extensions maintained by enthusiasts :) Also on OS X, fromTheme() will only return the application icon (as in the > icon shown in the Finder) if the current theme defines that same icon for > the calling application, and the theme search path is set of course. In all > other cases it will not, because the application icon is not defined > through a theme on OS X (nor is it on MS Windows, I presume). > > >> I think the solution with a packaged breeze icons resource working > >> out-of-the box could be a good (lightweight) addition for non-Plasma > >> (non-Linux?) users of KF5, to popularize KF5. They grab the icons > package > > Popularise, with Breeze "art"work? O:-) > Yes but mainly in the Qt (so also KDE) world :) I hope that making any valuable Qt app look more pro thanks to that is even better investment than popularizing GIMP and LibreOffice via that artwork before even Qt/KDE equivalents are shipped in stable on Win/Mac (Krita, Calligra). > Anyway, I don't think "grabbing an icon package" will work on OS X, not > if you want to create standalone app bundles which by definition contain > everything they need. > What I mean is "grabbing an icon package by software devs", not users. Adding the self-contained theme to the package would be a matter of 'a few clicks' (it's also legal becase that's combination within a media, not linking). > > >> and icons just work without thousands of files, caching, etc. 'One in a > >> million' would of these users would be interested in theming. > > I'd up that estimate if we're still talking about Breeze icons here O:-) > I mean one instance of the icon package, that uses Breeze. Anyone is free to create similarly complete package out of other theme but this should not be a trouble for app authors. I'd propose to delegate this out of the app projects. > > >> PS2: I have been beaten by situations such as KToolBar setting 0-size > >> icons by default. > > Partly this is because almost no KF5 code uses the fallback argument of > QIcon::fromTheme() explicitly, which means that the function returns an > empty icon if the search fails. > In particular, statements like > > app->setWindowIcon(QIcon::fromTheme(programName)) > > should read > > app->setWindowIcon(QIcon::fromTheme(programName, app->windowIcon())) > > > >> This is in a Windows env where no themes are (properly) installed. If > the > >> rcc-based solution is in use I would imagine that ideally all the KF5 > code > >> detects this somehow and would not look for xdg standard themes through > the > >> classic KIconLoader but silently adapt so the rcc resource works great. > >> Just a dream. > > If your rcc resource corresponds to the resource mentioned in the > QIcon::fromTheme() documentation (I think that talks about "qrc") and if I > interpret that documentation correctly then yes, code using that function > will find icons from the rcc/qrc "builtin" resource over those in xdg > themes (if the XDG icon repository is even in the icon theme search path). > > Yes, I'll try that in the same way as Kate on win/mac. And share the results, for sure. > >>> What I don't know > > > however is whether artists consider that these icons > >>> should be themeable... > > > > I think icon artists will consider that you should touch their icons (for > theming or anything else). They will probably also consider that their > icons are the "best" but they really should also consider it a right for > anyone to use other icons ;) > > (that >>> was a comment David : ) but I agree In short either all icons used by a given app are supported by selected theme, or theming is a waste of effort. After years I
Re: RCC for icons - update: Re: Icons installed by apps
And BTW, just found this.. so adding CC for Lars and Simon.
https://mail.kde.org/pipermail/kde-optimize/2005-June/001096.html
On 18 February 2016 at 12:05, Jaroslaw Staniek <stan...@kde.org> wrote:
>
> On 24 September 2015 at 23:04, David Faure <fa...@kde.org> wrote:
>
>> On Tuesday 22 September 2015 18:44:47 Jaroslaw Staniek wrote:
>> > On 22 September 2015 at 14:17, Jaroslaw Staniek <stan...@kde.org>
>> wrote:
>> > > Hello,
>> > > A couple of related questions while wrestling with issues such as [1].
>> > >
>> > > Let's assume Kexi app installs some icons to
>> > > PREFIX/share/kexi/icons/oxygen/32x32/places/ or
>> > > PREFIX/share/kexi/icons/breeze/32x32/places.
>> > > Can these be searched by the icon engine?
>> >
>> > Sorry for adding more info to clarify.
>> > UserIconSet is deprecated so I guess this functionality is deprecated
>> too...
>> > since QIcon::fromTheme() apaprently isn't able to find app icons.
>> >
>> > I've seen quite a few KDE apps compiling-in their (usually custom
>> > action) icons into qrc instead.
>> >
>> > I've not seen other app that do what Calligra apps do:
>> > using icons fron share/calligra/icons (in kdelibs4 times
>> > share/apps/calligra/icons).
>> >
>> > Comments?
>>
>> I guess qrc is actually better. Otherwise app1 might start depending on
>> icon installed
>> by app2 (without really noticing). And this simplifies deployment (and
>> speeds up lookup).
>>
>
> Hi David & All. I am back to this topic.
>
> I've got some experiments. .rcc files for icons is a nice thing, not to
> big, obviously quick to deploy.
>
> There's *rcc --project*
> (Outputs a qrc resource file containing all files from the current
> directory)
>
> Now, how to deal with it?
> Is a variant of KIconLoader needed that works with QResources?
> Obviously we need a QIconEngine-level solution to have icons available on
> demand instead of such hacks:
>
> QIcon tableIcon;
>
> tableIcon.addPixmap(QPixmap(":/icons/16-actions-table.png"));
>
> tableIcon.addPixmap(QPixmap(":/icons/22-actions-table.png"));
>
> tableIcon.addPixmap(QPixmap(":/icons/32-actions-table.png"));
>
> someQAction->setIcon(tableIcon)
>
>
> One approach is to build rcc out of a fresh installed
> PREFIX/share/icons/breeze/* files and does with the paths in a standard
> way. This is why I am looking at opportunity of reusing the logic of
> KIconLoader. Or maybe it's all silly because it's ready to use and I missed
> something?
>
> To build .rcc's I am using cmake's qt5_add_binary_resources() for Qt>=5.5
> with some add_custom_command() fallback for older Qt.
>
> At higher level, I was thinking about a reusable implementation, that
> eventually would maybe land in KIconThemes if there's interest. Or maybe as
> a separate tiny lib.
> I think the solution with a packaged breeze icons resource working
> out-of-the box could be a good (lightweight) addition for non-Plasma
> (non-Linux?) users of KF5, to popularize KF5. They grab the icons package
> and icons just work without thousands of files, caching, etc. 'One in a
> million' would of these users would be interested in theming.
> And this solution is generally usable for any Qt apps even if nothing else
> from KF5 is used: just load .rcc dynamically and things work.
>
> That's just a lower priority. My actual test is the application of the
> idea for Kexi.
>
> PS1: Feature I'm also considering: converting svgs to pngs before creating
> the rcc files. Not sure but svgs can be included too, for general use in
> big sizes and for high DPI screens.
>
> PS2: I have been beaten by situations such as KToolBar setting 0-size
> icons by default.
> This is in a Windows env where no themes are (properly) installed. If the
> rcc-based solution is in use I would imagine that ideally all the KF5 code
> detects this somehow and would not look for xdg standard themes through the
> classic KIconLoader but silently adapt so the rcc resource works great.
> Just a dream.
>
> PS3: A bonus of not having thousands of icon files is that some KDE apps
> are more capable to become 'portable apps' (in the http://portableapps.com
> meaning).
>
>
>>
>> What I don't know however is whether artists consider that these icons
>> should be themeable...
>>
>> BTW did you look into the xdg icon spec?
>> I guess it's not there?
>> On the other hand it doesn't prevent doing it since it's not about
>> sharing icons; it's just harder
>> to conv
RCC for icons - update: Re: Icons installed by apps
On 24 September 2015 at 23:04, David Faure <fa...@kde.org> wrote:
> On Tuesday 22 September 2015 18:44:47 Jaroslaw Staniek wrote:
> > On 22 September 2015 at 14:17, Jaroslaw Staniek <stan...@kde.org> wrote:
> > > Hello,
> > > A couple of related questions while wrestling with issues such as [1].
> > >
> > > Let's assume Kexi app installs some icons to
> > > PREFIX/share/kexi/icons/oxygen/32x32/places/ or
> > > PREFIX/share/kexi/icons/breeze/32x32/places.
> > > Can these be searched by the icon engine?
> >
> > Sorry for adding more info to clarify.
> > UserIconSet is deprecated so I guess this functionality is deprecated
> too...
> > since QIcon::fromTheme() apaprently isn't able to find app icons.
> >
> > I've seen quite a few KDE apps compiling-in their (usually custom
> > action) icons into qrc instead.
> >
> > I've not seen other app that do what Calligra apps do:
> > using icons fron share/calligra/icons (in kdelibs4 times
> > share/apps/calligra/icons).
> >
> > Comments?
>
> I guess qrc is actually better. Otherwise app1 might start depending on
> icon installed
> by app2 (without really noticing). And this simplifies deployment (and
> speeds up lookup).
>
Hi David & All. I am back to this topic.
I've got some experiments. .rcc files for icons is a nice thing, not to
big, obviously quick to deploy.
There's *rcc --project*
(Outputs a qrc resource file containing all files from the current
directory)
Now, how to deal with it?
Is a variant of KIconLoader needed that works with QResources?
Obviously we need a QIconEngine-level solution to have icons available on
demand instead of such hacks:
QIcon tableIcon;
tableIcon.addPixmap(QPixmap(":/icons/16-actions-table.png"));
tableIcon.addPixmap(QPixmap(":/icons/22-actions-table.png"));
tableIcon.addPixmap(QPixmap(":/icons/32-actions-table.png"));
someQAction->setIcon(tableIcon)
One approach is to build rcc out of a fresh installed
PREFIX/share/icons/breeze/* files and does with the paths in a standard
way. This is why I am looking at opportunity of reusing the logic of
KIconLoader. Or maybe it's all silly because it's ready to use and I missed
something?
To build .rcc's I am using cmake's qt5_add_binary_resources() for Qt>=5.5
with some add_custom_command() fallback for older Qt.
At higher level, I was thinking about a reusable implementation, that
eventually would maybe land in KIconThemes if there's interest. Or maybe as
a separate tiny lib.
I think the solution with a packaged breeze icons resource working
out-of-the box could be a good (lightweight) addition for non-Plasma
(non-Linux?) users of KF5, to popularize KF5. They grab the icons package
and icons just work without thousands of files, caching, etc. 'One in a
million' would of these users would be interested in theming.
And this solution is generally usable for any Qt apps even if nothing else
from KF5 is used: just load .rcc dynamically and things work.
That's just a lower priority. My actual test is the application of the idea
for Kexi.
PS1: Feature I'm also considering: converting svgs to pngs before creating
the rcc files. Not sure but svgs can be included too, for general use in
big sizes and for high DPI screens.
PS2: I have been beaten by situations such as KToolBar setting 0-size icons
by default.
This is in a Windows env where no themes are (properly) installed. If the
rcc-based solution is in use I would imagine that ideally all the KF5 code
detects this somehow and would not look for xdg standard themes through the
classic KIconLoader but silently adapt so the rcc resource works great.
Just a dream.
PS3: A bonus of not having thousands of icon files is that some KDE apps
are more capable to become 'portable apps' (in the http://portableapps.com
meaning).
>
> What I don't know however is whether artists consider that these icons
> should be themeable...
>
> BTW did you look into the xdg icon spec?
> I guess it's not there?
> On the other hand it doesn't prevent doing it since it's not about sharing
> icons; it's just harder
> to convince Qt to look there :) (I think qiconengine and kiconengine
> should stay compatible,
> so that we can even consider switching to qiconengine one day).
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional
On 28 January 2016 at 11:47, Martin Graesslin <mgraess...@kde.org> wrote: > On Thursday, January 28, 2016 11:10:20 AM CET Jaroslaw Staniek wrote: > > Now instead of that, everything but truly uncommon stuff would be ON by > > default. If someone knows what she/he is doing, will set to OFF but > this > > will be actually a choice, hopefully informed choice. > > > > Can we encourage the use of this approach? > > This is kind of the same as I suggest with the "No DBus Profile"? > > Yes. I believe somewhere deep in our philosophy is the fact that our origins come from Unix-like environments. I've been always a proponent of native experience on every OS (no Plasma or KWin for Windows outside of a playgoround, etc). Even if that means less performant apps or dumbing-down, let it be if the owner of the OS made it so for whatever reason. More often than not, differences in architectures are too deep to fight for popularizing usable abstractions (see various multimedia Qt APIs across the years) and it's nobody's fault. It's not a problem to have a recipe for "non-core" OS-es showing even dozens of -D options to cmake. Better, it's a kind of self-documenting approach in a way I see opposite to the above proposed idea of using dummy plugins or libs. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Menu/Command capitalization
On 8 January 2016 at 00:28, Pino Toscano <p...@kde.org> wrote: > Hi, > > In data giovedì 7 gennaio 2016 22:42:18, Jaroslaw Staniek ha scritto: >> Not too long ago MS Windows has moved from "Title Capitalization" to >> "Sentence capitalization" for menus and commands: >> https://msdn.microsoft.com/en-us/library/dn742392.aspx >> >> What can we do and should we do something about this? > > Nothing IMHO -- see below. > >> - For everyone else perhaps it's better to offer something officially >> or else some people would fork translations or avoid using KDE's code. > > You don't need to fork anything, just provide a "translation" on top of > the untranslated strings. Thanks for the notes, Pino. That was not the exact question. What I mean is who provides the translation. If not KDE, then the whole thing can only be forked unspecified number of times. In extreme case, if "Foo Bar" is replaced with "Foo bar" _in the code_, then also the code is also forked. Not good. Regarding the number of locales, I see things do not look that bad: we have en_US == C and en_GB only. Please correct me here. My idea is to provide extra English translations that are variants of the originals but with sentence capitalization. Ideally that would be the two extra: - en_GBS (based on en_GB) - en_USS (based on en_US) (S suffix == Sentence) I believe both can be largely generated on demand. Title capitalization is possible to automate (e.g. see http://titlecapitalization.com) but the opposite direction is even easier, we "just" need a list of exceptions and ability to control the process e.g. in a context string. Among others, proper nouns may need to be kept Uppercase. This is my initial overview. Technically at Qt level: Having the en_*S locales, our apps/libs would need to use them under certain conditions (e.g. on Android, Windows) instead of the original locales. Do nothing e.g. on Mac OS X. >> - Is automated conversion for capitalization a reasonable approach? >> Runtime or script-based generation. > > Definitely not: please never ever mess up with user-visible strings. Please see the above, maybe what I propose is nice enough, better than half of the strings in app in one style (KF5 strings), another in other style (app strings). Even the same title could have two forms in the same app. The same button's text. >> - Do we have checks for semantic strings and capitalization? If so >> would they need updates, or? > > By hand, when somebody spots a mistake and fixes it. > >> - Some (future?) KF5 users would target Windows expecting that the >> resulting apps look and feel largely native. > >> [...] > >> - Mac OS X and iOS is consistent with KDE capitalization: >> >> https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/2957-CH15-SW4 > > To simplify the situation: > - right now we are like OS-A but different than OS-B > - with your proposal, we would be like OS-B but different than OS-A > So, there would be always a class of users feeling "native" (regarding > the string capitalization), and another one feeling "alien". I've done a small research for you in the original post. There are not just *two* OSes. OS-A == Android, Jolla, Windows Phone, Windows Desktop OS-B == Mac OS X, iOS And KDE, GNOME (etc): undecided but actually both are OS-B because their legacy is follows: KDE - Windows (before the world moved to Sentence cap.), GNOME: Mac OS X. So neither OS-A nor OS-B is a small group. If anything, OS-A is bigger in number of potential users (I don't count things like KDE Plasma but apps). So there's also question how our apps/KF components look under GNOME. > Sorry, but I don't see how mass-changing English strings, to end up in > the very same situation (1 like, 1 different) wrt other OSes. At least > for me, it has been hard enough to keep KDE applications following our > style in the last 10+ years, I don't want to start over again. I understand, the cost of manual work makes no sense. So there's a way to automate the conversion I hope. Anyone interested to write a script that adds en_GBS and en_USS locales? A more important question is also: what to do with new messages, new apps, libs. I am also asking myself. If 90% of app's installations was in mobile or Windows, using the sentence style in the code would make sense. But this breaks the OS-B support. So ideal support would be IMHO to stay with current Title Capitalization in the code and have en_GBS and en_USS locales either generated or maintained partially by hand. What I write here is for the record, I am not planning to maintain the locales except for cases when I need something like this for
Menu/Command capitalization
Hello, Asking here as this is somewhat a cross platform issue. I do admit it isn't a massive one but rather strange; I've never noted it before, I just recently had to help with that for a customer's app. Not too long ago MS Windows has moved from "Title Capitalization" to "Sentence capitalization" for menus and commands: https://msdn.microsoft.com/en-us/library/dn742392.aspx What can we do and should we do something about this? Questions and basic research follows: - Of course for (most) FOSS people with pragmatic "good-enough" approach such a small difference isn't a problem. Popular Windows FOSS apps such as LibreOffice and GIMP ignore the guidelines. If this is all you're interested in, you can stop reading already :) - For everyone else perhaps it's better to offer something officially or else some people would fork translations or avoid using KDE's code. - Some (future?) KF5 users would target Windows expecting that the resulting apps look and feel largely native. - Is automated conversion for capitalization a reasonable approach? Runtime or script-based generation. - Maintaining the compliance "by hand" basically adds another variant to each English variant of translation (US, UK,...) - Are there other locales than English that use the Title Capitalization? (it's good to know the scale) I've spotted this article https://en.wikipedia.org/wiki/Letter_case#Title_case but did not find non-english examples. - Do we have checks for semantic strings and capitalization? If so would they need updates, or? - Not just Windows. Android and Windows Phone is similarly "affected" in the discussed area. https://www.google.com/design/spec/style/writing.html#writing-capitalization-punctuation - Mac OS X and iOS is consistent with KDE capitalization: https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/2957-CH15-SW4 - The most intrusive but ultimate solution: make our English translations drop the Title Capitalization -- Advantage: no special case for English anymore so no mistakes in message strings (I've commited quite a few such fixes in my career, have you?) -- Disadvantage: we would start to be inconsistent with Mac OS X/iOS guidelines, and I'd guess only with those :) -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Icons missing
On 6 December 2015 at 13:56, Thorsten Zachmann <zachm...@kde.org> wrote: > Hello all, > > I use a separate user for running calligra. I use ssh -X to login from my > normal desktop user to my kde running user. However when I start any > kde application I have no icons. With strace I can see it searches for > icons > in the hicolor folder instead of breeze. > Hi Thorsten, I am with you here. If it's important to have at least the default icon theme fully working regardless of the actual environment, hard coding icons to have just one theme is the compromise. This is the direction I am testing for Kexi. The only icons not owned by Kexi are the absolute fd.o standard subset (but even this may be distributed on non-fd.o platforms of course). Kexi is prepared now for that, uses special prefixes for breeze and oxygen-like themes. -> https://quickgit.kde.org/?p=calligra.git=tree=HEAD=kexi%2Fpics%2Fhicolor But it gets complex/error-prone. I am close to switching to a qrc files (one per theme). This thread shows the past discussion, not the only one I suppose: https://mail.kde.org/pipermail/kexi-devel/2015-September/000418.html Moreover when Qt-only libraries pop out from our code (as it's in case of Kexi) we want them to mix well with non-KDE apps because we want more users. The question is, why themes? Complex apps such as Calligra have many special icons [1]. I don't expect various themes (often originating from the outside of KF5-based environments) nicely following requirements and maintained for 100% compatibility. And nobody is to blame, the result is not worth the effort IMHO. And I've not seen many things worse than incomplete theme, half-oxygen, half-breeze for example. So I'd say "never again" and let's avoid such situation before the first stable release. A bonus is that it's eventually possible to properly document applications: screenshots will refer to real default look and feel. (well, for that also hardcoding Breeze QWidget style is needed :). [1] https://community.kde.org/index.php?title=Calligra/Icons/3.0 PS: It's all about priorities, I'm far from removing freedom. For people who really love to theme complex apps (1% of geeks?) firefox-like theming is quite possible: deliver theming extension that injects app-specific theming. If a theme is broken, then one can uninstall the extension or request fixes from the author of the extension, not from the application's team. That's the true nature of the plugin system - allow to decentralize the deployment. PS#2: Before asking about performance. Hello in 2015. Your smartphone and smartwatch injects and hardcodes icons already. If you read the post via a modern browser with javascript it eats you 1GiB RAM minimum and your icons/pixmap cache is 1GiB too. And many MB for the screen buffer of your 1GB+ graphics card all, in an uncompressed format :) > With the help of David Faure I found out the the icons are shown as > expected > when I call > > export KDE_FULL_SESSION=true > > before starting the application. > > I think using an application via ssh -X is used quite often and it should > work > out of the box with the need of setting any special export. Maybe you have > an > idea on how the behaviour can be improved. > > Please CC me as I'm not subscribed to the list. > > Thorsten Zachmann > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Icons missing on ssh -X, or: no real system default for icon theme
t already deployed apps if apps will maintain own snapshots of icons they use. After all apps' release is a snapshot of its source code too, and releases are not in sync. No app uses all the icons, and all Breeze icons take like 6M compressed. In a world where apps start to be deployed using VMs. > * at runtime even different versions of the same icon type might be used, > as > each app has its own copy (& not updated in-sync from normal breeze > iconset) > * preventing new icon themes to be created, as every app would need to be > hacked to enable the new theme during development > If we use qrc, qrc can be replaced. LO and Firefox have own systems for that. If someone really wants to theme an app, he/she will do that. Example: The breeze team greatly themed LO despite it using completely separate system. LO is Breeze-themed before we, in Calligra, even collected a list of TODOs (!). And I have found official version for Windows with this theme and use. (still no opensuse 13.2 version, that's an irony -- where's the benefit of modularization?) Plasma 4 was themeable but most themes were like variants of the same original theme. It was easy to have icons out-of-place or non-contrasting. Icon theme and widget theme was so often not independent, this should be known as important fact: workspace's and application's look is a sum of icons+style+layouts. Just like I can't use any kind of wheels for a given car, I need to know the rules to be safe. > * one currently does not know what icons the KF5/Qt5/* libs & plugins used > by > the app need and if they exist (imagine you hardcoded to "oxygen", and now > the > libs use icons only in breeze. e.g. what if "breeze" is soon dropped for > some > "storm"?) > > Instead I would like to see us rather come up with proper documentation of > icon ids used by the apps (& libs & plugins) and provided by the different > icon themes. > So it is possible to check to what degree which icon themes match the set > of > apps/plugins/libs one uses. To decide if picking some other fancy icon > theme > will work for the personal needs. Or to see which icons are missings, or > which > are not used at all. > Yes, sad aspect of themeing is that styles do not fit to themes sometimes, is that themes break silently and not in the app, what can be surprising for average user. Maybe that's an issue with a shared infra. It isn't up to the "promise" while themeing knobs have prominent place in the system settings. > In Calligra we have some initial support for overseeing icon ids used, due > to > some "koIcon" tagging (reusing mechanisms of "i18n"). I hope to brush that > up > and turn that into something for ECM, so everyone can use it. If someone is > interested to help there, please contact me. > That's useful and should be promoted. Also when someone who uses qrc. For now Qt developers put the icons to the qrc by hand I guess, without scripts. > (When creating app bundles for those alien systems like Android, Windows, > OSX, > where each bundle rather needs their own copies of all used libs, > knowing what subset of icons are used by the own stack allows to avoid to > include the complete big Breeze icontheme). > Aren't icons compiled into mobile apps by the SDKs usually? And if someone ports the app, sometimes with completely custom/separate UI and the same internals, even mapping icon names to the target system names isn't too useful. Sometimes this is like using a custom script to sort a 3-element list. 2 hours of extra work. Thanks for the reply, Friedrich. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTabBar/QTabBar and documentMode
On Thursday, 3 December 2015, René J.V. <rjvber...@gmail.com> wrote: > Hi, > > I've been looking into ways to configure (improve) the look and feel using the native platform theme on OS X, and was reminded quite quickly about one of the nuisances that can arise with the default look of the native widget used by QTabBar. It's easy to reach the number of open tabs where the underlying system starts truncating text, replacing it with an ellipsis. Adding a close button doesn't help of course; this affected the tabbed document editor from KDevelop4, for instance. > > What I had not realised was that QTabBar provides a documentMode exactly for this reason/application, which switches the widget to a mode more appropriate for multi-tab document views, on OS X. I see that Kate4 used to set that mode (makes you wonder why KDevelop4 didn't benefit from that), but the mode switch has disappeared from the current Kate code. > The only mention of the mode I've seen to date in KF5 frameworks code is in a comment (!) in kdelibs4support (src/kdeui/k4style.cpp). > Hi, that's one of my hints from 2010 https://blogs.kde.org/2010/09/29/elegance-4-tab-bar-uncluttered :) Definitely apps could be reviewed re the clutter even on Linux, KDE HIG can help too. I am not sure if automatic solutions are possible for the KF level. > I'm a bit early in asking this in that I haven't yet been able to test neither Kate nor KDevelop, but is there an "official" or consensual opinion about this (e.g. applications should call QTabBar::setDocumentMode themselves when appropriate ... and can be patched if they don't)? > > R. > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Question about goal of Windows/Mac frameworks
on) in that app is a ToC of "KDE", not the ToC of app :) You're welcome. For me a lot of that applies even to Linux. If we want 3rd-party software use our infra like that, make it compact, we make it trivial to use so it competes with currently used solutions, and make is do one thing well: display the apps' help, not the help of all KDE apps. That would improve things. Just compare: Java apps' help don't display Oracle server help aside of the actual help, .NET apps' help don't show help for all installed .NET apps. Until that is done, I'd accept that people strip down functionality severly, e.g. not shipping help at all in the initial versions. PS: I perceive my attitude as promoting the FOSS OS if not even particular desktops. E.g. If for some reason someone can't live without kioslaves in konqueror for the help protocol, it's easy to get them natively in their "home" OS. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] Question to experienced Mac devs about goal of Windows/Mac frameworks
On 21 October 2015 at 10:20, René J.V. <rjvber...@gmail.com> wrote: > T,FTFY :) > > Seriously, how many people on here are Mac developers with significant > experience targeting native OS X APIs, and how many have significant > experience using Macs as Unix-based workstations with a true, integrated > desktop? Think of significant as "going back to before the last few, free > iterations of the OS". > I wouldn't even call myself the former (I just have a working experience > with the native APIs) but I'm very much the latter. > > All contributions are welcome esp. on platforms where there is very little > support, but IMVHO, people not in either category shouldn't be making > official design decisions for the platform in question (and that applies > not just to Mac / Mac OS X). > I don't think separating community this way is acceptable. Or categorising people. There are smart people that can have multiple hats. Even for example, less advanced OS X users have right to demand native UI styling on the target OS. You're proposing to use one of the Linux styles which is clearly foreign look. > I'd advise very strongly to get, install a number of commercial big > software suites (MS Office, Adobe Creative, etc) and study how they are > installed and where they put things. Both > > examples exist on multiple platforms, and MS Office is actually very well > written for OS X. > > As to DBus: it's not just a piece of foreign software that happens to work > on OS X, but is actively developed for that OS. There is nothing "anti-mac" > in using it. > > dbus is foreign in most places. Even to KDE contributors it is a bit foreign; we enjoyed other working solution for ages. It wouldn't be even used if not Qt's support coming mostly for free. A couple of open questions: - Looking at competition is always good. Do these MS Office/Adobe apps use dbus? Or run services ported from Windows? That would be equivalent. Note, even MS isn't interested in dragging own OS' infra to the foreign OS (Windows -> OS X, recently Android), it is mostly using the infra available on the target OS (OS X, Android, respectively). - What do we miss on OS X without dbus? Except a risk for further bugs? Is OS X dysfunctional in the area of IPC until dbus got ported to OS X? I am also asking as former guy who worked on Windows port of dbus. If I want to talk to system services can I use dbus on OS X? No. I will have to use another IPC approach. Unnecessary complication. - "both examples exist on multiple platforms" - from what I observe over the years at least MS Office has largely separate teams for OS X with significantly separate code base and features (no scripting for example, no MS Access at all) and entirely separate GUI, which on OS X uses native APIs when possible or at least mimicks ones. If MS used, say, .NET solutions to IPC then, yet, that would be a point in favour of your idea. The approach to multiplatform development that drags infrastructure from the original OS is the one I do not accept. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On 14 October 2015 at 20:55, Boudewijn Rempt <b...@valdyas.org> wrote:
> On Wed, 14 Oct 2015, Martin Klapetek wrote:
>
>> On Wed, Oct 14, 2015 at 1:38 PM, Christoph Cullmann <cullm...@absint.com>
>> wrote:
>>
>> Given that lot opposition was here for a 5 lines change which does
>> break nothing
>> if packagers don't skrew up.
>>
>>
>> Not to be disrespectful, but history has proven that the assumption
>> above unfortunately doesn't always hold up. So it's just better not
>> to count on it. Hence so much of the opposition.
>>
>
> Well, sure, stuff can break. However, without changes like this, KDE's
> Frameworks libraries are _not fit for purpose_. These libraries _can not
> be used_ by the intended user group, that is application developers,
> except for the tiny minority that only targets Linux, and only cares
> about having their applications packaged by distributions. As for Krita,
> we currently maintain builds for three distributions, and I can't wait
> for the day we can have a generic linux build like Blender and Firefox.
>
And LO.
Yes, I hope it's easy to see the pattern. And some of us may remember
the internal thread from this month about challenges Calligra faces to
win users.
Deployment is rather important part of this.
Let me CC kde-windows too. The topic seems to fit to many places.
When Ubuntu introduced the LTS it started to beat us heavily. "I am
not using your software because for ${some} reason I am bound to LTS"
See just the newest request as a sample:
http://permalink.gmane.org/gmane.comp.kde.users.kexi/833
Customers^w Users are always right.
So yes, a practical approach to deployment on Linux is not too
different than the one on the Windows/Mac/99.(9)% of mobile.
People that are forced to use given app will even install a VM to do
so. Compare size of the copied libs to the size of VM...
Compare to the size of the apps installed on your smartphone...
One way how we could "integrate" deployment of apps is for the case
when multiple apps are keeping their KF5 stuff in one place such as:
C:\ProgramFiles\Common Files\KDE\KF5\{some-timestamp}
Speculation: Multiple versions could be present there, identified by a
strong {some-timestamp} ID. And installers shall be in a form of Qt
Installer ("web" installers able to add shared components). It would
be then up to people manage deployments of a given application to
manage KF5 version that is known to work the app. Technical challenge
is here that the KF5\{some-timestamp} dir belongs to application. And
that one app may just install, say, 30% of KF5, another may install
70% of it. That looks like too complex and boring to manage by us,
volunteers.
So for Windows, having the C:\ProgramFiles\Common Files\KDE\ used for
a root dir of private copies of KDE stuff (including KF5) would be
better than nothing.
But on the risk side is that someone would think the subdirs are there
to reuse. That's not true because back/forward compatibility is not
part of these components. They are bound to given app(s) (one app or
entire Calligra for example).
No clear solution here then. Being a fan of native solutions (services
native to the OS), and sp the principle of the least-surprise, I am
thus not fan of exposing of software collections via the KDE-Installer
on Windows or equivalents on Mac. I'd like to make sure that anyone
who wants to package a KF5/Qt app separately can do that freely,
strip-down things conveniently in a way we accept, and there won't be
conflict with other installations. And that the packaged app won't be
perceived as "unofficial" because of the way of deployment. Freedom of
deploying alternatives away of the official channel - that IMHO boosts
competition and non-forced cooperation - something many of us see
missing in iOS.
I trust that whenever contributors discover it's "cheaper" to join KDE
than staying on the custom side, they will be joining. I see that
would be a big win-win.
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi,
Just wanted to say I'd like to minimize dependencies for Kexi on Windows
too, among other things.
With my realistic hat on, risky ideas are like:
- depending on kdecoration to just have default icons
- build-time depending on xml/docbook processing tools to just have core
KF5 libs built
- depending on solution like dbus when native solution on given platform
exist (it's a bit like linking to wine libs to use MS DDE)
I am afraid that unless building is easy and dependencies are reasonably
minimal ('small but not smaller than possible'), quite a few 3rd-party
developers will skip the 'official' KF5 and will go with forking to make it
work quickly. In the best case we'd notice that code on GitHub or so. This
is likely - people rarely have time to do things right; we evangelizing
them to re-create feature-packed subsystem that mimics Linux infra wouldn't
help. It's not _this_ kind of interest that made them interested in KF5.
Christoph mentioned the example with sound, which sincely belongs to this
group too.
In kdelibs4 times even "KDE's outside world" crown jewels like Krita or
Nokia mobile ports of Calligra apps had to fork/cut off large portions of
kdelibs. Let's avoid that...
On 13 October 2015 at 17:54, Christoph Cullmann <cullm...@absint.com> wrote:
> Hi,
>
> >> I'm not sure whether it's the best solution. The problem you try to fix
> with
> >> it is distros breaking packaging. I agree with Martin K that this is a
> huge
> >> problem and that it will happen - since the automation of packages I
> also
> >> experienced that nobody looks at the output of optional dependencies
> and the
> >> packaging breaks.
> >>
> >> Given that I don't think we want an ENABLE_MINIMAL_DEPENDENCIES switch,
> but
> >> rather a mode which will break if not found during distro builds.
> >>
> >> Something like a "STRONGLY_RECOMMENDED" which is turned into "REQUIRED"
> if
> >> distros build (and maybe also kdesrc-build), but is optional if anybody
> else
> >> builds.
> >>
> >> But I'm not sure how this could be done. Anyway, long story short: I
> think we
> >> need the other way around. It should be optional by default, but should
> be
> >> turned into stricter requirements on the linux distro case.
> > I would be happy with such an solution, too.
> > But I am not that optimistic that this is easy to achieve, how to ensure
> all
> > distros
> > turn this magic on?
> >
> > The opposite direction at least would avoid the distro breakage and
> still allow
> > optional compiles for the "3rd party wants less dependencies" or "other
> platform
> > wants
> > less dependencies" use case.
> >
> > Even if not optimal, some ENABLE_MINIMAL_DEPENDENCIES would in my eyes
> still
> > better than
> > the current situation, were either we have optional stuff that will make
> us
> > unhappy because
> > of broken distro packages or the devs unhappy that need to patch
> dependencies
> > out on their own.
> >
> > e.g. Kåre did in most cases exactly that for the Windows build
> > (g...@git.kde.org:scratch/sars/kate-windows),
> > which IMHO is sad.
>
> My ECM proposal would be the following:
>
> 1) add to KDECMakeSettings.cmake:
>
> Dependencies mode
>
> if(KDE_SKIP_FULL_DEPENDENCIES)
> unset(KDE_FIND_REQUIRED_OR_OPTIONAL)
> set(KDE_TYPE_REQUIRED_OR_OPTIONAL "OPTIONAL")
> else()
> set(KDE_FIND_REQUIRED_OR_OPTIONAL "REQUIRED")
> set(KDE_FTYPE_REQUIRED_OR_OPTIONAL "REQUIRED")
> endif()
>
> 2) use that e.g. in knotifications:
>
> find_package(Phonon4Qt5 4.6.60 ${KDE_FIND_REQUIRED_OR_OPTIONAL} NO_MODULE)
> set_package_properties(Phonon4Qt5 PROPERTIES
>DESCRIPTION "Qt-based audio library"
>TYPE ${KDE_TYPE_REQUIRED_OR_OPTIONAL}
>PURPOSE "Required to build audio notification support")
>
> That would at least make people happy that want no missing features and
> allow
> me and others to work on minimizing the dependencies without annoying
> others.
>
> If there is some magic way to set KDE_SKIP_FULL_DEPENDENCIES for
> non-distro builds,
> that could be added later inside KDECMakeSettings.
>
> Greetings
> Christoph
>
> --
> - Dr.-Ing. Christoph Cullmann -
> AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
> Science Park 1 Tel: +49-681-38360-22
> 66123 Saarbrücken Fax: +49-681-38360-20
> GERMANYWWW: ht
Re: Policy for Dependencies
On 13 October 2015 at 23:22, Albert Astals Cid <aa...@kde.org> wrote: > > El Tuesday 13 October 2015, a les 08:55:27, Martin Graesslin va escriure: > > On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote: > > > Hi, > > > > thanks for raising this topic. I think it's very important that we have a > > general strategy for frameworks and not have thousands of micro-fixes in > > various frameworks. > > > > > 1) "Normal" deployment like we do in on Linux => just installing it with > > > all features if possible. 2) "Application Bundles/Installer" like we will > > > have to do it on Win/Mac and 3rdparty Linux people will need to do. > > > > > > I think the easiest solution is to make stuff optional. That will avoid > > > ugly "if (WIN OR APPLE OR ANDROID)".. hacks in CMake and allow people to > > > still build stuff with that deps on that operating systems if really > > > wanted. > > Given from the no-X11 fixes I think that we should avoid all if (WIN OR > > APPLE) as that: > > a) is hard to maintain > > b) doesn't scale > > c) not testable for the devs working on Linux > > > > Given that it should be feature based and we should make as much usage of > > the built in CMake features we have. I really like the approach we have now > > found for X11 on OSX: disable certain find modules at a global level. > > > > I think that is something which could be applied for more things. Control > > through global ECM settings. This could if we don't want to have global > > changes also through convenient command switches: > > > > e.g. cmake -DECM_BUILD_FOR_OSX_APPBUNDLE > > > > which then implies e.g. no phonon and no dbus and ... > > I disagree, phonon and dbus are available on OSX and could be made to work so > having a ECM_BUILD_FOR_OSX_APPBUNDLE that disables perfectly valid features > doesn't make sense to me. Albert, From the fact that some foreign solution (dbus is foreign to OSX and for that matter Windows) is available on these OSes one cannot conclude that having option not to include/use them in my OSX/Windows app makes no sense. These OSes have own solutions for sound system and desktop IPC. Just like explorer.exe shell is perfectly valid feature delivered by a FOSS project wine on Linux. This does not mean I have to base file browsing experience for my Linux users on explorer.exe. And have you actually read what the APPBUNDLE would mean? An OS with dozen of instances of dbus, each installed by one app, fighting for user's attention is a quite possible scenario. Albert, if you want dbus-based workspace, there are OSes where it's native. I bet you can use them. We're talking about portable code, not portable runtimes (like Java, .NET, Chrome) that feel foreign/superficial on every OS. Let's drop the desktop/workspace hat when talking about frameworks. Otherwise it's hard to hope that people will think about employing KF5 to the outside world tasks -- numerous dependencies still remind them the "kdelibs" times of a kitchen sink approach. That wouldn't be honest to KF5 contributors because of man-years of great work invested. Please don't stop maturing of KF5. Christoph doing a real native port, presents a rare use case close to real outside world. PS: Accept the fact that there are OSes without *rc files but registry. Quite close, this includes Linux+GNOME. Most probably even more users will uses/will use KDE software on such OSes than on the traditional one. I am convinced there are more Qt apps on these other OSes than under Linux. Your view may be different, more workspace-related, your definition of portability may be different too. I am looking at code that uses KF5 as a Qt code in the first place. Qt does not ignore design decisions of supported OSes, why would KF5 do this? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: X11 on Windows
On 12 October 2015 at 08:33, Martin Graesslin <mgraess...@kde.org> wrote: > Hi frameworks and windows devs, > > from the release announcement of the latest frameworks release I learned that > there were multiple changes to disable finding X11 on Windows (e.g. [1]). I > think such changes are wrong and I have spoken against such changes (they are > wrong, CMake supports disabling modules without checking in code!) in the past > multiple times when I was aware of them (please include me in any reviews > touching X11). > > Given that we came up with a good solution for OSX directly in ECM [2]. Can we > get a similar solution for Windows? Then we can stop to patch random > frameworks. > Hi Martin,good point. The difference is that KDE on Mac developer(s) prefer to support X11, and I am not sure anyone wants to spend precious time for supporting X11 on Windows. I am not, and I would be assuming WIN32 => NOT X11 in code I maintain. So if this is consistent with general direction, equivalent of APPLE_FORCE_X11 for windows makes no sense. So the case for Windows in KDECMakeSettings.cmake could be simpler, but yes, it's needed. Please give me some time for that. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Icons installed by apps
Thanks for advice David.
In the specs I see no mention about using share/{app}/ subdirs.
I also noted this: "It is recommended that the icons installed in the
hicolor theme look neutral, since it is a fallback theme that will be
used in combination with some very different looking themes."
For the record:
Well, we can't have everything. The above advice somehow worked when
most themes had colours. For technical reason (the lookup algorithm)
breeze-themed icons go to hicolor but breeze is absolutely not
neutral. It may fit to some flat-design based desktops such as GNOME 3
but not everywhere. Combined with, say, older-school colorful icons,
UI elements containing breeze icons look like disabled ones or just
out of place.
No idea what LXQt default theme will be; obviously it wouldn't be good
if on desktop that migrated to Qt, Qt-based apps looked out of place.
To be clear, it's often about 2 ot 3 custom icons in a small app that
are not portable, still its noticeable.
I am back to the idea of defaulting to uniform cross-platform look
(with platform-specific twists if time permits) and leaving option for
motivated contributors to contribute with theming extensions.
I'd say since Winamp theming support rarely has even a minor priority
in "real world" software projects...
(Document-level theming is entirely different topic, and I guess
highly useful one - still we don't have it even started)
On 24 September 2015 at 23:04, David Faure <fa...@kde.org> wrote:
> On Tuesday 22 September 2015 18:44:47 Jaroslaw Staniek wrote:
>> On 22 September 2015 at 14:17, Jaroslaw Staniek <stan...@kde.org> wrote:
>> > Hello,
>> > A couple of related questions while wrestling with issues such as [1].
>> >
>> > Let's assume Kexi app installs some icons to
>> > PREFIX/share/kexi/icons/oxygen/32x32/places/ or
>> > PREFIX/share/kexi/icons/breeze/32x32/places.
>> > Can these be searched by the icon engine?
>>
>> Sorry for adding more info to clarify.
>> UserIconSet is deprecated so I guess this functionality is deprecated too...
>> since QIcon::fromTheme() apaprently isn't able to find app icons.
>>
>> I've seen quite a few KDE apps compiling-in their (usually custom
>> action) icons into qrc instead.
>>
>> I've not seen other app that do what Calligra apps do:
>> using icons fron share/calligra/icons (in kdelibs4 times
>> share/apps/calligra/icons).
>>
>> Comments?
>
> I guess qrc is actually better. Otherwise app1 might start depending on icon
> installed
> by app2 (without really noticing). And this simplifies deployment (and speeds
> up lookup).
>
> What I don't know however is whether artists consider that these icons should
> be themeable...
>
> BTW did you look into the xdg icon spec?
> I guess it's not there?
> On the other hand it doesn't prevent doing it since it's not about sharing
> icons; it's just harder
> to convince Qt to look there :) (I think qiconengine and kiconengine should
> stay compatible,
> so that we can even consider switching to qiconengine one day).
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Minimum supported version of MSVC for frameworks
Hi,
Qt accepts 2012 at least doesn't it? I see KF5 following this a good thing.
From my perspective of supporting 3rd party devs:
Dependency on 2012 in practice can exist for many reasons, preference and
taste often being the last ones.
If the goal is to have maximum reach for KF5 possible, using one or two
modern features in a promile of the code base is less important.
We can still enjoy more language features in apps code.
And while I sympathise with the call for writing modern code I think a
proper order would be first to alter the rules and then write the code, not
the other way...
On Monday, 17 August 2015, Kevin Funk kf...@kde.org wrote:
On Sunday 16 August 2015 11:19:39 Alex Merry wrote:
On 2015-08-13 09:57, Kai Uwe Broulik wrote:
Hi,
My experience with MSVC 2013 was that you even need at least Update 4
for initializer lists to work properly, which was released quite
recently iirc.
And even then, initializer lists don't work in all circumstances
(specifically in member initialization like
struct foo {
int bar[3] = {1, 2, 3};
};
).
Actually, if you do use MSVC 2013, always make sure you install Update
4, otherwise the compiler's really quite broken (even generating double
destructor calls in some circumstances). I don't think it's unreasonable
to refuse to support MSVC 2013 without update 4.
Yep, I know.
So can we come to an agreement we would be better off raising the required
version to MSVC2013? I feel like people don't really want to revert the
C++11
portions of code they've written until now anyway...
Cheers,
Kevin
Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
--
Kevin Funk | kf...@kde.org | http://kfunk.org
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Our C++11 policy?
Here's the list of features for KF5: https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 I propose to refer to that. It seems that Q_NULLPTR is used (this is violated in the current KF5 master, a JJ patch welcome). On 13 August 2015 at 10:02, Jaroslaw Staniek stan...@kde.org wrote: Hi, What would be the C++11 policy for Calligra code, at least new one? First easier thing. There's nullptr is used in KF5 (so is Q_NULLPTR). I am asking because it's important to be consistent across the Calligra code and follow the policy in code reviews. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Default page size now missing
Hi, While looking at possible improvements of QPageSize (with John), another finding: Defaults for page size for KDE SC 4 apps come from the locale based on KLocale and specific config value. Now in QLocale we miss this information. QPrinterInfo::defaultPrinter().defaultPageSize() is something different, it more depends on the default printer, its defaults and capabilities. For example, traditionally, USA has Letter as default and some other countries have A4. The thing is that the default page size is also used for creation of documents (ODF, PDF...). Any ideas on how to address that in apps that don't use kdelibs4support? And maybe in KF5 and/or Qt. And do we want to address that? Even if Plasma 5 offers this config to the user, apps will ignore it one day when they from usage of kdelibs4support. That could be misleading. Personally I am copying the one-liners from kdelibs4support as a temporary solution: if a given config value is found, it's used. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
On Sunday, 5 July 2015, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 10 de juny de 2015, a les 13:24:57, Jaroslaw Staniek va escriure: On 10 June 2015 at 12:26, Alexander Potashev aspotas...@gmail.com wrote: (CCing kde-i18n-doc) Hi Jaroslaw, The list of fields to extract is hardcoded in [1]. How many fields do you want to add? Can they be useful in other projects? [1] http://websvn.kde.org/trunk/l10n-kf5/scripts/createdesktopcontext.pl?view =markup Thanks so much for the info, Alexander. I need one field at the moment, it's a plural noun explaining a folder name, that is for example: for a Table plugin, the the folder could be called Tables. How does this work for languages with multiple plurals? For the need I presented it's out of scope. The 'tables' here refers to a set, just that. Cheers, Albert It's quite custom as you see. Perhaps we can have a hint for the createdesktopcontext.pl in a # comment line that some field is up for translation? -- Alexander Potashev 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, : translators : and facilitators committed to Free Software development - : http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Alexander Potashev ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
On Sunday, 5 July 2015, Albert Astals Cid aa...@kde.org wrote:
El Diumenge, 5 de juliol de 2015, a les 12:19:53, Jaroslaw Staniek va
escriure:
Is anyone interested with that?
Currently I'm editing these desktop files by hand.
Besides you? I don't think anyone is,
That's strong even a bit counterproductive declaration...
we've been using .desktop files for ages
without the need for translating custom fields.
Maybe because this part of the standard isn't implemented and people did
not care and add some c++ virtual methods by hand.
This is for your own app plugins, right? If so why can't you just reuse
one of
the existing fields? It is not like anyone else than your will make sense
or
even see those .desktop fields, no?
It's part of the Plugin api that is intended to be public.
Plugins pattern alone is intended for being used for extensibility, by
others, right?
What translated field can be reused?
Name/description are used, keywords will be used, genericname is only left.
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
I did not mention one thing: the localestring type isn't optional, it's
just because the format has no strict validators, nobody bothered I guess.
Hmm as soon as there's a plugin in Kexi (or Krita or other heavy
plugin-based app) requiring more than one noun, (provides multiple classes)
reusing genericname won't be enough.
Disclaimer: It all works for me by editing the files, as I said. I am ok
with someone helping out after translation teams back this fix in the fdo
implementation.
I value most the fact that the task is simple, fixes something missing, and
can be delegated easily to some volunteer that would like to start
contribution to the core infra.
Cheers.
Cheers,
Albert
On Sunday, 5 July 2015, Albert Astals Cid aa...@kde.org wrote:
El Dilluns, 15 de juny de 2015, a les 22:14:25, Jaroslaw Staniek va
escriure:
Hi
Summing up,
As I need get things done, I'm looking for someone to help me with
createdesktopcontext.pl
- basically change from
my $regexp =
qr{^(Name|Comment|Language|Keywords|X-KDE-Keywords|About|Description|Generi
cName|Query|ExtraNames|X-KDE-Submenu)=(.+)};
-- to recognize extra fields of type localestring [1].
You'll also need to modify applycontext.cpp so that it applies the
translation
back to the desktop file.
Cheers,
Albert
Magic # translate comment is one solution but another could be that
for field Foo I am adding:
Foo=Bar
Foo[x-test]=xxBarxx
And in final .desktop file it's rather clean, no extra comments
appear.
[1]
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s03.html
On 11 June 2015 at 15:43, Burkhard Lück lu...@hube-lueck.de wrote:
Am Donnerstag, 11. Juni 2015, 09:28:40 schrieb Jaroslaw Staniek:
Thanks, please let me understand; first - regarding
KPluginMetaData:
Why is a hint needed there if
KPluginMetaData::readTranslatedString()
cust constructs a magic key with a [lang] sufffix?
You are right, no hint needed.
--
Burkhard Lück
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
Exactly, Albert. On Sunday, 5 July 2015, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 5 de juliol de 2015, a les 08:48:20, Jaroslaw Staniek va escriure: On Sunday, 5 July 2015, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 10 de juny de 2015, a les 13:24:57, Jaroslaw Staniek va escriure: On 10 June 2015 at 12:26, Alexander Potashev aspotas...@gmail.com wrote: (CCing kde-i18n-doc) Hi Jaroslaw, The list of fields to extract is hardcoded in [1]. How many fields do you want to add? Can they be useful in other projects? [1] http://websvn.kde.org/trunk/l10n-kf5/scripts/createdesktopcontext.pl?view =markup Thanks so much for the info, Alexander. I need one field at the moment, it's a plural noun explaining a folder name, that is for example: for a Table plugin, the the folder could be called Tables. How does this work for languages with multiple plurals? For the need I presented it's out of scope. The 'tables' here refers to a set, just that. Why do you need this to be part of the .desktop file instead of being somethign your plugin api provides, is it because you don't want to load the plugin to access it? Cheers, Albert Cheers, Albert It's quite custom as you see. Perhaps we can have a hint for the createdesktopcontext.pl in a # comment line that some field is up for translation? -- Alexander Potashev 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, : translators : and facilitators committed to Free Software development - : http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Alexander Potashev ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Custom translated fields
Is anyone interested with that?
Currently I'm editing these desktop files by hand.
On Sunday, 5 July 2015, Albert Astals Cid aa...@kde.org wrote:
El Dilluns, 15 de juny de 2015, a les 22:14:25, Jaroslaw Staniek va
escriure:
Hi
Summing up,
As I need get things done, I'm looking for someone to help me with
createdesktopcontext.pl
- basically change from
my $regexp =
qr{^(Name|Comment|Language|Keywords|X-KDE-Keywords|About|Description|Generi
cName|Query|ExtraNames|X-KDE-Submenu)=(.+)};
-- to recognize extra fields of type localestring [1].
You'll also need to modify applycontext.cpp so that it applies the
translation
back to the desktop file.
Cheers,
Albert
Magic # translate comment is one solution but another could be that
for field Foo I am adding:
Foo=Bar
Foo[x-test]=xxBarxx
And in final .desktop file it's rather clean, no extra comments appear.
[1]
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s03.html
On 11 June 2015 at 15:43, Burkhard Lück lu...@hube-lueck.de wrote:
Am Donnerstag, 11. Juni 2015, 09:28:40 schrieb Jaroslaw Staniek:
Thanks, please let me understand; first - regarding KPluginMetaData:
Why is a hint needed there if KPluginMetaData::readTranslatedString()
cust constructs a magic key with a [lang] sufffix?
You are right, no hint needed.
--
Burkhard Lück
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
On 5 July 2015 at 16:00, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 5 de juliol de 2015, a les 15:39:00, Jaroslaw Staniek va escriure: On Sunday, 5 July 2015, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 5 de juliol de 2015, a les 12:19:53, Jaroslaw Staniek va escriure: Is anyone interested with that? Currently I'm editing these desktop files by hand. Besides you? I don't think anyone is, That's strong even a bit counterproductive declaration... What is counterproductive? As far as i know you're the one trying to stretch what a .desktop file is and provides, so you're the one with the problem, so i guessed you're probably the only one interested in implementing this. we've been using .desktop files for ages without the need for translating custom fields. Maybe because this part of the standard isn't implemented and people did not care and add some c++ virtual methods by hand. Which part of the standard? The list of fields that a .desktop file reader should support is clearly defined at Recognized desktop entry keys of http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html and as far as I can see we translate all those fine. There's a section Extending the format, KDE uses this possibility a lot (200+ times in KF5 itself), the implemented probably predates the actual specs. http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html#extending KDE people wouldn't use the X- if it was not implemented. So simple. Actually i see Icon is missing, we could just as well add it to the hardcoded list, but that's a different discussion :) This is for your own app plugins, right? If so why can't you just reuse one of the existing fields? It is not like anyone else than your will make sense or even see those .desktop fields, no? It's part of the Plugin api that is intended to be public. Plugins pattern alone is intended for being used for extensibility, by others, right? What translated field can be reused? Name/description are used, keywords will be used, genericname is only left. http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html I did not mention one thing: the localestring type isn't optional, it's just because the format has no strict validators, nobody bothered I guess. I can't find in the spec that supporting custom fields of localestring type is required by a reader implementation. Actually how can i know that a non- standard key is localestring and not numeric? AFAICS I can't. In the light what I am saying below, we have to note: - the specs is highly informal (no meaning of must, can, shall is defined), compare that to ODF... - using it for plugin descriptions is a little overuse at our side as you noted too The specs' language can sound that such that nothing is required. Reading with a good will is the only thing required I guess :) So here: neither support for custom boolean nor any custom values is required. All types are equally described when it comes to importance. http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s03.html So the localestring type is not a special one. Hmm as soon as there's a plugin in Kexi (or Krita or other heavy plugin-based app) requiring more than one noun, (provides multiple classes) reusing genericname won't be enough. Yes, i agree using .desktop to declare strings/features for your plugin is probably sub-optimal. Actually using .desktop files for plugins is already a bit wrong since the .desktop files spec says they are to describe how a particular program is to be launched, how it appears in menus, etc.. Maybe we should just use .json which AFAIK (i'm a bit old) here is what Qt5 wants for plugins? We have facilities for translating .json too (again not really sure how it works). Yes, deprecating .deskop for plugins (e.g. a warning in kcoreaddons_desktop_to_json) would be probably the way to go. Disclaimer: It all works for me by editing the files, as I said. I am ok with someone helping out after translation teams back this fix in the fdo implementation. Editing files by hand can't be considered works regarding translations. You won't get much coverage since translators won't know they have to go to that file to translate it. I value most the fact that the task is simple, fixes something missing, and can be delegated easily to some volunteer that would like to start contribution to the core infra. I disagree that it's either a fix nor simple. Third option: I can easily generate code for the app that has needed context and move on. Please let me know when you retire the desktop files completely for describing plugins. That would be we especially welcome currently when we have to cleanup the build subdir in order to get the json generated properly (https://bugs.kde.org/show_bug.cgi?id=349398). -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers
Re: Notes to developers: what KAboutData::setApplicationData() is
On 18 June 2015 at 14:50, Jeremy Whiting jpwhit...@kde.org wrote: Jaroslaw, On Thu, Jun 18, 2015 at 3:20 AM, Jaroslaw Staniek stan...@kde.org wrote: Hi If you look at apps ported to KF5, KAboutData::setApplicationData() is used but there are also redundant lines in main(), at least these: app.setApplicationName(aboutData.componentName()); app.setApplicationDisplayName(aboutData.displayName()); app.setOrganizationDomain(aboutData.organizationDomain()); app.setApplicationVersion(aboutData.version()); Note, this is already performed by KAboutData::setApplicationData(). That may be, but if using QApplication instead of KApplication they are needed. See the note at https://community.kde.org/Frameworks/Porting_Notes#Application Hi Jeremy, KAboutData::setApplicationData() works with any QCoreApplication. What I meant is to recommend calling it in main() instead of placing the app.* calls when KApplication isn't used. I don't use KApplication already and quite a few of the apps listed by lxr do not but they still have the app.* calls, indeed maybe because of the porting notes. Maybe KAboutData::setApplicationData is not needed anymore instead or can get it's names and other values from QApplication's accessors? The current way looks cleaner to me, KAboutData is a nice data structure. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Notes to developers: what KAboutData::setApplicationData() is
(I am sorry, forgot to include kde-devel too) On 18 June 2015 at 11:20, Jaroslaw Staniek stan...@kde.org wrote: Hi If you look at apps ported to KF5, KAboutData::setApplicationData() is used but there are also redundant lines in main(), at least these: app.setApplicationName(aboutData.componentName()); app.setApplicationDisplayName(aboutData.displayName()); app.setOrganizationDomain(aboutData.organizationDomain()); app.setApplicationVersion(aboutData.version()); Note, this is already performed by KAboutData::setApplicationData(). For example Kate -- http://lxr.kde.org/source/kde/applications/kate/kate/src/main.cpp For the list see http://lxr.kde.org/search?_filestring=_string=setApplicationDisplayName Sometimes there are even deeper duplication of names, e.g. despite of using KAboutData there's also: QApplication::setApplicationName(kanagram); -- http://lxr.kde.org/source/kde/applications/kate/kate/src/main.cpp If I am right, this is a note for developers to fix that -- KAboutData was designed to make main() easier but actually main() looks unnecessary complicated for a number of KDE apps. Looks like people take another app's code as a template and copy it :) No idea if more general improvement could be an addition to the apidocs of a crazy check. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Notes to developers: what KAboutData::setApplicationData() is
Hi If you look at apps ported to KF5, KAboutData::setApplicationData() is used but there are also redundant lines in main(), at least these: app.setApplicationName(aboutData.componentName()); app.setApplicationDisplayName(aboutData.displayName()); app.setOrganizationDomain(aboutData.organizationDomain()); app.setApplicationVersion(aboutData.version()); Note, this is already performed by KAboutData::setApplicationData(). For example Kate -- http://lxr.kde.org/source/kde/applications/kate/kate/src/main.cpp For the list see http://lxr.kde.org/search?_filestring=_string=setApplicationDisplayName Sometimes there are even deeper duplication of names, e.g. despite of using KAboutData there's also: QApplication::setApplicationName(kanagram); -- http://lxr.kde.org/source/kde/applications/kate/kate/src/main.cpp If I am right, this is a note for developers to fix that -- KAboutData was designed to make main() easier but actually main() looks unnecessary complicated for a number of KDE apps. Looks like people take another app's code as a template and copy it :) No idea if more general improvement could be an addition to the apidocs of a crazy check. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
Hi
Summing up,
As I need get things done, I'm looking for someone to help me with
createdesktopcontext.pl
- basically change from
my $regexp =
qr{^(Name|Comment|Language|Keywords|X-KDE-Keywords|About|Description|GenericName|Query|ExtraNames|X-KDE-Submenu)=(.+)};
-- to recognize extra fields of type localestring [1].
Magic # translate comment is one solution but another could be that
for field Foo I am adding:
Foo=Bar
Foo[x-test]=xxBarxx
And in final .desktop file it's rather clean, no extra comments appear.
[1] http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s03.html
On 11 June 2015 at 15:43, Burkhard Lück lu...@hube-lueck.de wrote:
Am Donnerstag, 11. Juni 2015, 09:28:40 schrieb Jaroslaw Staniek:
Thanks, please let me understand; first - regarding KPluginMetaData:
Why is a hint needed there if KPluginMetaData::readTranslatedString()
cust constructs a magic key with a [lang] sufffix?
You are right, no hint needed.
--
Burkhard Lück
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Equivalent of KDE::version*()?
Hi, One would need a need runtime version information of particular kf5 libraries -- in addition to version with which the software has been built. It seems that mostly Plasma and KActivities have equivalent of runtime version information. I am not looking build-time *_version.h files generated (with *_VERSION_* macros) but something like plasma-framework/src/plasma/version.h. Attica is a good exception here, I cannot spot anything else. PS: Maybe the code can be generated? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
On 10 June 2015 at 22:18, Burkhard Lück lu...@hube-lueck.de wrote: Am Mittwoch, 10. Juni 2015, 16:19:28 schrieb Alexander Potashev: 2015-06-10 14:24 GMT+03:00 Jaroslaw Staniek stan...@kde.org: On 10 June 2015 at 12:26, Alexander Potashev aspotas...@gmail.com wrote: (CCing kde-i18n-doc) Hi Jaroslaw, The list of fields to extract is hardcoded in [1]. and also in http://websvn.kde.org/trunk/l10n-kf5/scripts/applycontext.cpp?view=markup kpluginmetadata supports only translations for fields Name + Description, that is hardcoded in frameworks/kcoreaddons as well. How many fields do you want to add? Can they be useful in other projects? [1] http://websvn.kde.org/trunk/l10n-kf5/scripts/createdesktopcontext.pl?vie w=markup Thanks so much for the info, Alexander. I need one field at the moment, it's a plural noun explaining a folder name, that is for example: for a Table plugin, the the folder could be called Tables. It's quite custom as you see. Perhaps we can have a hint for the createdesktopcontext.pl in a # comment line that some field is up for translation? That is not sufficient, you need this hint for translated fields in applycontext.cpp, createdesktopcontext.pl and kpluginmetadata Thanks, please let me understand; first - regarding KPluginMetaData: Why is a hint needed there if KPluginMetaData::readTranslatedString() cust constructs a magic key with a [lang] sufffix? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Custom translated fields
On 10 June 2015 at 12:26, Alexander Potashev aspotas...@gmail.com wrote: (CCing kde-i18n-doc) Hi Jaroslaw, The list of fields to extract is hardcoded in [1]. How many fields do you want to add? Can they be useful in other projects? [1] http://websvn.kde.org/trunk/l10n-kf5/scripts/createdesktopcontext.pl?view=markup Thanks so much for the info, Alexander. I need one field at the moment, it's a plural noun explaining a folder name, that is for example: for a Table plugin, the the folder could be called Tables. It's quite custom as you see. Perhaps we can have a hint for the createdesktopcontext.pl in a # comment line that some field is up for translation? -- Alexander Potashev 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? 2015-06-10 12:41 GMT+03:00 Jaroslaw Staniek stan...@kde.org: Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Alexander Potashev ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Custom translated fields
Hi, KPluginMetaData::readTranslatedValue() is cool as it supports custom translated fields, i.e. something more than Name[...] or Comment[...]. A question: How is make our scripty infrastructure know that a custom field such as Foo[...] should be translated as well? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
debugfull - debug
Hi, As with some other bits of knowledge during porting today I just share this one: https://community.kde.org/index.php?title=Calligra/Building/3diff=42353oldid=42349 When you use Qt4/KF5, debugfull is dead [1] so you'd be surprised debugging isn't working for you. We don't have any precise recipe from the core folks involved in the kf5, I can only say the above works like before when you also set CMAKE_CXX_FLAGS_DEBUG:STRING=-g3 CMAKE_C_FLAGS_DEBUG:STRING=-g3 in your cmake cache. CC'd the kf list so maybe my lame solution could be improved and find its way to the porting notes [2]. [1] http://quickgit.kde.org/?p=extra-cmake-modules.gita=commith=4068592ad9aa3f241027f6db [2] https://community.kde.org/Frameworks/Porting_Notes -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Renaming the Predicate framework to KDb?
On 9 April 2015 at 00:12, Luigi Toscano luigi.tosc...@tiscali.it wrote: Jaroslaw Staniek ha scritto: Dear All, As a part of the process of porting Kexi to Qt5/KF5, three frameworks have been extracted to separate repos. More about that in some announcement (ask me for details if you cannot wait). For now I have the following question. Apart from the name, I need to ask now: which ones? If they share translations with existing code, I can copy the translations (or maybe they are libraries without visible i18n, in that case please ignore this email). Hi Luigi, These are KProperty and KReport frameworks, in Playground/Libs/ since this night. Good question regarding the i18n. Both have UIs that have visible i18n in apps that use these frameworks. The former has moved to the Qt translation tools and the code won't be changed too much before the 1st release, for the latter it's planned to use the Qt translation tools and there will be massive renames and porting. Existing translations sit within Calligra (2.9, .po files seems to be well separated). Porting Status page: https://community.kde.org/Kexi/Porting_to_Qt%26KF_5 -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Renaming the Predicate framework to KDb?
On 9 April 2015 at 01:16, Luigi Toscano luigi.tosc...@tiscali.it wrote: Jaroslaw Staniek ha scritto: On 9 April 2015 at 00:12, Luigi Toscano luigi.tosc...@tiscali.it wrote: Jaroslaw Staniek ha scritto: Dear All, As a part of the process of porting Kexi to Qt5/KF5, three frameworks have been extracted to separate repos. More about that in some announcement (ask me for details if you cannot wait). For now I have the following question. Apart from the name, I need to ask now: which ones? If they share translations with existing code, I can copy the translations (or maybe they are libraries without visible i18n, in that case please ignore this email). Hi Luigi, These are KProperty and KReport frameworks, in Playground/Libs/ since this night. Thanks; for now I made them extract into our trunk/kf5 branch. But that the extraction wouldn't work for now, as in both cases there is a call to: source $srcdir/../../calligra_xgettext.sh so I temporarily disabled the extraction. Predicate seems to be still kdelibs4 based, is it correct? The kdelibs4 version won't be released/maintained (unless someone invests in it). The final repo will have Qt5 version only, at some stage is worked already, some cmake cleanups are needed and perhaps the mentioned renames. What was the purpose of that file, something that can't be done with the existing scripts? (I have the feeling that maybe we already talked about this). It's a helper from calligra.git, won't be used in the extracted repos. Thanks. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Renaming the Predicate framework to KDb?
Dear All, As a part of the process of porting Kexi to Qt5/KF5, three frameworks have been extracted to separate repos. More about that in some announcement (ask me for details if you cannot wait). For now I have the following question. We have a framework called Predicate, for (data)base connectivity/creation, a kind of QtSql on steroids, is in development and use since 2003. First presented in Malaga (as KexiDB). https://projects.kde.org/projects/playground/libs/predicate I came to a conclusion that the Predicate name feels a bit hacky and does not explain the purpose of the framework. It also does not help that the predicate noun is used elsewhere quite a bit. So how about renaming to KDb? I like how many parts of the KF5 have clear names, and realized KDb seems to be available [1], forms a short prefix and it's meaning is rather clear. Its length suitable for use as a prefix for class names. So the change in real code could be like this: Predicate::Connection == KDbConnection. Thanks! [1] The kdb project does not seem to be active: http://marc.info/?l=kde-announcem=90221935129358w=2 -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
