Re: proposal: remove KTextEditor interface from kdelibs repository

[Friedrich W. H. Kossebau]

Mardi, le 1 février 2011, à 16:43, Maksim Orlovich a écrit:
  erf; two dependencies in kdelibs on KTextEditor. ok, that makes it a no
  go then ... hm.. looking at it, only khtml has a build-time dependency
  on it. if
  the texteditor part isn't available (or the source of the crash even? :)
  what
  does the debugger do at that point?
 
 Pop up an error message and abort execution, as it expects it to be
 part of kdelibs.
 Which is coincidentally very similar to what KTextEditor tutorials
 suggest --- see
 http://techbase.kde.org/Development/Tutorials/Kate/KTextEditor_Example
 (except it needs katepart in specific)

Uh, that is old-fashioned. Should instead ask the user whether she wants to 
install the proper text editor module. Isn't there some simple standard api 
for that these days?

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org

Re: proposal: remove KTextEditor interface from kdelibs repository

[Friedrich W. H. Kossebau]

Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit:
 On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote:
  Uh, that is old-fashioned. Should instead ask the user whether she wants
  to install the proper text editor module. Isn't there some simple
  standard api for that these days?
 
 A simple standard api for what? installations of scripts and wallpapers
 and stuff, sure. there is the ghns things.
 
 For isntallation of compiled stuff, no.

Not something related to packagekit or similar? Eh, IMHO there should be 
something like that if there isn't. With OBS and Co. compiled stuff is not 
that much different, you just get a variant tailored to your (hardware) 
profil. Can someone please empty my TODO list? :)

 And I'm not sure there should be
 such a thing.

Hm. You don't agree that a user experience like
Sorry, missing X to do Y. Would you like to get X now for that?
is better than one à la
Na, no way to do Y.?

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org

Installing specific packages on demand (was: Re: proposal: remove KTextEditor interface from kdelibs repository)

[Friedrich W. H. Kossebau]

Mardi, le 1 février 2011, à 19:39, Sune Vuorela a écrit:
 On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote:
  And I'm not sure there should be
  such a thing.
  
  Hm. You don't agree that a user experience like
  
  Sorry, missing X to do Y. Would you like to get X now for that?
  
  is better than one à la
  
  Na, no way to do Y.?
 
 Yes. since we can't assume the user has the right to install to the
 system directory,

We can't assume for all, but in many installations the user does. Like the 
ususal private computer.
For administrated systems, there could be a substitute which instead of 
allowing to install rather aids the user to file a request to the admin, for 
convenience and getting things done.

 and we shouldn't set up a complete development
 environment for him.

I was thinking of interfacing to the normal packaging system of the system. 
He, something like DrKonqi installing the debug info packages on request. So 
something like that is existing already, just needs to be generalized perhaps.

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org

Re: proposal: remove KTextEditor interface from kdelibs repository

[Friedrich W. H. Kossebau]

Mardi, le 1 février 2011, à 19:42, Alexander Neundorf a écrit:
 On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote:
  Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit:
   On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote:
Uh, that is old-fashioned. Should instead ask the user whether she
wants to install the proper text editor module. Isn't there some
simple standard api for that these days?
   
   A simple standard api for what? installations of scripts and wallpapers
   and stuff, sure. there is the ghns things.
   
   For isntallation of compiled stuff, no.
  
  Not something related to packagekit or similar? Eh, IMHO there should be
  something like that if there isn't. With OBS and Co. compiled stuff is
  not that much different, you just get a variant tailored to your
  (hardware) profil. Can someone please empty my TODO list? :)
  
   And I'm not sure there should be
   such a thing.
  
  Hm. You don't agree that a user experience like
  
  Sorry, missing X to do Y. Would you like to get X now for that?
  
  is better than one à la
  
  Na, no way to do Y.?
 
 I think Lubos proposed something like this recently, i.e. at some point
 last year here on this list.

Others have done now and then as well, e.g., ahem, me ;) here a few years ago:
http://markmail.org/message/xo2b4zw2ee6si6g2

Oh, how cheap talk is :P

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org

Re: Installing specific packages on demand

[Friedrich W. H. Kossebau]

Mardi, le 1 février 2011, à 20:10, Sune Vuorela a écrit:
 On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote:
  We can't assume for all, but in many installations the user does. Like
  the ususal private computer.
  For administrated systems, there could be a substitute which instead of
  allowing to install rather aids the user to file a request to the admin,
  for convenience and getting things done.
  
  and we shouldn't set up a complete development
  environment for him.
  
  I was thinking of interfacing to the normal packaging system of the
  system. He, something like DrKonqi installing the debug info packages on
  request. So something like that is existing already, just needs to be
  generalized perhaps.
 
 Basically, a piece of software than have three relations:
 1) Required things
 2) Optional things that should be availably by default
 3) optional things that doesn't need to be available by default
 
 Packagers should assure that 1) is around. Packagers should try hard to
 make 2) available for all not uncommon installations.
 
 if 1) is missing, file bugs at the distribution.
 if 2) is missing, file bugs at the distribution or alternatively tell
 the user you broke your system, you get to keep the pieces.
 
 And then there is the handling of 3).
 
 Well.. let's not make it a bigger issue than it actually is.

Ah, Sune, guess we were missing each other :) I was talking of currently not 
installed optional things. And not speaking of optional things not existing as 
packages.

E.g. imagine someone installing some program over an expensive/slow connection 
(think mobile). She just installs the required things, to keep the needed 
bandwith low. Then hits a feature which is more useful with some optional 
thing X. Ideally the feature's code would be able to offer the action Trigger 
install of optional thing X to pimp doing Y.

Does this help to understand what I am looking forward to?

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org

Re: proposal: remove KTextEditor interface from kdelibs repository

[Friedrich W. H. Kossebau]

Mardi, le 1 février 2011, à 20:14, Alexander Neundorf a écrit:
 On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote:
  Mardi, le 1 février 2011, à 19:42, Alexander Neundorf a écrit:
   On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote:
Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit:
 On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote:
  Uh, that is old-fashioned. Should instead ask the user whether
  she wants to install the proper text editor module. Isn't there
  some simple standard api for that these days?
 
 A simple standard api for what? installations of scripts and
 wallpapers and stuff, sure. there is the ghns things.
 
 For isntallation of compiled stuff, no.

Not something related to packagekit or similar? Eh, IMHO there should
be something like that if there isn't. With OBS and Co. compiled
stuff is not that much different, you just get a variant tailored to
your (hardware) profil. Can someone please empty my TODO list? :)

 And I'm not sure there should be
 such a thing.

Hm. You don't agree that a user experience like

Sorry, missing X to do Y. Would you like to get X now for 
that?

is better than one à la

Na, no way to do Y.?
   
   I think Lubos proposed something like this recently, i.e. at some
   point last year here on this list.
  
  Others have done now and then as well, e.g., ahem, me ;) here a few years
  ago: http://markmail.org/message/xo2b4zw2ee6si6g2
  
  Oh, how cheap talk is :P
 
 I think this might be related:
 http://www.kdedevelopers.org/node/4232

Oh, nice, missed that before, thanks for the pointer, Alex :)

Indeed, that is pretty related. Hm, might be an interesting GSoC task to merge 
this with DrKonqi's debug packages loading, Phonon's new codec pulling and all 
the other GHNS/OCS related stuff... so at some not to distant time the 
KTextEditor example can be changed to code with a better user experience :)

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org

Re: Request: Inclusion of kio-upnp-ms to kde-runtime KIO slaves

[Friedrich W. H. Kossebau]

Lundi, le 9 mai 2011, à 10:12, Nikhil Marathe a écrit:
 On Sat, May 7, 2011 at 5:21 PM, Friedrich W. H. Kossebau
 
 kosse...@kde.org wrote:
  * Needed in toplevel CMakeLists.txt so FindHUpnp.cmake is found (might
  stop people giving it a try):
  set( CMAKE_MODULE_PATH  ${CMAKE_MODULE_PATH} ${CMAKE_CURRENT_SOURCE_DIR}
  )
 
 FindHUpnp.cmake is already in kdelibs/cmake. So I don't think this is
 required.

Well, this was for the current repo, not for when included in kde-runtime :)
kdelibs does not install FindHUpnp.cmake, so when I ran cmake to test kio-
upnp-ms after I git clone'd the repo cmake complained:
--- 8 ---
CMake Error at CMakeLists.txt:10 (find_package):
  Could not find module FindHUpnp.cmake or a configuration file for package
  HUpnp.
--- 8 ---
You might have installed FindHUpnp.cmake yourself sometime, or have some env 
variable setup properly, that maybe why you did not see that.

  * As there is no docu yet, this line should be removed in
  kio_upnp_ms.protocol:
  DocPath=kioslave/kio_upnp_ms.html
 
 done
 
  * upnptypes.h better is renamed to upnp-ms-types.h or similar
 
 done

good.
 
  * renamed upnptypes.h also would be added to kdelibs, as kde-runtime
  should not be a compile-time dep. And then ideally merged into
  kio/udsentry.h, like e.g. the Nepomuk ones are already
 
 How should I approach this? Should I create a separate review request
 for the UDSEntry addition
 later, or should I do it now?

Now, I think, as the kio-slave depends on it when compiled, so it should get 
in first, so when people test your merge request for the inclusion of kio-
upns-ms to kde-runtime, they can (well, have to) compile it with the lastest 
kdelibs.

 Will this break binary compatibility?

Break binary compatibility of what? If you just add some more entries to the 
enum StandardFieldTypes, starting with 29 or whatever the lastest number used 
(+1) before UDS_EXTRA is in the list, this should not affect 

Or do you mean programs using kio-upnp-ms already (like Amarok?)? Ah, true. 
Tricky. Would not work then, okay. So it would stay just a separate header, 
with the old enumeration.

 The compile time dependency is only for programs which will treat UPnP
 as special, and not normal kioslave users who use them via the Job
 interface.

Yes, but AFAIK this would be the first header installed from kde-runtime. And 
as it is just a header, it should be fine in kdelibs.

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org

Re: Request: Inclusion of kio-upnp-ms to kde-runtime KIO slaves

[Friedrich W. H. Kossebau]

Hi Nikhil,

you know that today, April 12th, is already Hard Feature Freeze?! Would be 
really sad if your upnp-ms kio-slave misses the deadline now!

Mardi, le 26 avril 2011, à 14:53, Nikhil Marathe a écrit:
 Hi,
 
 KDE SC 4.7 soft feature freeze is close, and I would like to propose
 the UPnP MediaServer KIO slave
 (https://projects.kde.org/projects/playground/base/kio-upnp-ms/) be
 included into the set of kio slaves shipped with kde-runtime. The
 slave was created as part of GSoC 2010 - Amarok and KDE UPnP support
 and it was decided that it should be merged into kde-runtime at some
 point.
 
 A couple of reasons I believe the slave is now ready for standard release
 is: 1) HUpnp (http://herqq.org/news.html) - the Qt based UPnP library used
 by the slave has a stable API and ABI with the release of 1.0.0 about 3
 weeks ago.
 2) The slave has been considerably simplified and single threaded, and
 stable now.
 3) The slave is independent and can be conditionally compiled and
 installed if HUpnp is installed. kdelibs already contains a
 FindHUpnp.cmake to find the HUpnp library.
 4) The Solid UPnP backend (enabled in 4.7, again if HUpnp is found)
 automatically launches UPnP media servers in the file manager with the
 slave.

Works nicely*. And given that, the Solid UPnP backend + showing up the devices 
are completely/almost useless if there is no UPnP MediaServer kio-slave to 
access them, so please let's see to have this kio-slave available with the 
next SC release.

*Besides, why isn't e.g. for images not the largest possible size delivered? 
Guess similar for audio/video streams only some medium quality is fetched per 
default? I think following what e.g. the MediaTomb web UI does, giving the 
best possible quality, would be better here.
Also could deliver a little bit more data, like Mimetype and Timestamps?

 My exams get over this week and I can ensure that krazy checks pass
 and the code is cleaned up some more.
 There is inline documentation where required, and the search and
 browse API documentation exists. There is no user
 manual since it is a slave.

Had a short look at the code, could not see any big flaws. And it works, so 
nothing which should stop the inclusion in kde-runtime
(Beware, I have no clue of HUPnP, so could not stop any misuse of its API, and 
have no idea how to talk exactly to a MediaServer)

But there are a few possibilites for optimisation:
* no use of QLatin1String,  should be QString(), ' should be (QLatin1)Char
* QString::replace( bla, ) used instead of QString::remove()
* QHash::contains()/QHash::operator[] used instead of it=QHash::find/it!=0/it
* toAscii() used instead of toLatin1()

controlpointthread.cpp:
* the global QRegExp searchCriteria should made const and static
* the strings used to calculate the expression should be defines, so the 
preprocessor does the string calculation already
* the timeout 35000 should be turned into a static const int at the begin of 
the file, so it can be easily found (could be even turned into a build time 
parameter)
* ControlPointThread::slotEmitSearchEntry: signal listEntry emitted before 
state is finalized
 
didlparser.cpp:
* Parser::parseResource: use Resource::insert(Key, Value) instead of r[k]=v;

objectcache.cpp:
* ObjectCache::attemptIdToPathResolution: m_idToPathRequestsInProgress = 
false; should be before emit

persistentaction.cpp:
* some magic values, better as const static ints at begin: 
m_delay = 1000;
m_timer-start( 5000 );

kio_upnp_ms.cpp:
* isn't that a busy loop in the end? 
while( m_statBusy )
QCoreApplication::processEvents();

Also think that instead of connect and disconnect of signal and slot with 
ControlPointThread you should rather use some good'ol'fashioned callback 
functions and some other way to exchange data with the worker thread.

 If there is no objection I would like to request a merge into
 kde-runtime. I will edit the 4.7 feature plan for the same.

I would think this is already a request ;) But if there is not enough time now 
and others would like to do their own review before it gets into kde-runtime, 
as there has not been an official merge request yet via 
https://git.reviewboard.kde.org, let's at least do the trick to still be part 
of the next release wave by upgrading the repo from playground to 
Extragear/Base as fast as possible.

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org

Review Request: make QTEST_KDEMAIN_CORE_WITH_COMPONENTNAME compile with -DQT_NO_CAST_FROM_ASCII

[Friedrich W. H. Kossebau]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101444/
---

Review request for kdelibs.


Summary
---

QTEST_KDEMAIN_WITH_COMPONENTNAME already has QLatin1String/QString::fromLatin1 
wrappers, but QTEST_KDEMAIN_CORE_WITH_COMPONENTNAME was still missing them.
Should not do any harm to add QLatin1String wrappers in the macro, but I am 
tired and might miss something, so up for review :)


Diffs
-

  kdecore/util/qtest_kde.h 29f08e5 

Diff: http://git.reviewboard.kde.org/r/101444/diff


Testing
---

My test programs using QTEST_KDEMAIN_CORE( TestName ) now compile with 
-DQT_NO_CAST_FROM_ASCII


Thanks,

Friedrich W. H.

FindKActivities.cmake missing from kdelibs KDE/4.7 ?

[Friedrich W. H. Kossebau]

Hi,

kde-workspace trunk is supposed to be compiled against kdelibs KDE/4.7, right?

For me it seems that FindKActivities.cmake is missing then in kdelibs KDE/4.7 
or kde-workspace trunk. Because kde-workspace/CMakeLists.txt has the line
find_package(KActivities REQUIRED)

But there is nowhere a FindKActivities.cmake for me:

koder@kleks: ~/Kode/kdegit/KDE$ find kdelibs -name FindKActivities.cmake
koder@kleks: ~/Kode/kdegit/KDE$ find kde-workspace -name FindKActivities.cmake
koder@kleks: ~/Kode/kdegit/KDE$

Is something wrong with my setup? Or does just everyone have some stale 
FindKActivities.cmake in their install files from recent experiments with 
other branches, so cmake can pick it up?

Searched the webs and found a FindKActivities.cmake *, put that in the cmake 
install modules dir and finally kde-workspace build fine for me.
*http://osdir.com/ml/kde-commits/2011-09/msg05764.html

Did not follow all recent threads, so I may have missed something. So is this 
a bug, shall I provide a patch (unless someone beats me to it)? For kdelibs?

Cheers
Friedrich

Re: FindKActivities.cmake missing from kdelibs KDE/4.7 ?

[Friedrich W. H. Kossebau]

Lundi, le 17 octobre 2011, à 19:35, Alex Merry a écrit:
 On 17/10/11 18:10, Friedrich W. H. Kossebau wrote:
  Hi,
  
  kde-workspace trunk is supposed to be compiled against kdelibs KDE/4.7,
  right?
  
  For me it seems that FindKActivities.cmake is missing then in kdelibs
  KDE/4.7 or kde-workspace trunk. Because kde-workspace/CMakeLists.txt has
  the line find_package(KActivities REQUIRED)
 
  But there is nowhere a FindKActivities.cmake for me:
 FindKActivities is provided by libkactivities (the kactivities module on
 git.kde.org).  If you don't have it, there won't be such a file.

Hm, but kdelibs KDE/4.7 has (and builds+installs for me by default) 
experimental/libkactivities, isn't that the official version of 
libkactivities to use?

 This, I believe, is how cmake is meant to work.  A package can provide
 its own Find*.cmake file, and find_package will fail if either the
 Find*.cmake file was not found or running the cmake script in said file
 reports that the package could not be found.

I understood it the other way round:
that code which relies on some other modul has to have it's own Find*.cmake 
for that modul (unless it is that common that cmake has it installed by 
default). All the Find*.cmake in all the KDE modules at least always supported 
me in this understanding :) So turns out I am wrong?

Cheers
Friedrich

RFC: Herding your program’s icons, how?

[Friedrich W. H. Kossebau]

Hi,

(cc: to kde-bindings for heads-up, follow-ups please only on kde-core-devel)

Problem__
How to get all icon-ids in your codebase?

Just blogged* about this, but then more something for this ml.

* http://frinring.wordpress.com/2012/04/26/herding-your-programs-icons-how/

When seeing for the icon-ids used in Calligra, I have used a simple approach 
to get at least most of them, doing a grep for lines with “KIcon(“. That gave 
me more than 1000 lines for Calligra, and almost all also directly used an 
icon-id, so there was chance to do a check and create a report for these.

Now this is quite unsatisfying to not be able to easily get a list of _all_ 
the icon resources used in your codebase, and having to do manually extraction 
is not nice. How do you deal with this in your project?


Proposal__

Ideally icon-ids would be kind-of tagged when used, so like gettext is able to 
extract all strings which need a translation, some geticon would be able to 
extract all icon-ids. The result could then be used to check the icon-ids 
against the icons available from the icon themes and the icons installed from 
the project itself, ideally automatically (as doing that manually is… pretty 
boring, time-consuming and error-prone).

I could imagine that there could be some macros

kicon(some-icon)

and

kiconid(some-icon)

which would resolve to

KIcon(QLatin1String(some-icon))  // kicon(...) is even more readable

and

some-icon

and would enable to automatically extract these icon-ids (with metadata like 
file, line, etc). It should be backward-compatible, as it is just some mark-up 
which resolves to what there was before. And while there is nothing to enforce 
that all icon-ids are marked up, the same problem exists with i18n, so 
something we are okay with.

With that markup IDEs might be even able to check the validness of icon-ids or 
offer code-completion, perhaps even with preview of the actual icon :) 
/dream


Questions__

What about icons used in UI files, will they still pass KIconLoader or 
whatever makes the icon being picked from the usual places?

Are there other usages of icon-ids which might not be catchable this way?

Would something similar work for non-C++ languages?

What could be better keywords for the macros?

What do you think in general? Comments, other/better proposals welcome!

Cheers
Friedrich

Moving scheck from kdesdk to tags/unmaintained/4/scheck ?

[Friedrich W. H. Kossebau]

Hi,

in preparation of the migration of kdesk to git I found that scheck in 
kdesdk is currently excluded from the build, because it has been never 
completely ported to Qt4/KDE4. And it seems noone has missed it for 4 years, 
perhaps accel conflicts  Co. are no longer a big problem?

Thus I will move kdesdk/scheck to tags/unmaintained/4/scheck next 
Sunday, May 20th, in the European evening, unless anyone objects.

Also blogged for a new maintainer of scheck, perhaps somebody likes to pick 
the scheck style up: http://frinring.wordpress.com/2012/05/17/maintainer-
wanted-port-the-scheck-style-to-qt4/

Any way, being in unmaintained soon does not prevent it to become migrated to 
a git repo later as well, if ported.

Cheers
Friedrich

Deleting kdepalettes from kdesdk

[Friedrich W. H. Kossebau]

Hi,

Mosfet once put palettes for both the Gimp and Xpaint that match the KDE 
standard color palette into kdesdk/kdepalettes *.  But that was at KDE3 
times, so these palettes are outdated, not Oxygen-like. And noone updated them 
in the last 4 years, so seems noone uses these.

* http://websvn.kde.org/trunk/KDE/kdesdk/kdepalettes/

Besides, these days a GIMP-style palette is offered at 
http://websvn.kde.org/trunk/playground/artwork/Oxygen/utils/oxygen.gpl
like also linked from http://techbase.kde.org/Projects/Oxygen/Style.

So in preparation for the migration of kdesdk to git I will be simply removing 
kdesdk/kdepalettes, next Sunday, May 20th, in the European evening, unless 
anyone objects.

Cheers
Friedrich

Re: Deleting kdepalettes from kdesdk

[Friedrich W. H. Kossebau]

Am Samstag, 19. Mai 2012, 10:14:26 schrieb Eike Hein:
 On 05/18/2012 03:23 PM, Friedrich W. H. Kossebau wrote:
  So in preparation for the migration of kdesdk to git I will be simply
  removing kdesdk/kdepalettes, next Sunday, May 20th, in the European
  evening, unless anyone objects.
 
 I'm curious about the connection between these two. Where will the
 history of the palettes be available in the converted git reposito-
 ries?

Good question. So far nowhere.

kdesdk/kdepalettes is a one-time-commit/dump of the palettes without any 
further changes, so there is no real history besides the commit log Initial 
import of the palettes and the date (actually Sun Jan 3 1999, so even the 
palette of KDE1 times), the only other commit, a move, was due to the 
introduction of /trunk/KDE.

The kdesdk module will be split over multiple repos, and none so far has 
kdepalettes included (but then plans for splitting are not completed yet). 
Just, none of the candidates is related to palettes, so who would search the 
history/files of kdepalettes there?

Would moving to tags/unmaintained/1 (or 2?) in svn be a way to secure the 
history to a degree? Initially I thought they are not unmaintained, but simply 
outdated (and kind-of continued in another place, at least the GIMP-style 
version, without any connection), so that is why I proposed to simply delete 
them.

So? Instead of remove do a move to tags/unmaintained/2 ?

Cheers
Friedrich

Review Request: Remove image/x-wmf and image/x-xfig from image thumbnailer's supported mimetypes

[Friedrich W. H. Kossebau]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105371/
---

Review request for KDE Runtime.


Description
---

The declared-as-supported mimetypes of the image thumbnailer are quite broad, 
assuming a lot of QImageIOPlugin existing and installed. But at least for x-fig 
and wmf there are no such plugins known, by what I can tell. So the claim of 
support is wrong.

Worse: There is no safe way to install an own, better thumbnailer, that one 
would be only chosen by pure luck. Reason is that the thumbnail creation 
invoking code just greps the first in the list of found thumbnail plugins, see 
the code in kde-runtime/kioslave/thumbnail/thumbnail.cpp:

QString ThumbnailProtocol::pluginForMimeType(const QString mimeType) {
KService::List offers = KMimeTypeTrader::self()-query( mimeType, 
QLatin1String(ThumbCreator));
if (!offers.isEmpty()) {
KService::Ptr serv;
serv = offers.first();
return serv-library();
}
[...]

E.g. trying to install an own xfig thumbnailer failed for me.

While changing the above code to use KMimeTypeTrader::preferredService(...) 
surely might be also good to do, I have no idea about the impact.
For now I just would like to have those two wrong claims removed.

Okay to backport to 4.9 (and 4.8)?


Diffs
-

  kioslave/thumbnail/imagethumbnail.desktop 53c9a33 

Diff: http://git.reviewboard.kde.org/r/105371/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

Re: Using userbase for manuals

[Friedrich W. H. Kossebau]

Hi,

Am Sonntag, 1. Juli 2012, 09:21:08 schrieb Albert Astals Cid:
 El Diumenge, 1 de juliol de 2012, a les 08:02:28, Boudewijn Rempt va 
escriure:
  In any case, Ingo Malchow said in his blog
  (http://blog.neverendingo.de/?p=125)
  
  We have a great userbase.kde.org but developers don’t use it that much,
  nor is there any links from applications towards Userbase.
  
  Well, actually we have. I replaced the offline help documentation in Krita
  with a link to the manual on userbase. I have done this for two reasons:
  
  * I couldn't maintain the offline manual anyway after the change to 2.0
  * this way the user gets sent right to the place where they can contribute
  to the manual (and I've got users contributing to it now)
  
  I'm not concerned that users cannot access the help when they are
  off-line.
  That's a vanishingly rare situation these days
 
 I disagree, as a matter of fact, I don't have internet connection in the
 room in my hostel, so if i had a need to use krita I'd need to read its
 manual (since my painting/drawing skills are null) and i'd be not happy to
 discover I can't read the manual.

+1

There are lot of nice places on this planet where there is no (good or cheap) 
internet connection. Which is fine in one way (gives you a break without 
needing to find excuses :) ) but bad for dependency on on-line stuff.

You preinstall most of your application as well, and do not apt-get them on-
demand (modulo web apps), right? :)

So at least being able to get snapshots of the stuff in userbase (as packages) 
would be really needed.

Otherwise I agree. The strange duplication between userbase and manuals 
ideally finds an end in the near future, and with the current efforts on 
translation support another show stopper has been removed.

Next on my wishlist would be a proper consistent structure on userbase, so 
documentation for different versions of a program is supported. After all 
there are usually versions of a program in use out there, and you do not want 
to disappoint those which can not update or do not want to update.

Cheers
Friedrich

Re: Review Request: Remove image/x-wmf and image/x-xfig from image thumbnailer's supported mimetypes

[Friedrich W. H. Kossebau]

 On July 11, 2012, 12:36 p.m., David Faure wrote:
  KMimeTypeTrader::query honours the sorting, so InitialPreference=10 should 
  have been enough in your thumbnailer.
  
  preferredService() basically calls first() ;)
  
  Patch is OK however.

IIRC I tried InitialPreference=10 but to no effect (but then we all fail 
sometimes).

But I did not inspect preferredService(), just looked at the name it seems :)
So the sorting by preference is already done when creating the cache I learn by 
your comment?

For KDELIBS NG I wonder if a thumbnail control should be added to the File 
Association settings, so the user can control which plugin stamps the 
thumbnail, if any. At least Calligra 2.6 will signal support for quite a lot of 
file types (due to the filter system there can be many), so overlapping of 
thumbnailers might happen more often.


- Friedrich W. H.


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105371/#review15667
---


On June 28, 2012, 5:39 a.m., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/105371/
 ---
 
 (Updated June 28, 2012, 5:39 a.m.)
 
 
 Review request for KDE Runtime.
 
 
 Description
 ---
 
 The declared-as-supported mimetypes of the image thumbnailer are quite broad, 
 assuming a lot of QImageIOPlugin existing and installed. But at least for 
 x-fig and wmf there are no such plugins known, by what I can tell. So the 
 claim of support is wrong.
 
 Worse: There is no safe way to install an own, better thumbnailer, that one 
 would be only chosen by pure luck. Reason is that the thumbnail creation 
 invoking code just greps the first in the list of found thumbnail plugins, 
 see the code in kde-runtime/kioslave/thumbnail/thumbnail.cpp:
 
 QString ThumbnailProtocol::pluginForMimeType(const QString mimeType) {
 KService::List offers = KMimeTypeTrader::self()-query( mimeType, 
 QLatin1String(ThumbCreator));
 if (!offers.isEmpty()) {
 KService::Ptr serv;
 serv = offers.first();
 return serv-library();
 }
 [...]
 
 E.g. trying to install an own xfig thumbnailer failed for me.
 
 While changing the above code to use KMimeTypeTrader::preferredService(...) 
 surely might be also good to do, I have no idea about the impact.
 For now I just would like to have those two wrong claims removed.
 
 Okay to backport to 4.9 (and 4.8)?
 
 
 Diffs
 -
 
   kioslave/thumbnail/imagethumbnail.desktop 53c9a33 
 
 Diff: http://git.reviewboard.kde.org/r/105371/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Friedrich W. H. Kossebau
 

Review Request: add note about Oxygen Icons to README.packagers

[Friedrich W. H. Kossebau]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106114/
---

Review request for KDE Runtime and Release Team.


Description
---

As discussed in the thread The misterious case of oxygen-icons there is an 
undocumented (de-facto) run-time depedency of kdelibs and kde-runtime on the 
Oxygen Icons 
(http://mail.kde.org/pipermail/release-team/2012-August/006364.html). Which 
should be better officially documented.

This patch adds a note about the run-time need for Oxygen Icons to 
kde-runtime/README.packagers.

Okay to commit both to master and 4.9 branch?


Diffs
-

  README.packagers 67705c7 

Diff: http://git.reviewboard.kde.org/r/106114/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

Re: Google Drive KIOSlave

[Friedrich W. H. Kossebau]

Hi Andrius,

Am Donnerstag, 27. September 2012, 08:23:46 schrieb Andrius da Costa Ribas:
 2. Google drive allows identical filenames.
 -files have a unique id, but can have the very same filename. It would not
 be practical to use the id in the kio url, but using the filename may lead
 to conflicts. Google drive windows syncing program renames the second file
 (e.g. file.txt and file (2).txt) but only in the syncing folder,
 however I don't think this is a clean solution for a kioslave.

You can prevent the conflicts by using the field UDS_DISPLAY_NAME in the 
UDSEntry object you create for a file. Set that field to the filename. In the 
url you better use the id, does not look pretty, but usually people only look 
at the names of the items in the currently selected folder.

See http://api.kde.org/4.x-api/kdelibs-
apidocs/kio/html/classKIO_1_1UDSEntry.html#a8c3c5c6ee998a9f0e413b8aafcc98597a95885a6aae5b1fce559e8c61a9d88dca

(In a perfect world the breadcrumbbar would also use the display name data for 
the display if not in url mode, no idea if it does, if not file a bug :) )

Only problem here will be that programs which get a file passed from your kio-
slave will see the id name, not the nice display name, as that information 
gets dropped. This is a problem your kio-slave will share with all others that 
use UDS_DISPLAY_NAME I guess.

Have a look at other kio-slaves using it:
http://lxr.kde.org/ident?i=UDS_DISPLAY_NAME

 3. It apparently has no character restriction on filenames.
 -windows syncing app replaces unsupported characters with underscores. I
 think percent encoding would be a better solution.

In theory linux file systems (at least the oldschool ones) also have no 
character restriction, they are just strings of bytes, interpretation left to 
user/programs. No idea how the KIO system handles copying of files between 
filesystems with different character restrictions.
Still I think nothing you have to care about in your kio slave, that is left 
to the parts of KIO which get a file from your kio slave, e.g. if copying, and 
have more restrictions.

Cheers
Friedrich

Kdelibs Coding Style vs. preparations for Qt5

[Friedrich W. H. Kossebau]

Hi,

what about adapting the Kdelibs Coding Style to the upcoming preparations for 
the porting to Qt5? A lot of (KDE) projects follow that kdelibs one, but there 
is (at least?) one rule which seems to conflict with the recommendations for 
the preparations:

--- 8 ---
Qt Includes 

If you add #includes for Qt classes, use both the module and class name. This 
allows library code to be used by applications without excessive compiler 
include paths. 

Example: 
// wrong
#include QString
 
// correct
#include QtCore/QString
--- 8 ---
From http://techbase.kde.org/Policies/Kdelibs_Coding_Style#Qt_Includes


Of course the current Qt Coding Style, which is the base of the kdelibs one, 
does not mention anything about that, given that its about their own headers.


Now the Porting from Qt 4 to Qt 5 guide from KDAB recommends this:
--- 8 ---
Fixing up includes

[...]

Or more portably (Which works in Qt 4 and Qt 5):
#include QWidget
--- 8 ---
From http://www.kdab.com/porting-from-qt-4-to-qt-5/


So what to do about this?

Will kde-frameworks be Qt5-only, so not need to support both Qt4 and Qt5 and 
thus to use module-less Qt includes? Or will the includes be if-def'ed?
So will projects which refer to the Kdelibs Coding Style need to add an 
exception to their rules for the includes, if they want to prepare for Qt5?

Or does the rule need adaption?

Cheers
Friedrich

Crashes with libQtUiTools.a if linked multiple times into the same process (with Bsymbolic-functions flag)

[Friedrich W. H. Kossebau]

Hi,

tl;dr how to avoid crashes if libQtUiTools.a is linked multiple times into a 
process?


You use at least one of kross, kjsembed, or plasma in your 
application/lib/module and possibly also directly libQtUiTools yourself?

Then bugs.kde.org shows that chances are that you have seen crashes with this 
in the backtrace:
#6  0xb5320313 in 
QFormInternal::domPropertyToVariant(QFormInternal::QAbstractFormBuilder*, 
QMetaObject const*, QFormInternal::DomProperty const*) () from XXX 

where XXX could be libplasma, libkjsembed, krossmoduleforms or your own 
binary/lib/module.

For historic reasons libQtUiTools is a static lib, not a shared, and there has 
been no work to change that, compare 
https://bugreports.qt-project.org/browse/QTBUG-437

A few days ago I looked into Kross scripts in Calligra the first time, only to 
ran into this problem, as reported to my distri here: 
https://bugzilla.novell.com/show_bug.cgi?id=819437

As can be read in that report, I saw in my backtrace that QFormInternal 
methods are once called in krossmoduleforms.so, once in libkjsembed.so.4 in 
the very same call stack, while they surely should be only done in a single 
place. And Hrvoje Senjan found that linking libQtUiTools.a into the own code 
without Bsymbolic-functions flag seems to avoid the crashes.

So, anyone with more clue than me WRT symbols from static libs and the 
Bsymbolic-functions linker flag who could tell if that indeed should fix such 
problems if code from the same static lib is arriving multiple times in the 
same process via different libs/modules?

If so, should all the places where ${QT_QTUITOOLS_LIBRARY} is linked in 
kdelibs and elsewhere get a blocker to the Bsymbolic-functions flag?
How would that be done, to force this flag to be unset?

What about other non-GCC platforms/compilers, is there a similar problem?

Cheers
Friedrich

Re: Crashes with libQtUiTools.a if linked multiple times into the same process (with Bsymbolic-functions flag)

[Friedrich W. H. Kossebau]

Hi Sune,

Am Samstag, 11. Mai 2013, 20:23:15 schrieb Sune Vuorela:
 On 2013-05-11, Friedrich W. H. Kossebau kosse...@kde.org wrote:
  So, anyone with more clue than me WRT symbols from static libs and the
  Bsymbolic-functions linker flag who could tell if that indeed should fix
  such problems if code from the same static lib is arriving multiple times
  in the same process via different libs/modules?
 
 It most likely will help on such a case.
 
 -Bsymbolic-functions ensures that functiotns are first resolved in the
 library/plugin itself before resolving it from outside the library.
 
 What happens, I think, is that it is sometimes using the functions from
 one of the static libs, other times from some of the other.
 
 I'm not sure we want libraries linking QtTools to be built with
 -Bsymbolic-functions because it breaks debugging and other magic using
 function overriding with LD_PRELOAD tricks, because they rely on being
 chosen first over the 'internal' functions.

Bsymbolic-functions seems default for all qt/kde libs these days, no? So it 
would need to be removed everywhere if following your answers.

In the meantime downstream (openSUSE KDE maintainers) have created a different 
patch which instead simply tells the linker to exclude libQtUiTools.a when 
generating the public symbols, by calling in all relevant places
+   # Do not export QtUiTools internal symbols
+   set_target_properties(krossmoduleforms PROPERTIES LINK_FLAGS -Wl,--
exclude-libs -Wl,libQtUiTools.a)

See request
https://build.opensuse.org/package/view_file?file=exclude-qtuitools-symbols-from-public-libraries.patchpackage=kdelibs4project=KDE%3ADistro%3AFactory

Hopefully that will soon make it upstream if it proves to be the right fix 
(tm).

Cheers
Friedrich

Re: Crashes with libQtUiTools.a if linked multiple times into the same process (with Bsymbolic-functions flag)

[Friedrich W. H. Kossebau]

Hi Thiago,

Am Sonntag, 12. Mai 2013, 14:21:10 schrieb Thiago Macieira:
 On domingo, 12 de maio de 2013 22.47.35, Friedrich W. H. Kossebau wrote:
  +   # Do not export QtUiTools internal symbols
  +   set_target_properties(krossmoduleforms PROPERTIES LINK_FLAGS
  -Wl,-- exclude-libs -Wl,libQtUiTools.a)
 
 It seems the correct fix would be to compile libQtUiTools.a with -
 fvisibility=hidden in Qt. It's already the case in Qt 5, so it should not be
 a problem anymore.
 
 For Qt 4, I could investigate, but does it help if it only applies to Qt
 4.8.5 or 4.8.6?

Depends if one could assume that some people out there are relying on these 
symbols being public. Who can know? Seems so far noone was really bitten by it 
(or at least has found out, like we now have for our KDE software, though then 
this problem should be with us since years potentially, no?), so perhaps 
better to keep things as they are.

If asked I would simply add a warning somewhere that this lib exposes all 
symbols as is. But not change the ABI, given that there is still the other 
solution for users of the lib, hiding that lib's symbols oneself with the 
exclude-libs flag.

Interesting problem still: so any public symbol from a static lib can 
potentially appear multiple times in a process, if coming with different 
libs/modules, and then the first instance of that symbol shadows all other 
instances, possibly even of incompatible versions? Evil trap...

So, our problem: Qt 4.8.5 is not out yet. KDE SC 4.10.4 might be out before, 
so ideally the fix goes out with that, to get it to users as soon as possible.

Question now is how to fix this in our code. Is exclude-libs supported 
outside gnu ld and gold? And for all platforms?

What other options are there, for platforms where visibility is not supported 
in any way? Can symbols from static libs be prefixed somehow on linking, to 
avoid clashes?

Cheers
Friedrich

Re: Crashes with libQtUiTools.a if linked multiple times into the same process (with Bsymbolic-functions flag)

[Friedrich W. H. Kossebau]

Am Montag, 13. Mai 2013, 10:06:59 schrieb Thiago Macieira:
 On segunda-feira, 13 de maio de 2013 17.41.58, Friedrich W. H. Kossebau 
wrote:
  Interesting problem still: so any public symbol from a static lib can
  potentially appear multiple times in a process, if coming with different
  libs/modules, and then the first instance of that symbol shadows all other
  instances, possibly even of incompatible versions? Evil trap...
 
 This is the same old problem of conflicting symbols. It's nothing new.
 
 In fact, it still exists *because* it's missing the latest innovation, from
 2005: hidden symbols.

Never hit this problem with _static_ libs in all the years so far, so new for 
me ;)

((I somehow would have assumed that symbols from static libs are namespaced on 
linking, especially as noone seems to have guarded such linking in any other 
way, also did not catch my attention elsewhere yet. Possibly because people 
were not aware that libQtUiTools is a static and not a shared lib, this fact 
being hidden behind the var ${QT_QTUITOOLS_LIBRARY}))

So, still wondering what the (most) platform-independent fix can be from our 
side to this problem?

Cheers
Friedrich

Re: Review Request 110563: Crash fix: hide symbols from static lib QtUitools.a (generically by new macro KDE4_HIDE_SYMBOLS_FROM_STATIC_LIBS)

[Friedrich W. H. Kossebau]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110563/
---

(Updated May 22, 2013, 11:19 a.m.)


Review request for Build System, kdelibs, Alexander Neundorf, and Thiago 
Macieira.


Changes
---

Put Crash keyword in title, to get more attention.
Also set Alex and Thiago explicitely as reviewers.

Want to get this in ASAP, before 4.10.4


Summary (updated)
-

Crash fix: hide symbols from static lib QtUitools.a (generically by new macro 
KDE4_HIDE_SYMBOLS_FROM_STATIC_LIBS)


Description
---

Like discussed in the thread Crashes with libQtUiTools.a if linked multiple 
times into the same process (with Bsymbolic-functions flag) on kde-core-devel 
( http://lists.kde.org/?t=13682986311r=1w=2 ) symbols from QtUitools.a 
are not hidden by default in Qt4 and thus will be added to the public symbols 
of the module/shared lib they are linked to. And thus can appear multiple times 
in the same process, resulting in symbol clashes and leading to problems at 
least with the Bsymbolic-functions flag or when being possibly incompatible 
versions.

Attached patch sees to solve that problem, by adding a macro 
KDE4_HIDE_SYMBOLS_FROM_STATIC_LIBS which should add any needed linker flags 
depending on the platform/linker used. 

Only issue is that instead of some variable I had to use QtUiTools.a as I 
found no variable which would resolve to that. E.g. ${QT_QTUITOOLS_LIBRARY} 
resolves to Qt4::QtUiTools for me. Any idea what to use there, in case 
another platform needs another name/prefix here?

Patch is against 4.10 branch, so I hope to get this in 4.10.4

http://lxr.kde.org/search?v=4.10-branchfilestring=string=QT_QTUITOOLS_LIBRARY 
shows that there are some more places where the symbols need hiding, but I 
first want feedback on the proposed approach.


Diffs
-

  cmake/modules/FindKDE4Internal.cmake cb63285 
  cmake/modules/KDE4Macros.cmake 3db4e24 
  kjsembed/kjsembed/CMakeLists.txt d70f260 
  kross/modules/CMakeLists.txt d245fd8 
  kross/qts/CMakeLists.txt d8cb4a5 
  plasma/CMakeLists.txt 674550d 

Diff: http://git.reviewboard.kde.org/r/110563/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

Re: Review Request 110563: Crash fix: hide symbols from static lib QtUitools.a (generically by new macro KDE4_HIDE_SYMBOLS_FROM_STATIC_LIBS)

[Friedrich W. H. Kossebau]

 On May 22, 2013, 6:28 p.m., Alexander Neundorf wrote:
  The documentation for the macro should be at the top of 
  FindKDE4Internal.cmake, where all the documentation is.
  
  For the technical side: this flag is new to me. Is it the only possible 
  solution ? Thiago ?
 
 Thomas Lübking wrote:
  For the technical side: this flag is new to me.
 I wasn't aware it's used and grepping the Makefiles of kdelibs, workspace 
 and runtime didn't show it here, btw.
 
 What it does:
 http://www.technovelty.org/c/what-exactly-does-bsymblic-do.html
 
 My 2¢
 There're various issues with it and i dare to claim that you more or less 
 want to use it alongside --dynamic-list only.
 Alternatively one would use 
 __attribute__((visibility([hidden|protected]))) or the -version-script 
 switch to protect/accelerate *certain* funtion/calls. (protected visibility 
 is afair gcc only, though)
 
 If downstream applies it, i'd frankly tell downstream to rtfm and not 
 just push everything claimed to make it fasta!!!
 
 This is by no means sth. one should apply uninformed since it has 
 impact on the runtime behavior that the developer needs to know about 
 (whoops, my trick to shadow friend qt_foo() to gain access to 
 protected/private d-bar only works sometiems - yes, one should not hack, 
 but one should also be aware that this hack can legally fail and not wonder 
 why it works here and on distro X but fails on distro Y)

Now the KDE packages for OpenSUSE are said to have been created with that flag 
already for a while, given Hrvoje Senjan saying we are using it 4 years 
already, this is first known issue it's caused so far 
(https://bugzilla.novell.com/show_bug.cgi?id=819437#c14)

http://qt-project.org/wiki/Performance_Tip_Startup_Time says: Use 
-Bsymbolic-functions for your shared libraries., more or less, with no big 
warnings. (Please note your warnings there, to have more downstream rtfm :) )

Surely -Bsymbolic-functions should be used with care.


Still, we have the problem that QtUitools.a exposes all its symbols on Linux  
similar. Which means symbol clashes if loaded multiple times in the same 
process. With and without -Bsymbolic-functions. One could fix QtUitools.a for 
4.8.future. Or see to do on our side what can be done, i.e. explicitely hide 
those symbols when linking the now existing versions of the static lib 
QtUitools.a into our code, so any of our code does not even try to lookup its 
symbols in the wrong place.

Which is what the proposed patch does, offer the option to mark an extern 
static library to be linked without exposing its symbols, on those platform 
where it is needed.

What other solution would there be?


- Friedrich W. H.


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110563/#review32984
---


On May 22, 2013, 6:45 p.m., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/110563/
 ---
 
 (Updated May 22, 2013, 6:45 p.m.)
 
 
 Review request for Build System, kdelibs, Alexander Neundorf, and Thiago 
 Macieira.
 
 
 Description
 ---
 
 Like discussed in the thread Crashes with libQtUiTools.a if linked multiple 
 times into the same process (with Bsymbolic-functions flag) on 
 kde-core-devel ( http://lists.kde.org/?t=13682986311r=1w=2 ) symbols 
 from QtUitools.a are not hidden by default in Qt4 and thus will be added to 
 the public symbols of the module/shared lib they are linked to. And thus can 
 appear multiple times in the same process, resulting in symbol clashes and 
 leading to problems at least with the Bsymbolic-functions flag or when being 
 possibly incompatible versions.
 
 Attached patch sees to solve that problem, by adding a macro 
 KDE4_HIDE_SYMBOLS_FROM_STATIC_LIBS which should add any needed linker flags 
 depending on the platform/linker used. 
 
 Only issue is that instead of some variable I had to use QtUiTools.a as I 
 found no variable which would resolve to that. E.g. ${QT_QTUITOOLS_LIBRARY} 
 resolves to Qt4::QtUiTools for me. Any idea what to use there, in case 
 another platform needs another name/prefix here?
 
 Patch is against 4.10 branch, so I hope to get this in 4.10.4
 
 http://lxr.kde.org/search?v=4.10-branchfilestring=string=QT_QTUITOOLS_LIBRARY
  shows that there are some more places where the symbols need hiding, but I 
 first want feedback on the proposed approach.
 
 
 Diffs
 -
 
   cmake/modules/FindKDE4Internal.cmake cb63285 
   cmake/modules/KDE4Macros.cmake 3db4e24 
   kjsembed/kjsembed/CMakeLists.txt d70f260 
   kross/modules/CMakeLists.txt d245fd8 
   kross/qts/CMakeLists.txt d8cb4a5 
   plasma/CMakeLists.txt 674550d 
 
 Diff

Re: Review Request 113965: Possible fix for bug 321100

[Friedrich W. H. Kossebau]

 On Nov. 20, 2013, 6:02 p.m., Albert Astals Cid wrote:
  I don't see why this should fix anything. Do you think anyone in the bug 
  can provide a valgrind trace to better understand why it's crashing?
 
 Christoph Feck wrote:
 See also https://git.reviewboard.kde.org/r/102981/ which has some 
 discussion and links to related bugs.
 
 Albert Astals Cid wrote:
 Why is it related? Who is modifying the entries variable? It's used in 4 
 places in the file, and actually there's no way to remove stuff from it, so I 
 don't see how it is related to the bug you point.
 
 Christoph Feck wrote:
 They are only related because replacing qDeleteAll() with manual deletion 
 fixed the crash for Boudewijn. Since my understanding ended there, I 
 suggested to post a review request.
 
 Thomas Lübking wrote:
 See http://lists.kde.org/?t=13219477845r=1w=2
 Qt 4.8 changed qDeleteAll to rely on the container being immutable.
 
 The patch detaches the container, what allows safe operation despite - 
 what's likely happening as it seemed the core issue back than - the container 
 is altered by the deletion of one or more of its items (eg. the items 
 deconstructor delists itself)
 
 An alternative solution would be to pass the to-be-deleted objects class 
 a static member flag to skip self delisting and set that around qDeleteAll() 
 (which would be followed by an erase())
 
 Albert Astals Cid wrote:
 Please look at the code and tell us where the item deconstructor delists 
 itself from the list.
 
 Thomas Lübking wrote:
 I said that it seemed the core issue back then, not that it happens here 
 (for sure) or would be the only trigger.
 
 Briefly looking at KArchive, i'd rather bet on a recursion (entries 
 containing a KArchiveEntry being or ultimately pointing down to the same  
 KArchiveDirectory)
 Just a wild guess, though - but testable if one can reproduce the bug 
 (unless you can assure that cannot be the case)
 
 Boudewijn Rempt wrote:
 I haven't been able to reproduce it myself on Linux. On Windows it was a 
 lot easier, but there I use an old and completely hacked-up version of 
 kdelibs. However, when I was giving a workshop at LGM, pretty much half of 
 the Linux users present (most of them *buntu) users had to disable autosave 
 to prevent this crash from happening.
 
 I'm puzzled... And I would love a better fix than mine, but that will 
 have to come from someone who understands karchive -- which I don't, not 
 really.
 
 Friedrich W. H. Kossebau wrote:
 I do not have a better fix yet, but I think I found the root of the 
 problem:
 in case of a duplicated name for an entry in KZip::doPrepareWriting() the 
 old entry is removed from d-m_fileList, but not from the parentDir directory 
 holding it:
 
 https://projects.kde.org/projects/kde/kdelibs/repository/revisions/ee5dea835039c8a8f765321378dbed398826f368/entry/kdecore/io/kzip.cpp#L1026
 
 Thus on destruction of that dir the qDeleteAll will try to delete an 
 entry that is already deleted. Seems that triggers not always a crash, 
 perhaps because the memory might still be available?
 
 Sadly I do not have a kdelibs development environment setup currently and 
 also short of disk space, so cannot come up with a patch/unittest. Anyone? 
 But so far I already see the problem that KArchiveDirectory has a method 
 addEntry( KArchiveEntry* ) (which currently in case of adding an entry with 
 the same name qwarns about that, and ignores the new entry), but not some 
 removeEntry( KArchiveEntry* ). This needs some more thinking what the 
 proper behaviour should be and how to solve that. Perhaps addEntry( 
 KArchiveEntry* ) should just overwrite the old entry, that would at least 
 match the behaviour in KZip::doPrepareWriting()...
 
 Any takers?

Took it myself ;)

Please see  review https://git.reviewboard.kde.org/r/114048/ for a proposal 
how to fix that problem in KZip::doPrepareWriting().


- Friedrich W. H.


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113965/#review44060
---


On Nov. 20, 2013, 9:40 a.m., Boudewijn Rempt wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/113965/
 ---
 
 (Updated Nov. 20, 2013, 9:40 a.m.)
 
 
 Review request for kdelibs.
 
 
 Bugs: 321100
 http://bugs.kde.org/show_bug.cgi?id=321100
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 While I haven't been able to reproduce the issue on Linux, many Krita users 
 encounter a crash in the destructor of  KArchiveDirectoryPrivate, where all 
 entries are removed with qDeleteAll.
 
 This patch removes the use of qDeleteAll.
 
 I'm not 100% sure

Re: Review Request 114048: fix crash in KZip on overwriting existing entries (+ unit test)

[Friedrich W. H. Kossebau]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114048/
---

(Updated Nov. 28, 2013, 1:05 a.m.)


Status
--

This change has been marked as submitted.


Review request for kdelibs and David Faure.


Bugs: 321100
http://bugs.kde.org/show_bug.cgi?id=321100


Repository: kdelibs


Description
---

CRASH REASON

In case of writing a file to a KZip object with a name for which there already 
exists an entry with the same name, the following will happen in 
KZip::doPrepareWriting(...):
when the existing entry in d-m_fileList is found, it is removed from 
d-m_fileList and deleted.

The problem is that each entry is also listed in the KArchiveDirectory it is 
contained in by the path derived from its name. And KArchiveDirectory is the 
one which does the lifetime handling of the entries, by a qDeleteAll(entries) 
in the private data destructor.
But in the above point it is forgotten to remove the entry from the 
KArchiveDirectory it was listed in. So KArchiveDirectory keeps a pointer to a 
no-longer existing entry. Which should result in a crash on that qDeleteAll. 
But in many situations something accidentally prevents that, see soon.

So after the old entry was removed and deleted, a new KZipFileEntry is created, 
then added both to d-m_fileList and the parentDir, by calling addEntry(...) on 
that. Now KArchiveDirectory::addEntry(...) checks if there is already an entry 
with such a name listed, and if so, simply emits a warning and returns without 
doing anything. In our case it will do so, because the old entry, with the same 
name, was not removed, so the new entry will not be added.

Means, we have a pointer to a non-existing entry and an entry which will not be 
cleaned up. Strange enough for users of KZip like Krita, which happened to 
accidentally write the same entry two times, a crash was not always 
experienced. Adding some debug output shows why: the new KZipFileEntry often 
gets exactly the memory assigned which was before assigned to the old entry 
that was just deleted.
  // first write of file
  KZip::doPrepareWriting:
  KZip::doPrepareWriting: created 0x1cfbc20
  KArchiveDirectory::addEntry: entry= 0x1cfbc20 name= samefile
  // second write of file
  KZip::doPrepareWriting:
  KZip::doPrepareWriting: deleting 0x1cfbc20
  KZip::doPrepareWriting: created 0x1cfbc20
  KArchiveDirectory::addEntry: entry= 0x1cfbc20 name= samefile
  KArchiveDirectory::addEntry: directory  / has entry samefile already 
  KArchiveDirectory::~KArchiveDirectory: /

So the old entry in KArchiveDirectory was pointing to the new entry again, thus 
not resulting in any problem.

But often enough that does not happen, so is assumed to lead to 
https://bugs.kde.org/show_bug.cgi?id=321100 because, as said before, Krita 
happened to accidentally write the same entry two times into the zip on saving 
.kra files.

PATCH
-
Attached patch fixes that by removing the old entry also properly from the 
KArchiveDirectory it is registered with before deleting it. The retrieval of 
the parent dir has been removed before the duplication check for that reason, 
so that the parent directory object is available when needed.

There is also a small unit test which tests behaviour on writing the same file 
two times into a zip.


DESTINATION?

If okayed, to which branches should that be applied? master, KDE/4.11, KDE/4.12?
Who could care to get this into KF5?


Diffs
-

  kdecore/io/karchive.h 7cd7c0c 
  kdecore/io/karchive.cpp 88e1de0 
  kdecore/io/kzip.cpp d5b0146 
  kdecore/tests/karchivetest.h 29dc791 
  kdecore/tests/karchivetest.cpp 8a5b9f3 

Diff: http://git.reviewboard.kde.org/r/114048/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

Review Request 114889: Fix KIO::convertSize(...) returning string with (I18N_ARGUMENT_MISSING) inside

[Friedrich W. H. Kossebau]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114889/
---

Review request for kdelibs.


Repository: kio


Description
---

Seems the code behind i18n() in kf5 does not like %-placeholders without any 
arguments passed in the i18n call. And thus inserts the warning.
(Effect can be seen e.g. in Okteta's File Info tool).

Attached patch fixes that, by delaying the argument substitution as proposed in 
http://api.kde.org/frameworks-5.x-api/frameworks-apidocs/ki18n/html/prg_guide.html#spec_usage


Diffs
-

  src/core/global.cpp 42f453b 

Diff: https://git.reviewboard.kde.org/r/114889/diff/


Testing
---

Results of KIO::convertSize(...) displays fine in Okteta with the patch.


Thanks,

Friedrich W. H. Kossebau

Re: Review Request 114889: Fix KIO::convertSize(...) returning string with (I18N_ARGUMENT_MISSING) inside

[Friedrich W. H. Kossebau]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114889/
---

(Updated Jan. 7, 2014, 4:24 p.m.)


Review request for kdelibs.


Changes
---

Updated patch to follow Chusslove's proposal for runtime performance 
improvement.


Repository: kio


Description (updated)
---

Seems the code behind i18n() in kf5 does not like %-placeholders without any 
arguments passed in the i18n call. And thus inserts the warning.
(Effect can be seen e.g. in Okteta's File Info tool).

Attached patch fixes that, by passing as argument a string with an argument 
placeholder again.


Diffs (updated)
-

  src/core/global.cpp 42f453b 

Diff: https://git.reviewboard.kde.org/r/114889/diff/


Testing
---

Results of KIO::convertSize(...) displays fine in Okteta with the patch.


Thanks,

Friedrich W. H. Kossebau

Re: Review Request 114889: Fix KIO::convertSize(...) returning string with (I18N_ARGUMENT_MISSING) inside

[Friedrich W. H. Kossebau]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114889/
---

(Updated Jan. 8, 2014, 10:43 a.m.)


Status
--

This change has been marked as submitted.


Review request for kdelibs.


Repository: kio


Description
---

Seems the code behind i18n() in kf5 does not like %-placeholders without any 
arguments passed in the i18n call. And thus inserts the warning.
(Effect can be seen e.g. in Okteta's File Info tool).

Attached patch fixes that, by passing as argument a string with an argument 
placeholder again.


Diffs
-

  src/core/global.cpp 42f453b 

Diff: https://git.reviewboard.kde.org/r/114889/diff/


Testing
---

Results of KIO::convertSize(...) displays fine in Okteta with the patch.


Thanks,

Friedrich W. H. Kossebau

Re: Review Request 110563: Crash fix: hide symbols from static lib QtUitools.a (generically by new macro KDE4_HIDE_SYMBOLS_FROM_STATIC_LIBS)

[Friedrich W. H. Kossebau]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/110563/
---

(Updated Sept. 17, 2014, 7:36 nachm.)


Status
--

This change has been discarded.


Review request for Build System, kdelibs, Alexander Neundorf, and Thiago 
Macieira.


Repository: kdelibs


Description
---

Like discussed in the thread Crashes with libQtUiTools.a if linked multiple 
times into the same process (with Bsymbolic-functions flag) on kde-core-devel 
( http://lists.kde.org/?t=13682986311r=1w=2 ) symbols from QtUitools.a 
are not hidden by default in Qt4 and thus will be added to the public symbols 
of the module/shared lib they are linked to. And thus can appear multiple times 
in the same process, resulting in symbol clashes and leading to problems at 
least with the Bsymbolic-functions flag or when being possibly incompatible 
versions.

Attached patch sees to solve that problem, by adding a macro 
KDE4_HIDE_SYMBOLS_FROM_STATIC_LIBS which should add any needed linker flags 
depending on the platform/linker used. 

Only issue is that instead of some variable I had to use QtUiTools.a as I 
found no variable which would resolve to that. E.g. ${QT_QTUITOOLS_LIBRARY} 
resolves to Qt4::QtUiTools for me. Any idea what to use there, in case 
another platform needs another name/prefix here?

Patch is against 4.10 branch, so I hope to get this in 4.10.4

http://lxr.kde.org/search?v=4.10-branchfilestring=string=QT_QTUITOOLS_LIBRARY 
shows that there are some more places where the symbols need hiding, but I 
first want feedback on the proposed approach.


Diffs
-

  cmake/modules/FindKDE4Internal.cmake cb63285 
  cmake/modules/KDE4Macros.cmake 3db4e24 
  kjsembed/kjsembed/CMakeLists.txt d70f260 
  kross/modules/CMakeLists.txt d245fd8 
  kross/qts/CMakeLists.txt d8cb4a5 
  plasma/CMakeLists.txt 674550d 

Diff: https://git.reviewboard.kde.org/r/110563/diff/


Testing
---


Thanks,

Friedrich W. H. Kossebau

KDiagram libs (KChart, KGantt) in KDE Review

[Friedrich W. H. Kossebau]

Hi,

Calligra, Massif-Visualizer, KMyMoney (and perhaps more) make use of KDAB's 
nice offer of their KDChart in the GPLv2 licensing variant. But as there are 
no real public releases of KDChart, all the projects have copied a dump of 
KDChart into their code repositories, updating now and then to newer versions 
of KDChart. Which is anything but perfect.

To improve things, after some talk with KDABians it was decided to create a 
KDE repo with a KDE-fied fork of KDChart, based on their latest Qt5ied 
version. So all FLOSS Qt5-based projects have a single place to-go-to for nice 
charting. Which would be centrally updated now and then. Still not perfect, 
but an improvement over the current situation.
To meet the KDE repo requirements, KDAB has also extended the license to 
GPLv2+ for this dump :)

That repo is named kdiagram and has just been moved into kdereview.
Final destination is extragear/graphics, as other charting/diagram software 
also is located there.

After the initial code dump in the repo, work has been done to convert the 
buildsystem from qmake to cmake/ECM and KDE-fy the code in general. But no 
real changes besides renaming/rebranding have been done to the codebase, so 
this should be quickly usable by all FLOSS programs with their own copy of 
KDChart so far, and just need a few s/KDChart/KChart/ etc. for adaption.

KDChart actually consists of two libraries, kdchart and kdgantt, which 
have been made explicitly separate libs in KDiagram, and named kchart and 
kgantt there (and thus the repo kdiagram instead of kchart, to not hide 
the gantt lib). Not yet clear if those libs would be merged more one day, so 
for now staying with a single repo, like the original, instead of splitting up 
into two repos by the two libs.

Ideally a first release of kdiagram (libs kchart, kgantt) is done before the 
porting work of Calligra to Qt5 starts somewhen end of February, so that port 
can rely on the then external libs from the start. For that the schedule now 
is:

tagging first release: February 16th
moving to Extragear/Graphics: February 22th
release first release: February 22th

Please do a
git clone kde:kdiagram
and give the libs some build testing (also go for all the compiled example and 
test apps) and review, especially the buildsystem. And perhaps prepare your 
FLOSS apps to use it already. This should give you KChart resp. KGantt in your 
CMakeLists.txt file:

find_package(KChart 2.6.0 REQUIRED)
target_link_libraries(myflossapp KChart)

find_package(KGantt 2.6.0 REQUIRED)
target_link_libraries(myflossapp KGantt)

Cheers
Friedrich

Re: KDiagram libs (KChart, KGantt) in KDE Review

[Friedrich W. H. Kossebau]

Am Montag, 9. Februar 2015, 00:23:58 schrieb Albert Astals Cid:
 El Diumenge, 8 de febrer de 2015, a les 00:29:26, Friedrich W. H. Kossebau
 va
 escriure:
  Hi,
  
  Calligra, Massif-Visualizer, KMyMoney (and perhaps more) make use of
  KDAB's
  nice offer of their KDChart in the GPLv2 licensing variant. But as there
  are no real public releases of KDChart, all the projects have copied a
  dump of KDChart into their code repositories, updating now and then to
  newer versions of KDChart. Which is anything but perfect.
  
  To improve things, after some talk with KDABians it was decided to create
  a
  KDE repo with a KDE-fied fork of KDChart, based on their latest Qt5ied
  version. So all FLOSS Qt5-based projects have a single place to-go-to for
  nice charting. Which would be centrally updated now and then. Still not
  perfect, but an improvement over the current situation.
  To meet the KDE repo requirements, KDAB has also extended the license to
  GPLv2+ for this dump :)
 
 Thanks KDABians for this.
 
 If this is basically a copypaste from the existing code we're already
 shipping i have no objection,


Yes, nearly copypaste: the copies of KDChart in Calligra  KMyMoney are older 
(2.4.1, based on Qt4) versions, while the copy of KDChart in Massif-Visualizer 
matches the version of the KChart lib in KDiagram.

 though you should probably get someone with
 CMake knowledge to review (and kill that autogen.py and g++.pri?)

Yes, any volunteers here for reviewing the CMake parts? :) Code should be 
similar to that of a KF5 tier1 lib.

Cheers
Friedrich

Re: KDiagram libs (KChart, KGantt) in KDE Review

[Friedrich W. H. Kossebau]

Am Dienstag, 17. Februar 2015, 23:07:07 schrieb Albert Astals Cid:
 El Diumenge, 8 de febrer de 2015, a les 00:29:26, Friedrich W. H. Kossebau 
va escriure:
  Hi,
  
  Calligra, Massif-Visualizer, KMyMoney (and perhaps more) make use of
  KDAB's
  nice offer of their KDChart in the GPLv2 licensing variant. But as there
  are no real public releases of KDChart, all the projects have copied a
  dump of KDChart into their code repositories, updating now and then to
  newer versions of KDChart. Which is anything but perfect.
  
  To improve things, after some talk with KDABians it was decided to create
  a
  KDE repo with a KDE-fied fork of KDChart, based on their latest Qt5ied
  version. So all FLOSS Qt5-based projects have a single place to-go-to for
  nice charting. Which would be centrally updated now and then. Still not
  perfect, but an improvement over the current situation.
  To meet the KDE repo requirements, KDAB has also extended the license to
  GPLv2+ for this dump :)
  
  That repo is named kdiagram and has just been moved into kdereview.
  Final destination is extragear/graphics, as other charting/diagram
  software also is located there.
 
 Scripty says (not sure if correct or not, lupdate is sometimes a bit weird)

So seems lupdate complained over nested classes (e.g. A::Private) being 
defined without the nesting class (A) being declared before, at least all the 
complains where on lines after class A::B.

For most of these cases I could see that nesting classes where not included 
before. Just, in some cases they are. Seems lupdate has problems with the 
macro used which declares the nested class in the nesting class 
(KCHART_DECLARE_PRIVATE_BASE_POLYMORPHIC). 

Pushed a commit fixing those cases where the include for the nesting class 
would have been missing.

But not sure what to do about the rest. Replacing the preprocessor macro with 
explicit code, just to make lupdate happy? Any other, better idea? (Fix 
lupdate? well, out of my scope sadly)

Cheers
Friedrich

Re: KDiagram libs (KChart, KGantt) in KDE Review

[Friedrich W. H. Kossebau]

Am Mittwoch, 11. Februar 2015, 16:30:39 schrieb Andreas Hartmetz:
 On Wednesday 11 February 2015 14:59:50 Adriaan de Groot wrote:
  On Monday 09 February 2015 01:50:03 Friedrich W. H. Kossebau wrote:
   Yes, nearly copypaste: the copies of KDChart in Calligra  KMyMoney
   are older  (2.4.1, based on Qt4) versions, while the copy of
   KDChart in Massif-Visualizer matches the version of the KChart lib
   in KDiagram.
  
  I've tried compiling the code on FreeBSD 10.1-RELEASE with Clang 3.4.1
  (I'm assuming that's a supported compiler -- on techbase, searching
  for supported compiler doesn't give me much compatibility
  information newer than KDE 4.2).
  
   - I need to add /usr/local/include to the include search path; this
  
  is not kdiagram specific, but seems to be a general Qt5 issue on
  FreeBSD.
  
   - TestDrawIntoPainter seems to hang; after 2 min at 100% CPU I killed
  
  it. I ran it separately by hand and get output about missing OpenGL
  drivers (which is true, I'm building kdiagram in a restricted
  environment; I didn't originally expect to need to have DBUS running
  
  to be able to do the tests either) and debug output like:
  QDEBUG : TestDrawIntoPainter::testTest() Time for drawing pixmap
  :
  :/test: 53682 ms
  :
Is that test supposed to take so much longer (minutes) than the
  
  other tests (deciseconds)?
 
 I guess so. The test is commented out in the .pro file in the KDAB
 version - the reason is probably that it takes so long.

Yes, this test is also aborted on CI, see 
http://build.kde.org/job/kdiagram_master_qt5/lastCompletedBuild/testReport/

And locally also ran forever=until I cancelled. Will disable then as well in 
KDiagram. And perhaps investigate for a possible error in the code, if I feel 
more curious later :)

  So from a it-compiles-and-the-tests-pass point of view on my platform,
  it looks good.

Thanks again for that testing, Ade, should have helped by that one fix for 
clean builds with clang in general :)

Cheers
Friedrich

Re: KDiagram libs (KChart, KGantt) in KDE Review

[Friedrich W. H. Kossebau]

Am Montag, 9. Februar 2015, 04:09:59 schrieb Aleix Pol:
 Hi,
 I just went through the cmake code.

Thanks, Aleix.

 Let's see:
 - I see this, what does need to be fixed?  # TODO: fix
 ecm_generate_headers to support camelcase .h files

See https://git.reviewboard.kde.org/r/122317/ , and for related discussion 
also https://git.reviewboard.kde.org/r/122193 

By current feddback in the other RR 122317 seems okay principally, just noone 
has yet ship-it-ed. Looking forward to someone doing so, so KDiagram can soon 
make use of the macro also for KChart (yes, could have also worked-around by 
lowercasing all filenames in the sources, but did not want to change even more 
things than just the namespace).

 - Library targets are usually called KF5*, see KF5Parts or KF5Gantt

Even if not part of KF5 itself? So should any libraries in KDE repos prefix 
their targets like that, because the related ECM macros are used?
I would rather think KF5 prefix should be reserved to libs from KF5, but if 
what you propose is already standard, I will follow.

 - Is this really needed? add_definitions(-DKDAB_NO_UNIT_TESTS). It's
 not very good to compile differently things if there's unit tests and
 not.

Not perfect, agreed. Okay if I add a TODO for now?
(given this is also in existing released code, and fixing might need some 
discussions)

 - some of the definitions in the root CMakeLists.txt files are already
 being defined by KDEFrameworkCompilerSettings. You might want to clean
 them up.

Fixed, 

 - misses a .reviewboardrc file.

Fixed.

 I created a small review request you also want to look into:
 https://git.reviewboard.kde.org/r/122495/

Thanks for that, going to comment on tonight.

Cheers
Friedrich

Moving KDiagram to extragear/graphics/libs (was: Re: KDiagram libs (KChart, KGantt) in KDE Review)

[Friedrich W. H. Kossebau]

Hi,

2 weeks have passed, seems there are no stoppers for KDiagram to move on into 
extragear/graphics/libs :) So filing now a ticket to sysadmin to do the move.

Thanks Albert, Aleix, Adriaan for having given KDiagram a check and (helping 
on) solving the issues you found (so KDiagram is Triple A rated? ;) )

Thanks also to whoever silently gave KDiagram some testing but did not report 
anything (hopefully a good sign).

Status:
* KDiagram builds on CI without warnings, all tests pass:
  http://build.kde.org/job/kdiagram_master_qt5/
* bugs.kde.org: added Product kdiagram, components KChart  KGantt
* reviewboard: kdiagram (first review request handled)
* i18n.kde.org: integrated, first translations done:
  http://i18n.kde.org/stats/gui/trunk-kf5/po/kgantt_qt.po/
  http://i18n.kde.org/stats/gui/trunk-kf5/po/kchart_qt.po/
* KMyMoney frameworks branch ported to KChart (and found first bugs :P)
* Massif-Visualizer frameworks branch has review request for port to KChart
  (maintainer on vacation currently)
* Calligra will start the Qt5/KF5 port the next days, so nothing yet to do

Currently known unsolved issues (which I consider no showstoppers):
* lupdate/Scripty fails on some files, but no deal right now, as no strings
  are in code affected. Will look into once I have more time.
* code is build with different flag if unit tests are build, not perfect
  actually only enables unit tests embedded directly in the source files,
  so not changing actual library code
  (marked as TODO for now, no regression against currently used
  old snapshots of KDChart)

First release:
Other than initially planned I will not do an immediate release of KDiagram 
now, but first collect some more feedback by the projects porting to it, 
especially Calligra. First release will still happen before or at time the 
first release of any project known that ported to it of course (so tell if 
yours does :) ).

Cheers
Friedrich

Re: branchGroup stable-qt4 Compile failures. Need dev assistance please.

[Friedrich W. H. Kossebau]

Hi Scarlett,

great work with the update of the KDE CI, thank you for caring for that side 
of development :)

2 things where you asked for more help: 

Am Dienstag, 21. April 2015, 13:45:06 schrieb Scarlett Clark:
 I know this is an external depend, but I have no experience with it.
 Can maybe a calligra dev take a look, as they need it.
 VC
 https://build-sandbox.kde.org/job/vc%20master%20stable-qt4/PLATFORM=Linux,co
 mpiler=gcc/2/console

Please build only the 0.7.4 release of vc, tagged with 0.7.4. So not 
master or anything else. That would be for any builds of vc, in any group 
(vc does not use qt anyway). AFAIK only Calligra uses vc right now, and in all 
branches Calligra needs vc 0.7(.4).
 
 With that said:
 Calligra: (probably vc)
 https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/calligra%20c
 alligra-2.9%20stable-qt4/10/

Yes, given so far no vc build completed, this seems to fail when trying to get 
a built version of vc. Should work better once there is one :)

Though there seems also another problem: commits to the calligra/2.9 branch 
are not triggering any builds of the qt4 stable build:
https://build.kde.org/view/branchGroup%20stable-qt4/job/calligra%20calligra-2.9%20stable-qt4/

That was not a problem in the old CI, but so far noone can tell what is wrong 
now. Commits to the frameworks and master branches seem to properly 
trigger builds of the respective build setups. Perhaps you might have an idea?

Cheers
Friedrich

Re: branchGroup stable-qt4 Compile failures. Need dev assistance please.

[Friedrich W. H. Kossebau]

Hi Scarlett,

Am Mittwoch, 29. April 2015, 23:26:14 schrieb Friedrich W. H. Kossebau:
 Am Dienstag, 21. April 2015, 13:45:06 schrieb Scarlett Clark:
  I know this is an external depend, but I have no experience with it.
  Can maybe a calligra dev take a look, as they need it.
  VC
  https://build-sandbox.kde.org/job/vc%20master%20stable-qt4/PLATFORM=Linux,
  co mpiler=gcc/2/console
 
 Please build only the 0.7.4 release of vc, tagged with 0.7.4. So not
 master or anything else. That would be for any builds of vc, in any group
 (vc does not use qt anyway). AFAIK only Calligra uses vc right now, and in
 all branches Calligra needs vc 0.7(.4).

See you changed that meanwhile, looks good WRT vc (and also the Calligra 
master build), thanks :) 

But then there is still the following bummer:

  With that said:
  Calligra: (probably vc)
  https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/calligra%2
  0c alligra-2.9%20stable-qt4/10/
 
 Yes, given so far no vc build completed, this seems to fail when trying to
 get a built version of vc. Should work better once there is one :)
 
 Though there seems also another problem: commits to the calligra/2.9
 branch are not triggering any builds of the qt4 stable build:
 https://build.kde.org/view/branchGroup%20stable-qt4/job/calligra%20calligra- 
 2.9%20stable-qt4/
 
 That was not a problem in the old CI, but so far noone can tell what is
 wrong now. Commits to the frameworks and master branches seem to
 properly trigger builds of the respective build setups. Perhaps you might
 have an idea?

Anything where we could help with to solve this? The calligra/2.9 branch is 
actually the hot branch these weeks still, main work is done there (especially 
the awesome Krita one), so not having CI as a reference up and working for 
this branch is a loss at the moment :) (see, CI is important to us :) so we 
appreciate your work even more)

Cheers
Friedrich

Best-practise currently for testing internal parts of libs? *_TEST_EXPORT macro?

[Friedrich W. H. Kossebau]

Hi,

what approach is best-practise currently for testing internal parts of libs? 
E.g. by symbols (classes) are not exported by default?

In Calligra we have code that uses XYZ_TEST_EXPORT macros for those symbols 
which should be only exported in test-enabled builds, e.g. by defining 
COMPILING_TESTS to true and having code in the export header like

#ifdef COMPILING_TESTS
#if defined _WIN32 || defined _WIN64
# if defined(calligrasheetsodf_EXPORTS)
#   define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_EXPORT
#   else
#   define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_IMPORT
#   endif
# else /* not windows */
#   define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_EXPORT
# endif
#else /* not compiling tests */
#   define CALLIGRA_SHEETS_ODF_TEST_EXPORT
#endif

But when switching to generated export headers, using cmake's 
generate_export_header macro, this seems no longer an option.

Grepping for TEST_EXPORT on lxr.kde.org points that this seems an older 
approach which only might have survived in the island of Calligra :) when the 
rest of KDE world evolved to something else?
So what are others doing?

The only place lxr.kde.org pointed out to use the *TEST_EXPORT approach was 
grantlee, which simply creates a separate file with the define that then is 
appended to the file generated with generate_export_header:
http://lxr.kde.org/source/grantlee/templates/lib/CMakeLists.txt

Seems a working hack which we could copy. But not sure if this is the best way 
and if this should not be done more generically?

Cheers
Friedrich

Re: Porting to frameworks 2: libkcompactdisc

[Friedrich W. H. Kossebau]

Am Freitag, 4. September 2015, 02:28:49 schrieb Alexander Potashev:
> 2015-09-04 0:49 GMT+03:00 Jeremy Whiting :
> > Second project I took a quick stab at libkcompactdisc which
> > audiocd-kio will need (which amarok will need for playing audio cds
> > once it's ported to qt5/kf5 too). I pushed to a frameworks branch and
> > it builds, but the resulting library is called
> > libkcompactdisc.so.SOVERSION. I guess we need to set a specific
> > version for this library, probably bumped from what the old
> > qt4/kdelibs4 version was?
> 
> Hi Jeremy,
> 
> I think the new fancy library naming scheme is
> "libKF5Xxx.so.SOVERSION", regardless of it being part of KF5 or not.
> Thus libKF5CompactDisc.so.5.

If that really is the scheme (is that noted somewhere?), I would ask to 
reconsider it. For once, because it will result in clashes if a lib really 
becomes part of KF5 (and thus becomes part of other packages which might be 
installed together with a package where the lib was initially in, unless the 
lib is the only content of the package, so that can be completely replaced by 
the KF5 package)

And also does it blur the hint by the name if something is part of KF5 or not. 
This lib may be using KF5, but it is not KF5. That namespace should be left to 
KF5 libs, like  libQt* is left to Qt libs.

I would rather propose libkcompactdisc2.so.SOVERSION here, so namespacing by 
postfix number. There is also the pattern libkcompactdisc-qt5.so.SOVERSION, 
which strikes out the dep to qt5, but not my favourite due to that 
verboseness. :)

Cheers
Friedrich

Re: Best-practise currently for testing internal parts of libs? *_TEST_EXPORT macro?

[Friedrich W. H. Kossebau]

Am Mittwoch, 2. September 2015, 11:20:19 schrieb David Faure:
> On Monday 31 August 2015 14:41:00 Friedrich W. H. Kossebau wrote:
> > The only place lxr.kde.org pointed out to use the *TEST_EXPORT approach
> > was
> > grantlee, which simply creates a separate file with the define that then
> > is
> > appended to the file generated with generate_export_header:
> > http://lxr.kde.org/source/grantlee/templates/lib/CMakeLists.txt
> 
> Konqueror has a simpler approach, a file that includes the generated file
> and adds the tests_export macro on top.

That might be less fragile than the grantlee approach, thanks for pointing to 
that solution :)

Though has the small beauty disadvantage that this needs both the generated 
and that wrapping export header to be installed. But no show-stopper. Will be 
strongly considered.

((While the set of Calligra libs are not yet stable and thus not promoted for 
use by 3rd-party, that is to change in the near future step-by-step, with kdb, 
kproperty and kreport even in separate repos and spearheading that move.
So our problem also needs to cover the headers that are installed.))

Cheers
Friedrich

Re: Best-practise currently for testing internal parts of libs? *_TEST_EXPORT macro?

[Friedrich W. H. Kossebau]

Am Montag, 31. August 2015, 09:26:52 schrieb Thiago Macieira:
> On Monday 31 August 2015 14:41:00 Friedrich W. H. Kossebau wrote:
> > #ifdef COMPILING_TESTS
> > #if defined _WIN32 || defined _WIN64
> 
> Remove the Windows check. The next lines are valid outside of Windows too
> and should be used on all platforms.
> 
> If and when I change Q_DECL_EXPORT to be protected visibility instead of
> default, this will be required.
> 
> > # if defined(calligrasheetsodf_EXPORTS)
> > #   define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_EXPORT
> > #   else
> > #   define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_IMPORT
> > #   endif

Thanks for the hint, picking up.

Cheers
Friedrich

Re: Best-practise currently for testing internal parts of libs? *_TEST_EXPORT macro?

[Friedrich W. H. Kossebau]

Hi Kevin, Jeremy & David,

thanks all for your replies so far, gives me/us a palette to chose from, nice 
:)

Seems exporting symbols only for testing is not a great no-go with known big 
traps, okay. So no need to port away from that tomorrow.

So... below:

Am Montag, 31. August 2015, 18:54:19 schrieb Kevin Funk:
> On Monday 31 August 2015 09:29:52 Jeremy Whiting wrote:
> > The way the knewstuff tests work is by linking the source files being
> > tested directly. For example the Entry test also links entry.cpp and
> > entry.h directly. This way it doesn't need to have Entry private
> > methods exported at all. This may or may not be the best way to do it
> > though, but has worked ok there and was the suggestion when I had the
> > same question when reenabling KNewStuff unit tests a year or so ago.
> 
> Unfortunately that requires you to compile entry.cpp (at least) twice. Once
> for the shared lib, once for each unit test using it.
> 
> Another approach is to do something CMake tried to advocate with its OBJECT
> libraries. It has its flaws (not going further in details), and there's a
> similar approach using static libraries.
> 
> Taking your example further:
> - Compile entry.cpp and all other files part of your lib into MyStaticLib
> - Make test_entry.cpp link against MyStaticLib (no exports needed)
> - Make the MyLib shared object link against MyStaticLib
> 
> The good:
> - entry.cpp (and all others) only need to be compiled once
> 
> The bad (compared against a shared-object-only solution):
> - each unit tests needs to be relinked in case MyStaticLib changes
> 
> We're using this approach in KDevelop plugins, successfully. Also to avoid
> any intermediate libs. We want the plugin to be self-contained, to reduce
> loading times and generally to reduce the number of installed libs.
> 
> PS: This approach is not really recommendable for large-scale projects like
> Calligra, I guess. Having to relink every unit test if you change some
> central implementation file is a no-go. Having a separate export macro like
> Friedrich suggested initially is the better thought.

The dynamic lib with separate export macro for tests and the static 
intermediate lib both would require relinking of all tests on changes of the 
lib, no? But linking with dynamic lib should be faster, that's what you had in 
mind, right?

Then, a dynamic lib could be composed from multiple static libs, if the final 
lib can be separated in different conceptual parts. And their separate 
building would allow more fine-grained control of visibility, in terms of what 
the sources see as possible includes. And then only those tests whose static 
lib changed need relinking.

So as you said, something to consider on case-by-case base. Good to know about 
those options you gave. Should turn that into some tutorial on techbase, 
possibly will once I am done with porting the export headers initially.

For now I am looking for a (quick) solution ideally with the existing 
design using additional symbol-exporting in test-enabled builds.
Guess I will be going for the Konqueror approach as intermediate solution. 
Though I am tempted to turn the grantlee solution in a wrapper macro around 
generate_export_header (and perhaps then ponder about a patch for upstream to 
allow additional export macros with generate_export_header). Let's see.

Cheers
Friedrich

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Friedrich W. H. Kossebau]

Hi Alexander & all,

thanks for pushing this further.

Am Samstag, 26. September 2015, 18:41:01 schrieb Alexander Potashev:
> Hi everyone,
> 
> We had a little discussion on how to name shared libraries in
> kde-core-devel@ thread "Porting to frameworks 2: libkcompactdisc" [1],
> but we did not come to consensus.
> 
> The question is, if you release a shared library with deps on Qt5
> and/or KF5, but the lib is not part of KF5, how should the .so file be
> named?
> 
> 1. Many people prefer a "KF5" prefix, e.g. libKF5Screen.so).
> 2. Another way of naming is a -qt5 suffix, e.g. libmarblewidget-qt5.so.
> 3. (probably some others?)
> 
> Friedrikh said in [1] that using a KF5 prefix for all libraries will
> "blur the hint by the name if something is part of KF5 or not".

Yes, I still think so:
libQt* is left to Qt libs, and IMHO in the same way should libKF5* be only 
used with real KF5 libs, if that prefix should have a consistent semantic, 
i.e. should say they are part of the KDE Frameworks.

Another reason, though rather less likely:
Even more because someone might start a new lib KF5Foo which they think to be 
become the killer lib for Foo purpose and one day to end up in the KDE 
Frameworks, but then somebody else writes an even better one and that one than 
becomes official KF5 lib for Foo. Would suck if someone occupied the name 
KF5Foo already with an existing lib (as in: released and used by 1-2 apps 
which are fine with the original lib and do not see a need to switch to the 
KF5 one). Better safe than sorry.

WRT to your question on IRC, Alexander:
"
[Samstag, 26. September 2015] [17:32:04 CEST]  frinring_: you are 
saying "it will result in clashes", but that should not be a problem: 
packagers can just forbid parallel installation of the standalone version and 
the new version which is part of KF5
"
which refers to the thread "Porting to frameworks 2: libkcompactdisc" where I 
wrote on 2015-09-04 11:59:57 GMT:
> [...] For once, because it will result in clashes if a lib really
> becomes part of KF5 (and thus becomes part of other packages which might be
> installed together with a package where the lib was initially in, unless the
> lib is the only content of the package, so that can be completely replaced
> by the KF5 package)

Forbidding parallel installation only works if the lib becomes a framework 
without any changes.
Given the high standards and required ABI stability there is a good chance 
that some API brush up (e.g. due to review feedback while proposed as KF5 lib) 
is made before turning into a KF5 lib, as was already pointed out by Sune. 
Having the same name would prevent that (for the usual problems with ABI 
changes).

((I find the "-qt5" postfix sligthly ugly as well, and personally rather use 
postfix integer counters to allow co-installability, but then my libs change 
ABI more often, so just qt version does not work ;) Now, looking at "ls 
/usr/lib64" things get relative, and with cmake config files the lib target 
names used are usually more nice anyway, so "-qt5" should not be such a 
bummer, and besides that this postfix seems to have become a pattern with some 
libs already, so using them would add to consistency.))

My 2 cents.

Cheers
Friedrich

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Friedrich W. H. Kossebau]

Hi Boudhayan,

Am Sonntag, 27. September 2015, 04:01:26 schrieb Boudhayan Gupta:
> We could kill two birds with one stone here, creating a new KDE module
> just for libraries (say, KDE Companion Libraries or something) and put
> everything in the KC5 (or whatever we decide) namespace.
> 
> I'm all for just putting everything in KDE Support, using the KS5
> namespace and removing the tier0 restriction from Support.

Some bummer here:
a) not all libraries are in repositories of their own
b) not all libraries are released on the same cycle

E.g. a) happens because the libs could be shared libs for sharing between 
multiple executables/plugins developed in a single repo. Or they are only 
slowly established as shared code and still developed strongly coupled with 
their main user executable/plugin and for that live in the same repo.
And b) is because there are a few libs in extragear or playground repos, so 
not covered by the "KDE Applications" release cycle or forced to follow.

So while I agree that having all libs nicely separated would be good to have, 
if only for discoverability, doing that with a single module at least 
currently would not work.

((Long-term we should perhaps look into that, because right now the layout of 
our repository structure does not make a difference between repos with 
executables, plugins and libraries (and mixed ones).
And IMHO if we have libs, thus code intended to be shared between other 
software, it would be great if it would be easy to developers to simply browse 
all of the libs to find something perhaps matching. If that list would be a 
virtual one, fine as well, but having the real repositories ordering also 
follow that grouping helps shaping minds and reduces complexicity needed due 
to the mapping.
(Would also make it simpler to know which libs there are that should be also 
noted at inqlude.org)

But different topic, with quite some details and strings attached, worth at 
least a different thread (and someone who can and would drive any planning for 
that for some time, not me).))

Cheers
Friedrich

Re: Cervisia?

[Friedrich W. H. Kossebau]

Am Sonntag, 5. Juni 2016, 14:22:45 CEST schrieb Nicolás Alvarez:
> > El 5 jun 2016, a las 09:08, Martin Koller  escribió:
> >> On Sunday 05 June 2016 09:14:42 Burkhard Lück wrote:
> >> 
> >> Some i18n issues:
> >> 
> >> It is a QApplication so you have to add the translators tab manually with
> >> aboutData.setTranslator
> > 
> > ok. what shall I write there (names, emails ?)
> > 
> > Isn't that a limited approach to name the translators in the sourcecode,
> > since every new translation added will need a source change ?
> 
> No; you use something like i18n("TRANSLATOR NAME") (I don't remember the
> exact string), so that the name comes from the translation itself.

It would be
setTranslator(i18nc("NAME OF TRANSLATORS", "Your names"),
  i18nc("EMAIL OF TRANSLATORS", "Your emails"));

And it needs to be these very strings, as they are here, both comment and 
content, because for those by definition there will be in the catalog 
translation strings which then contain the names of the people who did the 
translations for the given language. Which means, the i18nc call will then 
return the names (and emails) of the translators for the current language, as 
stored in the currently used translation catalog. (So not the names of all the 
translators who translated to any languages, just for the current).
And there will be always such strings with their translation in the 
translation catalog, they do not need to be present in the actual code which 
makes uses of them, and thus do not need to be present in the catalog template 
(pot file).

And as Albert already said in his email, it might not need to be done when 
using KMainWindow (or derived classes like KXmlGuiWindow), as by tradition the 
KMainWindow constructor ensures those strings are set on the global 
KAboutData::applicationData object.

See
https://api.kde.org/frameworks/kcoreaddons/html/
classKAboutData.html#a9a0a3e87cede16d6bb2e96d5bc5e5d4b
for all the details in the API documentation of KAboutData.

Cheers
Friedrich

Re: web server for appstream metadata screenshots

[Friedrich W. H. Kossebau]

Am Mittwoch, 8. Juni 2016, 13:10:04 CEST schrieb Sebastian Kügler:
> Hey,
> 
> I've been adding appstream metadata to one of the apps I maintain, among
> that are also screenshots, in the form of a URL. That means that I have to
> put the screenshots on a webserver.
> 
> Do we already have a canonical location for these screenshots? If not, let's
> create one before we get people hosting them on imgur, their private
> webserver or their router-behind-a-dsl-line. :)

Good idea, also when it comes to long-term availability of referenced images 
:)

It might make sense to reuse/share the screenshots with the ones used for the 
KDE app catalog we have at kde.org/applications/. For consistency and for 
efficiency.

Not sure though what a stable url would be like, given people planning to 
rework kde.org (and thus those app catalog pages), so perhaps relying on the 
current screenshot urls used by kde.org/applications is not perfect.

In any case, we need to keep versioning in mind, so that appdata for some 
older version of an app not suddenly gets a screenshot of the latest version 
highlighting features not present in the version the appdata is talking about.

Perhaps there would be some url scheme we can agree on, which then would be 
also used by whatever new KDE app catalog pages there will be on whatever new 
KDE website.

Cheers
Friedrich

State of Proposal to improving KDE Software Repository Organization?

[Friedrich W. H. Kossebau]

Hi,

(calligra-devel, kexi-devel, kimageshop mailinglists only for heads-up,
 please remove from reply, discussion only on kde-core-devel should be fine)

4 months ago there was the thread "Proposal to improving KDE Software 
Repository Organization" on this mailinglist.
What happened to that plan? Are people preparing its execution?

And would that be a time where some bigger reorganization of the repos is 
possible?

Reason that I ask is that due to the split of Calligra into several repos (see 
background^) the layout in the repo structure does no longer properly reflect 
the project organisation. Right now there are three active repos in the 
calligra/ repo substructure:
"calligra" at "calligra/"
"krita"at "calligra/krita"
"kexi" at "calligra/kexi"

(("calligra" at "calligra/" confuses at least kdesrc-build, sent an email to 
mpyne about if moving it to "calligra/calligra" should fix it.))

Things that are not properly matching organization:
* Krita starting with 3.* no longer is part of Calligra project
  (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
  what people think to which project Krita belongs)
* Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
  so no reason to be in a complete own toplevel structure,
  rather should be in the same sub structure, i.e. "Extragear",
  like extragear/calligra/* and extragear/graphics/krita

More, not only Calligra & Krita related:
* "Extragear" is an awful grouping name for apps with individual
  release plans, a legacy term that no longer fits most of the apps
  in that substructure
* "KDE Applications" is a misleading grouping name for apps with a
  central release plan, as if those with individual release plans
  are not "KDE" applications (as in, not done in the KDE community)
* a single category per app as needed by the current tree structure layout
  of the repos, like "office", "graphics", "utils", is rather awkward,
  many apps do not match exactly one or would match multiple categories

So IMHO some update of the repository organisation would be good, to reflect 
how things are these days.
Renaming of "Extragear" and "KDE Applications" is surely something which needs 
care from promo/marketing/VDG people first to find if that makes sense at all 
and what a good solution would be.
(Being both maintainer of Okteta, which is in "KDE Applications", and meta-co-
maintainer of Calligra, which is not, but still done in the very same KDE 
community, that current naming seems so wrong to me).

But the actual names and grouping aside, for the pure technical renewing 
(which also involves all infrastructure like translation system, 
documentation, phabricator, etc), who is currently planning or working on 
what?
So does it makes sense to wait some more, or should we assume the current 
organization stays for longer, and Calligra & Krita repos should be moved 
inside that organization for now?


^Some background about Calligra repo split, as things are slightly 
complicated:

KRITA)  The "krita" repo was split off, because Krita has finally become a 
full project of its own, separate from Calligra. A logical place for the krita 
repo in the KDE repo structure would perhaps have been somewhere in extragear, 
but at least due to the translators preferring to keep the string catalogs of 
Krita in the "calligra" module as before, for less work, the krita repo was 
for now put as submodule of "calligra/".

KEXI)  Kexi continues to be part of the Calligra project/subcommunity, but the 
Kexi developers preferred a small simple repo "kexi" of their own (for build 
time and size). So the placement at "calligra/kexi" makes perfect sense.

OTHERAPPS)  As the other Calligra apps (Braindump, Karbon, Sheets, Words, 
Stage, etc.) are more tightly coupled and the binary interfaces between libs, 
plugins & apps can still change every other week, for now no further repo 
splitting is planned (to ensure atomic commits on API changes), and they all 
stay in the existing "calligra" repo.


Cheers
Friedrich

Re: State of Proposal to improving KDE Software Repository Organization?

[Friedrich W. H. Kossebau]

Am Dienstag, 19. Januar 2016, 13:57:10 schrieb Ben Cooksley:
> On Tue, Jan 19, 2016 at 7:28 AM, Friedrich W. H. Kossebau
> 
> <kosse...@kde.org> wrote:
> > 4 months ago there was the thread "Proposal to improving KDE Software
> > Repository Organization" on this mailinglist.
> > What happened to that plan? Are people preparing its execution?
> 
> That plan is tied up in other things taking priority / lack of time / etc.
> We'll get there eventually. It is also in part related to the Phabricator
> move.

Okay, so still work in progress. Good.

> > And would that be a time where some bigger reorganization of the repos is
> > possible?
> > 
> > Reason that I ask is that due to the split of Calligra into several repos
> > (see background^) the layout in the repo structure does no longer
> > properly reflect the project organisation. Right now there are three
> > active repos in the calligra/ repo substructure:
> > "calligra" at "calligra/"
> > "krita"at "calligra/krita"
> > "kexi" at "calligra/kexi"
> > 
> > (("calligra" at "calligra/" confuses at least kdesrc-build, sent an email
> > to mpyne about if moving it to "calligra/calligra" should fix it.))
> 
> Repositories within repositories is a known bad thing to do, the
> systems don't handle it properly at all (as it was never an intended
> thing you should do). The proper fix is to move the repo to
> calligra/calligra (ie. have a "calligra/" top level grouping project).

This move is now requested on https://phabricator.kde.org/T1337 , the 
respective kde-build-metadata change locally prepared.

> > Things that are not properly matching organization:
> > * Krita starting with 3.* no longer is part of Calligra project
> > 
> >   (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
> >   what people think to which project Krita belongs)
> > 
> > * Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
> > 
> >   so no reason to be in a complete own toplevel structure,
> >   rather should be in the same sub structure, i.e. "Extragear",
> >   like extragear/calligra/* and extragear/graphics/krita
> 
> In the Phabricator world I had envisioned Extragear as no longer existing.

Okay, sounds good.

> > More, not only Calligra & Krita related:
> > * "Extragear" is an awful grouping name for apps with individual
> > 
> >   release plans, a legacy term that no longer fits most of the apps
> >   in that substructure
> > 
> > * "KDE Applications" is a misleading grouping name for apps with a
> > 
> >   central release plan, as if those with individual release plans
> >   are not "KDE" applications (as in, not done in the KDE community)
> > 
> > * a single category per app as needed by the current tree structure layout
> > 
> >   of the repos, like "office", "graphics", "utils", is rather awkward,
> >   many apps do not match exactly one or would match multiple categories
> 
> Phabricator will allow multiple "categories" to be tagged to a repository...

Nice, sounds even better.

> > So IMHO some update of the repository organisation would be good, to
> > reflect how things are these days.
> > Renaming of "Extragear" and "KDE Applications" is surely something which
> > needs care from promo/marketing/VDG people first to find if that makes
> > sense at all and what a good solution would be.
> 
> Extragear is really an internal structure, not part of marketing so I
> think we can go ahead and just kill it...

Seems we all pull on the same string then, glad to see that :)

> > (Being both maintainer of Okteta, which is in "KDE Applications", and
> > meta-co- maintainer of Calligra, which is not, but still done in the very
> > same KDE community, that current naming seems so wrong to me).
> > 
> > But the actual names and grouping aside, for the pure technical renewing
> > (which also involves all infrastructure like translation system,
> > documentation, phabricator, etc), who is currently planning or working on
> > what?
> 
> Like most things in this department, Sysadmin...

So in good hands, I leave it there :P Nah, ready to also do some share of work 
on this, as I would like this itch scratched as well. Please call me where you 
see fit.

> > So does it makes sense to wait some more, or should we assume the current
> > organization stays for longer, and Calligra & Krita repos should be moved
> &

Re: State of Proposal to improving KDE Software Repository Organization?

[Friedrich W. H. Kossebau]

Am Dienstag, 19. Januar 2016, 08:07:11 schrieb Elvis Angelaccio:
> 2016-01-19 2:05 GMT+01:00 Nicolás Alvarez <nicolas.alva...@gmail.com>:
> > 2016-01-18 21:57 GMT-03:00 Ben Cooksley <bcooks...@kde.org>:
> > > On Tue, Jan 19, 2016 at 7:28 AM, Friedrich W. H. Kossebau
> > > 
> > > <kosse...@kde.org> wrote:
> > >> So IMHO some update of the repository organisation would be good, to
> > 
> > reflect
> > 
> > >> how things are these days.
> > >> Renaming of "Extragear" and "KDE Applications" is surely something
> > 
> > which needs
> > 
> > >> care from promo/marketing/VDG people first to find if that makes sense
> > 
> > at all
> > 
> > >> and what a good solution would be.
> > > 
> > > Extragear is really an internal structure, not part of marketing so I
> > > think we can go ahead and just kill it...
> > 
> > Then the first thing to kill is https://extragear.kde.org/ (careful
> > with potential incoming broken links though).
> 
> This should probably have happened some time ago, but for some reason it
> still hasn't.
> See also this thread started by Helio:
> https://mail.kde.org/pipermail/kde-extra-gear/2015-August/002075.html

Picked that thread up, time to make that a "Done".

Cheers
Friedrich

Re: KDE CI enforcing ECMEnableSanitizers.cmake/KDECompilerSettings.cmake?

[Friedrich W. H. Kossebau]

Am Dienstag, 26. April 2016, 23:21:40 CEST schrieb Albert Astals Cid:
> El dimarts, 26 d’abril de 2016, a les 18:50:55 CEST, Friedrich W. H.
> Kossebau
> va escriure:
> > Am Montag, 25. April 2016, 23:26:45 CEST schrieb Albert Astals Cid:
> > > El dilluns, 25 d’abril de 2016, a les 10:59:13 CEST, Friedrich W. H.
> > > Kossebau
> > > 
> > > va escriure:

> > > > So do any projects which are build on KDE CI need to have
> > > > ECMEnableSanitizers.cmake included?
> > > > 
> > > > Would it make sense to have ASan as an option to be turned off?
> > > 
> > > It's compile time, it's off for your project, but you're linking against
> > > KF5 libraries that have ASAN compiled in.
> > > 
> > > > And is that possible, or is ASan usage viral (if deps built on CI have
> > > > it,
> > > > it needs to be used)?
> > > 
> > > Yes ASan usage is viral-ish, if you're using a library that was compiled
> > > with ASAN you either need to compile your binary with asan too or pass
> > > the
> > > LD_PRELOAD as the error says, that may be tricky since it needs a full
> > > path.
> > 
> > Given we have stable setting on CI, the path might be known perhaps.
> > 
> > What needs to be done with LD_PRELOAD here exactly? Perhaps that could be
> > done optionally based on a flag in the build setup in the future.
> 
> You set it to the asan library before running your binary.

Okay, that sounds doable. "Just" needs someone to add support for that :)
Filed a feature request on phabricator for that, anyone interested to earn 
some laurels on that?
https://phabricator.kde.org/T2366

> > Requiring ECMEnableSanitizers.cmake (or equivalent for non-cmake-based
> > buildsystem) for any projects on KDE CI to have tests being run properly
> > (if using other KDE CI products) feels like a small obstacle.
> > If possible without too much pain, it might be nice to avoid that.
> 
> It's hard to avoid unless you compile all libraries twice both with and
> without ASAN.

Double builds ideally can be avoided. And after all ASAN is very much useful 
on CI, that's why you(?) pushed it there, for some good catches already 
(myself could also harvest some bugs from it already) :)

> It is not a requirement for "any projects on KDE CI".
> 
> As pointed you can just LD_PRELOAD the ASAN library if you have troubles.
> Also that is only needed if you use other projects that are linked against
> ASAN.

As I understood it so far, almost anything built on KDE CI is built with ASAN, 
incl. 3rd-party dependencies like Qt5, no? As said above, it only makes sense 
to me to do it. But we need to also have support for the non-ECM-using 
projects, that's what I am here for and try to understand how things are done, 
to see what could be done.

> That is, you're trying not to use ECM (or ECMEnableSanitizers.cmake) but you
> depend on KF5 stuff that depends on ECM/ECMEnableSanitizers.cmake, maybe
> you're trying to be too fine in not needing ECM.

While I personally would also see to use ECM & CMake where possible, we still 
need to consider at least:

a) KF5 products do not require CMake as the buildsystem for any of its 
consumers. There is extra dance for supporting qmake/pkg-config buildsystems 
at least. So other potential KDE projects which use KF5 but not CMake cannot 
use ECM. Ideally there would be similar helpers like ECMEnableSanitizers.cmake 
one day for them, sure, but those still would be extra dependencies, and any 
extra dependency increases burdens, so would be nice to have it special 
settings for KDE CI optional if possible without a big deal.

b) Qt5 on CI is also build with ASAN (AFAIK, that is why the all Marble tests, 
which are Qt5-only, are failing, unless I missed something). So Qt5-only 
projects (as in: ECM/KF5-less) still would need to have separate support by/
for the KDE CI.

Cheers
Friedrich

Re: KDE CI enforcing ECMEnableSanitizers.cmake/KDECompilerSettings.cmake?

[Friedrich W. H. Kossebau]

Am Mittwoch, 27. April 2016, 01:29:06 CEST schrieb Jan Kundrát:
> On Wednesday, 27 April 2016 01:21:22 CEST, Albert Astals Cid wrote:
> > No, Qt5 is not built with ASAN on CI.

Okay, good to know.
(next to the failing tests I also remembered to have seen ASAN_OPTIONS 
detect_leaks=0 as env setting with the qt5 builds on CI. So that is just 
default env setup and those vars ignored otherwise, okay).

Next to documenting things, can we start with some rule what gets or should be 
built with ASAN, so people know what to expect?
I would assume: any KDE software based on C++/C. And then there might be a few 
exceptions, for whatever reasons (built screwed, incompatible, etc).

> > It is strange that your Qt5-only tests are failing, may it be that they
> > are
> > loading some plugin that is linked against some KF5 lib?

For Marble plugins only if something is not like it should be:
for one, the current build on CI even gets "-DQTONLY=TRUE" passed, which is 
turned into the cmake var "set(WITH_KF5 FALSE)", and all KF5 deps are looked 
for with "macro_optional_find_package(KF5 QUIET COMPONENTS something)", so 
should always yield NOT_FOUND (looking at it I found a bug which still made 
KF5DocTools to be found, but now fixed and should not have any effect on 
linking to KF5 libs).
More, the only things being explicitely linked to KF5 libs are KF5 thumbnailer 
plugin, KRunner plugin, and the KF5-enhanced Marble app variant. So nothing 
which should be used in the tests.

Ah, Phonon! That is linked by at least the RoutingPlugin. And Phonon gets 
instrumented with ASAN:
https://build.kde.org/job/phonon%20master%20kf5-qt5/
PLATFORM=Linux,compiler=gcc/5/console

That might explain what we see currently.

> Qt guesses what platform one is running on in order to blend with it. In
> KDE and under the Plasma desktop, this involves loading
> plugins/platformthemes/KDEPlatformTheme.so which belongs to KF5's
> frameworkintegration.
> 
> Is the KDE CI setting some variables which might trigger loading of these
> plugins [edited]?

Good idea, that might be indeed other intrusion path for ASAN deps.
@Scarlett, can you tell?

Cheers
Friedrich

Moving CI server documentation to community.ko? (was: Re: KDE CI enforcing ECMEnableSanitizers.cmake/KDECompilerSettings.cmake?)

[Friedrich W. H. Kossebau]

Am Montag, 25. April 2016, 23:26:45 CEST schrieb Albert Astals Cid:
> El dilluns, 25 d’abril de 2016, a les 10:59:13 CEST, Friedrich W. H.
> Kossebau
> va escriure:
> > Hi,
> > 
> > can anyone shed full light on KDE CI and the usage of ASan?
> > 
> > Currently e.g. all tests of Marble are failing, with the message
> > "ASan runtime does not come first in initial library list; you should
> > either link runtime to your application or manually preload it with
> > LD_PRELOAD."
> > 
> > https://build.kde.org/job/marble%20master%20kf5-qt5/
> > PLATFORM=Linux,compiler=gcc/26/testReport/
> > 
> > As Marble tries to be optionally Qt-only by tradition, also the current
> > Qt5(/ KF5)-based version has lots of custom CMake logic, for full
> > independence, and only falls back to using ECM macros/settings when it
> > comes to Plasma & other KDE system integration code.
> > 
> > Which currently also means all tests are not influenced anywhere by ECM
> > macros. Incl. KDECompilerSettings.cmake (and thus
> > ECMEnableSanitizers.cmake). So the code from ECMEnableSanitizers.cmake
> > which handles the
> > "ECM_ENABLE_SANITIZERS" cmake argument is never run.
> > 
> > Where currently -DECM_ENABLE_SANITIZERS='address' seems to be passed in
> > the
> > kf5-qt5 configuration:
> > https://quickgit.kde.org/?p=sysadmin%2Fci-builder-tools.git=blob=build
> > %2Fkf5-qt5.cfg
> > 
> > Is this the reason that all the Marble tests fail on KDE CI, with the
> > given
> > error?
> > 
> > So do any projects which are build on KDE CI need to have
> > ECMEnableSanitizers.cmake included?
> > 
> > Would it make sense to have ASan as an option to be turned off?
> 
> It's compile time, it's off for your project, but you're linking against KF5
> libraries that have ASAN compiled in.
> 
> > And is that possible, or is ASan usage viral (if deps built on CI have it,
> > it needs to be used)?
> 
> Yes ASan usage is viral-ish, if you're using a library that was compiled
> with ASAN you either need to compile your binary with asan too or pass the
> LD_PRELOAD as the error says, that may be tricky since it needs a full
> path.
> > While using ASan seems to be useful for improved test coverage, this
> > requirement still would need to be explained and documented somewhere,
> > please.
> 
> Where would you document it?

Right now AFAIK the only documentation about CI is at https://
sysadmin.kde.org/services/continuous-integration/

Though perhaps it makes sense to move that over to somewhere below https://
community.kde.org/Infrastructure, both to improve finding it and
to lower the burden for non-sysadmin people to maintain the pages (possibly 
still need higher edit restrictions to minimize wrong information there).

Sysadmin & else, what do you think?

Cheers
Friedrich

Re: KDE CI enforcing ECMEnableSanitizers.cmake/KDECompilerSettings.cmake?

[Friedrich W. H. Kossebau]

Am Montag, 25. April 2016, 23:26:45 CEST schrieb Albert Astals Cid:
> El dilluns, 25 d’abril de 2016, a les 10:59:13 CEST, Friedrich W. H.
> Kossebau
> va escriure:
> > Hi,
> > 
> > can anyone shed full light on KDE CI and the usage of ASan?
> > 
> > Currently e.g. all tests of Marble are failing, with the message
> > "ASan runtime does not come first in initial library list; you should
> > either link runtime to your application or manually preload it with
> > LD_PRELOAD."
> > 
> > https://build.kde.org/job/marble%20master%20kf5-qt5/
> > PLATFORM=Linux,compiler=gcc/26/testReport/
> > 
> > As Marble tries to be optionally Qt-only by tradition, also the current
> > Qt5(/ KF5)-based version has lots of custom CMake logic, for full
> > independence, and only falls back to using ECM macros/settings when it
> > comes to Plasma & other KDE system integration code.
> > 
> > Which currently also means all tests are not influenced anywhere by ECM
> > macros. Incl. KDECompilerSettings.cmake (and thus
> > ECMEnableSanitizers.cmake). So the code from ECMEnableSanitizers.cmake
> > which handles the
> > "ECM_ENABLE_SANITIZERS" cmake argument is never run.
> > 
> > Where currently -DECM_ENABLE_SANITIZERS='address' seems to be passed in
> > the
> > kf5-qt5 configuration:
> > https://quickgit.kde.org/?p=sysadmin%2Fci-builder-tools.git=blob=build
> > %2Fkf5-qt5.cfg
> > 
> > Is this the reason that all the Marble tests fail on KDE CI, with the
> > given
> > error?
> > 
> > So do any projects which are build on KDE CI need to have
> > ECMEnableSanitizers.cmake included?
> > 
> > Would it make sense to have ASan as an option to be turned off?
> 
> It's compile time, it's off for your project, but you're linking against KF5
> libraries that have ASAN compiled in.
> 
> > And is that possible, or is ASan usage viral (if deps built on CI have it,
> > it needs to be used)?
> 
> Yes ASan usage is viral-ish, if you're using a library that was compiled
> with ASAN you either need to compile your binary with asan too or pass the
> LD_PRELOAD as the error says, that may be tricky since it needs a full
> path.

Given we have stable setting on CI, the path might be known perhaps.

What needs to be done with LD_PRELOAD here exactly? Perhaps that could be done 
optionally based on a flag in the build setup in the future.

Requiring ECMEnableSanitizers.cmake (or equivalent for non-cmake-based 
buildsystem) for any projects on KDE CI to have tests being run properly (if 
using other KDE CI products) feels like a small obstacle.
If possible without too much pain, it might be nice to avoid that.

(For Marble nevertheless I have a patch up for review to optionally use 
ECMEnableSanitizers.cmake)

Cheers
Friedrich

Re: Usage of QNetworkAccessManager

[Friedrich W. H. Kossebau]

Am Donnerstag, 14. Juli 2016, 12:50:11 CEST schrieb David Faure:
> On jeudi 14 juillet 2016 18:33:37 CEST Ben Cooksley wrote:
> > Please therefore ensure your application handles redirects
> > appropriately (the form of the code will depend on the version of Qt
> > in use) if you decide to use QNAM.
> 
> As an example,
> https://lxr.kde.org/source/playground/sdk/inqlude-client/downloadhandler.cpp
> has working Qt 5 code for this.

Could someone of you with clue about it add some tutorial/guidelines somewhere 
below https://community.kde.org/Guidelines_and_HOWTOs, please?

Cheers
Friedrich

kapidox: supporting also QML (and cmake, Python,, ...)

[Friedrich W. H. Kossebau]

Hi, Olivier and all,

picking up from the short chat on #plasma today:

so given kapidox is overcoming the old API dox generating scripts with more 
proper semantic info...
where the old scripts allowed to use random Mainpage.dox at random places in 
the directories to structure the created documentation (e.g. to group QML 
"classes" away from C++ classes), kapidox now would need extension of its 
spec, with semantics needed to talk about QML types and C++ classes to allow 
proper generation of nicely separated pages.

This actually touches a broader problem with the current generated 
documentation, which right now is centric to the C++ interfaces. Though 
existing KDE library products have at least interfaces in
* C++
* QML
* CMake macros [1]
and perhaps one day bindings in Python and other languages would be also 
provided directly with the products and thus it would be great to have their 
documentation covered as well easily.

[1] E.g. KCoreAddon installs a few cmake macros, like 
kcoreaddons_desktop_to_json, which have nice API dox inside, but there is 
nothing generated from that on api.kde.org currently, both bad for 
discoverability or pointing people to things with urls.


For a solution:
Perhaps at the generation side there could be another level right below the 
library, for the interface (C++, QML, CMake, ...).
So "Product" > "Library" > "Interface", 

By the example of Plasma Components 
(https://api.kde.org/frameworks/plasma-framework) there would then be in the 
header
KDE API Reference > The KDE Frameworks > Plasma > QML
KDE API Reference > The KDE Frameworks > Plasma > C++
and in the left sidebar there would be another section "Language" (or better 
term) which would allow to switch to the docs for the other interfaces 
supported (C++, QML, CMake, ...).

On the metainfo.yaml spec side, no idea yet.

Cheers
Friedrich

Re: CI Requirements - Lessons Not Learnt?

[Friedrich W. H. Kossebau]

Hi Eike,

first of all, thanks for turning this into a policy creation process :)

Am Donnerstag, 19. Januar 2017, 02:29:00 CET schrieb Eike Hein:
> On 01/17/2017 11:46 PM, Adriaan de Groot wrote:
> > But CI has a really important function: it shows us the health of the
> > sources for everything; and that's something the release team needs, and
> > the whole community can be interested in. So "opting out" of CI deprives
> > us of a good view of the state of our software products.
> 
> Agreed. But under the proposed document, you can essentially only
> opt out by behaving so badly that sysadmin sees no choice but to
> kick you out, and it labels that as "rude". I think it also
> communicates why we care about CI (e.g. as regression catcher).
> 
> This thread has slowed down now - there's been no strong objections
> raised to the current version of the doc. If everyone is happy with
> it, I propose we start linking it from the /Policies/ main page by
> start of February and try to live with it.

Given this is a policy affecting all of the KDE projects, please first propose 
it officially in a separate own thread, with a proper subject. Perhaps even on 
kde-community, as kde-core-devel might not be read by many, given it used to 
be focussed on kdelibs/core apps. Even people reading kde-core-devel might 
have missed it, as this thread here started to become heated and long, so most 
free time contributors might not have invested time into reading more than the 
first.

Some feedback on the policy itself:
"Dependency changes for software covered by the CI system should be submitted 
through code review"
-> I would propose to additionally recommend contacting sysadmin as soon as 
one knows that a new dependency is coming up, not only first at the time the 
official review request is made. That should give sysadmin some more time in 
advance to handle the needed new dependency in CI, and perhaps also give 
feedback on issues. 
Ideally it might even result in the new dependency already being available at 
the time of the review request, so if the review itself is done quickly, CI 
does not block the merge.

IIRC this would also reflect what has been done now and then :)

Cheers
Friedrich

Re: announcement: Kwave is in kdereview

[Friedrich W. H. Kossebau]

Am Sonntag, 9. Oktober 2016, 17:44:02 CEST schrieb Albert Astals Cid:
> El diumenge, 9 d’octubre de 2016, a les 11:44:16 CEST, David
> 
> Faure va escriure:
> > AFAIK KLocalizedString::setApplicationDomain isn't
> 
> necessary, you should
> 
> > instead define the domain as a -D flag during compilation, but
> 
> I'm no expert
> 
> > on that, check the wiki.
> 
> Don't recomend the domain flag for anything that is not a
> library, it is a bad idea, several things in applications break if
> you do that.

What breaks exactly?
(Actually I turned to use the flag also in app code to avoid 3rd-party plugins 
being able to ruin translations in the app code by wrongly calling 
KLocalizedString::setApplicationDomain, seen that too often (fixed it of 
course when seen :) )).

The only price I know of is extra QByteArray creation per each i18n* call...

In any case, everybody reading this, when switching to use 
KLocalizedString::setApplicationDomain() as intended by the ki18n developers, 
make sure that all app code is not seeing any TRANSLATION_DOMAIN definition, 
as otherwise any i18n*() call will use the flag-based variant and thus 
internally ignore to whatever applicationDomain was set.
So e.g. if having lib and app code in one build system, only set 
TRANSLATION_DOMAIN for the lib code.

Cheers
Friedrich

TRANSLATION_DOMAIN not to be used for app code (was: Re: announcement: Kwave is in kdereview)

[Friedrich W. H. Kossebau]

Am Sonntag, 9. Oktober 2016, 22:21:56 CEST schrieb Albert Astals Cid:
> El diumenge, 9 d’octubre de 2016, a les 18:05:29 CEST, Friedrich W. H. 
Kossebau va escriure:
> > Am Sonntag, 9. Oktober 2016, 17:44:02 CEST schrieb Albert Astals Cid:
> > > El diumenge, 9 d’octubre de 2016, a les 11:44:16 CEST, David
> > > 
> > > Faure va escriure:
> > > > AFAIK KLocalizedString::setApplicationDomain isn't
> > > 
> > > necessary, you should
> > > 
> > > > instead define the domain as a -D flag during compilation, but
> > > 
> > > I'm no expert
> > > 
> > > > on that, check the wiki.
> > > 
> > > Don't recomend the domain flag for anything that is not a
> > > library, it is a bad idea, several things in applications break if
> > > you do that.
> > 
> > What breaks exactly?
> 
> Anything using KLocalizedString::applicationDomain()
> 
> https://lxr.kde.org/search?_filestring=&_string=KL.*%3AapplicationDoma

The XMLGUI ones though only fallback to that if the rc file has no domain tag 
set, so there one would be safe (unless missing the tag, but that is also 
needed with libs).

But kcheckaccelerators testing and KTipDialog seems to indeed rely on that 
property, was not on my radar, thanks for the info. Guess I simply never used 
them, so did not affect me.

> > (Actually I turned to use the flag also in app code to avoid 3rd-party
> > plugins being able to ruin translations in the app code by wrongly calling
> > KLocalizedString::setApplicationDomain, seen that too often (fixed it of
> > course when seen :) )).
> > 
> > The only price I know of is extra QByteArray creation per each i18n*
> > call...
> > 
> > In any case, everybody reading this, when switching to use
> > KLocalizedString::setApplicationDomain() as intended by the ki18n
> > developers, make sure that all app code is not seeing any
> > TRANSLATION_DOMAIN definition, as otherwise any i18n*() call will use the
> > flag-based variant and thus internally ignore to whatever
> > applicationDomain
> > was set.
> > So e.g. if having lib and app code in one build system, only set
> > TRANSLATION_DOMAIN for the lib code.
> 
> Isn't that obvious?

At least from my own experience and the code from others where I saw related 
issues, all the i18n magic is sadly not always obvious.
Example for definition also existing for app code that I just found:
https://lxr.kde.org/source/kde/pim/kmail/src/CMakeLists.txt
(cc:ed pimsters for heads-up)

*cough* also https://lxr.kde.org/source/kde/kdegraphics/okular/CMakeLists.txt 
*cough*

Cheers
Friedrich

Re: Moved to KDE Review: KProperty

[Friedrich W. H. Kossebau]

Am Dienstag, 11. Oktober 2016, 00:04:12 CEST schrieb Jaroslaw Staniek:
> On 10 October 2016 at 23:58, Albert Astals Cid  wrote:
> > The i18n system is a bit borked, you're using tr and correctly using
> > ecm_create_qm_loader
> > but then the name of the catalog doesn't match
> > kpropertycore_qt vs kproperty_qt.pot
> > 
> > And then you're trying to use
> > 
> >  ki18n_install(po)
> > 
> > that is not how you install qt-only based translations (this is also
> > broken in
> > kdb and kreport).
> > 
> > The clazy report is at https://paste.kde.org/pqqy5twmb
> 
> ​Thanks,
> CCd Friedrich who once helped with porting to tr() (IIRC).
> @Friedrich would be great to get support from you :)

Done for what all that was listed here.

Cheers
Friedrich

Re: KMarkdownWebView (kpart) in KDE Review

[Friedrich W. H. Kossebau]

Am Dienstag, 22. August 2017, 22:41:28 CEST schrieb Albert Astals Cid:
> You don't have a Messages.sh

Thanks for taking a look, though... there is one, in src/:
https://cgit.kde.org/kmarkdownwebview.git/tree/src/Message.sh

Placement missing to follow some pattern?

For completeness I just pushed added extraction from rc file, though the 
current one has no strings. But a wrong domain still, and will not hurt to be 
prepared for possibly future additions there.

Cheers
Friedrich

Re: KMarkdownWebView (kpart) in KDE Review

[Friedrich W. H. Kossebau]

Am Dienstag, 22. August 2017, 23:09:18 CEST schrieb Allen Winter:
> One Krazy issue about making an explicit ctor, see
> http://ebn.kde.org/krazy/reports/kdereview/kmarkdownwebview/src/index.html

Fixed.

> I ran clazy too and it found no issues.

Happy to read. Thanks for having had a look, Allen :)

Cheers
Friedrich

Re: KMarkdownWebView (kpart) in KDE Review

[Friedrich W. H. Kossebau]

Am Dienstag, 22. August 2017, 23:38:06 CEST schrieb Friedrich W. H. Kossebau:
> Am Dienstag, 22. August 2017, 22:41:28 CEST schrieb Albert Astals Cid:
> > You don't have a Messages.sh
> 
> Thanks for taking a look, though... there is one, in src/:
> https://cgit.kde.org/kmarkdownwebview.git/tree/src/Message.sh

Seems I am blind to some trailing "s" :) My bad, fixed.

Cheers
Friedrich

KMarkdownWebView (kpart) in KDE Review

[Friedrich W. H. Kossebau]

Hi,

KMarkdownWebView today entered KDE Review. This repo contains a kpart for 
rendered display of Markdown files, using web technologies (webpage with 
JavaScript library which creates HTML from the plaintext handed in).

I consider it rather a hack and would favour something done natively in Qt 
(e.g. like the Markdown Okular generator in https://phabricator.kde.org/
D7382). But for now it serves the use-case of providing a webpage-like 
rendered display of markdown documents. Especially for the live preview 
plugin for Kate & KDevelop currently worked on*.

* https://frinring.wordpress.com/2017/08/21/look-what-you-have-donewwdo

See also https://cgit.kde.org/kmarkdownwebview.git/about/

The separate library libKMarkdownWebView is done for sharing code with a 
thumbnailer plugin, whose code yet is to be committed to this repo, as it 
resists to work right now.

Initial build on CI looks good:
https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20SUSEQt5.9/
https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20FreeBSDQt5.7/

And people on #kde-devel & #kdevelop also reported successful builds and 
usage.


Target would be extragear/$SOMETHING, with $SOMETHING possibly "utils".

Initial release planned right after leaving kdereview.

Question: is there any appstream metadata possible for plugins?

Cheers
Friedrich

Moving KMarkdownWebView to extragear/utils (was: Re: KMarkdownWebView (kpart) in KDE Review)

[Friedrich W. H. Kossebau]

Hi,

Am Dienstag, 22. August 2017, 00:18:19 CEST schrieb Friedrich W. H. Kossebau:
> KMarkdownWebView today entered KDE Review. This repo contains a kpart for
> rendered display of Markdown files, using web technologies (webpage with
> JavaScript library which creates HTML from the plaintext handed in).

Thanks Elvis, Albert, Allen for your replies, also anyone who gave feedback on 
irc (and those possibly who tested and stayed silent as no issues were hit).

So 14 days will have passed upcoming Tuesday, and seems no showstoppers are 
left for leaving kdereview to become a "normal" repo.

Besides the fixing commits for the things commented on no other bigger changes 
happened since it entered kdereview, cmp. https://cgit.kde.org/
kmarkdownwebview.git/log/ , but you might want to give it a final check.

> I consider it rather a hack and would favour something done natively in Qt
> (e.g. like the Markdown Okular generator in https://phabricator.kde.org/
> D7382). But for now it serves the use-case of providing a webpage-like
> rendered display of markdown documents. Especially for the live preview
> plugin for Kate & KDevelop currently worked on*.
> 
> * https://frinring.wordpress.com/2017/08/21/look-what-you-have-donewwdo
> 
> See also https://cgit.kde.org/kmarkdownwebview.git/about/
> 
> The separate library libKMarkdownWebView is done for sharing code with a
> thumbnailer plugin, whose code yet is to be committed to this repo, as it
> resists to work right now.
> 
> Initial build on CI looks good:
> https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20SUSEQt5.9
> /
> https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20FreeBSDQ
> t5.7/

> 
> Target would be extragear/$SOMETHING, with $SOMETHING possibly "utils".

So unless anyone objects, I will ask to have the repo in extragear, in repo 
hierarchy path extragear/utils.

Once it's moved and I pinged the translators, a week later should see first 
release then.

Cheers
Friedrich

Re: KMarkdownWebView (kpart) in KDE Review

[Friedrich W. H. Kossebau]

Hi Elvis,

(seems my reply I started last week was somehow lost, pardon for late reply)

Am Dienstag, 22. August 2017, 11:31:00 CEST schrieb Elvis Angelaccio:
> On martedì 22 agosto 2017 00:18:19 CEST, Friedrich W. H. Kossebau wrote:
> > Hi,
> > 
> > KMarkdownWebView today entered KDE Review. This repo contains a kpart for
> > rendered display of Markdown files, using web technologies (webpage with
> > JavaScript library which creates HTML from the plaintext handed in).
> > 
> > I consider it rather a hack and would favour something done natively in Qt
> > (e.g. like the Markdown Okular generator in https://phabricator.kde.org/
> > D7382). But for now it serves the use-case of providing a webpage-like
> > rendered display of markdown documents. Especially for the live preview
> > plugin for Kate & KDevelop currently worked on*.
> > 
> > * https://frinring.wordpress.com/2017/08/21/look-what-you-have-donewwdo
> > 
> > See also https://cgit.kde.org/kmarkdownwebview.git/about/
> > 
> > The separate library libKMarkdownWebView is done for sharing code with a
> > thumbnailer plugin, whose code yet is to be committed to this repo, as it
> > resists to work right now.
> > 
> > Initial build on CI looks good:
> > https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20SUSEQt5
> > .9/
> > https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20FreeBS
> > DQt5.7/
> > 
> > And people on #kde-devel & #kdevelop also reported successful builds and
> > usage.
> > 
> > 
> > Target would be extragear/$SOMETHING, with $SOMETHING possibly "utils".
> > 
> > Initial release planned right after leaving kdereview.
> > 
> > Question: is there any appstream metadata possible for plugins?
> 
> Yes, have a look at kio-gdrive or kio-stash as example.

Took that as template, thanks for pointer.

> From a quick look, everything works fine.
> 
> One minor issue I spotted: if I preview a markdown file in some archive,
> the ark preview window has a menu named "No text" instead of "Edit" (with
> the "Select All" action). This could be fixed by adding the
> Edit element in kmarkdownwebviewpartui.rc (not sure if
> there is another fix).

Perhaps the Ark preview window does not load the std xmlgui config, so those 
toplevel menu entry names are missing? I remember I have seen that also with 
other parts.
Fixed for now by the workaround you proposed, an explicit Edit.

Cheers
Friedrich

Recommended modesetting driver for Intel graphic cards (was: Re: liquidshell in kdereview)

[Friedrich W. H. Kossebau]

Am Donnerstag, 16. November 2017, 23:24:52 CET schrieb Ingo Klöcker:
> On Dienstag, 7. November 2017 20:55:57 CET Martin Flöser wrote:
> > Am 2017-11-07 20:08, schrieb Martin Koller:
> > >> Are you aware that KWin uses QtQuick for all its UI elements, such as
> > >> Alt+TAB?
> > > 
> > > I have deactivated the compositor since sadly it simply does not work
> > > on my laptop (the intel graphics driver just freezes the whole
> > > machine).
> > 
> > I did not talk about compositor, I talked about QtQuick! Yes, KWin uses
> > QtQuick for rendering it's UI, that is unrelated to compositing.
> > 
> > Now you mention that your intel graphics driver freezes the whole
> > system. I'm using Intel on all my systems and it's the most used driver
> > out there. We get many, many, many bug reports in KWin about issues.
> > Freezing systems has not been in the list for now something like two
> > years.
> > 
> > Given that I am very certain that you have a hardware issue where people
> > can help you with. Intel GPUs are good enough to run the Plasma session
> > without any negative impact.
> > 
> > So let us help you fix your issues that you can enjoy our work without
> > having to spend time on writing your own shell.
> > 
> > First thing: are you using the xorg-modesettings driver? If not: install
> > it, problems solved. Do not (I repeat) do not use the xorg-intel driver.
> > 
> > For kernel I recommend at least version 4.13 as this comes with the
> > atomic modesettings driver stack enabled by default. If you do not have
> > such a kernel version yet I highly recommend to give it a try.
> 
> Martin, thanks a lot for your advice!
> 
> I've suffered from freezes since I updated my openSUSE 13.2 to Tumbleweed
> some time ago (and much longer on my laptop where I've switched to Leap and
> later Tumbleweed much earlier).

Same here, happy to finally see someone with correlated experience. I never 
got any useful hints in the log files, so was close to consider my hardware 
broken. Strange enough all freezes seemed to happen while moving the mouse 
though, which kept the hope alive it was something software-related.

Curious to see if my daily freeze will now be a thing of the past now that I 
changed the driver. Though I am on a 2nd gen 915 device, while all the 
modesettings driver talk I came across on a quick search seemed to be only 
about gen4 and later? No issues seen for one hour so far, hope grows :)

> The switch to the modesetting driver seems
> to have fixed those issues. It took me some time to find out how to enable
> the modesetting driver. To save others the time here's how to do it: Write
> #=
> Section "Device"
>Identifier  "Intel Graphics"
>Driver  "modesetting"
> EndSection
> #=
> to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure that this
> is the only (or at least the first) "Device" section in any of the files in
> /etc/X11/xorg.conf.d/.

Another approach seems to be to uninstall xf86-video-intel, that way the 
seemingly hardcoded driver-auto-match logic will skip forward to the 
modesetting driver:

[12.125] (==) Matched intel as autoconfigured driver 0
[12.125] (==) Matched intel as autoconfigured driver 1
[12.125] (==) Matched modesetting as autoconfigured driver 2
[12.125] (==) Matched fbdev as autoconfigured driver 3
[12.125] (==) Matched vesa as autoconfigured driver 4
[12.125] (==) Assigned the driver to the xf86ConfigLayout
[12.125] (II) LoadModule: "intel"
[12.127] (WW) Warning, couldn't open module intel
[12.127] (II) UnloadModule: "intel"
[12.127] (II) Unloading intel
[12.127] (EE) Failed to load module "intel" (module does not exist, 0)
[12.127] (II) LoadModule: "modesetting"
[12.127] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so

Cheers
Friedrich

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Am Montag, 6. November 2017, 19:24:51 CET schrieb Martin Koller:
> On Montag, 6. November 2017 17:37:15 CET Friedrich W. H. Kossebau wrote:
> > > light color theme:
> > > http://members.aon.at/m.koller/liquidshell_20171103_174650.png dark 
> > > color
> > > theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png
> > 
> > Please consider using a non-KDE logo on the start menu on representative/
> > advertising screenshots (ideally some new liquidshell logo one, also to
> > help promoting it and building an identity).
> > Given the history meaning of the KDE logo as the logo of a desktop, using
> > the KDE logo will spoil the concerted effort of the rebranding done
> > (whether it was a good idea or not is too late to discuss) and only
> > continue the confusion, for no good.
> > 
> > So with the Plasma workspaces having moved to the Plasma logo, leaving the
> > KDE logo for the community, liquidshell should have and use its own
> > dedicated logo as well. (and yes, the start-here-kde icons would need
> > renaming finally)
> I'm very bad at creating appealing graphics, therefore I used exiting icons
> where possible.
> Is there some KDE artist who is willing to create a new logo for me ?

I recommend to follow https://vdesign.kde.org/how.html and poke the VDG people 
directly with your requirement.

> Regarding the rebranding: does that mean KDE (the people behind the project)
> does not like to promote KDE ?
> Very confusing in my view.
> I really meant to show "that is a KDE (based) application" by using its logo
> - was not clear that this is not welcomed.

Surely we want to promote KDE, the community :) Just, like e.g. apps like 
Okular, Dolphin, Okteta, KDevelop etc. also want to promote KDE, the 
community, they do it via the entry in the Help menu or in the About data. 
Still they have their own logo/icon for showing off e.g. "he, it's me, okular" 
and have their logo/icon displayed as identifier.

The start menu icon here serves a similar purpose usually, it shows "he, its 
me, workspace product X/operating system Y". But not saying "I am done by A", 
especially when A creates different variants of the product type. 

And with the history of "KDE" being once the name of a workspace product, 
using its logo on the start menu like in the formerly named "KDE" product 
could trigger the uninformed people to consider liquidshell being the new 
"KDE". Adding to confusion and wasted resources in fighting those 
misconception.
So better prevent from the start, so our time could be spent in bug fixing 
instead.


BTW, would you like assistance to have liquidshell covered on build.kde.org? 
Seems it is not there yet.

Cheers
Friedrich

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Am Dienstag, 7. November 2017, 20:08:59 CET schrieb Martin Koller:
> On Dienstag, 7. November 2017 16:42:40 CET Martin Flöser wrote:
> > Am 2017-11-03 21:30, schrieb Martin Koller:
> > I don't mind what you develop in your spare time. Not at all. What I
> > mind is if a product is added to KDE as a competitor/replacement to a
> > product I work on because of misunderstood things. What I see here is
> > that you completely misunderstood what hardware acceleration means and
> > gives to the system.
> 
> See above. I did not start liquidshell because I was bored. Believe me, I
> have other hobbies. I started it just because I got fed up with the
> problems I had with plasmashell and I need to use some DE for my daily
> work. Restarting plasmashell multiple times a day is just not funny.

I think what Martin F. is also asking here, and what surely one expects as 
standard in KDE, is that the description of the liquidshell product/project is 
not making false or unresearched claims or speaking badly about alternative 
solutions, especially from the same community. In short: being respectful :)

So e.g. if this was about some new liquidhexeditor, I as author of Okteta 
would be not happy about phrases like:

* "liquidhexeditor is a replacement for okteta"
"replacement" (to me) comes with meaning of successor, being better. Which is 
attributing things.
The more neutral word "alternative" might be better here.

* "It does not use QtQuick but instead relies on QtWidgets."
"not use X but relies on Y" also tells me that "X" sucks and better is 
avoided.
Where one could rather say "Uses X for everything because property 1, property 
2 and property 3", without losing a word about "Y".  Just listing the factors 
one made their choice on for using "X" leaves everyone with their idea about 
the qualities of "Y".
E.g. it could be said that QWidgets are a stable mature UI technology and 
(like already is sayed) provide a consistent UI across shell and apps (at 
least the QWidget-based apps).
No need to speak here about alternatives like QQ, Gtk, or EFL, there are 
people for any who think that to be a better base to build a UI on.

So Martik K., IMHO the current README carries still some of the frustration 
you had experienced with the Plasma shell. While this has been part of your 
motivation for your work on a new solution, it could be now time to step back 
and to turn completely into positive thinking like most of the README already 
is, for a peaceful, cooperative co-existence :) 

I propose to start the README with the product requirements you had in mind 
when working on liquidshell, perhaps by listing the features already 
implemented (and then listing some which you still consider to add).
With those, potential users might be able to see whether the requirements 
match those they are looking for themselves, and developers might be able to 
follow your decisions on why creating a separate project and on the 
technologies used for the implementation.

BTW, you are surely aware that other UI components of the Plasma workspace, 
like the System Settings, are ported to QtQuick currently. So given your 
implementation choices, do you plan to create a liquidsystemsettings variant 
as well?

Cheers
Friedrich

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Am Dienstag, 7. November 2017, 19:27:31 CET schrieb Martin Koller:
> On Dienstag, 7. November 2017 15:32:23 CET Friedrich W. H. Kossebau wrote:
> > BTW, would you like assistance to have liquidshell covered on
> > build.kde.org? Seems it is not there yet.
> 
> Wow - didn't know that this exists.
> Is this just for testing if it compiles or are packages released from there
> ? 

It is for checking building with current state of other KDE software that is 
in the same dependency tree. As well as tracking unit tests results and other 
code quality measurements.

No packages generated there, only automated testing done.

Cheers
Friedrich

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Hi Martin,

Am Freitag, 3. November 2017, 21:30:19 CET schrieb Martin Koller:
> I'd like to announce an application I've implemented over the last few weeks
> - liquidshell

Congrats to the achievement. It surely feels good to run a workspace one has 
created one themselves :)

While myself I will choose Plasma over liquidshell due to my needs and 
expectations of certain features, I can see that liquidshell would satisfy 
those persons who need or want just a simple hard-coded shell following a 
well-known UI design & concept, yet stay with the usual tools and apps from 
the KDE software world, ideally perfectly integrated with the workspace (think 
filemanager, terminal, text editor, etc). People like obviously yourself :) So 
those persons might be surely happy about you sharing your work with them.

My hopes for liquidshell as another project under the KDE community umbrella:
* improvements for shared middleware, perhaps even introducing some more
  where it makes sense to share between Plasma, liquidshell & others
  (pushing for more clear UI-core separation, which in theory is for good)
  libtm might be one such thing, the weather data provider system also calls
  for being shared code with Plasma (and e.g. the Marble weather plugin)
* another testing ground for protocols & standards in development
* make more obvious that "KDE" is about a community, not a certain software
* give perhaps remaining trinity desktop developers and other
  Plasma-no-Qt-jay-fans a new center for their goals and as result also new
  contributors for the shared middleware, tools and apps (at least for their
  current QtWidgets UI variant ;) )

Re: gosh, yet another workspace
In a perfect world everybody would join work on the one true golden workspace 
solution, reality is that there is no such one-workspace-which-fits-all. Not 
to forget the mythical person-month issue.

And if people rather go and write their own software instead of joining 
existing projects, it should be the projects asking themselves why they have 
not been attractive enough in the first place.
Telling people instead "you should not do X, but Y" is rather the opposite of 
what Free Software is about. Even when first saying "Your are free, but".

I applaud you, Martin, for managing to solve your needs yourself and for 
sharing the results with the rest of the world, instead of keeping them for 
yourself.
And as KDE community we can feel honored you trust us to be the best place for 
further development of your software, instead of going github or elsewhere.

Re: liquidshell as name
When I read liquidshell I first thought about something very dynamic, highly 
animated. So not sure "liquid" is the best term to use in the name. But then 
we all know naming is hard, good luck with it :)

Cheers
Friedrich

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Some more branding oriented nitpicks:

Am Freitag, 3. November 2017, 21:30:19 CET schrieb Martin Koller:
> - uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual
> Desktops, Bluetooth, Network

Please consider saying rather "KDE Frameworks dialogs", due to "KDE dialogs" 
being a concept which no longer exists at age of KDE Frameworks and Plasma.

> light color theme:
> http://members.aon.at/m.koller/liquidshell_20171103_174650.png dark  color
> theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png

Please consider using a non-KDE logo on the start menu on representative/
advertising screenshots (ideally some new liquidshell logo one, also to help 
promoting it and building an identity).
Given the history meaning of the KDE logo as the logo of a desktop, using the 
KDE logo will spoil the concerted effort of the rebranding done (whether it 
was a good idea or not is too late to discuss) and only continue the 
confusion, for no good.

So with the Plasma workspaces having moved to the Plasma logo, leaving the KDE 
logo for the community, liquidshell should have and use its own dedicated logo 
as well. (and yes, the start-here-kde icons would need renaming finally)

Cheers
Friedrich

Re: KDE Review: Rust Qt Binding Generator

[Friedrich W. H. Kossebau]

Am Sonntag, 3. September 2017, 18:14:49 CET schrieb Jos van den Oever:
> Dear KDE-ers,
> 
> A new project is up for review: Rust Qt Binding Generator.
> 
> The project is a command-line executable that creates Rust code and Qt code
> from a binding description in JSON.
> 
> The code is currently at kde:scratch/vandenoever/rust_qt_binding_generator
> 
> If you want to use Rust code in your Qt project or if you would like to add
> a Qt UI on your Rust code, this program will help you.
> 
> The binding can describe a Objects, Lists and Trees. Objects generate C
> ++ derived from QObject. Lists and Trees generate C++ classes derived from
> QAbstractItemModel. On the Rust side, a trait is created. This trait is the
> interface that the developer needs to fill with code.
> 
> The project comes with a demo application that shows Rust code powering a Qt
> widgets project, a Qt Quick Controls project and a Qt Quick Controls 2
> project. It shows a list, file system tree, a system process view and a
> chart.
> 
> That demo with the code for it is easiest way to appreciate what you can do
> with rust_qt_binding_generator.
> 
> The idea of this binding generator is that you write each part in the most
> appropriate language. Rust bindings for Qt are hard to get right and will
> still have caveats for a while. With this generator, you write the UI in C++
> or QML. The generated code has no dependencies apart from Qt Core and the
> Rust crate libc.
> 
> A simple example: Hello World.
> 
> ```json
> {
> "cppFile": "src/greeting.cpp",
> "rust": {
> "dir": "rust",
> "interfaceModule": "interface",
> "implementationModule": "implementation"
> },
> "objects": {
> "Greeting": {
> "type": "Object",
> "properties": {
> "message": {
> "type": "QString"
> }
> }
> }
> }
> }
> ```
> 
> Preparation: create a new CMake project with a Rust project in the folder
> 'rust'.
> 
> ```
> kwrite CMakeLists.txt
> kwrite bindings.json
> mkdir rust
> (cd rust && cargo init --name rust --lib)
> ```
> 
> Create bindings with this command:
> 
> ```bash
> rust_qt_binding_generator binding.json
> ```
> 
> Add the files to the main Rust library module, `rust/src/lib.rs`
> 
> ```rust
> extern crate libc;
> 
> pub mod interface;
> mod implementation;
> ```
> 
> And modify tell Cargo to build a static library in `rust/Cargo.tom`:
> 
> ```
> [package]
> name = "rust"
> version = "1.0.0"
> 
> [dependencies]
> libc = "*"
> 
> [lib]
> name = "rust"
> crate-type = ["staticlib"]
> ```
> 
> Next step: put your code in rust/src/implementation.rs:
> 
> ```rust
> use interface::*;
> 
> pub struct Greeting {
> emit: GreetingEmitter,
> }
> 
> impl GreetingTrait for Greeting {
> fn create(emit: GreetingEmitter) -> Greeting {
> Greeting {
> emit: emit,
> }
> }
> fn emit() ->  {
> 
> }
> fn message() ->  {
> "Hello world!"
> }
> }
> 
> ```
> 
> The GreetingEmitter is generated struct that can emit signals such as
> valueChanged(). It is not needed in this simple example, but the interface
> requires it. You might have new values coming in of which you'd need to
> notify the UI.
> 
> The demo has more advanced examples. List and Tree let you implement
> QAbstractItemModel with Rust code but the API is quite different.
> 
> There is no QAbstractItemModel::data and QAbstractItemModel::setData to
> implement. Instead, you define properties for each list or tree item and
> have to implement functions like
> 
> ```rust
> fn name(row: usize) ->  {
> if row == 0 {
> return "Alice";
> }
> "Bob"
> }
> ```
> 
> This project is not a typical C++ KDE project, but I hope it can be part of
> KDE anyway.

3 months passed and this is still in kdereview. Time to move it on or bounce 
it back, to playground or even outside of KDE spheres.

I would like us to accept it though, extragear/sdk seems the best fit.

Before though this should be addressed at least:
https://phabricator.kde.org/D9357 (Some fixes for CMakeLists.txt)
https://phabricator.kde.org/D9458 (Fix i18n message catalog naming, add 
catalog for generator app)

One could also argue about the name of the generator binary, 
"rust_qt_binding_generator" is quite verbose. Perhaps "rqtbindgen", 
"rustqtbindgen" or similar would be following existing naming (cmp. e.g. 
"cbindgen" Rust crate for similar purpose).

Cheers
Friedrich

Re: CI system maintainability

[Friedrich W. H. Kossebau]

Am Donnerstag, 28. März 2019, 11:27:44 CET schrieb Daniel Vrátil:
> I'm completely fine with mandatory code review for everything and I'd be
> happy to have this in PIM. I think the biggest problem in PIM to overcome
> will be finding the reviewers - I dare say I'm currently the only one who
> has at least a little idea about what's going on in Akonadi, so getting for
> instance Laurent to review my Akonadi patches might be hard - same for me
> reviewing Laurent's KMail patches. This will require non-trivial amount of
> effort for all members of the community to gain deeper understanding of the
> other components within the project and a willingness to step up and do a
> code review even if they don't feel 100% comfortable with the code base.
> But I believe that in the long run the benefits clearly out-weight the
> cost.

So why do you not do this already? Why would you only do this is there is a 
policy requiring you to do it?
And why do you think this policy-driven behavioural change will work or is 
needed with everyone else?

Also, how do you ensure the review is actually of quality?
And not just socially driven "+1 for my buddie!", where buddy then also 
mentally shifts part of responsibility to other buddy, because, he, more eyes 
means I do not need to do the full work myself, glitches will be caught be 
them surely! Reviewer found a code formatting issue, done here, review 
happened.
The opposite also has been seen, reviewers feel they need to do "real" review 
and find things, so start to nitpick or to demand wrong changes, wasting 
everyone's time.

For myself I know I will happily have other people review my patches, but 
only if there are qualified people to be expected to do it with the needed 
quality in a reasonable time.

Then, trying to force by that policy other people to become proper specialist 
for certain other code projects to do qualified reviews, actually is a trade-
off. They will have less time for their actual code project, becoming less a 
specialist there (or having time to review other people's contribution to 
that project).
We need more contributors, not force existing contributors to distribute 
their abilities & resources over more projects (and thus having less for 
their actual one).

I am also not aware of many contributors to KDE projects who are not capable 
to make a responsible decision between the few obvious simple fixes and those 
normal changes which better get feedback from others first. If one is unsure 
about one's post-beer late-night quick hack, one will upload it for review, 
no? At least if one's previous late-night commits turned out to be late-night 
mental state impacted.
To deal with those few which seem challenged to do that decision properly, I 
find such a policy for everyone harmful, I know it would impact my 
contribution willingness, when I come across a typo or other simple and 
obvious to fix things. And just leave the garbage around along my current 
working path.

Besides, it will not solve the issue this thread is about, with some people 
not caring (quickly) enough if CI builds fail or if there are regressions in 
tests.

Review builds once implemented and deployed will help there partially as a 
side-effect only, catching some build fails before. But also not if this 
breaks (e.g. due to API/behavioural changes) depending projects, as CI at 
least currently does not rebuild dependent projects (cmp. also T7374).

A society with people doing things only due to policies and not intrinsic 
motivation seems very flawed to me, makes me wonder why people are in there 
given no-one forced them into this society.

https://community.kde.org/Policies/
Commit_Policy#Code_review_by_other_developers has some policies already, 
which should be enough:
1.1 Think Twice before Committing
1.2 Never commit code that doesn't compile
1.3 Test your changes before committing
1.4 Double check what you commit
1.10 Code review by other developers
1.11 Take responsibility for your commits
1.12 Don't commit code you don't understand
Well, perhaps could be amended by an explicit note about keeping CI working.

Enforcing review of any commits IMHO should be only done for people who 
notoriously failed to comply with those existing rules. If we are unable to 
pinpoint those people, talk with them and make them comply or sort out their 
reasons to not yet comply, but instead create as workaround new generic 
policies for everyone, we make this a worse society. And also a less 
effective, with more rubber stamps needed.

Cheers
Friedrich

Re: CI system maintainability

[Friedrich W. H. Kossebau]

Am Donnerstag, 28. März 2019, 09:29:22 CET schrieb Kevin Ottens:
> Hello,
> 
> On Thursday, 28 March 2019 09:16:11 CET Ben Cooksley wrote:
> > Please note that the commits in this instance were pushed without
> > review, so restrictions on merge requests wouldn't make a difference
> > in this case unfortunately.
> 
> Maybe it's about time to make reviews mandatory... I know it's unpopular in
> KDE, and I advocated for "don't force a tool if you can get someone to look
> at your screen or pair with you" in the past. Clearly this compromise gets
> somewhat exploited and that's especially bad in the case of a fragile and
> central component like KDE PIM.

Mandatory reviews in my experience only result in more fake reviews due to 
people pressuring each other to quickly get their simple patches reviewed, 
lowering the general quality of reviews.
Also does the overhead reduce the number of minor improvements, where one (as 
qualified person) simply would have pushed in a minute a fix and get back to 
concentrate on the real work, instead of starting an overhead of having to 
juggle with yet another patch-under-review where the current work depends on.

IMHO the actual problem here is: people do not do their post-push work and 
care for the state on CI.

From what I saw, many breakages happened with reviewed patches. Whole 
releases even get done while CI is reporting failed builds, or at least lots 
of failing tests.

I have no idea how to fix that. We would need to ask the people for whom this 
happens why it does happen, and how we can improve things so that CI checks 
become part of their workflow.

Cheers
Friedrich

Re: CI system maintainability

[Friedrich W. H. Kossebau]

Hi Laurent,

Am Donnerstag, 28. März 2019, 14:33:59 CET schrieb laurent Montel:
> For example I works all days on kde (pim or other) when I wake up, or at
> noon after my lunch or the evening, I will not wait several days for a
> review because nobody has time to do it.
> 
> (For example I make ~ 15 commits by days on pim/ruqola/framework, I don't
> want to wait several days/weeks until someone wants to review my patchs)

Something might be lost in translation here, do you think, because you work 
daily on code of KDE projects, and other people (so potential reviewers) do 
not, this is an argument to do instant pushes of unreviewed commits?

While I understand one can get impatient if not getting instant review of 
changes one would like to depend on with further changes (I know this well :) 
), still this seems a flawed argument at least for part-time-contributors 
based KDE projects, where the people one co-operates with only have time now 
and then, like once per week. It could be seen unfair & ignorant to them if 
one simply ignores their opinion, because one has more time reserved/
available.

Not sure where this is from, but often I have seen an unwritten policy 
applied where people for a patch uploaded for review after one week of no 
response add a ping and then wait another week, before finally pushing the 
change. To me this seems a fair and reasonable policy, only ignores people 
who are on vacation for some more weeks or otherwise inactive, but I have not 
seen that ever been a real issue.

Given the actual purpose of this thread, I would be more curious how you have 
CI integrated in your workflow? And where things could be improved, to 
prevent the current state of unhappiness for people who care about CI some 
more? Given you said you work daily on KDE projects, it seems that the 
brokeness of those projects on the KDE CI has slipped your attention.
So how does this happen, and how could this be prevented, other than people 
having to hunt you down on irc and tell you :)

Cheers
Friedrich

Re: CI system maintainability

[Friedrich W. H. Kossebau]

Am Donnerstag, 28. März 2019, 16:04:01 CET schrieb Boudhayan Gupta:
> I don't care if you lose time. I don't want the guys building my house to
> cut corners mixing my concrete because it's going to save time.

There is a difference here though, no? The people building your house will 
not live in that house. They only make money from building, so: less effort & 
lesser time for same money received -> better.

We here create software we use ourselves, no? So we are building our own 
house, and would not be expected to cut corners on our own grounds.

> As a user, I simply do not want unreviewed crap running on my computer.
> Yes, crap, because no software engineer writes bug-free code all the time,
> and if you're so overconfident that you don't need reviews on even your
> one-liners, you're probably too overconfident to be writing good code
> anyway, so I'm going to operate on the presumption that if the code hasn't
> had more than one pair of eyeballs ever looking at it, it's crap.

Hmmm... (I cannot stop myself typing the following :) )

In that case, I have to immediately notify you to make sure that you remove 
Okteta from any of the devices you have reach to, if you even ever installed 
it, best recommend your distribution to delete the package. Because 
shockingly all the >4000 commits of its >100k lines of code have been done 
without review. So it surely is an insane pile of crap by presumption, unless 
finally someone will give it another pair of eyeballs.

Though I assume no-one is using it anyway, given there are so few bugs 
reported ;)

> As a developer, I know that even one-liners, and especially one-liners, the
> sort where you think "meh, this is a tiny little thing, I don't have to be
> careful" are the ones that have the most dangerous typos and unintended
> bugs. Reviews catch that.

This sounds to me like review is magically preventing bugs.
Well, it increases the chance things get catched. Though reviews also 
increase the chance to be sloppy, as there is: review to catch that. Then 
after all is the reviewer also a developer, who also only sees a one-liner, 
where they think "meh, this is a tiny little thing, I don't have to be 
careful".

A review is only useful if the reviewers are qualified and invest the proper 
resources.

I prefer one responsible experienced developer over an unresponsible 
unexperienced developer & unresponsible unexperienced reviewer any time.

More I prefer of course one responsible experienced developer & one 
responsible experienced reviewer :)

Based on my personal experience bubble, not by any scientific means.

Cheers
Friedrich

Re: CI system maintainability

[Friedrich W. H. Kossebau]

Thanks for reply. More below:

Am Donnerstag, 28. März 2019, 16:56:33 CET schrieb laurent Montel:
> Le jeudi 28 mars 2019, 16:11:12 CET Friedrich W. H. Kossebau a écrit :
> > Hi Laurent,
> > 
> > Am Donnerstag, 28. März 2019, 14:33:59 CET schrieb laurent Montel:
> > > For example I works all days on kde (pim or other) when I wake up, or 
at
> > > noon after my lunch or the evening, I will not wait several days for a
> > > review because nobody has time to do it.
> > > 
> > > (For example I make ~ 15 commits by days on pim/ruqola/framework, I
> > > don't
> > > want to wait several days/weeks until someone wants to review my 
patchs)
> > 
> > Something might be lost in translation here, do you think, because you
> > work
> > daily on code of KDE projects, and other people (so potential reviewers)
> > do
> > not, this is an argument to do instant pushes of unreviewed commits?
> 
> I maintain pim* from several years, I fix bugs, I improve apps, I fix all
> bugs that I put in my code, so for this one I consider that I can commit
> without review them (as other guys on other project that they maintain).
> For framework I mainly use phabricator.

I was thinking of projects where there are multiple persons contributing/
maintaining, like Frameworks.

So for projects where you are the only person who has any real insight, 
indeed I agree to pushing directly, as I do that as well :)

Because IMHO the costs for having to hope & wait for somebody else to do a 
"review", where one then spends lots of time rather explaining things to 
someone, who is not really into the project and also never might be, is not 
anywhere worth the time one could have otherwise invested in fixing other 
existing bugs or adding new features or improving code quality.

If people want to get into a project, doing own patches or just watching the 
commits and asking normally on irc or by email about the architecture should 
work good enough. Abusing reviews for teaching about some project would annoy 
me at least, usually the patch is to fix some annoying bug or add a wanted 
feature, so it should get in as early as possible.

> > Not sure where this is from, but often I have seen an unwritten policy
> > applied where people for a patch uploaded for review after one week of no
> > response add a ping and then wait another week, before finally pushing 
the
> > change. To me this seems a fair and reasonable policy, only ignores 
people
> > who are on vacation for some more weeks or otherwise inactive, but I have
> > not seen that ever been a real issue.
> 
> 2 weeks for a commit, for me it's too long.
> I understand why people can be demotivated when they must wait long time
> until having an answer.

Well, 2 weeks is the time-out, only reached in worst case. Ideally people 
give some feedback before, which often enough happens. And indeed one also 
has to hunt people down to get a review, like at meetings or in chat (or 
trade review work with each other :) ). But isn't this the same also at work-
work, unless there is a dedicated review team which needs to react by itself? 
Co-operating on something needs social interaction after all. 

> > Given the actual purpose of this thread, I would be more curious how you
> > have CI integrated in your workflow?
> 
> CI: sometime I look at it, sometime not, sometime some guys informs me that
> it's broken (I remember that Luca told me some days ago that a package
> didn't compile, so I fixed it).
> Sometime my code compiles on local so for me it's ok but it's just that I
> forgot to trash my builddir.

So you do not go on yourself to build.kde.org and check yourself? Does #kde-
pim have a bot reporting build failures?

For what I can tell e.g. for KDevelop, personally I rely on the bot on 
#kdevelop  reporting the CI state/build results, as I only look at emails 
rather once a day, while the chat channel is more real-time, and one also can 
immediately talk to peers about why some build now fails, as well as 
coordinate who will fix that.

> > And where things could be improved, to
> > prevent the current state of unhappiness for people who care about CI 
some
> > more? Given you said you work daily on KDE projects, it seems that the
> > brokeness of those projects on the KDE CI has slipped your attention. So
> > how does this happen, and how could this be prevented, other than people
> > having to hunt you down on irc and tell you :)
> 
> I think that Luca idea to send an email directly to the people which breaks
> code when it breaks from several commit is a good idea.

Noted. Personally I would also fancy that over the generic mass emailing, 
where most of the time it was somebody else breaking stuff, so they should 
care. Given the

Re: CI system maintainability

[Friedrich W. H. Kossebau]

Am Donnerstag, 28. März 2019, 23:06:17 CET schrieb laurent Montel:
> Le jeudi 28 mars 2019, 18:27:42 CET Friedrich W. H. Kossebau a écrit :
> > Am Donnerstag, 28. März 2019, 16:56:33 CET schrieb laurent Montel:
> > > Le jeudi 28 mars 2019, 16:11:12 CET Friedrich W. H. Kossebau a écrit :
> > > > Given the actual purpose of this thread, I would be more curious how
> > > > you
> > > > have CI integrated in your workflow?
> > > 
> > > CI: sometime I look at it, sometime not, sometime some guys informs me
> > > that
> > > it's broken (I remember that Luca told me some days ago that a package
> > > didn't compile, so I fixed it).
> > > Sometime my code compiles on local so for me it's ok but it's just that
> > > I
> > > forgot to trash my builddir.
> > 
> > So you do not go on yourself to build.kde.org and check yourself? Does
> > #kde- pim have a bot reporting build failures?
> 
> Long time ago we had it in #kontact.
> It's not the case now.

Do you remember a reason why it is no longer the case?

IMHO bringing the build report bot back to the chat channel could help with 
the issue this thread is about.

People tend to look more often into the chat channel then in their email 
folder, so this bot would improve the visibility of the state on 
build.kde.org, also be in a public place so people can directly chat about 
any reasons.

> > > > more? Given you said you work daily on KDE projects, it seems that 
the
> > > > brokeness of those projects on the KDE CI has slipped your attention.
> > > > So
> > > > how does this happen, and how could this be prevented, other than
> > > > people
> > > > having to hunt you down on irc and tell you :)
> > > 
> > > I think that Luca idea to send an email directly to the people which
> > > breaks
> > > code when it breaks from several commit is a good idea.
> > 
> > Noted. Personally I would also fancy that over the generic mass emailing,
> > where most of the time it was somebody else breaking stuff, so they 
should
> > care. Given the time-offset due to build times it is also unclear who
> > broke
> > things, given the email is not easy to parse, and one might already be 
off
> > again to other things in life.
> > 
> > Question is: when would you read the email, and how quick would you 
react?
> 
> I read it sometime as it arrives in my kdepim-devel mailbox, but indeed
> sometime we can have several mail in same time because we increase a 
package
> dependancy and it breaks all other packages. So indeed I didn"t look at all
> the time.
> 
> But when a people signals me a problem I try to fix it quickly.
> 
> An email send after 1 day that package is broken can be a good idea, so it
> can't be a dependancy problem because we increase package version just that
> it's really broken.

Increasing the package version ideally should not result in CI breakages. 
Ideally CI only fails if there is a real issue, otherwise people just get 
used to it failing and do not give the deserved attention.

What would prevent you to turn to a system like used with KDE Frameworks, 
where there is some internal dependency version and a separate actual 
version, with the actual version bumped earlier and the internal dependency 
version only bumped some days later? From what I saw, you increase versions 
quite often in PIM, so related breakages would happen quite often.

Cheers
Friedrich

PS: Okay if we start to slim the list of CC:s a bit now? Would leave out 
plasma, kdevelop, frameworks-devel on any next reply at least.

Re: KDiff3 1.8 release.

[Friedrich W. H. Kossebau]

Hi Michael,

Am Samstag, 9. März 2019, 16:53:58 CET schrieb Michael Reeves:
>I would like to move forward with a 1.8 release targeting end of Apirl.
> Could someone please check over the kf5/qt5 changes to make sure there are
> no major problems? Also there is custom painter that tries to handle left
> to right text manually what is the proper way to support this? I will be
> doing at least the next few releases independent of Applications do to the
> amount time past since the last release for kdiff3. The 1.8 branch creation
> and freeze is set for 3-22 if no major issues are found.

When I gave it a (quick) look earlier today, nothing grave catched my eyes 
when it comes to Qt5/kF5 interfacing code (just a few favourite nitpicks of 
mine, which are already reviewed/pushed :) ).
No idea about the custom RL painter myself or proper ways.

Two things I noticed though which you ideally give some look:

kdiff3 -h & -v show both a window as well as print output on the commandline.
The windows are a bit unexpected and unusual given one already is on the 
commandline, perhaps that feature to also show a window could be removed?

You might also want to port the debug output from fprintf(stderr, ...) & Co. 
to qCDebug() & Co.

Cheers
Friedrich

Re: libqaccessibilityclient now in kdereview

[Friedrich W. H. Kossebau]

Am Dienstag, 25. Juli 2017, 13:25:39 CET schrieb Jonathan Riddell:
> libqaccessibilityclient is now in kdereview.  It's in a git repo
> called libkdeaccessibilityclient but we filed a sysadmin request to
> rename it.
> 
> We just released 0.2.0 in unstable (for some reason 0.1.1 was released
> in stable some years ago).
> 
> What is it?
> 
> Since it's hard to grasp all the bits related to accessibility, I'll try to
> explain what the lib is for.
> Most of the stack is part of Qt 5, so nothing to worry about, that's the
> part that lets applications expose their UI over DBus for AT-SPI, so they
> work nicely with assisitve tools (e.g. Orca). In accessibility language,
> the applications act as "servers" and the screen reader for example is a
> client.
> 
> This library is for writing clients, so applications that are assistive,
> such as screen readers. It currently has two users: KMag and Simon.
> KMag can use it to follow the focus (e.g. when editing text, it can
> automatically magnify the part of the document where the cursor is.
> 
> For Simon Listens, the use is to be able to let the user trigger menus and
> buttons by voice input.

Soon it will be 2 years that libqaccessibilityclient entered kdereview, and I 
just found it seems to be still in that state, at least by what repo-metadata 
claims and given no emails to the thread which sonud like review done
I came across it when compiling kmag myself, where the optional dep on this 
exists.

It is not on build.kde.org. Possibly it is not clear yet where this library 
should end up, given there is no separate kdereview product group?

Where should it end, "Extragear"? "KDE Applications"?

Given Simon seems struggling, and KMag will not get a visum for wayland, are 
there still plans for a future, with other customers/clients? I see there have 
been a row of commits last November, incl. the 0.3.0 release, so seems there 
is some plan? 

In any case, would be good to complete the review process. To binary bin or to 
released & maintained product group.

When trying to build kmag, I found that the CMake Config files of the then 
latest libqaccessibilityclient master version were not up to modern standards 
(missing ConfigVersion.cmake file, no include dir set on imported target, 
missing deps check). I pushed some fixes for that directly, given my 
confidence in related cmake experience over what was currently in the code. 

Also fixed directly the search for Qt modules which was done without checking 
the result, And introduced the BUILD_TESTING option as known from elsewhere, 
to allow controlling whether to build the tests (and examples).

And some more clean-up for things that jumped to me from the cmake code.

Please give the commits some post-push review, though it should be fine, 
following usual coding seen elsewhere.

Actually there is more I would change, but that might get more invasive (e,g. 
using GNUInstallDirs or KDEInstallDirs) and needs more discussion/testing, so 
I would go for normal patch review then. But before that, I would like to see 
the kdereview process finished as well as build.kde.org having a normal build 
of it :)

Would be good to also have state on the last comments in this thread:
* does not compile with clang <- cannot easily check myself, so no idea
* autotests need Qt5Test, but if the dependency is not installed,
  fails silently <- should be fixed by commit d01385005c5d (BUILD_TESTING)

Cheers
Friedrich

Re: Review Request: plasma-thunderbolt

[Friedrich W. H. Kossebau]

Am Mittwoch, 15. Mai 2019, 15:27:07 CEST schrieb Daniel Vrátil:
> Thus I'd kindly ask you to take one more look at the codebase [1] and let me
> know if there are any more issues to fix, or if we can proceed to include
> this in the next Plasma release.

Pushed some small fixes to toplevel CMakeLists.txt

Other things seen on quick look at code (also not tested runtime):
* kded misses a Messages.sh file.
* no COPYRIGHT license files in the repo
* kde_enable_exceptions() duplicated a few times, perhaps only do in subdirs 
where needed or use of kde_target_enable_exceptions() if fitting
* libkbolt being a private library could be reflected in the libname, also get  
   
install(TARGETS kbolt ${KDE_INSTALL_TARGETS_DEFAULT_ARGS} LIBRARY 
NAMELINK_SKIP)

Cheers
Friedrich

PSA: Use newer add_test(NAME COMMAND ), check CI, esp. with min ECM >=5.38

[Friedrich W. H. Kossebau]

Hi,

tl:dr
In your CMake code replace all remaining
add_test( )
with
add_test(NAME  COMMAND )
to make sure test executables are still found once you bump the minimum ECM 
version required >= 5.38.
And check your product on KDE CI, where not found test executables are now 
properly reported as failure (everything got already up-to-date builds with 
that change, if part of groups "Frameworks", "Applications" or "Extragear").
At least one project missed to see some unit-test regression on released 
versions due to test executables not found and not run, without being 
reported as failure on CI.

Long version:
It was found that on KDE CI some build states had been reported with a blue 
ball (=all good), while actually most of its tests were not run, due to the 
test executable not found. This was due to the logic on CI mapping ctest's 
 to jenkins , with the later not invalidating an "all good" 
state. This has now been changed (D20874),  with 'Unable to find 
executable' is now reported as , so will be treated like a failed 
test.
(Locally a "make test" reports not found tests as failed, so we should have 
ourselves run "make test" more often it seems :) ).

Tests executables not or no longer being found can happen when you bumped the 
minimum required ECM version to 5.38 or above and use KDECMakeSettings. 
Because this will trigger the placement of all built executable code into the 
toplevel bin/ directory, not in the normal build dir.
Which breaks the inherit assumption of

   add_executable(testfoo ${SRCS}) # add_executable( ...)
   add_test(foo-test testfoo)  # add_test( )

where the command is taken as verbatim command and usually works as the name 
of the executable target is also the name of the executable, which was placed 
in the build dir, which is the default working directory on running the 
tests.

To fix this, use the newer signature of add_test:

   add_test(NAME foo-test COMMAND testfoo)

(so just insert "NAME" & "COMMAND" before the two arguments).

Because "[i]f  specifies an executable target (created by 
add_executable()) it will automatically be replaced by the location of the 
executable created at build time." Thus the test binaries being placed in 
bin/ will no longer be an issue.
See https://cmake.org/cmake/help/latest/command/add_test.html
This signature exists already with cmake 2.8.12.

Any other related wrapper calls, like ecm_add_test, are fine and do not need 
any work.

For more background why this is needed at all, see the docs about the efforts 
trying to make tests & apps runnable uninstalled for developer convenience 
(yes, no free lunch):
https://api.kde.org/ecm/kde-module/KDECMakeSettings.html
https://community.kde.org/Guidelines_and_HOWTOs/Making_apps_run_uninstalled

Cheers
Friedrich

RFC: Deprecating KDesignerPlugin in favour of new ECMAddQtDesignerPlugin

[Friedrich W. H. Kossebau]

Hi,

following up on a recent discussion about kdesignerplugin currently providing 
a single Qt Designer plugin for all of those modules from KDE Frameworks which 
provide custom QWidgets, and with this coupling running against the idea of 
mpdularization with KDE Frameworks, a few patches have been sketched and made 
working to approach this.

Please see for discussion of problem and proposed solution with a series of 
patches this task:

https://phabricator.kde.org/T11289

Please add your comments there, as well as on the patches, especially the 
proposed ECMAddQtDesignerPlugin addition to ECM.

If everyone agrees with the appraoch, would be material for KF 6.62 earliest 
(so only post upcoming KF 6.61).

Cheers
Friedrich

HEADS-UP: from now do new deprecations in KF API by *_DEPRECATED_* macros only using upcoming version number

[Friedrich W. H. Kossebau]

Hi,

with KF 5.64 now branched and thus the new deprecation macros going to be 
released for the first time, now please make sure when in the future marking 
API as deprecated to use the correct current version, i.e. the one where the 
deprecation will be made public the first time.

So if pushing a commit which deprecates API, make sure the "x" is matching the 
upcoming version of KF where the deprecation will be released the first time:

#if KFOO_ENABLE_DEPRECATED_SINCE(5, x)
/**
 * @deprecated Since 5.x. Use bar(). // Sadly doxygen needs data duplicated
 */
KFOO_DEPRECATED_VERSION(5, x, "Use bar()")
void foo();
#endif

((In a perfect world this boilerplate/duplication would not be needed and 
tools would automate this for us, but for now we have to do it manually.))

Do _not_ use an older KF version where the API might already have been 
considered deprecated, but was forgotten to be marked. Use the upcoming KF 
release version only.


In the last weeks, since 5.63 was branched, while the new deprecation macros 
generated with ECMGenerateExportHeader were introduced you may have seen also 
lots of older versions being used. But that was fine due to the macros not yet 
been released and changes done to be historically correct, like also matching 
any already existing version info in the API dox by the @deprecated tag. 
Hopefully we have catched any existing KF API which has been considered 
deprecated before.

But now with KF 5.64 being branched and going to be officially released 
exposing the new deprecation macros and thus the options to control visibility 
of and warnings about deprecated KF API, people using KF libraries in their 
software will e.g. start to use the *_DISABLE_DEPRECATED_BEFORE_AND_AT macros, 
to protect themselves against usage of API deprecated the first time up to a 
certain version, for which they have checked their code builds fine against.
And we would thus ran chance to break their software builds if we now marked 
more API as being deprecated in previous versions in future KF releases. Not 
our mission :)

Cheers
Friedrich

Re: Quick Charts in KDE Review

[Friedrich W. H. Kossebau]

Am Donnerstag, 7. November 2019, 16:21:40 CET schrieb Nate Graham:
> On 11/7/19 7:34 AM, Friedrich W. H. Kossebau wrote:
> > Am Montag, 21. Oktober 2019, 15:22:23 CET schrieb Arjen Hiemstra:
> >> Quick Charts is a QML module that implements a set of high-performance,
> >> GPU accelerated
> >> charts. Currently the main user of it is a new KSysGuard UI I have been
> >> working on, but
> >> once it is part of Frameworks I also hope to convert several bits of
> >> Plasma to using it.
> > 
> > If there is only one user currently, might it perhaps be a better idea to
> > do some independent releases for a while to get more feedback on the API,
> > before settling to the API freeze by being part of KDE Frameworks? It
> > will be at least a year until KF6 is there to properly fix up any
> > potential API inconveniences which users might find.
> > I would at least recommend to first get some API shaping by real-world
> > exposure.
> 
> Seems like a chicken-egg problem: more exposure would be provided by
> getting it through the review process, no? I can see us porting the
> graphs in KInfoCenter to use this, for example. But since that's
> shipping code, we might not want to do that until it's formally a framework.

If one restricts oneself to use only libraries part of KDE Frameworks, but not 
from the "Extragear" domain, one should reconsider it, this does not make much 
sense as long one also uses non-KDE-party libraries (which also do not follow 
KF rules).

Review process is about passing something from playground into the set of no-
longer-playground repos. Which for libs can be KDE Frameworks domain, but also 
the "Extragear" domain. Both are equally post-review.
And "Extragear" gives the flexibility to do another product version with 
different ABI, once there has been more feedback from more users.
An approach e.g. taken by KUserFeedback. But also compare the concept of Qt 
labs modules.
Having an API mainly done for one user only right now runs a good chance to 
miss the API needs of other potential candidates. Everyone needs a different 
20 % of the API concepts, they say when throwing with numbers ;)

Np chicken-egg problem here. Release-often-and-early should be simply applied 
to KChickCharts as well. But I recommend to do as others and not bind to 
current first ABI for some time to come, like begin of KF6, instead plan for 
some optional ABI-breaking releases in the near future. So be under the rules 
of Extragear, not yet Frameworks.
But people learn best from own mistakes, so feel free to ignore some old 
person's comment-from-experience. ;)
If the API proves to be not perfect and one knows how it would be better, ~12 
months (to KF6) can be very long :P

Cheers
Friedrich

Re: Quick Charts in KDE Review

[Friedrich W. H. Kossebau]

Am Samstag, 9. November 2019, 14:16:08 CET schrieb David Edmundson:
> > If one restricts oneself to use only libraries part of KDE Frameworks, but
> > not from the "Extragear" domain, one should reconsider it, this does not
> > make much sense as long one also uses non-KDE-party libraries (which also
> > do not follow KF rules).
> 
> Plasma effectively has such a rule.
> 
> Treating this as a more meta discussion about libs, sure, with KDE
> rules in extragear you can change ABI/API but the consequences still
> mean in reality you can't.
> Release an incompatible lib, things explode until recompiled.

I am confused this is assuming one releases an incompatible library not using 
respective versioning schemes and not allowing parallel install?
But people do that properly, no?
 
> If we use a lib in plasma and in an application and then change the
> lib API we always have a window where either applications latest
> release or plasma latest release won't compile against the released
> lib. Even if you bump the .so version

Why the "even"? One should. That's what the purpose of the so version is.

> the headers aren't
> co-installable.

Some projects do proper version namespaces also for include path on changed 
ABI. If projects do not, they should start to do IMHO.
Even without, normally developers only work against one version of the 
library, so just having one variant of headers installed works good enough.

> Due to this release problem Plasma has previously made any use of
> extragear (or unstable 3rd party) #ifdef'd and always not in core
> functionality.

Given Plasma requires recent versions of KF on .0 releases, the same can be 
done also for newer versions of non-KF libraries, where one then switches to 
the new API series. No need for #ifdef.

> >But I recommend to do as others and not bind to
> 
> current first ABI for some time to come
> 
> Note this is all somewhat moot for this specific case. There is only a
> QML import. It can change ABI all it wants. Changing API is also
> doable as long as QML import bumps and the old version still works.

That is no different to normal compiled library symbols, no?
One also cannot break "ABI" (not sure what the respective name would be in 
dynamic languages), i.e. change names of symbols or their types at QML layer.

Think QQC 1 and QQC 2.

Of course this comes at cost. But personally I am willing to pay that price 
over having to stick with API which proved to be not good enough and thus 
makes my own code worse.
Thus my 2 cent recommendation to stay flexible for now :) But everyone has 
different priorities, just wanted to make you consider this.

Cheers
Friedrich

Re: Quick Charts in KDE Review

[Friedrich W. H. Kossebau]

Am Montag, 21. Oktober 2019, 15:22:23 CET schrieb Arjen Hiemstra:
> Hi,
> 
> Quick Charts has been moved to KDE review. The intent is to make it a
> Tier 1 framework.

Any chance the official name can be "KQuickCharts"? "Quick Charts" is a 
generic name which only asks for being misunderstood, is hard to google etc..
 
> Quick Charts is a QML module that implements a set of high-performance,
> GPU accelerated
> charts. Currently the main user of it is a new KSysGuard UI I have been
> working on, but
> once it is part of Frameworks I also hope to convert several bits of
> Plasma to using it.

If there is only one user currently, might it perhaps be a better idea to do 
some independent releases for a while to get more feedback on the API, before 
settling to the API freeze by being part of KDE Frameworks? It will be at 
least a year until KF6 is there to properly fix up any potential API 
inconveniences which users might find.
I would at least recommend to first get some API shaping by real-world 
exposure.

Sorry otherwise for not reviewing myself, not into QML the recent months.

Cheers
Friedrich

Heads-up for developers using KF modules: how to disable visibility of & warnings about deprecated API for >= 5.64

[Friedrich W. H. Kossebau]

Hi,

tldr; Please test now with git master the new available C++ macros with KF
-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0xXXYYZZ
-DKF_DEPRECATED_WARNINGS_SINCE=0xXYYZZ
-DKF_NO_DEPRECATED_WARNINGS
-DKF_NO_DEPRECATED
as well as individual specializations per library, e.g.
-DK{LIB}_DISABLE_DEPRECATED_BEFORE_AND_AT=0xXYYYZZ
-DK{LIB}_DEPRECATED_WARNINGS_SINCE=0xXXYYZZ
-DK{LIB}_NO_DEPRECATED_WARNINGS
-DK{LIB}_NO_DEPRECATED 
so issues can be catched before the 5.64 release.


Last WE git master of all KDE Frameworks has seen the completion of the 
introduction of a new feature which allows developers building against KDE 
Frameworks libraries to control which of its deprecated API is visible to the 
compiler as well as for which versions deprecation warnings should be emitted.

You are invited or rather encouraged to give this a testing now already, so 
issues can be catched before this gets released in then KF 5.64.

Without any settings, you will get warnings when using deprecated API, any 
deprecated API is visible to your build.

To just get rid of any warnings, use (with CMake, also ff.)
add_definitions(-DKF_NO_DEPRECATED_WARNINGS)

To just hide any deprecated API to your build, use
add_definitions(-DKF_NO_DEPRECATED)

To disable warnings about API deprecated first after a given version or, in 
other words, only see warnings for API deprecated first in versions up to and 
including a given, use (example: 5.28.0)
add_definitions(-DKF_DEPRECATED_WARNINGS_SINCE=0x051C00) # 5.28.0

To hide deprecated API up to and including a certain version (e.g. the minimal 
KF version you support), use (example: 5.28.0)
add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x051C00) # 5.28.0
This also sets the default of KF_DEPRECATED_WARNINGS_SINCE to that version,
so you will not see any warnings for API deprecated in newer versions, unless
setting another version explicitly for that.

Next to these KDE Frameworks wide settings, one can also override them for 
individual libraries, using macros with a prefix matching the library name.

E.g. to override for KCoreAddons the version at and before which deprecated 
API is made invisible to the compiler, one does this (order is not relevant):
add_definitions(
-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x051C00 # 5.28.0
-DKCOREADDONS_DISABLE_DEPRECATED_BEFORE_AND_AT=0x05
)

The names here are following the similar macros introduced with Qt 5.13, cmp
https://doc.qt.io/qt-5/qtglobal.html#QT_DISABLE_DEPRECATED_BEFORE , so one can 
apply known approaches. Just using BEFORE_AND_AT, because BEFORE is not really 
correct ;)
QT_DEPRECATED_WARNINGS_SINCE also exists, with same default mechanism for API 
with a versioned deprecation macro used (only used with newer deprecated Qt 
API it seems), but so far had not been publically documented yet (cite: "Just 
forgot it (and also the reviewers) I would guess. There is no plan to change 
it, at least none I'm aware of.")

Cheers
Friedrich

Heads-up for developers working _on_ KF modules: how to mark deprecated API from now on

[Friedrich W. H. Kossebau]

Hi,

tldr; For deprecated API of KDE Frameworks modules please use 
ECMGenerateExportHeader and the respective macros to mark & wrap deprecated 
API, otherwise the whole effort breaks down. Question: where would you expect 
the documentation for how to do this?


The introduction of ECMGenerateExportHeader to KDE Frameworks has been 
completed now, all 34 KF modules having deprecated C++ API have been adapted 
to use the CMake macro ecm_generate_export_header as well as the new C++ 
macros available from the respective generated export header.

So whenever there is some API to be deprecated, its declaration would now be 
decorated like this:

#if KFOO_ENABLE_DEPRECATED_SINCE(5, x)
/**
 * @deprecated Since 5.x. Use bar(). // Sadly doxygen needs data duplicated
 */
KFOO_DEPRECATED_VERSION(5, x, "Use bar()")
void foo();
#endif

The version 5.x needs to be listed with the DEPRECATION_VERSIONS argument of 
the ecm_generate_export_header, otherwise at least KFOO_DEPRECATED_VERSION(5, 
x, "") will fail to build (you will run into this for sure as I did, just 
needs remembering, so start now :) ).

A perfect programming language would not need all this fragile duplication, 
but with current C++ this seems the closest we can do to support users of our 
libraries to control visibility of deprecated API and warnings about it, as 
well as help ourselves during ABI breaks to do smoother porting and see the 
legacy API that can be dropped.


There are some more details around all this (like when not to use the #if 
wrapper because building-against-library compiler needs to always see virtual 
methods or enum values, or disabling deprecated API from the library build 
itself using KFOO_BUILD_DEPRECATED_SINCE), my question now is where this is 
best documented in detail. I already added small snippets in some places, but 
still search for a place documenting all known cases and pitfalls.

So, if in need of guidance how to use the new deprecation mechanisms, where 
would you expect to find the help? Many answers wanted here.

Cheers
Friedrich

Re: KTimeTracker in kdereview

[Friedrich W. H. Kossebau]

Am Dienstag, 19. November 2019, 05:20:23 CET schrieb Alexander Potashev:
> Hi,
> 
> KTimeTracker [1] has been moved to kdereview.

Did some favourite-nitpicks review comments as direct fixes.

Otherwise looks nice code on a quick superficial view. Needs other eyes though 
for proper review.

You want to instruct the Messages.sh to just care for the src/ subdir, and 
there also exclude the test/ subdir (just in case and to speed up execution).
Possibly first part can best be handled by moving Messages.sh into the src/ 
subdir.

Cheers
Friedrich

Re: ELF Dissector in kdereview

[Friedrich W. H. Kossebau]

Am Samstag, 12. Oktober 2019, 12:46:19 CEST schrieb Volker Krause:
> From the feedback everything should be addressed, apart from the following:
...
* "hicolor" icons for the app icon are not yet added & installed
  (proposal: copy over the breeze ones for now, like done for e.g. heaptrack)

Cheers
Friedrich

Re: Submitting Grantlee as a KF5 Framework

[Friedrich W. H. Kossebau]

Hi Stephen,

Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly:
> Great, Grantlee is now available at g...@git.kde.org:grantlee.git.
> 
> I've pushed a few commits to make it depend on ECM etc.

You pushed only to github though it seems :) Forwarded your commits now to the 
master branch on the main KDE repo. And did some commits to make things even 
more (current) KF-like.

Speaking of making sure all is synced & moved from github to KDE systems:

There are still some merge requests open on https://github.com/steveire/
grantlee/pulls. Also are there some open issues which might be wanted to be 
moved over to bugs.kde.org?

Cheers
Friedrich

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

[Friedrich W. H. Kossebau]

Am Samstag, 21. Dezember 2019, 23:32:10 CET schrieb Stephen Kelly:
> On 21/12/2019 19:12, Friedrich W. H. Kossebau wrote:
> > Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly:
> >> Great, Grantlee is now available at g...@git.kde.org:grantlee.git.
> >> 
> >> I've pushed a few commits to make it depend on ECM etc.
> >> 
> >> Once the review period is finished it can be part of KF5 releases.
> > 
> > There are quite some things which yet need to be done for now:
> > to be a true KF module there is a set of policies which needs to be met,
> > see https://community.kde.org/Frameworks/Policies
> > 
> > 1) Framework directory structure:
> > moving stuff into src/, autotests/ & docs/
> > 
> > 2) Framework documentation:
> > current system needs adaption to both online (KApiDox) and
> > offline (ECMAddQCH) systems
> 
> Cool, I wonder if there's another multi-library framework for comparison?

With ECMAddQCH, Sonnet & KNewStuff create separate QCH files for their 
multiple libs.

With KApiDox, IIRC it has the assumption 1 module <=> 1 documentation unit 
(not involved there),
Olivier (cc:ed) should be able to hint you what is possible.

> > Another challenge would be moving into the KF5 namespace for the library
> > artifacts (at least I would expect/recommend this to happen, for
> > consistent
> > user experience)
> > a) include dirs below subdir KF5/
> > b) CMake modules with KF5 prefix
> > c) CMake imported target in KF5 namespace
> 
> I don't support changing things like this in the KF5 timeframe.

IMHO not sharing the namespace "KF5" spoils the story of KDE Frameworks, where 
the namespace gives consistent developer experience and product messaging.

Having Grantlee being a special kid, with unregular CMake modules names and 
differently namespace imported CMake targets, makes things more complex.

Being consistent is what we so like about Qt, and KF should not stay behind, 
no?

Perhaps joining the "Release Service" (formerly known as "KDE Applications") 
is a better place then, it also contains a set of libraries already.
That would serve the purpose of having releases happening regularly.

Cheers
Friedrich

CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

[Friedrich W. H. Kossebau]

Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly:
> Great, Grantlee is now available at g...@git.kde.org:grantlee.git.
> 
> I've pushed a few commits to make it depend on ECM etc.
> 
> Once the review period is finished it can be part of KF5 releases.

There are quite some things which yet need to be done for now:
to be a true KF module there is a set of policies which needs to be met, see 
https://community.kde.org/Frameworks/Policies

1) Framework directory structure:
   moving stuff into src/, autotests/ & docs/
2) Framework documentation:
   current system needs adaption to both online (KApiDox) and
   offline (ECMAddQCH) systems

I could do 1) if you like, and help with 2) on the ECMAddQCH part.

Another challenge would be moving into the KF5 namespace for the library 
artifacts (at least I would expect/recommend this to happen, for consistent 
user experience)
a) include dirs below subdir KF5/
b) CMake modules with KF5 prefix
c) CMake imported target in KF5 namespace

Now, the question is if we want Grantlee to be backwards-compatible after the 
move into KDE Frameworks, or if some breakage is possible?

When it comes to CMake targets & modules, the first challenge is:

Grantlee5 supports components, "Templates" & "TextDocument". To allow people 
doing e.g.
--- 8< ---
find_package(Grantlee5 CONFIG COMPONENTS Templates)
--- 8< ---
So when Grantlee becomes a component in KF5 itself, so people would use for 
finding it
--- 8< ---
find_package(KF5 CONFIG COMPONENTS Grantlee)
--- 8< ---
these two, "Templates" & "TextDocument", would need to become subcomponents. 
Which though is a concept CMake does not support.

So what to do here? Split Grantlee into two separate libs, with separate CMake 
config files? Done by KF5NewStuff, where one repo provides 2 separate configs.
Or just merge and do not allow making dep chain more narrow (Grantlee's 
TextDocument pulls in QtGui as dep, so fails if no devel package not present)?


Then Grantlee's CMake module brings two namespaced imported targets:
* Grantlee5::Templates
* Grantlee5::TextDocument
With Grantlee being part of KDE Frameworks, one would expect to have targets 
named like
* KF5::GrantleeTemplates
* KF5::GrantleeTextDocument
or similar.

Just, seems CMake does not expect the use case of exporting targets with 
different names, there is only one property available to set the base name, 
cmp. current
--- 8< ---
set_property(TARGET Grantlee_Templates PROPERTY EXPORT_NAME Templates)
--- 8< ---
So when wanting to keep backward compatibility, we are stuck here with the old 
basenames.
Do you know any simple trick to have a separate CMake config file with 
separate imported targets, which still refer to the same library executable?
Never done myself, so no idea what could be done. Doing a separate target and 
exporting that one will fail possibly once trying to set OUTPUT_NAME property 
to the same,
Perhaps one could do a manual cmake config file which has the old one as 
find_dependency and then defines an alias target on the imported target?

Cheers
Friedrich

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

[Friedrich W. H. Kossebau]

Am Sonntag, 22. Dezember 2019, 17:08:15 CET schrieb Stephen Kelly:
> On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote:
> > Perhaps joining the "Release Service" (formerly known as "KDE
> > Applications") is a better place then, it also contains a set of
> > libraries already. That would serve the purpose of having releases
> > happening regularly.
> The goals of making Grantlee a Framework are:
> 
> * Make more frequent releases which don't depend on me
> 
> * Make it more easy for others to contribute to development
> 
> 
> I think at the point that renaming happens, the name Grantlee will
> disappear, and we'll have two libraries (KF5::TextDocument and
> KF5::TextTemplates or so in CMake and probably removing the C++ namespace).

There is no need to drop the name "Grantlee", IMHO that is a well-known 
product/solution identifier by now for the needs it solves. There are other 
non-generic-name identifiers in KDE Frameworks (Sonnet, Purpose, Prison, 
Attica, Solid, Baloo, Syndication) instead of "K" + generic descriptive 
english name, so it is also nothing new in concept.

KF5::TextDocument & KF5::TextTemplates as target/lib names e.g. would be less 
useful, as they could describe a lot of things and would need to be longer to 
be more exact :)

So having "Grantlee" as easily searchable term which also is properly defined 
what solution scope it is about can be actually seen as an advantage.

> I think all of that should be done together and I don't think that
> should be done until compatibility is broken to become Qt6-based (KF6).
> 
> If joining the Release Service helps reach the goals, and there is
> consensus that Grantlee can't be a framework without partial renaming
> (ie renaming the CMake interface but little else) in KF5, then that
> might be the way to go.

So far I was hoping we could have both for KF5 already, backward-compatible 
CMake config files with old imported targets as well as parallel new KF5-
namespaced CMake names. Myself still no good idea how to do this in CMake 
without too much manual complicated fragile hackery.

Cheers
Friedrich

Re: Keysmith in kdereview

[Friedrich W. H. Kossebau]

Hi Bhushan,

Am Mittwoch, 18. Dezember 2019, 15:50:36 CET schrieb Bhushan Shah:
> Hello everyone!
> 
> Keysmith (https://invent.kde.org/kde/keysmith) has been moved to
> kdereview.
> 
> Keysmith is a Two-factor code generator for Plasma Mobile and Desktop
> and is using oath-toolkit for this purpose. User interface is written in
> the kirigami.

Did some usual-nitpick-CMake-code cleanup commit already (things which also 
apply to other new Plasma repos, someone might want to brush over their 
CMakeLists.txt as well, using that commit as reference).

Other things noticed on superficial look:
* UI not translated, i18n support setup missing completely
* uses own "ENABLE_TESTING", not "BUILD_TESTING" flag from KDECompilerSettings
  proposed:
  + switch flag use to BUILD_TESTING
  - remove option(ENABLE_TESTING "Enable tests" ON)
  - remove enable_testing() (done by KDECompilerSettings)
* you might want to check if KF 5.37 has minimum version of Kirigami features 
used, otherwise needs bumping

Also surprised to see org.kde namespace added to the binary executable name, 
is that a new xdg recommendation?

No clue about purpose of app otherwise, so no usage tested besides starting :)

Cheers
Friedrich