Re: [kcalc][kcharselect][kcron] Merged frameworks branch to master, now KF5 based

[Luigi Toscano]

Christoph Feck ha scritto:
> Hi,
> 
> I just merged the "frameworks" KF5 porting branches of the following 
> applications to "master" branch:
> 
> - kcalc
> - kcharselect
> - kcron
> 
> These applications will be released as KF5 applications for the KDE 
> Applications 15.03 release.
> 
> Please check if everything went smooth, and report issues/regressions 
> to bugs.kde.org. Also, I have no administrative powers to make the 
> required changes to our infrastructures, so if not already done, 
> please help with rewiring CI, translations, pko, etc.

Translations moved, hopefully.

Ciao
-- 
Luigi

Re: LibRingClient has moved to extragear/network

[Luigi Toscano]

Elv1313 . ha scritto:
> Hi,
> 
> After going through kdereview for the last few weeks, libringclient
> (formerly the sflphone-kde client logic library) is now moving to KDE
> extragear. I am currently starting to remove the legacy Qt4 support
> still required by the KDE4 client (and porting it to kf5) so the
> translation issue should be solved in the coming week. For now, the
> translations are still based on kde4 l10n way of handling pure Qt
> libraries.

If it's still kdelibs4-based, can you please fix the translation branches on
projects.kde.org so that trunk_kf5 is empty for now?

I'm moving the translations.

Ciao
-- 
Luigi

Re: Review Request 122652: Use correct default value when UDS_ACCESS/UDS_FILE_TYPE is not set

[Luigi Toscano]

> On Feb. 25, 2015, 6:57 p.m., Mark Gaiser wrote:
> > I "think" this is OK, but just don't know.
> > 
> > Anyway, your diff is for kdelibs (KDE SC 4.xx). I don't know if that gets 
> > another release. Either way, KIO frameworks [1] is where this should be 
> > applied to when you get a ship it.
> > [1] http://quickgit.kde.org/?p=kio.git

kdelibs 4.14 still receives fixes and it's released with KDE Applications (at 
least as long as we have kdelibs4-based applications). So, if it fixes a bug, 
it can go in.
Of course it should be forward-ported to KIO Framework if it is still relevant 
there.


- Luigi


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


On Feb. 20, 2015, 10:28 p.m., Stefan Brüns wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122652/
> ---
> 
> (Updated Feb. 20, 2015, 10:28 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Bugs: 339193
> http://bugs.kde.org/show_bug.cgi?id=339193
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> The default value for UDSEntry::numberValue(...) is 0, whereas KFileItem
> uses the special value KFileItem::Unknown == (mode_t) -1.
> 
> CCBUG: 339193
> 
> 
> Diffs
> -
> 
>   kio/kio/kfileitem.cpp f431d3608cfe646fb882365921e694af8ff8838f 
> 
> Diff: https://git.reviewboard.kde.org/r/122652/diff/
> 
> 
> Testing
> ---
> 
> dolphin remote:
> -> no lock icon on smb:, mtp:, ... links
> 
> 
> Thanks,
> 
> Stefan Brüns
> 
>

Re: Review Request 119363: Port kde-baseapps to use docbook 4.5

[Luigi Toscano]

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


The changes described in this review have been applied long time. The encoding 
issue has been addressed in the following two reviews:
 * kdoctools: https://git.reviewboard.kde.org/r/120648/
 * kdelibs4support: https://git.reviewboard.kde.org/r/120649/

which are now pushed and closed. So this review can be closed.

- Luigi Toscano


On Aug. 24, 2014, 6:33 p.m., Marko Käning wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119363/
> ---
> 
> (Updated Aug. 24, 2014, 6:33 p.m.)
> 
> 
> Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> ---
> 
> This suggests to upgrade the docbook DTD from 4.2 to 4.5.
> 
> ---
> 
> There is still an open issue here:
> 
>  Spaces in DATA_INSTALL_DIR need to be handled properly, so that the path in 
> the DTD file
> 
> /Library/Application\ Support/kf5/kdoctools/customization/dtd/kdex.dtd
> 
>  is correctly set, i.e. using "%20" instead of a space.
> 
> 
> Diffs
> -
> 
>   doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
>   dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
>   kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
>   kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
>   kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 
> 
> Diff: https://git.reviewboard.kde.org/r/119363/diff/
> 
> 
> Testing
> ---
> 
> Builds/installs fine (if one doesn't use any white-space in DATA_INSTALL_DIR 
> path) 
> 
> 
> Thanks,
> 
> Marko Käning
> 
>

Re: Review Request 122812: Fix BIC introduced in kdelibs 4

[Luigi Toscano]

> On March 4, 2015, 10:19 p.m., Albert Astals Cid wrote:
> > Given the BIC change is already part of 4.14.6 i'd say we just ignore it, 
> > it's not like anyone cares for that symbol, right?

Is it already out? If not, no way to skip 4.14.6 or mark it as "don't use it" 
for distributions (or tell them to ship the patches)?
I would vote for that.
(for sure the revert should be introduced in frameworks before 5.8; a 
BIC-incompatible version was never released)


- Luigi


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


On March 4, 2015, 6:26 p.m., Andrea Iacovitti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122812/
> ---
> 
> (Updated March 4, 2015, 6:26 p.m.)
> 
> 
> Review request for kdelibs and Albert Astals Cid.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> First of all sorry for that!
> In commit c2046dd7064634d4d6ba50cafd8b1047bd133859 I introduced a BIC by 
> renaming public DOMString::trimSpaces() to DOMString::parsedUrl().
> However AFICT trimSpaces() was only used internally by khtml.
> I can either revert the commit or apply this patch that reinstate old 
> DOMString::trimSpaces() and mark it as deprecated.
> 
> 
> Diffs
> -
> 
>   khtml/dom/dom_string.h 087f697 
>   khtml/dom/dom_string.cpp a3c4abd 
> 
> Diff: https://git.reviewboard.kde.org/r/122812/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrea Iacovitti
> 
>

Re: Review Request 122812: Fix BIC introduced in kdelibs 4

[Luigi Toscano]

> On March 4, 2015, 10:19 p.m., Albert Astals Cid wrote:
> > Given the BIC change is already part of 4.14.6 i'd say we just ignore it, 
> > it's not like anyone cares for that symbol, right?
> 
> Luigi Toscano wrote:
> Is it already out? If not, no way to skip 4.14.6 or mark it as "don't use 
> it" for distributions (or tell them to ship the patches)?
> I would vote for that.
> (for sure the revert should be introduced in frameworks before 5.8; a 
> BIC-incompatible version was never released)
> 
> Albert Astals Cid wrote:
> Yes https://www.kde.org/announcements/announce-applications-14.12.3.php

Right; I think we could still advertise the issue, the patch which solves it 
and have a fixed 4.14.7. Just saying.


- Luigi


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


On March 4, 2015, 6:26 p.m., Andrea Iacovitti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122812/
> ---
> 
> (Updated March 4, 2015, 6:26 p.m.)
> 
> 
> Review request for kdelibs and Albert Astals Cid.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> First of all sorry for that!
> In commit c2046dd7064634d4d6ba50cafd8b1047bd133859 I introduced a BIC by 
> renaming public DOMString::trimSpaces() to DOMString::parsedUrl().
> However AFICT trimSpaces() was only used internally by khtml.
> I can either revert the commit or apply this patch that reinstate old 
> DOMString::trimSpaces() and mark it as deprecated.
> 
> 
> Diffs
> -
> 
>   khtml/dom/dom_string.h 087f697 
>   khtml/dom/dom_string.cpp a3c4abd 
> 
> Diff: https://git.reviewboard.kde.org/r/122812/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrea Iacovitti
> 
>

Re: Review Request 122652: Use correct default value when UDS_ACCESS/UDS_FILE_TYPE is not set

[Luigi Toscano]

> On Feb. 25, 2015, 6:57 p.m., Mark Gaiser wrote:
> > I "think" this is OK, but just don't know.
> > 
> > Anyway, your diff is for kdelibs (KDE SC 4.xx). I don't know if that gets 
> > another release. Either way, KIO frameworks [1] is where this should be 
> > applied to when you get a ship it.
> > [1] http://quickgit.kde.org/?p=kio.git
> 
> Luigi Toscano wrote:
> kdelibs 4.14 still receives fixes and it's released with KDE Applications 
> (at least as long as we have kdelibs4-based applications). So, if it fixes a 
> bug, it can go in.
> Of course it should be forward-ported to KIO Framework if it is still 
> relevant there.
> 
> Stefan Brüns wrote:
> So shall I commit this (and https://git.reviewboard.kde.org/r/122653/ as 
> well)?
> 
> AFAIK next Applications release is due in short time.
> 
> Will of course forward port to KF5
> 
> Stefan Brüns wrote:
> I am still waiting for a ship it. Patch applies cleanly to KF5 kio ...

Sorry, but I'm not the one who can give a "Ship it" on this. As this is also a 
bug fix for the kio framework, I would add the kdeframeworks group and the kio 
maintainer (dfaure) to the review.


- Luigi


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


On Feb. 20, 2015, 10:28 p.m., Stefan Brüns wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122652/
> ---
> 
> (Updated Feb. 20, 2015, 10:28 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Bugs: 339193
> http://bugs.kde.org/show_bug.cgi?id=339193
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> The default value for UDSEntry::numberValue(...) is 0, whereas KFileItem
> uses the special value KFileItem::Unknown == (mode_t) -1.
> 
> CCBUG: 339193
> 
> 
> Diffs
> -
> 
>   kio/kio/kfileitem.cpp f431d3608cfe646fb882365921e694af8ff8838f 
> 
> Diff: https://git.reviewboard.kde.org/r/122652/diff/
> 
> 
> Testing
> ---
> 
> dolphin remote:
> -> no lock icon on smb:, mtp:, ... links
> 
> 
> Thanks,
> 
> Stefan Brüns
> 
>

Re: Review Request 122987: Allow user to specify path to myspell dictionary files

[Luigi Toscano]

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


(not entitled to give a ship it, but) have you checked if this is still 
relevant for the Sonnet framework?

- Luigi Toscano


On March 17, 2015, 1:22 p.m., Eugene Shalygin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122987/
> ---
> 
> (Updated March 17, 2015, 1:22 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Repository: sonnet
> 
> 
> Description
> ---
> 
> Not on all systems myspell dictionaries are located in 
> /usr/share/myspell/dicts/,  which is hardcoded in the hunspell plugin 
> sources. For instance, on Gentoo it is /usr/share/myspell/. So let the user 
> define this path.
> 
> 
> Diffs
> -
> 
>   src/plugins/hunspell/CMakeLists.txt 098fb49 
>   src/plugins/hunspell/hunspell-plugin-conf.h.cmake PRE-CREATION 
>   src/plugins/hunspell/hunspellclient.cpp 9e3aa67 
>   src/plugins/hunspell/hunspelldict.cpp 621113d 
> 
> Diff: https://git.reviewboard.kde.org/r/122987/diff/
> 
> 
> Testing
> ---
> 
> hunspell plugin began to work on Gentoo
> 
> 
> Thanks,
> 
> Eugene Shalygin
> 
>

Re: Review Request 122987: Allow user to specify path to myspell dictionary files

[Luigi Toscano]

> On March 17, 2015, 1:41 p.m., Luigi Toscano wrote:
> > (not entitled to give a ship it, but) have you checked if this is still 
> > relevant for the Sonnet framework?

Ups, this review is for sonnet; I was confused by the group (please use 
kdeframeworks instead of kdelibs for Frameworks-related reviews)


- Luigi


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


On March 17, 2015, 1:22 p.m., Eugene Shalygin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122987/
> ---
> 
> (Updated March 17, 2015, 1:22 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Repository: sonnet
> 
> 
> Description
> ---
> 
> Not on all systems myspell dictionaries are located in 
> /usr/share/myspell/dicts/,  which is hardcoded in the hunspell plugin 
> sources. For instance, on Gentoo it is /usr/share/myspell/. So let the user 
> define this path.
> 
> 
> Diffs
> -
> 
>   src/plugins/hunspell/CMakeLists.txt 098fb49 
>   src/plugins/hunspell/hunspell-plugin-conf.h.cmake PRE-CREATION 
>   src/plugins/hunspell/hunspellclient.cpp 9e3aa67 
>   src/plugins/hunspell/hunspelldict.cpp 621113d 
> 
> Diff: https://git.reviewboard.kde.org/r/122987/diff/
> 
> 
> Testing
> ---
> 
> hunspell plugin began to work on Gentoo
> 
> 
> Thanks,
> 
> Eugene Shalygin
> 
>

Re: GCompris in kdereview

[Luigi Toscano]

On Monday 30 of March 2015 11:56:13 Luca Beltrame wrote:
> Bruno Coudoin wrote:
> > As we cannot have a translated stable branch and we need to
> 
> Perhaps naive question: why?

I think temporarily as they are in kdereview. We never had a stable branch for 
kdereview, maybe because it was meant for applications moving from the "new 
program with no regular releases" to "regular releases, either in SC or on 
their own in extragear".

If this is true, now we have a kitchen and egg problem :)

Question for GCompris developers: do you plan to stop working on the current 
stable branch (master), which means no releases from it, and merging devel 
into it, soon? This would solve the problem (up-to-date translatable master, 
end of review, move to extragear, regular releases, stable translation branch, 
profit).

Ciao
-- 
Luigi

Re: Moving KDots to KDE Review

[Luigi Toscano]

Minh Ngo ha scritto:
> Hi folks,
> 
> I would like to move my project [1] to KDE Reviews and receive some feedback
> to make it become a part of the KDEGames project in prospect.
> 
> According to the wiki article [2] I have to contact with sysadmins and post
> this message in this mail list.

Few points from i18n point of view:
- do you plan other kdelibs4-based versions?
- related to the previous question: can you please fix the i18n branches from
projects.kde.org? If the current master is KF5-based, as it seems, and you
don't plan other kdelibs4 versions, please set trunk_kf5 to master and the
other fields to none.

Ciao
-- 
Luigi

Re: Distros and QtWebEngine

[Luigi Toscano]

Jan Kundrát ha scritto:
> On Monday, 20 April 2015 21:14:51 CEST, Sune Vuorela wrote:
>> And Red Hat is following Fedora.
> 
> RHEL might not be a good example here because they are a rather a strange
> beast. RHEL has actually never shipped QtWebKit (!) and they also aren't
> shipping Qt5 so far.

Just my guess, as I'm not involved in the operating system, but Qt5 was not
stable enough (and no applications) when RHEL7 was frozen.

As for QtWebKit, problem of maintainability (count the CVE).

Ciao
-- 
Luigi

Re: Distros and QtWebEngine

[Luigi Toscano]

Albert Astals Cid ha scritto:
> El Dilluns, 20 d'abril de 2015, a les 15:52:12, Lisandro Damián Nicanor Pérez 
> Meyer va escriure:
> 
>> I could also say that Fedora+Debian+Debian derivatives (Ubuntu is mostly in
>> the same position as us) is also a large userbase for KDE to loose.
>>
>> But *it's not really* about which distro or app is going to loose more user
>> base, it's about keeping the current one. I don't want Debian nor KDE to
>> loose users, in the same way I do not want to ship something that's
>> unmaintainable.
> 
> Maybe you guys should just trust the Qt project to maintain QtWebEngine and 
> just run with what they provide instead of needing 3 people to "maintain" it 
> yourselves?

Qt project can maintain their bits, sure. Are they looking "inside" the big
block, or do they import the core engine as it is? If the latter, well, it's
not that simple as trusting them.


> 
> What's wrong with that besides it going against your rules?

The rules are there not because someone wants to have unhappy users; think
about the rule about untangling tons of embedded libraries and patching issues.

> 
> That you need to provide longer maintaince times than what Qt upstream 
> provides?
> 
> Just state that there's no such long maintaince time for that package or just 
> install the newer version of Qt. And yes again that probably goes against 
> your 
> rules, but it's your rules, so you can just improve them for everyone's 
> benefit :)

Even Firefox ended up providing an yearly stable release for make it easier,
and it's not an hard dependency (and they don't even provide a stable API).


That said, let's talk for a moment on real use cases: how many applications
can need an *hard* dependency on the beast, apart from mail apps?

Ciao
-- 
Luigi

Re: Distros and QtWebEngine

[Luigi Toscano]

Milian Wolff ha scritto:
> I'm not a KDE PIM maintainer, but with my KDevelop hat 
> on (that uses a web view to display documentation pages, currently QtWebKit), 

kio_man uses khtml (why don't you use it)? But anyway, also khtml is
deprecated. On the other side, the html for manpages is pretty basic, and we
control the generation - are we sure it can't work with QText* things?
Same thing for khelpcenter, I can fix the generated html.
I think that sometime the full blown html viewer has been abused, hence my
question.

Ciao
-- 
Luigi

Re: Review Request 123458: Improvements to the handling of font weights and styles

[Luigi Toscano]

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


I think this should go to Qt (I think it's quite difficult they will accept it, 
as Qt4 is in hard freeze mode), and they will probably ask to see if it applies 
to Qt5 as well.
We just mirror Qt... not sure how to handle this.

- Luigi Toscano


On April 22, 2015, 12:06 a.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123458/
> ---
> 
> (Updated April 22, 2015, 12:06 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X and Qt KDE.
> 
> 
> Repository: qt
> 
> 
> Description
> ---
> 
> Handling of and support for less common font weight/style combinations is far 
> from ideal on OS X but not perfect on Linux either. It is not difficult to 
> run into typefaces that will not be restored properly from settings files for 
> instance, because QFont(family,weight,style) and other methods to obtain a 
> QFont from a font description do not return the appropriate font.
> This is especially the case on OS X where the code makes the assumption in at 
> least two locations that anything that isn't "Normal" is "Bold". In other 
> places, including generic code, parsers apply overly course numberic weight 
> classifications or fail to consider weights like "Medium", "Semibold", 
> "Regular", "Roman" etc. (and return a fall-back weight: Normal).
> Among the font families that are affected there are als common fonts like 
> Segoe UI and Helvetica Neue (UI fonts on MS Windows and OS X 10.10+). NB: 
> medium/semi-/demi-bold weights are perfect in UIs on high-resolution screens.
> 
> The proposed patch improves the code by adding additional checks against 
> style names and weights. The changes are not only to Mac-specific files so 
> Linux benefits from this too (and other platforms ought to, as well).
> 
> I'm putting it up for review on here mainly for lack of time to figure out 
> why I failed to get in onto Qt's own code review site. It may appear there 
> too, but if not:
> 
> I herewith put the attached code changes in the public domain, for possible 
> inclusion into the Qt 4.x codebase under the license that governs that 
> software.
> 
> 
> Diffs
> -
> 
>   src/gui/dialogs/qfontdialog.cpp d791462 
>   src/gui/dialogs/qfontdialog_mac.mm d557a7a 
>   src/gui/kernel/qt_mac.cpp fb241ce 
>   src/gui/text/qfontdatabase.cpp 4c2ace4 
>   src/gui/text/qfontdatabase_mac.cpp 816a7bd 
>   src/gui/text/qfontengine_coretext.mm 204d685 
>   src/plugins/platforms/fontdatabases/coretext/qcoretextfontdatabase.mm 
> 312015f 
>   tools/qtconfig/mainwindow.cpp 1bb6e4e 
> 
> Diff: https://git.reviewboard.kde.org/r/123458/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 and Kubuntu 14.04.2 against Qt 4.8.7 with the qtconfig utility 
> and the attached test application
> 
> 
> File Attachments
> 
> 
> fontweight issue test application
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/bbebc0af-e457-4fdf-965c-3918d8e871d0__fontweightissue.pro
> fontweight issue test application
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/cfdcbf23-406a-4abf-b0cb-5fdc1957dfe9__main.cpp
> fontweight issue test application
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/9898afae-82ca-4c92-b7d9-5607d0dd8e24__dialog.h
> fontweight issue test application
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/8ad258bf-7f82-4db4-a344-ce81d75e8c50__dialog.cpp
> fontweight issue test application
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/2f0a7c6e-4601-406e-b703-603a36bff62b__fontweightissue.desktop
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 123458: Improvements to the handling of font weights and styles

[Luigi Toscano]

> On April 22, 2015, 12:40 a.m., Luigi Toscano wrote:
> > I think this should go to Qt (I think it's quite difficult they will accept 
> > it, as Qt4 is in hard freeze mode), and they will probably ask to see if it 
> > applies to Qt5 as well.
> > We just mirror Qt... not sure how to handle this.

Yes, I know you wrote that it should go to Qt, just stating that I'm not sure 
how to handle this patch in our Qt mirrors.


- Luigi


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


On April 22, 2015, 12:06 a.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123458/
> ---
> 
> (Updated April 22, 2015, 12:06 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X and Qt KDE.
> 
> 
> Repository: qt
> 
> 
> Description
> ---
> 
> Handling of and support for less common font weight/style combinations is far 
> from ideal on OS X but not perfect on Linux either. It is not difficult to 
> run into typefaces that will not be restored properly from settings files for 
> instance, because QFont(family,weight,style) and other methods to obtain a 
> QFont from a font description do not return the appropriate font.
> This is especially the case on OS X where the code makes the assumption in at 
> least two locations that anything that isn't "Normal" is "Bold". In other 
> places, including generic code, parsers apply overly course numberic weight 
> classifications or fail to consider weights like "Medium", "Semibold", 
> "Regular", "Roman" etc. (and return a fall-back weight: Normal).
> Among the font families that are affected there are als common fonts like 
> Segoe UI and Helvetica Neue (UI fonts on MS Windows and OS X 10.10+). NB: 
> medium/semi-/demi-bold weights are perfect in UIs on high-resolution screens.
> 
> The proposed patch improves the code by adding additional checks against 
> style names and weights. The changes are not only to Mac-specific files so 
> Linux benefits from this too (and other platforms ought to, as well).
> 
> I'm putting it up for review on here mainly for lack of time to figure out 
> why I failed to get in onto Qt's own code review site. It may appear there 
> too, but if not:
> 
> I herewith put the attached code changes in the public domain, for possible 
> inclusion into the Qt 4.x codebase under the license that governs that 
> software.
> 
> 
> Diffs
> -
> 
>   src/gui/dialogs/qfontdialog.cpp d791462 
>   src/gui/dialogs/qfontdialog_mac.mm d557a7a 
>   src/gui/kernel/qt_mac.cpp fb241ce 
>   src/gui/text/qfontdatabase.cpp 4c2ace4 
>   src/gui/text/qfontdatabase_mac.cpp 816a7bd 
>   src/gui/text/qfontengine_coretext.mm 204d685 
>   src/plugins/platforms/fontdatabases/coretext/qcoretextfontdatabase.mm 
> 312015f 
>   tools/qtconfig/mainwindow.cpp 1bb6e4e 
> 
> Diff: https://git.reviewboard.kde.org/r/123458/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 and Kubuntu 14.04.2 against Qt 4.8.7 with the qtconfig utility 
> and the attached test application
> 
> 
> File Attachments
> 
> 
> fontweight issue test application
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/bbebc0af-e457-4fdf-965c-3918d8e871d0__fontweightissue.pro
> fontweight issue test application
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/cfdcbf23-406a-4abf-b0cb-5fdc1957dfe9__main.cpp
> fontweight issue test application
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/9898afae-82ca-4c92-b7d9-5607d0dd8e24__dialog.h
> fontweight issue test application
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/8ad258bf-7f82-4db4-a344-ce81d75e8c50__dialog.cpp
> fontweight issue test application
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/2f0a7c6e-4601-406e-b703-603a36bff62b__fontweightissue.desktop
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: kwallet-query moved to kdereview

[Luigi Toscano]

Valentin Rusu ha scritto:
> * Allen Winter  [2015-04-23 17:32:32 -0400]:
> 
>> On Thursday, April 23, 2015 10:25:20 PM Valentin Rusu wrote:
>>> This is a rather simple script and I think it should go to kde-utils.
>>> I'd like to write a manpage for it, buy AFAICT that's not the KDE way of
>>> doing it. 
>>
>> But it is the old-timer way of doing it and I would very much appreciate a 
>> manpage.
> 
> I'd also like very much adding it. Can I use asciidoc for that?
> 

We use DocBook for manpages as well. They are converted by a kdoctools macro
during compilation time.
No specific tool, but you can take inspiration from other manpages (ark,
khangman, etc).

Ciao
-- 
Luigi

Re: kwallet-query moved to kdereview

[Luigi Toscano]

Valentin Rusu ha scritto:

> The kwallet-query tool is now part of KF5::Wallet. I'll now request
> kdereview/kwallet-query repository removal.

src/runtime/kwallet-query/src/querydriver.cpp:153:47: error: ‘class
QByteArray’ has no member named ‘toStdString’
 std::cout << QJsonDocument(json).toJson().toStdString() << std::endl;

Testing on Qt 5.3; as Frameworks is supposed to work with Qt 5.2, can you
please fix it?

Ciao
-- 
Luigi

Re: Frameworks compiler and Qt requirements after Qt 5.7?

[Luigi Toscano]

On Friday 26 of June 2015 16:24:50 Mark Gaiser wrote:
> Hi,
> 
> If Qt's plans progress according to what they post on the mailinglist then
> Qt 5.6 will be LTS, 5.7 will up the compiler requirements to the following:
> 
> GCC 4.7
> Clang 3.2
> MSVC 2012
> 
> Framework currently requires:
> GCC 4.5
> Clang 3.1
> MSVC 2012
> 
> When frameworks started it had slightly less strict compiler requirements
> then Qt had. But now that Qt is upping the compiler requirement, we should
> follow as well. In fact, we should probably also update the Qt version
> requirement which right now is at 5.2.
> 
> I have no clue when Qt 5.7 will be released, but i'm guessing around this
> time next year. Frameworks currently is at version 5.11 (5.12 coming up).
> If we add a year to that then frameworks is at version 5.24 when Qt 5.7 is
> released (big guess!). So why don't we change our requirements starting
> with frameworks 5.25 (nice number as well)? I'd propose changing it to the
> following:
> 
> Qt 5.7 minimal requirement
> GCC 5.1 (or somewhere in 5.x)
> Clang 3.6.1 (or perhaps even 3.7)
> MSVC 2015

Even if we change the required version of Qt, why would we need to increase 
the compiler requirements? I think that if we decide to go this way, we should 
follow the same route: Qt requirements for Frameworks.
That said, I think that bumping the minimum required versions of a specific Qt 
version immediately after its release would be a bit too much.

Ciao
-- 
Luigi

Re: Moving akonadi from kdesupport and akonadi-search from playground

[Luigi Toscano]

Daniel Vrátil ha scritto:
> Hi all,
> 
> we (the KDE PIM team) kinda screwed up when we forgot to communicate our
> intentions about
> next KDE PIM release with the release team and we ended up in a situation that
> we have
> some repositories in modules from which they cannot be released as part of KDE
> Applications,
> so releasing KF5-based KDE PIM as part of KDE Applications is currently
> endangered.

I have a related question about this (sorry for hijacking the thread), but as
I'm moving translations around...
- do you mean do you want to move those to modules to kdepim?
- do we need all kdepim, kdepim-runtime, kdepimlibs AND kde/pim?

Ciao
-- 
Luigi

Re: [kdelibs/KDE/4.14] cmake/modules: Remove policy settings from FindKDE4Internal.

[Luigi Toscano]

Allen Winter ha scritto:
> Stephen,
> 
> For years I have passed -DKDE4_ENABLE_HTMLHANDBOOK=1 to cmake when building 
> KDE projects.
> As of today I get this error:
> 
> CMake Error at cmake/modules/KDE4Macros.cmake:315 (add_custom_target):
>   add_custom_target cannot create target "htmlhandbook" because another
>   target with the same name already exists.  The existing target is a custom
>   target created in source directory
>   "/data/mykde/src/KDE/kdelibs/doc/kioslave/data".  See documentation for
>   policy CMP0002 for more details.
> Call Stack (most recent call first):
>   doc/kioslave/file/CMakeLists.txt:2 (kde4_create_handbook)
> 
> As I recall, KDE4_ENABLE_HTMLHANDBOOK automagically created the html versions 
> of the handbooks
> which I found quite handy.  In any event, should I stop passing variable now? 
> or is this something you can fix?
> 

Maybe it could be the same issue fixed in kdoctools (but I think never
backported):

https://git.reviewboard.kde.org/r/116650/
http://quickgit.kde.org/?p=kdoctools.git&a=commit&h=8aad0fb7aaa3bbb9da8801d2d12f3396f74569d5

Does it look the same?

Ciao
-- 
Luigi

Re: Moving akonadi from kdesupport and akonadi-search from playground

[Luigi Toscano]

laurent Montel ha scritto:
> Le Monday 20 July 2015, 22:58:39 Luigi Toscano a écrit :
>> Daniel Vrátil ha scritto:
>>> Hi all,
>>>
>>> we (the KDE PIM team) kinda screwed up when we forgot to communicate our
>>> intentions about
>>> next KDE PIM release with the release team and we ended up in a situation
>>> that we have
>>> some repositories in modules from which they cannot be released as part of
>>> KDE Applications,
>>> so releasing KF5-based KDE PIM as part of KDE Applications is currently
>>> endangered.
>>
>> I have a related question about this (sorry for hijacking the thread), but
>> as I'm moving translations around...
>> - do you mean do you want to move those to modules to kdepim?
> 
> We don't want to merge it in kdepim
> We want to move in "KDE/" .
Dan confirmed that the destination module is the pim/ module/namespace.

> 
>> - do we need all kdepim, kdepim-runtime, kdepimlibs AND kde/pim?
> 
> For what ?

For the release :)

Ciao
-- 
Luigi

Notes from the Phabricator BoF

[Luigi Toscano]

Hi all,
thanks to Victor Blazquez, here are the notes from the Phabricator BoF. Feel 
free to add your comments and corrections.


Feedback on Phabricator gathered outside the BoF from people who could not 
attend:
-

krita
used for everything (reviews, tasks, mockups, even bugs);
overwelmingly positive feedback from community
- annoyance: big unified list of projects; confusing

akonadinext
used reviews, tasks; prefer tasks separate from bugs
used internally in company too; also used sprint module
- problem: in case of tasks coming from company phabricator and KDE
  phabricator, the line which reference the commit message will clash
  (same Tx), a different prefix is needed 
  -> (ervin said it's not a problem), as you could use the full URL of the
 task instead of just the task ID in the commit message.
- annoyance: few rendering/usability bugs in the kanboard view
 with many tasks

tanglu
phabricator developers responsive
thousands of projects handled in tanglu (no repositories yet)
- problem: fast development can be a problem for updates (no real 
  stable branch)

Positive feedback from Ivan (kactivities)
Positive feedback from Eike (konversation)


BoF
-

Remove login form which is not LDAP
- Change message and write something like "Authenticate through 
identity.kde.org"
Uses of maniphest vs bugzilla
- No migration for now (not the foreseeable future)
Projects hierarchy (https://secure.phabricator.com/T3670)
Custom view and notifications for groups 
- Dashboards
- Share queries inside a group (check later)
Can we push a patch through the webpage? (keep an eye on upstream)
Do we want to reuse our CI system? 
https://wiki.jenkins-ci.org/display/JENKINS/Phabricator+Plugin
When a new review is posted, trigger the CI, it needs some changes to the CI
Lack of integration with CI is not a blocker
Suggestion: It would be nice not need to test every patch (CI), to be 
discussed

Support for arcanist is available for other plaftorms (Windows, MacOSx)

Good feedback in general from the people who assisted

Ciao
-- 
Luigi

Re: Notes from the Phabricator BoF

[Luigi Toscano]

Il 30 luglio 2015 22:42:44 CEST, Kevin Kofler  ha 
scritto:
> Luigi Toscano wrote:
> > Feedback on Phabricator gathered outside the BoF from people who
> could not
> > attend:
> 
> Were there no complaints about the fact that you can still not view
> anything 
> at all without logging in?

No. I did not ask sysadmins, but I guess it's just an implementation details in 
the experimental phase. Other Phabricator instances are widely open; there is a 
good ACL system.

Ciao

-- 
Luigi

Re: Plasma Applet for Audio Volume for kdereview

[Luigi Toscano]

Jonathan Riddell ha scritto:
> plasma-pa is a new volume manager and is intended to be a replacement for 
> KMix in Plasma.
> 
> We plan to ship it as a beta in Plasma 5.4 and it's currently in kdereview 
> for your reviewing attention.
> 
> https://projects.kde.org/projects/kdereview/plasma-pa
> 
> Please check over it and consider if it passes review.

No documentation?

Ciao
-- 
Luigi

Review Request 124657: Show URL again in bookmarks view and URL texbox

[Luigi Toscano]

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

Review request for KDE Base Apps.


Repository: kde-baseapps


Description
---

Fix two KUrl porting TODO items. Thanks to the porting notes!
The URL of the bookmark was not shown because the value was not
passed to the treeview/table model and to the textbox.


Diffs
-

  keditbookmarks/bookmarkinfowidget.cpp 98ce303 
  keditbookmarks/kbookmarkmodel/model.cpp e949469 

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


Testing
---

Compiled, executed the bookmark editor. Added and changed few bookmarks, the 
URL is correctly updated.


Thanks,

Luigi Toscano

Re: Review Request 124657: Show URL again in bookmarks view and URL texbox

[Luigi Toscano]

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

(Updated Aug. 8, 2015, 1:51 a.m.)


Review request for KDE Base Apps.


Changes
---

(Maybe) better way to build the URL


Repository: kde-baseapps


Description
---

Fix two KUrl porting TODO items. Thanks to the porting notes!
The URL of the bookmark was not shown because the value was not
passed to the treeview/table model and to the textbox.


Diffs (updated)
-

  keditbookmarks/bookmarkinfowidget.cpp 98ce303 
  keditbookmarks/kbookmarkmodel/model.cpp e949469 

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


Testing
---

Compiled, executed the bookmark editor. Added and changed few bookmarks, the 
URL is correctly updated.


Thanks,

Luigi Toscano

Re: Review Request 124657: Show URL again in bookmarks view and URL texbox

[Luigi Toscano]

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

(Updated Aug. 8, 2015, 11:47 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Base Apps and David Faure.


Changes
---

Submitted with commit 64e8b30cf24623c52595efca3f57bc776c5ca188 by Luigi Toscano 
to branch frameworks.


Repository: kde-baseapps


Description
---

Fix two KUrl porting TODO items. Thanks to the porting notes!
The URL of the bookmark was not shown because the value was not
passed to the treeview/table model and to the textbox.


Diffs
-

  keditbookmarks/bookmarkinfowidget.cpp 98ce303 
  keditbookmarks/kbookmarkmodel/model.cpp e949469 

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


Testing
---

Compiled, executed the bookmark editor. Added and changed few bookmarks, the 
URL is correctly updated.


Thanks,

Luigi Toscano

Re: Review Request 122556: Bump Qt version to 5.4

[Luigi Toscano]

> On Ago. 9, 2015, 3:33 p.m., Nikita Skovoroda wrote:
> > What's the status of this?
> > Dolphin (and maybe some other apps) already depends on 5.4.
> 
> Nikita Skovoroda wrote:
> Plasma and Kwin require Qt 5.4 since Plasma 5.3.0 release, btw.

Plasma (and Kwin, which is part of Plasma) are not relevant for this review, as 
they are a different product than KDE Applications.

On the other side, the fact that some applications (Dolphin) require Qt 5.4 is 
relevant (and the fact that this review is 5 months old and Qt 5.4 is now 
widely available too). Also, as Frank pointed out, kde-baseapps is still 
releaseing from a kdelibs4-based master branch, so this dependency will apply 
not before KDE Applications 15.12.


- Luigi


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


On Feb. 13, 2015, 9:06 a.m., Arjun AK wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122556/
> ---
> 
> (Updated Feb. 13, 2015, 9:06 a.m.)
> 
> 
> Review request for KDE Base Apps.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> ---
> 
> `QUrl::fromUserInput(userInput, workingDirectory, UserInputResolutionOptions 
> options)` seems to be Qt 5.4+. We either need to bump requirement to 5.4 or 
> do what kompare 
> [did](https://projects.kde.org/projects/kde/kdesdk/kompare/repository/revisions/master/entry/libdialogpages/diffpage.cpp#L45)
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 6df9015 
> 
> Diff: https://git.reviewboard.kde.org/r/122556/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Arjun AK
> 
>

Re: Updating our tools

[Luigi Toscano]

Michael Pyne ha scritto:
> On Sun, August 9, 2015 09:58:26 Allen Winter wrote:
>> On Sunday, August 09, 2015 09:35:06 PM Ben Cooksley wrote:
>>> On Sun, Aug 9, 2015 at 3:15 AM, Allen Winter  wrote:
 On Saturday, August 08, 2015 04:59:49 PM Elvis Angelaccio wrote:
> Sorry to bump this old thread, but it looks like Krazy still complains
> about kdelibs4 errors even if an application is now KF5 based.
> For instance consider again Kanagram:
> http://ebn.kde.org/krazy/reports/kde-4.x/kdeedu/kanagram/index.html
>
> Am I missing something? Is there another page showing KF5-related
> issues
> for KF5-ready apps?

 If Krazy is running in the kde-4.x component, then it does use the KDE4
 checkers.

 For now, Krazy only knows its looking at KF5 code if it's running in the
 frameworks 5 component in
 http://ebn.kde.org/krazy/index.php?component=frameworks&module=framewor
 ks5

 I don't see kanagram listed in the frameworks5 component.

 The KDE projects also lists kanagram in kde-4.x only, as far as I can
 tell.
 So first step is to get kanagram listed as a frameworks project.
>>>
>>> To my knowledge there isn't anything on projects.kde.org which states
>>> a project is kde-4.x only. Where is this information coming from?
>>
>> the projects db
>>
>> I see that kanagram master is kf5 based but is not part of frameworks.
>> therefore I will need to invent a way to detect that a project is kf5 based.
>> do we have an easy way to detect kde4 vs. kf5 projects?
> 
> The only way I'm aware of is to use the kde-build-metadata/logical-module-
> structure metadata (this is used by kdesrc-build and the CI). This is much 
> more annoying than a simple lookup but there are at least a couple of tools 
> in 
> kde-build-metadata that can be used to help.
> 
> I believe i18n tracks the 'unstable' and 'stable' branches for each module 
> and 
> 'unstable' might mean "KF5" by now. This information *is* available with the 
> project data directly. But maybe Albert or Luigi could better explain how the 
> i18n infra is setup and what we can conclude from these variables.

We track four branches (information available from kde_projects.xml):
stable/kdelibs4
trunk/kdelibs4
stable/kf5
trunk/kf5

We don't use them directly, but we keep our metadata in sync with them. Yes,
that could be done in better way; but we can't consume the information
directly from projects.k.o because a wrong/outdated information leads to
wrongly tracked messages (and maintainer sometime forget to update them).


Ciao
-- 
Luigi

Documentation (was Re: Plasma Applet for Audio Volume for kdereview)

[Luigi Toscano]

On Wednesday 12 of August 2015 10:05:34 Sebastian Kügler wrote:
> Also, the Evolve survey was pretty clear that we utterly suck in the
> documentation arena. Playing with words doesn't solve that, writing
> documentation and maintaining it does.
> 
> We may change the rules, and that's perhaps what we should do, but that
> doesn't begin with "let's ship a new module without docbook", that should
> begin with a cunning plan to move to online docs, the wiki, etc. and
> integrate that into the help function of applications. Right now the help
> button is a sort-of catch22, docs are usually useless, so I don't see the
> necessity to write them, so they're more useless (or not present).

I've seen many review requests from Burkhard to review tons of documentation. 
He is doing a big work on many modules (few applications receives some hel p 
from the maintainers).
Thanks to maintainers who checked and approved the reviews, but I didn't see 
any request for changing them or updating them before this effort, regardless 
of the format (reading the generated documentation is possible without dealing 
with DocBook).

If you think that the documentation is useless, please report it, just for any 
bug. I don't see why it can't be improved, again regardless of the format. 
Even without thinking about future formats, a simple document in any format 
with the updates is always more than welcome.

About the format, personally speaking, a system which relies only on online 
docs is not going to work, both ways should be possible (offline and online).

> 
> Anyway, discussion in this thread is moot, since I've committed a docbook
> which is hopefully helpful for those who know to find it.
So let's change the thread.

Ciao
-- 
Luigi

Re: Using nullptr instead of Q_NULLPTR

[Luigi Toscano]

On Thursday 13 of August 2015 12:59:01 Ivan Čukić wrote:
> >> I prefer the first option, it's the way forward and if someone was using
> > 
> > I'd say that requiring a newer gcc just like that would go against the
> > nature of the KF5 project.
> 
> I don't really see why it is "against the nature of KF5". It would not
> be the first time we require a higher compiler version than the one
> required by the Qt version we require.

But then we need a clear agreement.

I don't care about proprietary compilers whose version released two years ago 
does not support extensions supported for years already by FLOSS compilers. 
What I don't like in this story is that we set up a rule, an promise with 
users, which was broken and now it's like it does not matter.

> 
> Qt 5.5 requires gcc 4.8 for linux and windows. So even they increment
> the versions from time to time.
> 
> We can switch everything to Q_NULLPTR even without anyone complaining
> about it, but we will have to switch back in a few releases.

But we are not there in those few releases, which could be months away. The 
things to do is follow the rule and revert the changes, and then *after* 
change the rule. IMHO.

Ciao
-- 
Luigi

Re: Using nullptr instead of Q_NULLPTR

[Luigi Toscano]

On Thursday 13 of August 2015 15:01:16 Ivan Čukić wrote:
> > What I don't like in this story is that we set up a rule, an promise with
> > users, which was broken and now it's like it does not matter.
> 
> Yes, we did set up the rule requirements for gcc 4.5 and MSVC10 back in
> 2013.
> 
> Since then, we broke the rule and increased to MSVC11 (VS2012).
> 
> Now, we can increase, if we want to, the gcc requirement to 4.6.
> 
> If you think that the additional work of writing a patch, then
> increasing the compiler version requirement, and then reverting the
> patch is warranted, it is fine by me.
> 
> As Lamarque pointed out, gcc 4.6 is required for Qt 5.1. KF5 requires
> Qt 5.3. If someone is able to compile Qt, he will be able to compile
> KF5 - I guess that is the reason this issue has passed unnoticed for
> this long.

I apologize, I mixed up two different emails that came today on a similar 
topic. There is nothing to discuss on this, given the requirement of Qt 5.1. 
Please take a look also at "Minimum supported version of MSVC for frameworks" 
on kde-frameworks-devel. 

Ciao
-- 
Luigi

Re: Proposal to improving KDE Software Repository Organization

[Luigi Toscano]

David Faure ha scritto:
> On Sunday 16 August 2015 13:51:29 Michael Pyne wrote:
>> There's no reason even with our current build metadata that we'd *have* to 
>> have project hierarchies, as long as each underlying git repository name 
>> remains unique. It might even make things easier since there would be no way 
>> for a sub-path in our project hierarchy (such as kde/kdelibs/kactivities) to 
>> mask a git repository name (kdelibs in this case).
> 
> Ben and I discussed it today and we think there is usefulness in one level of 
> subtree within the
> Applications product, to be able to keep the 'groups' like kdegraphics, 
> kdemultimedia etc. which
> are useful in order to have a maintainer per 'group' (as reinforced by the 
> release team recently).
> 
> But yes, only one level, and AFAICS only useful in Applications.
> kactivities (to pick your example) would be "at the root of" Frameworks, no 
> sub-path needed.
> 
Does it mean a giant big blob for extragear and playground? Translation-wise,
having the 'groups' is really useful to not get lost.

Also, when phabricator support subproject, using groups would be useful again
to not have a big blob of projects (it was one of the few complains I recorded
for phabricator, the big list of projects).

Ciao
-- 
Luigi

Re: Bringing back rsibreak from unmaintained

[Luigi Toscano]

Jan Kundrát ha scritto:
> On Monday, 17 August 2015 20:04:04 CEST, Albert Astals Cid wrote:
>> Other comments?
> 
> Nice, happy to see it -- it builds here, with a bunch of warnings:
> 
> [2/29] Generating index.cache.bz2
> index.docbook:2: element para: validity error : ID gnu-fdl already defined
> element div: validity error : ID header already defined

Please revert your libxml2 to a previous version:
https://bugzilla.gnome.org/show_bug.cgi?id=737840

Ciao
-- 
Luigi

Re: kdesudo in git

[Luigi Toscano]

On Thursday 20 of August 2015 12:16:55 Jonathan Riddell wrote:
> I've just moved kdesudo into playground
> 
> playground/utils/kdesudo
> 
> it has a bunch of translations from its previous home on Launchpad.
> 
> Could these be imported into KDE please?

Do we really need it? I thought that kdesu can work with sudo if you configure 
it (runtime configuration, even if you can change the default with a compile 
flag).

Ciao
-- 
Luigi

Re: [kde-doc-english] The new data dirs and kf5 docs

[Luigi Toscano]

On Thursday 20 of August 2015 14:46:45 Yuri Chornoivan wrote:
> Hi,
Hi, 
CC: kde-core-devel@ for some help (see below).

> 
> As it was pointed by Burkhard [1], the paths in kf5 docs should be
> updated/fixed to the new configuration.
> 
> The list is rather big now:
> 
> fundamentals/config.docbook
> korganizer
> knotes
> kalarm
> kmail
> konversation
> kate/plugins.docbook
> kgeography
> kwordquiz
> kstars/faq.docbook
> kstars/config.docbook
> kstars/install.docbook
> khangman
> killbots
> ktuberling/technical-reference.docbook
> okteta
> tellico/faqs.docbook
> tellico/fundamentals.docbook
> tellico/configuration.docbook
> kile/inedx.docbook
> kile/usermenu.docbook
> kile/scripting.docbook
> 
> However, it is not clear what environment variables can (or should) be
> used to help user in finding the proper files. In my KDE 4 environment
> some variables are undefined:
> 
> [yurchor@localhost uk]$ printenv|grep XDG
> XDG_VTNR=1
> XDG_SESSION_ID=c1
> XDG_MENU_PREFIX=kde-
> XDG_CONFIG_DIRS=/etc/xdg:/etc/xdg/kde4
> XDG_SEAT=seat0
> XDG_DATA_DIRS=/usr/share:/usr/share:/usr/local/share
> XDG_RUNTIME_DIR=/run/user/500
> XDG_CURRENT_DESKTOP=KDE
> 
> As you can see, there are no XDG_DATA_HOME (default $HOME/.local),
> XDG_CONFIG_HOME (default $HOME/.config) and XDG_CACHE_HOME.
> 
> So,
> 
> 1. Can anybody confirm that all these variables are defined in Plasma 5
> and other modern DEs?
> 
> 2. Are there any objections about usage something like `echo
> ${XDG_DATA_DIRS%%:*}` instead of `kde4-config --install data`? What are
> the possible shortcomings? Does it work for shells other than BASH?

I don't think it's the proper way. I think the solution is to use qtpaths. I 
would ask on the kde-core-devel@ list for more details.

> 
> [1]
> https://techbase.kde.org/Projects/Documentation/KDE_(health_table)#KDE_Frame
> works 

Ciao
-- 
Luigi

Re: kdesudo in git

[Luigi Toscano]

On Thursday 20 of August 2015 11:48:25 Jonathan Riddell wrote:
> On Thu, Aug 20, 2015 at 01:34:42PM +0200, Luigi Toscano wrote:
> > On Thursday 20 of August 2015 12:16:55 Jonathan Riddell wrote:
> > > I've just moved kdesudo into playground
> > > 
> > > playground/utils/kdesudo
> > > 
> > > it has a bunch of translations from its previous home on Launchpad.
> > > 
> > > Could these be imported into KDE please?
> > 
> > Do we really need it? I thought that kdesu can work with sudo if you
> > configure it (runtime configuration, even if you can change the default
> > with a compile flag).
> 
> Alas because of the separation that kdesu has between a backend and a
> frontend it can't work with sudo's password save mechanism and it asks
> for a password every time which gets very annoying.  Arguably we don't
> need it since sudo isn't used much now for GUIs most things use
> policykit but that would need some consultation to work out.

Maybe it's possible to change kdesu to expose a "please cache this" property 
between backend and frontend (in a secure way). Better than keeping two 
programs for exactly the same thing.

Ciao
-- 
Luigi

Re: Review Request 124824: [OS X] FindKDE4Internal.cmake : reintroduce a cmake_minimum_required statement

[Luigi Toscano]

> On Ago. 19, 2015, 8:06 p.m., Stephen Kelly wrote:
> > This patch is not correct. 
> > 
> > What repo were you trying to build? Add cmake_minimum_required(VERSION 
> > 2.8.9) there.
> 
> Stephen Kelly wrote:
> Why did this review go quiet? Did you pull and realize that line was 
> already there in whatever repo you're looking at?
> 
> René J.V. Bertin wrote:
> What, my 2 replies below aren't sufficient? :) If you missed them, that'd 
> probably support of my idea that most KDE devs are focussed away from 
> flogging dead horses (i.e., KDE4 code, to quote one of those devs, a rather 
> "visible" one I won't name).
> 
> No, I didn't pull whatever repo after pulling the 4.14 branch head of one 
> of the KDE PIM components and bumping into this error.

David Faure, durink Akademy, was rebuilding the last kdelibs4 branch for most 
applications, I think to ensure that the changes in the default cmake policy 
did not break them.
He did various fixes, so I think that fixing this in the proper way (which I 
can't help to, sorry) would be good.


- Luigi


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


On Ago. 19, 2015, 7:41 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124824/
> ---
> 
> (Updated Ago. 19, 2015, 7:41 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and kdelibs.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> The recent removal of the code block from FindKDE4Internal.cmake starting 
> with the `cmake_minimum_required` statement breaks configuring on OS X:
> 
> ```
> -- The C compiler identification is AppleClang 6.0.0.657
> -- The CXX compiler identification is AppleClang 6.0.0.657
> -- Check for working C compiler: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> -- Check for working C compiler: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>  -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
> -- Check for working CXX compiler: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
>  -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Looking for Q_WS_X11
> -- Looking for Q_WS_X11 - not found
> -- Looking for Q_WS_WIN
> -- Looking for Q_WS_WIN - not found
> -- Looking for Q_WS_QWS
> -- Looking for Q_WS_QWS - not found
> -- Looking for Q_WS_MAC
> -- Looking for Q_WS_MAC - found
> -- Looking for QT_MAC_USE_COCOA
> -- Looking for QT_MAC_USE_COCOA - found
> -- Found Qt-Version 4.8.7 (using /opt/local/libexec/qt4/bin/qmake)
> -- Looking for include file pthread.h
> -- Looking for include file pthread.h - found
> -- Looking for pthread_create
> -- Looking for pthread_create - found
> -- Found Threads: TRUE  
> CMake Error at /opt/local/share/cmake-3.2/Modules/FindPkgConfig.cmake:112 
> (elseif):
>   given arguments:
> 
> "VERSION_LESS" "3.1"
> 
>   Unknown arguments specified
> Call Stack (most recent call first):
>   /opt/local/share/cmake-3.2/Modules/FindPkgConfig.cmake:501 
> (_pkgconfig_parse_options)
>   /opt/local/share/cmake-3.2/Modules/FindOpenSSL.cmake:43 (pkg_check_modules)
>   /opt/local/share/apps/cmake/modules/Qt4ConfigDependentSettings.cmake:224 
> (FIND_PACKAGE)
>   /opt/local/share/apps/cmake/modules/FindQt4.cmake:1207 (INCLUDE)
>   /opt/local/share/apps/cmake/modules/FindKDE4Internal.cmake:425 
> (find_package)
>   /opt/local/share/cmake-3.2/Modules/FindKDE4.cmake:108 (find_package)
>   CMakeLists.txt:4 (find_package)
> 
> 
> -- Configuring incomplete, errors occurred!
> ```
> 
> The attached patch is the minimum reintroduction of the removed code that 
> allows the cmake procedure to conclude successfully.
> 
> CMake experts might be aware of other ways to address this issue more in line 
> with the reason the block was removed.
> 
> 
> Diffs
> -
> 
>   cmake/modules/FindKDE4Internal.cmake 7d54b9b 
> 
> Diff: https://git.reviewboard.kde.org/r/124824/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with KDELibs 4.14.11 (v4.14.10-20-g150d983) and CMake 3.2.2 .
> 
> The unmodified code from v4.14.10-20-g150d983 is fine on Linux with cmake 
> 3.0.1 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 125043: expose the WheelMouseZooms global setting through the input ("mouse") KCM

[Luigi Toscano]

> On Set. 4, 2015, 3:21 p.m., Thomas Lübking wrote:
> > kcontrol/input/kmousedlg.ui, line 82
> > 
> >
> > You *must* ask the i18n team about this (requires an exception) on 
> > kde-...@kde.org
> > 
> > Since this will have no impact on QTextBrowser (Qt4 or 5) and maybe 
> > some other views in either direction, this limited impact needs to be 
> > somehow lined out (since to a user there's hardly a difference between 
> > QTextBrowser and KTextBrowser)

kde-workspace 4.14? It's still tracked on our i18n branches, but given that the 
last release is out (see 
https://mail.kde.org/pipermail/release-team/2015-August/008835.html), I think 
we will stop tracking that branch soon. (PS: the list is kde-i18n-...@kde.org). 
This is quite dead code at this point...


- Luigi


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


On Set. 4, 2015, 1:51 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125043/
> ---
> 
> (Updated Set. 4, 2015, 1:51 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, kde-workspace and kdelibs.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> KDE4 has been providing a setting that (would have) allowed to avoid unwanted 
> text zooming during simulated inertial scrolling (scroll coasting). KDE PIM 
> applications were immune to that issue because certain KDELibs classes use 
> the parameter, which made it all the more annoying that other (e.g. 
> Kate-based) applications weren't. Sadly this setting wasn't published via a 
> GUI.
> 
> This patch adds a checkbox to the input ("mouse") KCM which seemed like the 
> most appropriate place if not only because it also makes sense to provide 
> this KCM on non-X11 platforms like OS X and MS Windows (where settings like 
> "double or single click" are relevant).
> 
> I consider this a fix of an omission bug, but I realise that it could also be 
> considered a new feature, so this RR is also intended to give some public 
> exposure to my patch rather than keeping it to myself.
> 
> 
> Diffs
> -
> 
>   kcontrol/input/kmousedlg.ui b48a606 
>   kcontrol/input/mouse.h d926a99 
>   kcontrol/input/mouse.cpp cebb174 
> 
> Diff: https://git.reviewboard.kde.org/r/125043/diff/
> 
> 
> Testing
> ---
> 
> For now only on OS X with kdelibs 4.14.11 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 125043: expose the WheelMouseZooms global setting through the input ("mouse") KCM

[Luigi Toscano]

> On Set. 4, 2015, 3:38 p.m., Martin Gräßlin wrote:
> > You are aware that this is a dead repo and that this is a new feature for a 
> > repository that has been feature frozen for years?
> > 
> > Given that I think this should not and never be merged. If you want to keep 
> > the repo going for OSX I suggest to create a branch for your patches.
> 
> René J.V. Bertin wrote:
> As I wrote in the summary, I don't consider this so much a new feature as 
> a fix to an omission because the parameter is used in kdelibs (and possible 
> elsewhere I don't know about). Besides, this concerns a KCM that I think 
> should have been part of kde-runtime (but that's probably a moot point).
> 
> Also, this is not only about OS X. There are several distribution 
> releases that ship KDE4 as the default desktop officially supported LTS 
> version, and I'd hope they too would be interested in upstream fixes. As such 
> I don't see the point in creating another branch, or in maintaining a freeze 
> on a branch that isn't going to see any more releases
> A separate repository with only fixes, organised by project and possibly 
> target platform could make sense though.

I disagree: a separate branch makes definitely more sense than a separate 
repository (which would lead more confusion and divide the code).


- Luigi


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


On Set. 4, 2015, 4:22 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125043/
> ---
> 
> (Updated Set. 4, 2015, 4:22 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, kde-workspace and kdelibs.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> KDE4 has been providing a setting that (would have) allowed to avoid unwanted 
> text zooming during simulated inertial scrolling (scroll coasting). KDE PIM 
> applications were immune to that issue because certain KDELibs classes use 
> the parameter, which made it all the more annoying that other (e.g. 
> Kate-based) applications weren't. Sadly this setting wasn't published via a 
> GUI.
> 
> This patch adds a checkbox to the input ("mouse") KCM which seemed like the 
> most appropriate place if not only because it also makes sense to provide 
> this KCM on non-X11 platforms like OS X and MS Windows (where settings like 
> "double or single click" are relevant).
> 
> I consider this a fix of an omission bug, but I realise that it could also be 
> considered a new feature, so this RR is also intended to give some public 
> exposure to my patch rather than keeping it to myself.
> 
> 
> Diffs
> -
> 
>   kcontrol/input/kmousedlg.ui b48a606 
>   kcontrol/input/mouse.h d926a99 
>   kcontrol/input/mouse.cpp cebb174 
> 
> Diff: https://git.reviewboard.kde.org/r/125043/diff/
> 
> 
> Testing
> ---
> 
> For now only on OS X with kdelibs 4.14.11 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 125043: expose the WheelMouseZooms global setting through the input ("mouse") KCM

[Luigi Toscano]

> On Set. 4, 2015, 3:38 p.m., Martin Gräßlin wrote:
> > You are aware that this is a dead repo and that this is a new feature for a 
> > repository that has been feature frozen for years?
> > 
> > Given that I think this should not and never be merged. If you want to keep 
> > the repo going for OSX I suggest to create a branch for your patches.
> 
> René J.V. Bertin wrote:
> As I wrote in the summary, I don't consider this so much a new feature as 
> a fix to an omission because the parameter is used in kdelibs (and possible 
> elsewhere I don't know about). Besides, this concerns a KCM that I think 
> should have been part of kde-runtime (but that's probably a moot point).
> 
> Also, this is not only about OS X. There are several distribution 
> releases that ship KDE4 as the default desktop officially supported LTS 
> version, and I'd hope they too would be interested in upstream fixes. As such 
> I don't see the point in creating another branch, or in maintaining a freeze 
> on a branch that isn't going to see any more releases
> A separate repository with only fixes, organised by project and possibly 
> target platform could make sense though.
> 
> Luigi Toscano wrote:
> I disagree: a separate branch makes definitely more sense than a separate 
> repository (which would lead more confusion and divide the code).
> 
> René J.V. Bertin wrote:
> In case it wasn't clear: I meant a separate repository containing only 
> patchfiles. The patch under consideration here is not specific to OS X so 
> wouldn't justify the creation of an OS X branch (I just haven't gotten around 
> to including it in my Kubuntu PPA yet).
> 
> Jeremy Whiting wrote:
> I think what Martin and Luigi are suggesting is a branch maybe called LTS 
> or something for feature improvements since master is frozen and has been for 
> quite a long time.

Exactly, a separate repository with patches does not make sense (git already 
manages patches).


- Luigi


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


On Set. 4, 2015, 4:22 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125043/
> ---
> 
> (Updated Set. 4, 2015, 4:22 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, kde-workspace and kdelibs.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> KDE4 has been providing a setting that (would have) allowed to avoid unwanted 
> text zooming during simulated inertial scrolling (scroll coasting). KDE PIM 
> applications were immune to that issue because certain KDELibs classes use 
> the parameter, which made it all the more annoying that other (e.g. 
> Kate-based) applications weren't. Sadly this setting wasn't published via a 
> GUI.
> 
> This patch adds a checkbox to the input ("mouse") KCM which seemed like the 
> most appropriate place if not only because it also makes sense to provide 
> this KCM on non-X11 platforms like OS X and MS Windows (where settings like 
> "double or single click" are relevant).
> 
> I consider this a fix of an omission bug, but I realise that it could also be 
> considered a new feature, so this RR is also intended to give some public 
> exposure to my patch rather than keeping it to myself.
> 
> 
> Diffs
> -
> 
>   kcontrol/input/kmousedlg.ui b48a606 
>   kcontrol/input/mouse.h d926a99 
>   kcontrol/input/mouse.cpp cebb174 
> 
> Diff: https://git.reviewboard.kde.org/r/125043/diff/
> 
> 
> Testing
> ---
> 
> For now only on OS X with kdelibs 4.14.11 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 125068: Make Format Painter work in KRichTextWidget

[Luigi Toscano]

> On Set. 7, 2015, 10:12 p.m., Albert Astals Cid wrote:
> > Ship It!

Is the fix relevant for to the ktextwidgets framework as well?


- Luigi


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


On Set. 6, 2015, 1:39 a.m., Allen Winter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125068/
> ---
> 
> (Updated Set. 6, 2015, 1:39 a.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Bugs: 221947
> http://bugs.kde.org/show_bug.cgi?id=221947
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This patch, originally from Anders Lund back in 2010, fixes the problem with 
> the Format Painter changes not taking effect.
> 
> 
> Diffs
> -
> 
>   kdeui/widgets/krichtextwidget.cpp 36ca232 
> 
> Diff: https://git.reviewboard.kde.org/r/125068/diff/
> 
> 
> Testing
> ---
> 
> Tried it.  Format Painter function in KJots works now, so fixes bug 221947
> 
> 
> Thanks,
> 
> Allen Winter
> 
>

Re: Moving KDE Connect out of playground

[Luigi Toscano]

On Thursday 10 of September 2015 02:33:55 Albert Vaca wrote:
> +kde-core-devel
> 
> Hi,
> 
> With the latest changes we are making to KDE Connect as part of the sprint
> in Randa, I think that the project is becoming mature enough to be moved
> out of playground. Not only that, but Kubuntu and other distros are already
> installing KDE Connect by default, regardless of it being in playground.
> 
> I think that extragear/network is the best place for KDE Connect to be in,
> as we don't want to be tied to external release schedules for now.
> 
> Any thoughts?

Nothing against moving it outside playground, it should have been done long 
time ago.

>From a technical point of view, shouldn't we follow the usual procedure with a 
moving to kdereview?

Ciao
-- 
Luigi

Re: Moving KDE Connect out of playground

[Luigi Toscano]

Albert Vaca ha scritto:
> Our awesome sysadmins already moved the two repos (kdeconnect-android and
> kdeconnect-kde) to Review.
> 

I moved the translations for both repositories. Please update the translations
branches for kdeconnect-android so that trunk_kf5 is master and trunk is none;
yes, it's android and it does not matter, but it's easier for us.

Translation branches for kdeconnect-kde are fine (translations moved few
months ago). In addition to master, we track also the 'kde4' branch. Do you
plan to release additional versions from there, or can we drop that branch?

Ciao
-- 
Luigi

Re: Moving KDE Connect out of playground

[Luigi Toscano]

On Tuesday 15 of September 2015 08:01:44 Albert Vaca wrote:
> I don't think that having "descriptive documentation" (more about this
> later) is that important nowadays, and IMO users will likely google for
> help way before they use the help button when they find issues. Since most
> people I talked to in Randa agreed with me on this, I'm a bit surprised to
> find that you want to enforce this as a strong requirement. I can of course
> write a few lines to meet this requirement, but I would like to start a
> discussion to re-think why we are doing this.
> 
> IMO, the kind of documentation that users need is not a list of every
> button in the KCM with a redundant description like the one we provide
> (probably because most projects write it just to meet the requirement), but
> instead answers to questions like "I see error X, what to do?". And this
> kind of help is easier to find online, in wikis, forums, etc. than in the
> static documentation we provide.
> 
> Leaving aside the utility of having docs, they are yet another moving piece
> to maintain and likely to become outdated (eg: "Activity Settings" help
> shows a screenshot from KDE 4), specially in a piece of software in change
> like KDE Connect.
> 
> To put an example of a similar case, Windows 10 completely removed the
> "Help Center" and now it sends you online to the MS site if you need help.
> 
> Why don't we move our docs to the userbase wiki, and make it an open and
> live thing that users can update (ala Arch Linux wiki)? If there are no
> objections, I could start a page for KDE Connect there and make the help
> button in the KCM link to it. Also, since right now we don't have any
> numbers around how many poeple uses our help, moving it to the web would
> give us some nice analytics around it for free.

My requirement for documentation is that could be available both ways, online 
and offline. All online it's nice until you are disconnected.

Changing the content of the documentation is fine, of course, but it is a 
different story than the offline/online discussion.

Please note that the documentation shipped with the system is available online 
already (on docs.kde.org).

For sure this is a broader topic (apart from the kdeconnect example), and you 
could say I'm opinionated as kdoctools maintainer, but still.

Ciao
-- 
Luigi

Re: Moving KDE Connect out of playground

[Luigi Toscano]

On Tuesday 15 of September 2015 09:06:40 Jeremy Whiting wrote:
> I see your points and actually agree. I'm completely ok with having
> help go to some online documentation on userbase. I see the
> requirement for offline/included help documentation to be going down
> lately as you say and completely moot for kdeconnect since it
> technically requires an internet connection anyway.

I disagree about the last point: it requires a connection between two systems, 
not even intranet with Bluetooth. It does not require to be on the Internet.

Ciao
-- 
Luigi

Re: Moving Kapture to KDEGraphics

[Luigi Toscano]

On Thursday 17 of September 2015 17:43:08 Boudhayan Gupta wrote:
> Hi,
> 
> Kapture (formerly KScreenGenie) has been in review for a couple of
> months now. I've just finished the rename, which I believe was the
> last pending task before moving to KDE Graphics.

Please also rename the template file generated by Messages.sh (I can't do it 
right now).

Ciao
-- 
Luigi

Re: Review Request 125560: Give unique names to the targets created by KDE4Macros.cmake

[Luigi Toscano]

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


This is the backport of the same fix applied long time ago to KDocTools, so 
generating longer, unique target names. The change is basically the same and it 
has been throughly tested. I would wait few days and if no one else object, I 
would give a ship it.

- Luigi Toscano


On Ott. 8, 2015, 7:38 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125560/
> ---
> 
> (Updated Ott. 8, 2015, 7:38 p.m.)
> 
> 
> Review request for Build System, kdelibs and Luigi Toscano.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Backport of review 116650.
> Needed to fix build of some software after kdelibs' 4.14.11 cmake refactoring
> 
> 
> Diffs
> -
> 
>   cmake/modules/KDE4Macros.cmake 8622959 
> 
> Diff: https://git.reviewboard.kde.org/r/125560/diff/
> 
> 
> Testing
> ---
> 
> k3b and skanlite tarballs now build.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

Re: Help please. Kdoctools build.

[Luigi Toscano]

Scarlett Clark ha scritto:
> I need some help please. I am working through a new rebuild on my sandbox CI
> system and I was quickly halted due to kdoctools.I am not even sure where to
> start with this.
> 
> https://build-sandbox.kde.org/job/kdoctools%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/2/console

What is the login to access the logs? (I tried my identity login but I don't
have the proper rights)
On the other side, could the jobs be made public?

Ciao
-- 
Luigi

Re: Help please. Kdoctools build.

[Luigi Toscano]

Albert Astals Cid ha scritto:
> El Friday 27 November 2015, a les 15:41:26, Scarlett Clark va escriure:
>> I need some help please. I am working through a new rebuild on my sandbox
>> CI system and I was quickly halted due to kdoctools.I am not even sure
>> where to start with this.
>>
>> https://build-sandbox.kde.org/job/kdoctools%20master%20kf5-qt5/PLATFORM=Linu
>> x,compiler=gcc/2/console
>>
>> Piles of memory leaks. I guess this is the new ASAN flag? 
> 
> Seems newer builds of ASAN also include the Leak Sanitizer, this is an 
> unintended consequence that we now have much more warnings than just with 
> ASAN.
> 
> I'd prefer if we can try to also fix those leaks, if not i'm pretty sure 
> there's a way to disable LeakSanitizer while still having AdressSanitizer 
> enabled.

The problem is that the leaks in this specific case come from external
libraries (libxml2 and libxslt). While it would be good to report the issues
to the upstream projects, it could be take a while before a proper fix is
released.

Can we easily blacklist some of the libraries?

Ciao
-- 
Luigi

Re: Fwd: RFC: Enabling -DECM_ENABLE_SANITIZERS='address' in jenkins

[Luigi Toscano]

Scarlett Clark ha scritto:
> Resent - meant for list.
> Help please folks, I need someone with more knowledge with gcc and compiler
> flags / settings.

In the meantime, could you please reenable ASAN? I fixed few leaks in
kdoctools itself (my fault, right), so I'd like to see if there are real leaks
in libxml2/libxslt.
But right now the build fails because ASAN is disabled.

Ciao
-- 
Luigi

Re: Policy regarding QtWebKit and QtScript

[Luigi Toscano]

Pau Garcia i Quiles ha scritto:
> 
> 
> On Tue, Dec 22, 2015 at 11:02 PM, Albert Astals Cid  > wrote:
> 
> 
> > Soon Qt 5.6 will be released and with it, 2 quite widely used
> > frameworks will disappear: QtWebKit and QtScript. Also QtQuick 1, but
> > I think this is much less of a problem.
> 
> As far as I understand they are just going to be stopped from releasing, 
> this
> doesn't mean we can't keep using them, no?
> 
>  
> IMHO they will break sooner than later. They are going unsupported and IIRC
> also getting out of CI. It's just a matter of time.
> 
> The 6-12-18 months they will still be buildable and usable are the time to
> look for an alternative, or to enhance QJSEngine/QWebEngine, so that they are
> good for KDE. According to qt-interest, some commercial and LGPL users seem to
> face the same problems, therefore The Qt Company is probably open to 
> enhancements.

Shouldn't it be the other way around? Workable solution first and drop the old
one later?

But yeah, maybe too late, sadly.

Ciao
-- 
Luigi

Re: Review Request 125910: Fix for Bug 334525 - Gwenview hangs when switching from normal to full screen mode

[Luigi Toscano]

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


For the record: this was submitted to the knotifications frameworks, not to 
kdelibs.

- Luigi Toscano


On Dic. 29, 2015, 9:54 p.m., Johannes Stefan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125910/
> ---
> 
> (Updated Dic. 29, 2015, 9:54 p.m.)
> 
> 
> Review request for kdelibs and Martin Klapetek.
> 
> 
> Bugs: 334525
> http://bugs.kde.org/show_bug.cgi?id=334525
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Setting default reason for going into fullscreen mode
> 
> 
> Diffs
> -
> 
>   kdeui/notifications/knotificationrestrictions.cpp 818edea 
> 
> Diff: https://git.reviewboard.kde.org/r/125910/diff/
> 
> 
> Testing
> ---
> 
> Compiled an tested - DBus Log as expected:
> 
> # begin DBUS-log #
> method call sender=:1.223 -> dest=org.freedesktop.ScreenSaver serial=56 
> path=/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=Inhibit
>string "Gwenview"
>string "no_reason_specified"
> method call sender=:1.6 -> dest=:1.3 serial=588 
> path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; 
> member=Inhibit
>string "Gwenview"
>uint32 0
>string "no_reason_specified"
>uint32 8
> signal sender=:1.3 -> dest=(null destination) serial=351 
> path=/org/gnome/SessionManager; interface=org.freedesktop.DBus.Properties; 
> member=PropertiesChanged
>string "org.gnome.SessionManager"
>array [
>   dict entry(
>  string "InhibitedActions"
>  variant uint32 8
>   )
>]
>array [
>]
> signal sender=:1.3 -> dest=(null destination) serial=352 
> path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; 
> member=InhibitorAdded
>object path "/org/gnome/SessionManager/Inhibitor29"
> method return sender=:1.3 -> dest=:1.6 reply_serial=588
>uint32 1169992534
> method call sender=:1.4 -> dest=:1.21 serial=56 
> path=/org/gnome/Mutter/IdleMonitor/Core; 
> interface=org.gnome.Mutter.IdleMonitor; member=RemoveWatch
>uint32 35
> method call sender=:1.6 -> dest=org.freedesktop.DBus serial=589 
> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
>string 
> "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0=':1.223'"
> method call sender=:1.6 -> dest=org.freedesktop.DBus serial=590 
> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; 
> member=GetNameOwner
>string ":1.223"
> method return sender=:1.6 -> dest=:1.223 reply_serial=56
>uint32 1169992534
> method call sender=:1.6 -> dest=:1.21 serial=592 
> path=/org/gnome/Mutter/DisplayConfig; 
> interface=org.freedesktop.DBus.Properties; member=Set
>string "org.gnome.Mutter.DisplayConfig"
>string "PowerSaveMode"
>variant   int32 0
> method call sender=:1.21 -> dest=:1.3 serial=1073 
> path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; 
> member=IsInhibited
>uint32 16
> method call sender=:1.21 -> dest=org.freedesktop.DBus serial=1074 
> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch
>string 
> "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0=':1.4'"
> method return sender=:1.21 -> dest=:1.4 reply_serial=56
> method return sender=:1.3 -> dest=:1.21 reply_serial=1073
>boolean false
> # end of DBUS-log #
> 
> 
> Thanks,
> 
> Johannes Stefan
> 
>

Re: Review Request 125910: Fix for Bug 334525 - Gwenview hangs when switching from normal to full screen mode

[Luigi Toscano]

> On Dic. 30, 2015, 3:48 p.m., Luigi Toscano wrote:
> > For the record: this was submitted to the knotifications frameworks, not to 
> > kdelibs.
> 
> Martin Klapetek wrote:
> Yes, sorry, I wrote it as a message here but now I see that it didn't get 
> through; I still have "Publish" here :S
> 
> There are no more kdelibs releases planned and the same bug happens in 
> frameworks, so I pushed it to frameworks.

Afaik we are still publishing patch releases of kdelibs 4.14 branch, so I would 
add the fix there too.


- Luigi


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


On Dic. 29, 2015, 9:54 p.m., Johannes Stefan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125910/
> ---
> 
> (Updated Dic. 29, 2015, 9:54 p.m.)
> 
> 
> Review request for kdelibs and Martin Klapetek.
> 
> 
> Bugs: 334525
> http://bugs.kde.org/show_bug.cgi?id=334525
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Setting default reason for going into fullscreen mode
> 
> 
> Diffs
> -
> 
>   kdeui/notifications/knotificationrestrictions.cpp 818edea 
> 
> Diff: https://git.reviewboard.kde.org/r/125910/diff/
> 
> 
> Testing
> ---
> 
> Compiled an tested - DBus Log as expected:
> 
> # begin DBUS-log #
> method call sender=:1.223 -> dest=org.freedesktop.ScreenSaver serial=56 
> path=/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=Inhibit
>string "Gwenview"
>string "no_reason_specified"
> method call sender=:1.6 -> dest=:1.3 serial=588 
> path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; 
> member=Inhibit
>string "Gwenview"
>uint32 0
>string "no_reason_specified"
>uint32 8
> signal sender=:1.3 -> dest=(null destination) serial=351 
> path=/org/gnome/SessionManager; interface=org.freedesktop.DBus.Properties; 
> member=PropertiesChanged
>string "org.gnome.SessionManager"
>array [
>   dict entry(
>  string "InhibitedActions"
>  variant uint32 8
>   )
>]
>array [
>]
> signal sender=:1.3 -> dest=(null destination) serial=352 
> path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; 
> member=InhibitorAdded
>object path "/org/gnome/SessionManager/Inhibitor29"
> method return sender=:1.3 -> dest=:1.6 reply_serial=588
>uint32 1169992534
> method call sender=:1.4 -> dest=:1.21 serial=56 
> path=/org/gnome/Mutter/IdleMonitor/Core; 
> interface=org.gnome.Mutter.IdleMonitor; member=RemoveWatch
>uint32 35
> method call sender=:1.6 -> dest=org.freedesktop.DBus serial=589 
> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
>string 
> "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0=':1.223'"
> method call sender=:1.6 -> dest=org.freedesktop.DBus serial=590 
> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; 
> member=GetNameOwner
>string ":1.223"
> method return sender=:1.6 -> dest=:1.223 reply_serial=56
>uint32 1169992534
> method call sender=:1.6 -> dest=:1.21 serial=592 
> path=/org/gnome/Mutter/DisplayConfig; 
> interface=org.freedesktop.DBus.Properties; member=Set
>string "org.gnome.Mutter.DisplayConfig"
>string "PowerSaveMode"
>variant   int32 0
> method call sender=:1.21 -> dest=:1.3 serial=1073 
> path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; 
> member=IsInhibited
>uint32 16
> method call sender=:1.21 -> dest=org.freedesktop.DBus serial=1074 
> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch
>string 
> "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0=':1.4'"
> method return sender=:1.21 -> dest=:1.4 reply_serial=56
> method return sender=:1.3 -> dest=:1.21 reply_serial=1073
>boolean false
> # end of DBUS-log #
> 
> 
> Thanks,
> 
> Johannes Stefan
> 
>

Re: Review Request 125910: Fix for Bug 334525 - Gwenview hangs when switching from normal to full screen mode

[Luigi Toscano]

> On Dic. 30, 2015, 3:48 p.m., Luigi Toscano wrote:
> > For the record: this was submitted to the knotifications frameworks, not to 
> > kdelibs.
> 
> Martin Klapetek wrote:
> Yes, sorry, I wrote it as a message here but now I see that it didn't get 
> through; I still have "Publish" here :S
> 
> There are no more kdelibs releases planned and the same bug happens in 
> frameworks, so I pushed it to frameworks.
> 
> Luigi Toscano wrote:
> Afaik we are still publishing patch releases of kdelibs 4.14 branch, so I 
> would add the fix there too.
> 
> Martin Klapetek wrote:
> Ah, do we have any records for that? Also when would the next release be?

With every stable release of KDE Applications (x.y, x.y.z, x.y.z+1, etc, so 
non-beta).

You can check the release tools, kdelibs is listed:
https://quickgit.kde.org/?p=sysadmin%2Frelease-tools.git&a=blob&h=ca78d7665498409a5d8b892b255cb6783cea078b&hb=dd91ca9e998550e10f17c850544753ac065ea9e9&f=modules.git


- Luigi


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


On Dic. 29, 2015, 9:54 p.m., Johannes Stefan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125910/
> ---
> 
> (Updated Dic. 29, 2015, 9:54 p.m.)
> 
> 
> Review request for kdelibs and Martin Klapetek.
> 
> 
> Bugs: 334525
> http://bugs.kde.org/show_bug.cgi?id=334525
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Setting default reason for going into fullscreen mode
> 
> 
> Diffs
> -
> 
>   kdeui/notifications/knotificationrestrictions.cpp 818edea 
> 
> Diff: https://git.reviewboard.kde.org/r/125910/diff/
> 
> 
> Testing
> ---
> 
> Compiled an tested - DBus Log as expected:
> 
> # begin DBUS-log #
> method call sender=:1.223 -> dest=org.freedesktop.ScreenSaver serial=56 
> path=/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=Inhibit
>string "Gwenview"
>string "no_reason_specified"
> method call sender=:1.6 -> dest=:1.3 serial=588 
> path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; 
> member=Inhibit
>string "Gwenview"
>uint32 0
>string "no_reason_specified"
>uint32 8
> signal sender=:1.3 -> dest=(null destination) serial=351 
> path=/org/gnome/SessionManager; interface=org.freedesktop.DBus.Properties; 
> member=PropertiesChanged
>string "org.gnome.SessionManager"
>array [
>   dict entry(
>  string "InhibitedActions"
>  variant uint32 8
>   )
>]
>array [
>]
> signal sender=:1.3 -> dest=(null destination) serial=352 
> path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; 
> member=InhibitorAdded
>object path "/org/gnome/SessionManager/Inhibitor29"
> method return sender=:1.3 -> dest=:1.6 reply_serial=588
>uint32 1169992534
> method call sender=:1.4 -> dest=:1.21 serial=56 
> path=/org/gnome/Mutter/IdleMonitor/Core; 
> interface=org.gnome.Mutter.IdleMonitor; member=RemoveWatch
>uint32 35
> method call sender=:1.6 -> dest=org.freedesktop.DBus serial=589 
> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
>string 
> "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0=':1.223'"
> method call sender=:1.6 -> dest=org.freedesktop.DBus serial=590 
> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; 
> member=GetNameOwner
>string ":1.223"
> method return sender=:1.6 -> dest=:1.223 reply_serial=56
>uint32 1169992534
> method call sender=:1.6 -> dest=:1.21 serial=592 
> path=/org/gnome/Mutter/DisplayConfig; 
> interface=org.freedesktop.DBus.Properties; member=Set
>string "org.gnome.Mutter.DisplayConfig"
>string "PowerSaveMode"
>variant   int32 0
> method call sender=:1.21 -> dest=:1.3 serial=1073 
> path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; 
> member=IsInhibited
>uint32 16
> method call sender=:1.21 -> dest=org.freedesktop.DBus serial=1074 
> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch
>string 
> "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0=':1.4'"
> method return sender=:1.21 -> dest=:1.4 reply_serial=56
> method return sender=:1.3 -> dest=:1.21 reply_serial=1073
>boolean false
> # end of DBUS-log #
> 
> 
> Thanks,
> 
> Johannes Stefan
> 
>

Re: KActivities repository split

[Luigi Toscano]

Ivan Čukić ha scritto:
> Hi everyone,
> 
> As previously announced, KActivities has been split into a few
> separate repositories. This mail is mostly intended to notify our dear
> packagers of the change, and the plan for the transition period.
> 
> KActivities framework 5.19 (as released a few days ago) contains
> everything that it used to, this is about the next version - 5.20.
> 
> This is the former setup:
> --
> 
> Everything was contained in kde:kactivities, and distributions used to
> split it into different packages.
> 
> 
> This is the setup now:
> ---
> 
> - kde:kactivities - contains the framework and QML includes, it will
> soon become a tier1 integration framework
> - kde:kactivitymanagerd - contains the activities service and its plugins
> - kde:kactivities-stats - the (first-to-be-released-with-5.20)
> framework for getting the usage statistics collected by the activities
> service
> 
> - KIO module from kde:kactivities will be moved to kio-extras
> - KCM module will be moved to plasma-desktop/kcms
> - fileitem plugin will also need a new home (any ideas?)

Can you please also describe how this affects translations? How translations
files (and desktop files, which are sources for translations too) are moved
around, so that we can move them around

(you can follow up to kde-i18n-doc@ only for this part).

Also, see below:
> 
> 
> The release schedules:
> -
> 
> kde:kactivities and kde:kactivities-stats will follow kde frameworks
> release schedule, other components will follow Plasma's release
> schedule.
> 
> How to handle this transition is explained below.
> 
> 
> Dependencies:
> -
> 
> - kde:kactivities has a optional runtime, but *strongly* recommended
> dependency on kde:kactivitymanagerd (on Plasma distributions)
> - kde:kactivities-stats is not used by anyone at the moment (plasma
> has had an internal copy with a different soname for some time now,
> and it will keep that internal copy until plasma 5.7). Plasma 5.7 will
> depend on kactivities and kactivities-stats.
> 
> 
> The transition period:
> -
> 
> The situation with kde:kactivitymanagerd is clear, when making 5.20
> packages of kde:kactivities, please make the kde:kactivitymanagerd
> package to be a hard requirement (alternatively, make plasma-workspace
> require kde:kactivitymanagerd, and make it to be just an optional
> dependency for kde:kactivities).
> 
> The potential problem is with the additional modules like KCM, KIO and
> the FileItem plugin for Dolphin. If the user updates to kf5.20 before
> updating to plasma 5.6 (which will be released after kf5.20, but will
> not depend on kf5.20) these components will be missing, along with the
> features they provide.
> 
> Therefore, as a one-off, we are going to release kcm+kio+fileitem
> plugin as a tarball called kactivities-workspace-5.5 (alternatively,
> is is also available as a git repository at
> kde:scratch/ivan/kactivities-workspace).
> 
> We will also release kactivitymanagerd 5.5 before kf5.20 so that a
> package can be created on time for the update.
> 
> To recap, we are going to make these two releases out of schedule:
> - kactivitymanagerd-5.5 that will contain the activities service
> needed for the upgrade to kf5.20
> - kactivities-workspace-5.5 that will contain workspace plugins (KIO,
> KCM, FileItem) for the period between the upgrade to kf5.20 and
> upgrade to plasma 5.6.

Please don't forget translations for those special tarballs.

Ciao
-- 
Luigi

Re: mailing list archive gone ?

[Luigi Toscano]

Martin Koller ha scritto:
> On Saturday 27 February 2016 17:02:27 Thomas Lübking wrote:
>> On Samstag, 27. Februar 2016 16:09:00 CEST, Martin Koller wrote:
>>> Hi,
>>>
>>> https://mail.kde.org/pipermail/kde-core-devel/
>>>
>>> shows only 3 mails from the year 2000.
>>> Where are the other archives gone ?
>>
>> No idea, but it's still on https://marc.info/?l=kde-core-devel&r=1&w=2
> 
> What is the official address ?
> 
> Here https://www.kde.org/support/mailinglists/
> it says: https://mail.kde.org/mailman/listinfo/kde-core-devel
> and this pages says, the archives should be at 
> http://mail.kde.org/pipermail/kde-core-devel/
> 
> There's somewhere something wrong...
> 

Our lists were not indexed by us, but on marc.info, for historical reasons
which I don't know. What I remember is recently the automatic aliasing of the
index to marc.info could not be kept and, while recent lists have all their
history on our servers, the older ones have still no archives. Ask sysadmins
for more details, but it's not an unknown issue.

Ciao
-- 
Luigi

Re: KDE file dialog

[Luigi Toscano]

Martin Koller ha scritto:
> In KDE4 times there was a common file dialog for the applications, I think 
> this is what KFileDialog was made for.
> Now where some applications are already ported to KF5, there seems to be no 
> such thing anymore
> (or it does not work here).
> KFileDialog is deprecated, QFileDialog does not have the functionality of 
> KFileDialog (e.g. aside preview).
> As I find KFileWidget having e.g. preview possibility, I assume QFileDialog 
> would use this widget via
> the platform integration, right ?
> If so, does this only work when running plasma5 as desktop or is there a way 
> to get the KDE4 features
> in KF5 application file dialogs even when running inside a KDE4 session ?
> 

This is what I use:
export QT_QPA_PLATFORMTHEME=kde

and  you need the integration plugin installed. It used to be part of
Frameworks (frameworksintegration), it will be part of Plasma (but hopefully
still usable without).
The idea is that other desktop environments will provide their own integration
plugin, but I agree that there are use cases where this won't happen (run
application as root, run as another user, minor Qt-based desktop environments,
etc). That said, I'm just an user regarding Plasma stuff.

Ciao
-- 
Luigi

Re: KDE file dialog

[Luigi Toscano]

Martin Koller ha scritto:
> On Sunday 28 February 2016 15:58:20 Luigi Toscano wrote:
>> Martin Koller ha scritto:
>>> In KDE4 times there was a common file dialog for the applications, I think 
>>> this is what KFileDialog was made for.
>>> Now where some applications are already ported to KF5, there seems to be no 
>>> such thing anymore
>>> (or it does not work here).
>>> KFileDialog is deprecated, QFileDialog does not have the functionality of 
>>> KFileDialog (e.g. aside preview).
>>> As I find KFileWidget having e.g. preview possibility, I assume QFileDialog 
>>> would use this widget via
>>> the platform integration, right ?
>>> If so, does this only work when running plasma5 as desktop or is there a 
>>> way to get the KDE4 features
>>> in KF5 application file dialogs even when running inside a KDE4 session ?
>>>
>>
>> This is what I use:
>> export QT_QPA_PLATFORMTHEME=kde
>>
>> and  you need the integration plugin installed. It used to be part of
>> Frameworks (frameworksintegration), it will be part of Plasma (but hopefully
>> still usable without).
> 
> ok, good. I've now installed frameworksintegration and I've now the preview 
> feature back -
> but I have also now (in my POV) ugly black-and-white icons which I don't like.
> Installing systemsettings5 (openSuse 13.2) does not show any icon related 
> section
> (in fact it only shows 6 different sections).
> I'd like to have the oxygen icons as in all my other KDE4 apps.
> Where can I set this ?

The icon kcm is currently part of the plasma-desktop source package (but it
does not depend on it). I don't know how it is packaged in openSUSE. But see
below (qt5ct)


> Should a KF5 app (with frameworksintegration) not also use the settings from 
> a still used KDE4 desktop ?

frameworksintegration is going to be part of plasma, in fact. There would need
to be an "old plasma" integration. Or you can use an alternative system to set
it, like https://sourceforge.net/projects/qt5ct/

> How would this work in e.g. a gnome desktop ?

Afaik the Gtk+ style is used. There is also this project for a better
integration, see https://fedoraproject.org/wiki/Changes/QGnomePlatform


Ciao
-- 
Luigi

Re: Review Request 127264: Set CMP0064 to OLD to suppress CMake warnings

[Luigi Toscano]

> On March 3, 2016, 5:54 p.m., Aleix Pol Gonzalez wrote:
> > cmake/modules/KDE4Macros.cmake, line 1003
> > 
> >
> > Without the conditionals, the code would work just as well.
> 
> Rohan Garg wrote:
> Unless you have a CMake so old that said policy doesn't exist. For eg. on 
> Debian stable :)

(which is still 3.0.2, so way more than the minimum required version for 
Frameworks (2.8.12))


- Luigi


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


On March 3, 2016, 1:58 p.m., Rohan Garg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127264/
> ---
> 
> (Updated March 3, 2016, 1:58 p.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This follows the same idea from 826a5ff3278f492a99ac6827614e1d0ca40a45e8
> 
> 
> Diffs
> -
> 
>   cmake/modules/KDE4Macros.cmake 5bb2ffa 
> 
> Diff: https://git.reviewboard.kde.org/r/127264/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rohan Garg
> 
>

Re: Review Request 127264: Set CMP0064 to OLD to suppress CMake warnings

[Luigi Toscano]

> On March 3, 2016, 5:54 p.m., Aleix Pol Gonzalez wrote:
> > cmake/modules/KDE4Macros.cmake, line 1003
> > <https://git.reviewboard.kde.org/r/127264/diff/1/?file=447921#file447921line1003>
> >
> > Without the conditionals, the code would work just as well.
> 
> Rohan Garg wrote:
> Unless you have a CMake so old that said policy doesn't exist. For eg. on 
> Debian stable :)
> 
> Luigi Toscano wrote:
> (which is still 3.0.2, so way more than the minimum required version for 
> Frameworks (2.8.12))
> 
> Rohan Garg wrote:
> Except we're talking about kdelibs here, from the KDE 4 era.

Even better (for your patch)! 2.8.9 is the current minimum, so not old at all 
for kdelibs4.


- Luigi


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


On March 3, 2016, 1:58 p.m., Rohan Garg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127264/
> ---
> 
> (Updated March 3, 2016, 1:58 p.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This follows the same idea from 826a5ff3278f492a99ac6827614e1d0ca40a45e8
> 
> 
> Diffs
> -
> 
>   cmake/modules/KDE4Macros.cmake 5bb2ffa 
> 
> Diff: https://git.reviewboard.kde.org/r/127264/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rohan Garg
> 
>

Re: Review Request 127264: Set CMP0064 to OLD to suppress CMake warnings

[Luigi Toscano]

> On March 3, 2016, 5:54 p.m., Aleix Pol Gonzalez wrote:
> > cmake/modules/KDE4Macros.cmake, line 1003
> > <https://git.reviewboard.kde.org/r/127264/diff/1/?file=447921#file447921line1003>
> >
> > Without the conditionals, the code would work just as well.
> 
> Rohan Garg wrote:
> Unless you have a CMake so old that said policy doesn't exist. For eg. on 
> Debian stable :)
> 
> Luigi Toscano wrote:
> (which is still 3.0.2, so way more than the minimum required version for 
> Frameworks (2.8.12))
> 
> Rohan Garg wrote:
> Except we're talking about kdelibs here, from the KDE 4 era.
> 
> Luigi Toscano wrote:
> Even better (for your patch)! 2.8.9 is the current minimum, so not old at 
> all for kdelibs4.
> 
> Rohan Garg wrote:
> Maybe I'm doing a terrible job of explaining it. The CMP0064 policy was 
> introduced in v3.4 , which is not available in Debian stable. Does that clear 
> things up? Or am I missing something?

I'm supporting your patch. My comment is in fact to point out that version of 
cmake is not so old.


- Luigi


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


On March 3, 2016, 1:58 p.m., Rohan Garg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127264/
> ---
> 
> (Updated March 3, 2016, 1:58 p.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This follows the same idea from 826a5ff3278f492a99ac6827614e1d0ca40a45e8
> 
> 
> Diffs
> -
> 
>   cmake/modules/KDE4Macros.cmake 5bb2ffa 
> 
> Diff: https://git.reviewboard.kde.org/r/127264/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rohan Garg
> 
>

Re: remove khelpcenter from next Plasma release?

[Luigi Toscano]

On Wednesday 09 of March 2016 15:29:28 Sebastian Kügler wrote:
> Hi all,
> 
> [For the sake of sanity, please reply to both list, this topic affects
> applications and Plasma.]
> 
> One of the topics we are discussing at the current Plasma sprint is whether
> we really want khelpcenter as part of the Plasma releases in the future.
> Some data points:
> 
> - khelpcenter is unmaintained, it has seen a rough port to KF5, but has
>   otherwise seen zero love, this shows
> - just dropping it would mean that the user gets sent to a webpage
> containing the latest version of the documentation, so khelpcenter's
> usecase is actually just being an offline cache, fallback mechanism are
> already in place 
> - said user documentation is spotty, this is only semi-related, but still 
doesn't exactly make a strong case for keeping it
> - it uses KHTML

There is a non-committed work to have search working again, which will cut the 
bug list. You should have probably already noticed a bunch of commits which 
fixes some language related issues.

Apart from that, I see a continued push to remove support for non-connected 
users. I still think that there is a value in that, but no one seems to agree 
with that.

Moreover, khelpcenter is not just for *our* documentation, but to access also 
other documentation on the system.

> A casual poll among developers here at the sprint reveals that ~70% would
> rather see it gone from Plasma, the rest abstains. Nobody from my
> (admittedly small) sample really wants to keep it.
> 
> Killing it could mean that we remove it entirely (to unmaintained), or if
> anybody is interested in maintaining it making it part of Applications, or
> Extragear.
> 
> Let's seriously think about dropping it from Plasma 5.7 and onwards. If
> anybody is hell-bent on keeping it, this person should consider maintaining
> it as well. Unmaintained code in Plasma is not cool, and so far nobody
> seems to care enough to step up.

That said, I perceive this email as "khelpcenter is not welcome in Plasma", 
probably with a maintainer ("hell-bent on keeping it" sounds very negative to 
me). So not sure what should be the discussion about.

Again, please recheck the recent list of commits.

Ciao
-- 
Luigi

Re: remove khelpcenter from next Plasma release?

[Luigi Toscano]

On Wednesday 09 of March 2016 16:16:54 Sebastian Kügler wrote:
> On Wednesday, March 09, 2016 17:05:14 Luigi Toscano wrote:
> > That said, I perceive this email as "khelpcenter is not welcome in
> > Plasma",
> > probably with a maintainer ("hell-bent on keeping it" sounds very negative
> > to me). So not sure what should be the discussion about.
> 
> The discussion is about removing it from Plasma releases starting with 5.7,
> see the subject of my email.
> 
> Let me cut right to the chase, do you want to maintain it? Does it need to
> be in Plasma?
Yes, I can maintain it. In fact many features come from components I already 
control.


> You're right that Plasma devs don't seem to want it, I thought my initial
> email made that pretty clear. We do think that disconnected systems are
> rather a fringe case, and that our time and effort is better spent on other
> things.
Then the question still holds: with a maintainer, does it have a place in 
Plasma? I'm not talking about an hypothetical time and effort for maintaining 
this offline use case (which will continue to be 0) but in the light of the 
statement above. In other words, if the question mark in the subject is real 
or rhetorical.
I'm ready for both possible outcomes.

-- 
Luigi

Re: remove khelpcenter from next Plasma release?

[Luigi Toscano]

On Wednesday 09 of March 2016 16:50:39 Sebastian Kügler wrote:
> On Wednesday, March 09, 2016 17:30:01 Luigi Toscano wrote:
> > > Let me cut right to the chase, do you want to maintain it? Does it need
> > > to
> > > be in Plasma?
> > 
> > Yes, I can maintain it. In fact many features come from components I
> > already  control.
> > 
> > > You're right that Plasma devs don't seem to want it, I thought my
> > > initial
> > > email made that pretty clear. We do think that disconnected systems are
> > > rather a fringe case, and that our time and effort is better spent on
> > > other
> > > things.
> > 
> > Then the question still holds: with a maintainer, does it have a place in
> > Plasma? I'm not talking about an hypothetical time and effort for
> > maintaining  this offline use case (which will continue to be 0) but in
> > the
> > light of the statement above. In other words, if the question mark in the
> > subject is real or rhetorical.
> > I'm ready for both possible outcomes.
> 
> Ah OK, sorry for misunderstanding it.
> 
> I think there are the following options:
> 
> 1) keeping it in Plasma with maintainer
> 2) keeping it outside of Plasma with maintainer
> 3) moving it to unmaintained (that's basically killing it)
> 4) keeping the status quo (not wanted)
> 
> My personal preference would be an optional component (hence Extragear),
> since I think that the vast majority of users has web access, so
> khelpcenter isn't necessary and only adds to our maintainance burden
> without much gain in those cases.

My offer stands and we can rule out 4) and 3).
Note that 2) could also mean a move to Applications (from your point of view 
it does not matter too much).
The case 1) shouldn't add maintenance anyway as the maintainer is identified.

> 
> If we can move from 4) to 1) (so status quo but with maintainer), that would
> already be an improvement of course.
> 
> The question mark was honest, we haven't made a decision on it, but
> different people do have expressed a preference for not shipping it (as or
> by default in Plasma releases). We may have missed important points, and we
> don't want to just kick things out unilaterally.

I think we can leave some time for other people to comment. The shortest 
deadline of all possibilities is the one for moving into Applications, and 
there are still 8 days before the dependency freeze and two weeks before the 
branch.

-- 
Luigi

Re: remove khelpcenter from next Plasma release?

[Luigi Toscano]

Luigi Toscano ha scritto:
> On Wednesday 09 of March 2016 16:50:39 Sebastian Kügler wrote:
>> On Wednesday, March 09, 2016 17:30:01 Luigi Toscano wrote:
>>>> Let me cut right to the chase, do you want to maintain it? Does it need
>>>> to
>>>> be in Plasma?
>>>
>>> Yes, I can maintain it. In fact many features come from components I
>>> already  control.
>>>
>>>> You're right that Plasma devs don't seem to want it, I thought my
>>>> initial
>>>> email made that pretty clear. We do think that disconnected systems are
>>>> rather a fringe case, and that our time and effort is better spent on
>>>> other
>>>> things.
>>>
>>> Then the question still holds: with a maintainer, does it have a place in
>>> Plasma? I'm not talking about an hypothetical time and effort for
>>> maintaining  this offline use case (which will continue to be 0) but in
>>> the
>>> light of the statement above. In other words, if the question mark in the
>>> subject is real or rhetorical.
>>> I'm ready for both possible outcomes.
>>
>> Ah OK, sorry for misunderstanding it.
>>
>> I think there are the following options:
>>
>> 1) keeping it in Plasma with maintainer
>> 2) keeping it outside of Plasma with maintainer
>> 3) moving it to unmaintained (that's basically killing it)
>> 4) keeping the status quo (not wanted)
>>
>> My personal preference would be an optional component (hence Extragear),
>> since I think that the vast majority of users has web access, so
>> khelpcenter isn't necessary and only adds to our maintainance burden
>> without much gain in those cases.
> 
> My offer stands and we can rule out 4) and 3).
> Note that 2) could also mean a move to Applications (from your point of view 
> it does not matter too much).
> The case 1) shouldn't add maintenance anyway as the maintainer is identified.
> 
>>
>> If we can move from 4) to 1) (so status quo but with maintainer), that would
>> already be an improvement of course.
>>
>> The question mark was honest, we haven't made a decision on it, but
>> different people do have expressed a preference for not shipping it (as or
>> by default in Plasma releases). We may have missed important points, and we
>> don't want to just kick things out unilaterally.
> 
> I think we can leave some time for other people to comment. The shortest 
> deadline of all possibilities is the one for moving into Applications, and 
> there are still 8 days before the dependency freeze and two weeks before the 
> branch.

Any other comment from anyone else?

Ciao
-- 
Luigi

Re: Reviewboard timing (was Re: Sunsetting of Infrastructure and the Phabricator migration)

[Luigi Toscano]

Ben Cooksley ha scritto:
> On Sat, Mar 19, 2016 at 12:12 AM, Luigi Toscano
>  wrote:
>> On Friday 18 of March 2016 19:46:03 Ben Cooksley wrote:
>>> In terms of Reviewboard, there are no plans to import it's contents
>>> into Phabricator, as the level of effort required is too high. Once we
>>> are migrated to Phabricator for reviews, i'm proposing that everyone
>>> has 4 weeks to finish any final reviews up within Reviewboard before
>>> it is set to read only by disabling login for everyone. Reviews still
>>> open at that point would be discarded.
>>
>> (starting a subthread on kde-core-devel as advised)
>>
>> I think this timing is too short. I agree with closing down Reviewboard, of
>> course, but I would propose something a bit more complicated (it seems that
>> reviewboard permissions does not allow to easily set it):
>> - close down new submissions (physically remove the pages? Comment out the
>> code in reviewboard)
>> - leave open the existing reviews for 6 months and add periodic reminders to
>> them.
> 
> 6 months seems a bit excessive. Reviews shouldn't be sticking around
> for too long - and if the patch is still needed nothing stops someone
> from picking it up and posting it on Phabricator to continue with it.
> 
> Any specific reason for such a long wind down?

My experience: reviews shouldn't be sticking but reality and expectations do
not match sometime, and I fear it will be a chunk of lost code.

Ciao
-- 
Luigi

Re: remove khelpcenter from next Plasma release?

[Luigi Toscano]

Luigi Toscano ha scritto:
> Luigi Toscano ha scritto:
>> On Wednesday 09 of March 2016 16:50:39 Sebastian Kügler wrote:
>>> On Wednesday, March 09, 2016 17:30:01 Luigi Toscano wrote:
>>>>> Let me cut right to the chase, do you want to maintain it? Does it need
>>>>> to
>>>>> be in Plasma?
>>>>
>>>> Yes, I can maintain it. In fact many features come from components I
>>>> already  control.
>>>>
>>>>> You're right that Plasma devs don't seem to want it, I thought my
>>>>> initial
>>>>> email made that pretty clear. We do think that disconnected systems are
>>>>> rather a fringe case, and that our time and effort is better spent on
>>>>> other
>>>>> things.
>>>>
>>>> Then the question still holds: with a maintainer, does it have a place in
>>>> Plasma? I'm not talking about an hypothetical time and effort for
>>>> maintaining  this offline use case (which will continue to be 0) but in
>>>> the
>>>> light of the statement above. In other words, if the question mark in the
>>>> subject is real or rhetorical.
>>>> I'm ready for both possible outcomes.
>>>
>>> Ah OK, sorry for misunderstanding it.
>>>
>>> I think there are the following options:
>>>
>>> 1) keeping it in Plasma with maintainer
>>> 2) keeping it outside of Plasma with maintainer
>>> 3) moving it to unmaintained (that's basically killing it)
>>> 4) keeping the status quo (not wanted)
>>>
>>> My personal preference would be an optional component (hence Extragear),
>>> since I think that the vast majority of users has web access, so
>>> khelpcenter isn't necessary and only adds to our maintainance burden
>>> without much gain in those cases.
>>
>> My offer stands and we can rule out 4) and 3).
>> Note that 2) could also mean a move to Applications (from your point of view 
>> it does not matter too much).
>> The case 1) shouldn't add maintenance anyway as the maintainer is identified.
>>
>>>
>>> If we can move from 4) to 1) (so status quo but with maintainer), that would
>>> already be an improvement of course.
>>>
>>> The question mark was honest, we haven't made a decision on it, but
>>> different people do have expressed a preference for not shipping it (as or
>>> by default in Plasma releases). We may have missed important points, and we
>>> don't want to just kick things out unilaterally.
>>
>> I think we can leave some time for other people to comment. The shortest 
>> deadline of all possibilities is the one for moving into Applications, and 
>> there are still 8 days before the dependency freeze and two weeks before the 
>> branch.
> 
> Any other comment from anyone else?
> 

I think I made up my mind. If no one else objects further, I officially ask
the release team (in CC) if it is possible to accept khelpcenter as part of
Applications for the upcoming release 16.04, module "applications". No
dependency changes are planned for the current master branch khelpcenter for 
now.

We will have a bit of overlap for a while (khelpcenter/Plasma5.6 vs
khelpcenter/Applications16.04), but the version number from Applications is
higher, so it shouldn't be a problem for packagers (they already handled the
more complicated khelpcenter/kde-runtime vs khelpcenter/Plasma).

If this is accepted, I will manage the various tickets with sysadmins (and at
least move the translations myself).

Ciao
-- 
Luigi

Reviewboard timing (was Re: Sunsetting of Infrastructure and the Phabricator migration)

[Luigi Toscano]

On Friday 18 of March 2016 19:46:03 Ben Cooksley wrote:
> In terms of Reviewboard, there are no plans to import it's contents
> into Phabricator, as the level of effort required is too high. Once we
> are migrated to Phabricator for reviews, i'm proposing that everyone
> has 4 weeks to finish any final reviews up within Reviewboard before
> it is set to read only by disabling login for everyone. Reviews still
> open at that point would be discarded.

(starting a subthread on kde-core-devel as advised)

I think this timing is too short. I agree with closing down Reviewboard, of 
course, but I would propose something a bit more complicated (it seems that 
reviewboard permissions does not allow to easily set it):
- close down new submissions (physically remove the pages? Comment out the 
code in reviewboard)
- leave open the existing reviews for 6 months and add periodic reminders to 
them.

Ciao
-- 
Luigi

Re: remove khelpcenter from next Plasma release?

[Luigi Toscano]

On Thursday 17 of March 2016 11:54:31 Aaron Honeycutt wrote:
> Kubuntu uses it for our Documentation but our current tools do have a PDF
> export option as well as epub so we could use a different tool to read
> those files without khelpcenter. I do thank every developer for his/her
> work and current work on that package!

Why use a different tool? KHelpCenter is (mostly) simply changing the release 
schedule...

-- 
Luigi

Re: [Kde-pim] Qt 4 Builds

[Luigi Toscano]

laurent Montel ha scritto:
> Le dimanche 27 mars 2016, 11:58:07 CEST Kevin Kofler a écrit :
>> laurent Montel wrote:
>>> We will not create more release from kdepim4, no distro uses it even
>>> debian :)
>>
>> Fedora will ship (it's currently under review) a kdepim4 package containing
>> KNode and KTimeTracker, which are not included in the new KF5 kdepim.
> 
> Oh?:)
> Fedora continue to support some programs which are not supported from several 
> years before kdepim5 ?
> Interesting good luck :)
> 
> Better solution to find others new programs which are maintaining no ?

Do you plan an akonadi resource for NNTP? :)

Ciao
-- 
Luigi

Re: [Kde-pim] Qt 4 Builds

[Luigi Toscano]

laurent Montel ha scritto:
> Le dimanche 27 mars 2016, 14:02:26 CEST Luigi Toscano a écrit :
>> laurent Montel ha scritto:
>>> Le dimanche 27 mars 2016, 11:58:07 CEST Kevin Kofler a écrit :
>>>> laurent Montel wrote:
>>>>> We will not create more release from kdepim4, no distro uses it even
>>>>> debian :)
>>>>
>>>> Fedora will ship (it's currently under review) a kdepim4 package
>>>> containing
>>>> KNode and KTimeTracker, which are not included in the new KF5 kdepim.
>>>
>>> Oh?:)
>>> Fedora continue to support some programs which are not supported from
>>> several years before kdepim5 ?
>>> Interesting good luck :)
>>>
>>> Better solution to find others new programs which are maintaining no ?
>>
>> Do you plan an akonadi resource for NNTP? :)
> 
> It's necessary to have an application which use akonadi ?
> For sure Akregator kf5 doesn't use akonadi and it's not a problem.
> 
> (and yes there was a nntp akonadi resource in kde4 removed in kf5 as unused)

No, it's not necessary, but when KNode was removed I thought that the idea was
to integrate the NNTP viewing inside KMail, more or less like what Thunderbird
does. Hence my question.

Ciao
-- 
Luigi

Review Request 127515: Port away keditbookmarks from KCmdLine* and K4AboutData

[Luigi Toscano]

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

Review request for KDE Base Apps and David Faure.


Repository: kde-baseapps


Description
---

Starting point: the output of convert-kcmdlineargs.pl

Then cleanups: moved statements as suggested by scripts comments; converted the 
remaining items (ki18n, etc); fixed headers; added consts, QStringLiteral, 
translation domain; fixed termination on parser validity errors (away from 
KCmdLineArgs::usage); etc, etc.

Set keditbookmarks version to 5.0.

Explicitly added KI18n and CoreAddons to the required libraries (cmake).

Commented out app.disableSessionManagement in kbookmarkmerger for now (probably 
not critical anyway).

-
If this proves to be correct, can I push directly push further porting 
commits/cleanups to keditbookmarks (hoping for a standalone KF5 release in the 
not far future) or do you prefer to review all changes?


Diffs
-

  keditbookmarks/CMakeLists.txt b44f389 
  keditbookmarks/kbookmarkmerger.cpp 5f17a98 
  keditbookmarks/main.cpp 4302318 

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


Testing
---

Compile, the two programs can run, now with proper version details. No apparent 
regression in parameter parsing.


Thanks,

Luigi Toscano

Re: Review Request 127515: Port away keditbookmarks from KCmdLine* and K4AboutData

[Luigi Toscano]

> On March 29, 2016, 9:02 a.m., David Faure wrote:
> > Yes you can push further cleanups directly.

Thanks, I'm updating the review with the required changes for references and 
then I will push it.


- Luigi


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


On March 28, 2016, 6:06 p.m., Luigi Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127515/
> ---
> 
> (Updated March 28, 2016, 6:06 p.m.)
> 
> 
> Review request for KDE Base Apps and David Faure.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> ---
> 
> Starting point: the output of convert-kcmdlineargs.pl
> 
> Then cleanups: moved statements as suggested by scripts comments; converted 
> the remaining items (ki18n, etc); fixed headers; added consts, 
> QStringLiteral, translation domain; fixed termination on parser validity 
> errors (away from KCmdLineArgs::usage); etc, etc.
> 
> Set keditbookmarks version to 5.0.
> 
> Explicitly added KI18n and CoreAddons to the required libraries (cmake).
> 
> Commented out app.disableSessionManagement in kbookmarkmerger for now 
> (probably not critical anyway).
> 
> -
> If this proves to be correct, can I push directly push further porting 
> commits/cleanups to keditbookmarks (hoping for a standalone KF5 release in 
> the not far future) or do you prefer to review all changes?
> 
> 
> Diffs
> -
> 
>   keditbookmarks/CMakeLists.txt b44f389 
>   keditbookmarks/kbookmarkmerger.cpp 5f17a98 
>   keditbookmarks/main.cpp 4302318 
> 
> Diff: https://git.reviewboard.kde.org/r/127515/diff/
> 
> 
> Testing
> ---
> 
> Compile, the two programs can run, now with proper version details. No 
> apparent regression in parameter parsing.
> 
> 
> Thanks,
> 
> Luigi Toscano
> 
>

Re: Review Request 127515: Port away keditbookmarks from KCmdLine* and K4AboutData

[Luigi Toscano]

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

(Updated March 29, 2016, 10:40 p.m.)


Review request for KDE Base Apps and David Faure.


Changes
---

Update with the requested fixes for reference.


Repository: kde-baseapps


Description
---

Starting point: the output of convert-kcmdlineargs.pl

Then cleanups: moved statements as suggested by scripts comments; converted the 
remaining items (ki18n, etc); fixed headers; added consts, QStringLiteral, 
translation domain; fixed termination on parser validity errors (away from 
KCmdLineArgs::usage); etc, etc.

Set keditbookmarks version to 5.0.

Explicitly added KI18n and CoreAddons to the required libraries (cmake).

Commented out app.disableSessionManagement in kbookmarkmerger for now (probably 
not critical anyway).

-
If this proves to be correct, can I push directly push further porting 
commits/cleanups to keditbookmarks (hoping for a standalone KF5 release in the 
not far future) or do you prefer to review all changes?


Diffs (updated)
-

  keditbookmarks/CMakeLists.txt b44f389 
  keditbookmarks/kbookmarkmerger.cpp 5f17a98 
  keditbookmarks/main.cpp 4302318 

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


Testing
---

Compile, the two programs can run, now with proper version details. No apparent 
regression in parameter parsing.


Thanks,

Luigi Toscano

Re: Review Request 127515: Port away keditbookmarks from KCmdLine* and K4AboutData

[Luigi Toscano]

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

(Updated March 29, 2016, 1:43 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Base Apps and David Faure.


Changes
---

Submitted with commit f7266d77bd11c678689bc64bdc5697f7ad1c76fd by Luigi Toscano 
to branch frameworks.


Repository: kde-baseapps


Description
---

Starting point: the output of convert-kcmdlineargs.pl

Then cleanups: moved statements as suggested by scripts comments; converted the 
remaining items (ki18n, etc); fixed headers; added consts, QStringLiteral, 
translation domain; fixed termination on parser validity errors (away from 
KCmdLineArgs::usage); etc, etc.

Set keditbookmarks version to 5.0.

Explicitly added KI18n and CoreAddons to the required libraries (cmake).

Commented out app.disableSessionManagement in kbookmarkmerger for now (probably 
not critical anyway).

-
If this proves to be correct, can I push directly push further porting 
commits/cleanups to keditbookmarks (hoping for a standalone KF5 release in the 
not far future) or do you prefer to review all changes?


Diffs
-

  keditbookmarks/CMakeLists.txt b44f389 
  keditbookmarks/kbookmarkmerger.cpp 5f17a98 
  keditbookmarks/main.cpp 4302318 

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


Testing
---

Compile, the two programs can run, now with proper version details. No apparent 
regression in parameter parsing.


Thanks,

Luigi Toscano

Re: kdewebkit?

[Luigi Toscano]

On Thursday 21 of April 2016 08:45:44 Scarlett Clark wrote:
> https://build.kde.org/job/kdewebkit%20master%20kf5-qt5/PLATFORM=Linux,compil
> er=gcc/32/console
> 
> And if I understand correctly, qt webkit is no more? So should this project
> be removed from CI?


IIRC as long as we support Qt <5.6, we can't kill it. Moreover, not all 
software has been ported, (and you can always compile it even with newer Qt).

-- 
Luigi

Re: kolourpaint now KF5 based

[Luigi Toscano]

Martin Koller ha scritto:
> Hi all,
> 
> just wanted to let you know that I have now completed the kolourpaint port to 
> KF5
> and this is now in its master branch. I have also updated kde-build-metadata
> Hope I did all correct.

I'm going to update the i18n branches on repo-metadata (which generated
kde_projects.xml) and move the translations.

Do you know that there is a thread on kde-devel@ about the status of the
Frameworks version of Kolourpaint?
I see you don't depend anymore on qimageblitz. Would you reintroduce the
dependency if qimageblitz was released for Qt5? Jeremy was working on it.

Ciao
-- 
Luigi

Re: Can't release applications

[Luigi Toscano]

On Wednesday, 27 July 2016 12:22:45 CEST Aleix Pol wrote:
> Hi,
> There's a major blocker when trying to release applications nowadays.
> To update the stable branch one needs to commit to the
> kde:sysadmin/repo-metadata.git repository, which can't be accessed by
> KDE Project maintainers.
> 
> How can we solve this?

When you release, don't you file sysadmin tickets anyway for uploading the 
files and other steps?

Fixing the details in repo-metadata is another step that can go in the ticket.

(I also have access there, even if I mostly update the l10n branches).

-- 
Luigi

Re: Review Request 128684: Proofread + update khtml-general kcm docbook

[Luigi Toscano]

> On Ago. 16, 2016, 9:05 a.m., David Faure wrote:
> > doc/kcontrol/khtml-general/index.docbook, line 51
> > 
> >
> > Well, qt5-webkit and kwebkitpart do still exist. They're just not 
> > really maintained (but then again that is a problem for konqueror itself as 
> > well, especially due to being built on top of deprecated web engines...). 
> > (I hate this situation.)
> 
> Burkhard Lück wrote:
> Thanks to your hints I just detected that kwebkitpart has a frameworks 
> branch. Building this branch I get the webkit engine back in konqueror kf5.
> But kwebkitpart frameworks branch is unreleased, stable/released branch 
> is 1.3 kde4 based, master as well.
> So should I update the docbooks for konqueror with kwebkitpart/frameworks 
> branch?
> 
> Burkhard Lück wrote:
> > So should I update the docbooks for konqueror with 
> kwebkitpart/frameworks branch?
> 
> kde-doc-english: please comment/answer my question
> thanks
> 
> Yuri Chornoivan wrote:
> +1

The kwerbkitpart is under construction, and there may be a qwebengine part 
instead or in addition. I would leave that part commented with a reminder to 
revisit it before the documentation freeze.


- Luigi


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


On Ago. 15, 2016, 1:40 p.m., Burkhard Lück wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128684/
> ---
> 
> (Updated Ago. 15, 2016, 1:40 p.m.)
> 
> 
> Review request for Documentation, KDE Base Apps, Plasma, and David Faure.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> proofread + update
> comment webkit
> 
> code in kde-baseapps - docbook in plasma-desktop?
> 
> 
> Diffs
> -
> 
>   doc/kcontrol/khtml-general/index.docbook 1b9c80e 
> 
> Diff: https://git.reviewboard.kde.org/r/128684/diff/
> 
> 
> Testing
> ---
> 
> passes checkXML5
> 
> 
> Thanks,
> 
> Burkhard Lück
> 
>

Re: Review Request 128803: Import konqueror kcm docbooks from kde-runtime master

[Luigi Toscano]

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



I was wondering about splitting kde-baseapps; in that case, this change should 
be applied later to the split repositories.

- Luigi Toscano


On Ago. 30, 2016, 4:01 p.m., Burkhard Lück wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128803/
> ---
> 
> (Updated Ago. 30, 2016, 4:01 p.m.)
> 
> 
> Review request for KDE Base Apps and David Faure.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> ---
> 
> doc/kcontrol/bookmarks/ doc/kcontrol/filemanager/ doc/kcontrol/history/ 
> doc/kcontrol/kcmcss/ doc/kcontrol/khtml-adblock/ doc/kcontrol/khtml-behavior/ 
> doc/kcontrol/khtml-general/ doc/kcontrol/khtml-java-js/ 
> doc/kcontrol/khtml-plugins/ doc/kcontrol/performance/
> splitted from kde-runtime master using https://github.com/ajdruff/git-splits
> 
> Not included in build so far, the CMakeLists.txt and the dtd have to be 
> adapted to kf5
> 
> If this is pushed to kde-baseapps master, the kcontrol subdirs in 
> plasma-desktop have to be removed, see 
> https://git.reviewboard.kde.org/r/128685/
> 
> 
> Diffs
> -
> 
>   doc/kcontrol/bookmarks/CMakeLists.txt PRE-CREATION 
>   doc/kcontrol/bookmarks/index.docbook PRE-CREATION 
>   doc/kcontrol/filemanager/CMakeLists.txt PRE-CREATION 
>   doc/kcontrol/filemanager/index.docbook PRE-CREATION 
>   doc/kcontrol/history/CMakeLists.txt PRE-CREATION 
>   doc/kcontrol/history/index.docbook PRE-CREATION 
>   doc/kcontrol/kcmcss/CMakeLists.txt PRE-CREATION 
>   doc/kcontrol/kcmcss/index.docbook PRE-CREATION 
>   doc/kcontrol/khtml-adblock/CMakeLists.txt PRE-CREATION 
>   doc/kcontrol/khtml-adblock/index.docbook PRE-CREATION 
>   doc/kcontrol/khtml-behavior/CMakeLists.txt PRE-CREATION 
>   doc/kcontrol/khtml-behavior/index.docbook PRE-CREATION 
>   doc/kcontrol/khtml-general/CMakeLists.txt PRE-CREATION 
>   doc/kcontrol/khtml-general/index.docbook PRE-CREATION 
>   doc/kcontrol/khtml-java-js/CMakeLists.txt PRE-CREATION 
>   doc/kcontrol/khtml-java-js/index.docbook PRE-CREATION 
>   doc/kcontrol/khtml-plugins/CMakeLists.txt PRE-CREATION 
>   doc/kcontrol/khtml-plugins/index.docbook PRE-CREATION 
>   doc/kcontrol/performance/CMakeLists.txt PRE-CREATION 
>   doc/kcontrol/performance/index.docbook PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/128803/diff/
> 
> 
> Testing
> ---
> 
> history looks good, see git-log-doc-kcontrol.txt
> 
> 
> File Attachments
> 
> 
> git-log-doc-kcontrol.txt
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/08/30/fd446511-8b66-48c3-ab4f-97086d79f090__git-log-doc-kcontrol.txt
> 
> 
> Thanks,
> 
> Burkhard Lück
> 
>

Re: Splitting kde-baseapps?

[Luigi Toscano]

On Wednesday, 14 September 2016 15:46:28 CEST Burkhard Lück wrote:
> Hi,
> 
> what is the future of the kde-basapps repo?
> 
> It consists of:
> 
> 1) Konqueror code + docbooks in subdirs doc, konq-plugins,  konqueror  + lib
> 
> 2) kfind code + docbook in subdir kfind
> 
> 3) kdepasswd (don't we have already a similar dialog in frameworks/
> kwidgetaddons?)
> 
> 4) kdialog
> 
> 5) keditbookmarks (documentation is part of konqueror docbooks)
> 
> See also https://git.reviewboard.kde.org/r/128803/


I spoke briefly with David about this. The simpler scripts that I tried to 
split the repo simply forget something (like the history of doc/ which was 
moved around; I tried with kfind, which is already prepared for the split from 
the structural point of view). I'm waiting for a script used by the PIM team 
to see if it improves that.

-- 
Luigi

Re: announcement: Kwave is in kdereview

[Luigi Toscano]

Thomas Eschenbacher ha scritto:
> Hello,
> 
> according to
> https://community.kde.org/Policies/Application_Lifecycle#Stage_2:_Stable
> I hereby announce the move of Kwave to "kdereview", on it's way to
> "kdemultimedia".
> 
> Kwave is a sound editor built on KF5 and exists since November 1998. I
> am the maintainer of that project since ~2000 and still actively working
> on it.
> 
> Currently Kwave is in "kdereview" (for quite a while) and my initial
> intention was to get it into KEG. But as I found out, KEG no longer
> exists (although it is mentioned in the web site mentioned above) and I
> also came to the conclusion that kdemultimedia would be a better place
> for it.

While "extragear" is not the official name for a place anymore, if your
application has its own release schedule, detached from other released
"products" by KDE, then you may see that some internal tooling consider it
"extragear".
So it moves to the question: do you want to release with "KDE Applications",
adhere to that release schedule (major release every 4 months, with specific
freezes, etc)? If yes, then "kdemultimedia" is the place, if not it's
"extragear-multimedia". Which means that kwave will be released when you
release it.


> 
> Background:
> This is attempty #5. The first one (~2005) has hit the migration from
> CVS to SVN and I was asked to postpone it. The second one was ~2009,
> there I hit the migration from SVN to GIT. The third one was 2013, and
> finally 2015 I got into kdereview, where the project resides right now -
> and waits for approval to go further into kdemultimedia.
This is a bit unfortunate. I can say that someone could have helped pushing
the kdereview process when you entered kdereview. kdereview is not a place for
long staying, while in your case you had releases from it, which makes things
a bit complicated for some internal tools.
That said, we can move forward with the review process (which is the entire
core of the meaning of "being kdereview").

-- 
Luigi

Re: announcement: Kwave is in kdereview

[Luigi Toscano]

Burkhard Lück ha scritto:
> Am Sonntag, 9. Oktober 2016, 11:44:16 CEST schrieb David Faure:
>> 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.
> 
> https://api.kde.org/frameworks/ki18n/html/prg_guide.html#link_prog says:
> 
> Connecting to Catalogs in Application Code
> All *i18n* calls in an application can be connected to a single domain by 
> calling the static KLocalizedString::setApplicationDomain method with the 
> domain as the argument:
> 
> Therefore KLocalizedString::setApplicationDomain seems to be correct
> 

And -DTRANSLATION_DOMAIN= is for libraries, as explained in the next
section:
https://api.kde.org/frameworks/ki18n/html/prg_guide.html#link_lib


Ciao
-- 
Luigi

Re: Dropping kdelibs4-based applications in KDE Applications 17.12

[Luigi Toscano]

On Friday, 11 November 2016 18:24:42 CET Christoph Feck wrote:
> On 11.11.2016 16:45, Dominik Haumann wrote:
> > On Thu, Nov 10, 2016 at 11:42 PM, Albert Astals Cid  wrote:
> >> Hi, my proposal would be to make KDE Applications 17.08 the last release
> >> we
> >> accept applications based on kdelibs4, that means people have a year
> >> until KDE Applications 17.12 to port the applications from the list
> >> below to KF5.
> >> 
> >> The ones that aren't ported we would just drop to unmaintained or if they
> >> have an active developer team that somehow doesn't want to move to KF5
> >> they could move to "extreagear".
> 
> Will we still release the KDE4 platform for not-yet-ported extragear
> applications (Amarok etc.) with 17.12?
> 
> If we stop releasing it, then we should also move all unported
> applications to 'unmaintained'. Any developer willing to port can
> surrect it from there.

I don't see a direct connection. This discussion is about KDE Applications, 
and while I totally agree on having extragear applications ported as well as 
soon as possible and we should try to see which active applications are still 
unported, forcing them from not being released is a bit too much (i.e. they 
could release bugfixes for kdelibs4 versions, for example).

> 
> >> I know lots of you would want to see this happen *now* but remember
> >> there's
> >> people using those apps so dropping them makes them no good.
> >> 
> >> Comments?
> > 
> > I think this is a very good idea and support this.
> > 
> > However, the list you provided is possibly longer, for instance there
> > are applications that are not part of this the Applications release. I
> > *know* that this sounds like it's off-topic, but I don't think it is
> > for the following reason:
> > 
> > What do you think about having a Randa meeting (or similar) with focus
> > on finishing ports to KF5? Would that make sense?
> 
> If we had developers with free time for other projects, that time would
> be better spent on helping projects such as KDEPIM, rekonq, or Calligra.
> These are applications several of our users would switch to if they worked.

That would be a huge help.

> 
> > I'm thinking of apps like Kile or similar that while already ported,
> > still don't have a stable release. I'm pretty sure there are many
> > more.
> 
> As far as I know, Kile developer had to wait for the KF5 release of Okular.

That's what I knew as well.

> 
> > Such an initiative would also show that we don't simply drop old apps,
> > instead, we would show that we care to bring along as many apps as we
> > can.
> 
> But we also need someone caring for bugreports/regressions after the
> port. We have some applications ported (e.g. KTorrent) where the
> original developer no longer has time for bug handling, and now the
> regressions pile up.

Yes, afaik one of the reasons why it was not packaged in Debian yet 
(regressions).

-- 
Luigi

Re: Kwave is in kdemultimedia now

[Luigi Toscano]

Christoph Feck ha scritto:
> On 11.11.2016 20:41, Thomas Eschenbacher wrote:
>> as suggested by Ben, I hereby to inform you that today
>> Kwave has been moved to kdemultimedia :)
> 
> Thanks for your patience :) Did sysadmins also add an entry at reviewboard or
> phabricator for code reviews? If not, which would
> you prefer?

I would say that it's pointless for new projects to create reviewboard entries
at this point. It would be good to start fresh directly with Phabricator. I
can create the project and the observer repository.

-- 
Luigi

Re: Kwave is in kdemultimedia now

[Luigi Toscano]

Luigi Toscano ha scritto:
> Christoph Feck ha scritto:
>> On 11.11.2016 20:41, Thomas Eschenbacher wrote:
>>> as suggested by Ben, I hereby to inform you that today
>>> Kwave has been moved to kdemultimedia :)
>>
>> Thanks for your patience :) Did sysadmins also add an entry at reviewboard or
>> phabricator for code reviews? If not, which would
>> you prefer?
> 
> I would say that it's pointless for new projects to create reviewboard entries
> at this point. It would be good to start fresh directly with Phabricator. I
> can create the project and the observer repository.
> 

That said, the kwave repository is available already on reviewboard (it has
been for a while). The offer for Phabricator items still stands.

-- 
Luigi

Re: Kwave is in kdemultimedia now

[Luigi Toscano]

On Tuesday, 15 November 2016 06:52:26 CET Thomas Eschenbacher wrote:
> Luigi Toscano wrote:
> > Luigi Toscano ha scritto:
> >> Christoph Feck ha scritto:
> >>> On 11.11.2016 20:41, Thomas Eschenbacher wrote:
> >>>> as suggested by Ben, I hereby to inform you that today
> >>>> Kwave has been moved to kdemultimedia :)
> >>> 
> >>> Thanks for your patience :) Did sysadmins also add an entry at
> >>> reviewboard or phabricator for code reviews? If not, which would
> >>> you prefer?
> >> 
> >> I would say that it's pointless for new projects to create reviewboard
> >> entries at this point. It would be good to start fresh directly with
> >> Phabricator. I can create the project and the observer repository.
> > 
> > That said, the kwave repository is available already on reviewboard (it
> > has
> > been for a while). The offer for Phabricator items still stands.
> 
> Well... that's a good question!
> 
> I tried to find out what is the "must have" feature that would make me
> say "yes", but I am not sure.
> 
> I think I already have all things that I need (and even more, the KDE
> infrastructure is really great!!!), and offering two different tools for
> bugtracking, reviewing, contributing and so on - wouldn't that confuse
> the users and bear the risk of having duplicates in the databases? Or
> are the databases behind coupled in some way?

We don't offer two tools. We are moving to some tools (reviewboard, kanboard) 
to others (phabricator) for some tasks. Bugs are not going to be moved from 
bugs.kde.org (task tracking in phabricator and bug tracking are not exactly 
the same thing).

> I am a friend of the philosophy "one project - one tooling", so I guess
> when I say yes to Phabricator it would be wise to switch off the already
> existing alternatives?

I'm not sure if we can easily close reviewboard for specific projects. I would 
simply advertise the new tool.

-- 
Luigi

Re: kio-gdrive - was - Re: New project moved to review

[Luigi Toscano]

In data domenica 20 novembre 2016 13:24:50 CET, Elvis Angelaccio ha scritto:
> On Sun, Nov 20, 2016 at 12:39 PM, Boudhayan Gupta  wrote:
> > Hi all,
> > 
> > I seem to have missed this discussion and since there's a ticket to
> > move this I've become aware of this now, and am asking here.
> > 
> > If we *are* to move to extragear, Extragear/network is the more
> > appropriate location for this. Reasons:
> > 
> > 1) GDrive is not PIM related - it is networked file storage.
> > 
> > 2) It depends on a Google Account, sure, but that account does not
> > need to have GMail enabled on it. It need have nothing else enabled on
> > it but Google Drive.
> > 
> > 3) If I'm browsing the archives, I'm never going to think looking into
> > PIM for a Google Drive client. I *will* look at network though.
> > 
> > Inputs?
> 
> I think both locations would be fine (and in fact, it used to live in
> playground/network). I proposed to move it to PIM because it depends
> on libkgapi which is a PIM library. This would avoid a "cross-module"
> dependency, but perhaps this is not an issue? 

IMHO it is not an issue. Extragear means "something with its own release 
schedule", so it does not really matter.
I see it too closer to network than pim.

> Though imho the ideal
> solution would be making libkgapi a framework (but requires someone
> willing to do the work).
That's up to Dan, but I don't think it would prevent kio-gdrive from being 
moved (or kept in) to network

Ciao
-- 
Luigi

Re: kio-gdrive - was - Re: New project moved to review

[Luigi Toscano]

Elvis Angelaccio ha scritto:
> 
> Sysadmin has moved kio-gdrive to extragear/network.
> 
> @Luigi: can you please update the i18n metadata?

I answered on IRC BUT for the record (and to avoid https://xkcd.com/979/),
translations have been moved to the proper module and repo-metadata has been
updated as well.
Also, the stable5 i18n branch was set to track the "1.0" branch.

Ciao
-- 
Luigi

Re: Review Request 129644: i10n: update Czech Republic to Czechia

[Luigi Toscano]

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



Ahoj, out of curiosity: this is for kdelibs4 applications, how was handled in 
the sources used by Qt5 applications? I don't think we have those information 
in Frameworks anymore.

It would maybe worth to have consistency between the value of Frameworks 5 and 
kdelibs4 applications.

- Luigi Toscano


On Dec. 13, 2016, 12:36 a.m., Jiri Bohac wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129644/
> ---
> 
> (Updated Dec. 13, 2016, 12:36 a.m.)
> 
> 
> Review request for KDE Runtime and Localization and Translation (l10n).
> 
> 
> Repository: kde-runtime
> 
> 
> Description
> ---
> 
> This year, the country has oficially adopted the short name Czechia.
> The short name has been entered to the UNTERM and UNGEGN databases in July 
> 2016
> Czechia is used in iso_3166 since September 2016
> 
> 
> Diffs
> -
> 
>   l10n/cz/entry.desktop 05297c3 
> 
> Diff: https://git.reviewboard.kde.org/r/129644/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jiri Bohac
> 
>

Re: announcement: plymouth-kcm in kdereview

[Luigi Toscano]

Jonathan Riddell ha scritto:
> On Thu, Dec 29, 2016 at 12:58:10PM +0100, Marco Martin wrote:
>> Hi all,
>> announcing a new KCM module to change the plymouth splash screen
>> The repository is named plymouth-kcm and is headed for kdereview now.
>> its final resting place would be the workspace area, to be released in sync 
>> with the rest of Plasma
> 
> [...]
> There's no docs, I don't know if anyone cares about these for kcms any
> more, probably not.  Seems a general System Settings issue, the Help
> button is shown but does nothing when I click it even for
> e.g. kcmshell5 colors. This works again when I install khelpcenter but
> it should have sensible fallback like apps do.  Except the apps launch
> a web page which doesn't exist.  Is it time to just give up on docs
> and accept they're not actually that important?

Interesting, the fallback is in the libraries, and it should definitely work
in this case if it does not. We have the documentation for many KCMs.
It opens a web page that does not exist because there is no documentation now.

> 
> [...]
> No Product in Phabricator

This is not correct, the repository is available:
https://phabricator.kde.org/source/plymouth-kcm/

You don't need a separate project for it, and anyway the Plasma project is
already assigned to it.

-- 
Luigi

Re: imagewriter in kdereview

[Luigi Toscano]

Jonathan Riddell ha scritto:
> Please review imagewriter which I've just had moved to kdereview.
> 
> It's a simple tool to write ISO images to a USB key.  It should be
> cross platform and work on Linux, mac, windows.
> 
> It's based on ROSA Image Writer and the ROSA maintainer has agreed to
> maintain it in KDE.  Compared to ROSA I've switched to i18n and used
> kauth and made the ROSA branding optional.

Does it mean that the make-it-cool branch will be merged to master soon?
The current master has no support for KI18n (and not even for
ecm_install_po_files_as_qm). I think that it's better to wait until it's
merged before enabling the translations.

-- 
Luigi

Re: Zanshin is in kdereview

[Luigi Toscano]

On Monday, 19 June 2017 18:50:23 CEST Kevin Ottens wrote:
> Hello,
> 
> On Tuesday, 13 June 2017 00:07:01 CEST Albert Astals Cid wrote:
> > Have you read the page that speaks about how to write Messages.sh files?
> > It's quite good. Please read it and explain what you don't understand.
> 
> It's more that I don't quite see clearly the distribution of the .po and
> such after the Message.sh is run.
> 
> That being said, wouldn't that be more natural to either extend extractrc to
> spit out mock QObject::tr() calls? Or to have the Message.sh run perl on
> the file?
> 
> Sounds cleaner to me than having several catalogs loaded for an otherwise
> self-contained application.

I haven't checked the code, but the idea is that:
- messages handled by Qt translation system should end up in the _qt 
file;
- messages from KI18n should end up in a file or a set of files named as you 
want (you just need to set the proper domain which matches the file name).

So please try to follow these guidelines. If the application already uses 
KI18n directly or indirectly, I would just use it for everything.

-- 
Luigi

Re: Zanshin is in kdereview

[Luigi Toscano]

Kevin Ottens ha scritto:
> Hello,
> 
> On Monday, 19 June 2017 18:56:39 CEST Luigi Toscano wrote:
>> On Monday, 19 June 2017 18:50:23 CEST Kevin Ottens wrote:
>>> On Tuesday, 13 June 2017 00:07:01 CEST Albert Astals Cid wrote:
>>>> Have you read the page that speaks about how to write Messages.sh files?
>>>> It's quite good. Please read it and explain what you don't understand.
>>>
>>> It's more that I don't quite see clearly the distribution of the .po and
>>> such after the Message.sh is run.
>>>
>>> That being said, wouldn't that be more natural to either extend extractrc
>>> to spit out mock QObject::tr() calls? Or to have the Message.sh run perl
>>> on the file?
>>>
>>> Sounds cleaner to me than having several catalogs loaded for an otherwise
>>> self-contained application.
>>
>> I haven't checked the code, but the idea is that:
>> - messages handled by Qt translation system should end up in the _qt
>> file;
>> - messages from KI18n should end up in a file or a set of files named as you
>> want (you just need to set the proper domain which matches the file name).
>>
>> So please try to follow these guidelines. If the application already uses
>> KI18n directly or indirectly, I would just use it for everything.
> 
> I find unfortunate we actively discourage being able to work without ki18n in 
> such case. But OK, got better things to do I'll stop fighting this one.

We are not discouraging anyone.
You can definitely work without KI18n, or mixing Qt-only modules with
KI18n-managed modules. Marble and Step are two example of this, and this is
not because we like it or not but there are specific technical reasons for it.

In this case, every module which links to kparts should use KI18n, but you can
have pure Qt libraries (even static) which uses ::tr. And of course you need
two translations files.

I'm not sure why you didn't like the above solution. Now, can we properly
discuss this? I don't want people coming back and saying that a solution was
forced for $reasons when it was not forced at all.
(that said, KI18n is better, but again you don't need to use it).


> 
> This one switches it all to i18n: https://phabricator.kde.org/D6283

I'm going to put a -1 until we discuss this properly.

Ciao
-- 
Luigi

Re: Ksysguard dev

[Luigi Toscano]

On Monday, 19 June 2017 20:50:25 CEST Alexandre Biche wrote:
> Hi guys,
> I want to add network I/O stats to ksysguard but I you closed
> kde-workspace's github repo and I don't find the plasma 5 github repo.
> Can you give me the way to start contributing please


Github is a mirror; kde-workspace is the kdelibs4 version.

Also (all the page, and "Getting the code"):
https://community.kde.org/Get_Involved/development

-- 
Luigi

Re: Moving AtCore to Extragear

[Luigi Toscano]

Albert Astals Cid ha scritto:
> El diumenge, 18 de juny de 2017, a les 9:48:07 CEST, Lays Rodrigues va 
> escriure:
>> Hey guys, good morning. =D
>> Any more comments on AtCore code?
>> How the moving to Extragear work?
> 
> Are you planning to at least answer my last comments saying "we don't really 
> care about that level of perfection"? (which is a fair position)
> 

In addition to Albert's comment, I noticed now (still going through the
backlog after vacation) that atcore use tr() for messages, but there is no
Messages.sh file to extract the strings (which should be called atcore_qt,
check the similar files in step or marble or in tier1 frameworks).

Unfortunately the repository was already moved directly to extragear, and I
expressed already my disagreement about this move with still open questions.

-- 
Luigi

Re: Zanshin is in kdereview

[Luigi Toscano]

On Friday, 23 June 2017 16:08:31 CEST Kevin Ottens wrote:
> Hello,
> 
> On Tuesday, 20 June 2017 22:14:33 CEST Kevin Ottens wrote:
> > On Monday, 19 June 2017 21:50:16 CEST Luigi Toscano wrote:
> > > [...]
> > > I'm not sure why you didn't like the above solution.
> > 
> > Just more work over time, and I don't have the bandwidth ATM. Typically we
> > tend to assume ki18n and a single catalog as the common case (and rightly
> > so), so does releaseme assume that too? And then I have to think about
> > both
> > files for shipping, etc.
> > 
> > I just don't have the energy to think all that through so I'd rather go
> > the
> > lazy and easy path with the patch I did.
> > 
> > > Now, can we properly discuss this? I don't want people coming back and
> > > saying that a solution was forced for $reasons when it was not forced at
> > > all. (that said, KI18n is better, but again you don't need to use it).
> > > 
> > > > This one switches it all to i18n: https://phabricator.kde.org/D6283
> > > 
> > > I'm going to put a -1 until we discuss this properly.
> > 
> > Hope the above clarifies my reasons a bit.
> > 
> > In a nutshell: tr() was used for an hypothetical mobile port, this port is
> > still not in sight with the bandwidth I currently have and tr() is
> > creating
> > me troubles mainly due to the kparts plugins; so either I drop said
> > plugins
> > or I switch to i18n to be like everyone else. I'm going for being like
> > everyone else.
> > 
> > It can always be revisited later if there's really a mobile port or such
> > emerging.
> 
> Can we lift the -1, review that patch and move on now?

There is a legitimate request change linked to the -1, as stated in the 
review.

-- 
Luigi

Re: AtCore on KDE Review

[Luigi Toscano]

Lays Rodrigues ha scritto:
> Hi guys of kde-core.
> 
> Any new review of AtCore? =D

I think that there were questions open on your side. Did you address the two
issues, namely:

> On Fri, Jun 23, 2017 at 11:19 PM, Lays Rodrigues  wrote:

> -> aacid
> 
> "Partially, i personally still think it'd be better if you move the
> PrinterState AXIS and MeasuramentUnits enums inside AtCore (or make them 
> C++11
> "enum class").
> 
> Also note how PrinterState AXIS MeasuramentUnits is not consistent naming
> "
> 
> For that, I think this is the diff: https://phabricator.kde.org/D6363
> 

This seems to be merged; Albert, does it address your concern?


> 
> -> Luigui
> "In addition to Albert's comment, I noticed now (still going through the
> backlog after vacation) that atcore use tr() for messages, but there is no
> Messages.sh file to extract the strings (which should be called atcore_qt,
> check the similar files in step or marble or in tier1 frameworks)."​

I don't think that this has been addressed

-- 
Luigi