Re: Placement of config files for Plasma 5 and KF5-based applications

[Elias Probst]

On 01/28/2015 08:43 AM, Martin Gräßlin wrote:
> There was a change to put config files into org.kde.foo, but that had to be 
> reverted as it broke for setups like KWin where the configuration is not done 
> in the same process.

See:
http://lists.kde.org/?l=kde-frameworks-devel&m=139913479611824&w=2
https://git.reviewboard.kde.org/r/117989/ (reverted)




signature.asc
Description: OpenPGP digital signature

Re: Placement of config files for Plasma 5 and KF5-based applications

[Martin Steigerwald]

Am Mittwoch, 28. Januar 2015, 08:43:41 schrieb Martin Gräßlin:
> On Tuesday 27 January 2015 01:01:27 Thomas Pfeiffer wrote:
> > Hi everyone,
> > first of all, I think it's a great step in the right direction that
> > we're now putting our config files in ~/.config instead of ~/.kde(4),
> > we're now finally "standard-compliant".
> > 
> > However, where we still could - and imho should - do better is with
> > where exactly we put them. If I look at my .config folder, I see
> > mostly folders there, and then a lot of KDE files directly on the top
> > level. If everyone would do that, .config would be a huge mess of
> > files and it would be difficult to find the one you're looking for.
> > We should not be the "bad boy" here.
> > 
> > The question is: Where should we put the files? Putting them all in a
> > .config/kde folder again would be possible and would clear up the
> > top-level clutter, but I think we could go further.
> > In fact, I don't see a reason why config files from otherwise
> > completely unrelated applications that only have in common that they
> > were made by KDE should all reside in the same folder, whereas other
> > applications each have their own folder.
> > 
> > What could make sense is having e.g. everything from Calligra in one
> > folder, or everything from KDE Edu or KDE Games.
> > And I'd put all Plasma stuff into one folder. Actually, there already
> > is a plasma-workspace folder on my system, which contains an "env"
> > and a "shutdown" folder. Why not put Plasma-related config files in
> > there?
> > 
> > I also have a "KDE" folder with Marble Virtual Globe.conf and
> > Sonnet.conf in there, and a kde.org folder with libphonon.conf and
> > marble.conf. This doesn't make us look very professional, as it shows
> > that there is currently no guideline for where to put our config
> > files.
> > I think we should change that!
> > 
> > So, for me there are three questions:
> > 1. Should we come up with guidelines for config file placement?
> > 2. Does my suggestion above make sense or if now how should it be done
> > instead?
> > 3. If we want guidelines, how do we make them known and maybe even
> > "enforce" them via code checking or some such?
> 
> There was a change to put config files into org.kde.foo, but that had to
> be reverted as it broke for setups like KWin where the configuration is
> not done in the same process.
> 
> Given that at least for KWin I do not want to do any changes as
> a) the risk of breakage is too high
> b) it's too much work (all code needs to be hunted down for usage of
> "kwinrc" (git grep shows 46 usages just in kwin, no idea how spread out
> it is in other places to configure kwin) or KSharedConfig::openConfig
> and similar)

Wow. I thought there would be one define that the config file is there and 
there and it would be used in all places.

> c) I simply don't care whether users have a "problem" with
> ~/.config containing many files, it's a directory for applications, not
> for the user

I think having all KDE related configs together in one place has an 
advantage:

One can recover the KDE configuration with a simple rsync command from 
backup, without affecting any non KDE stuff.

I did so in the past. It has been quite a while since I last did it, as 
KDE / Plasma configuration does not seem to be easy to break, but I still 
think its a valuable feature to have all KDE related things in one place.

"its not for the user" is no reasoning I agree with. Most config files are 
plain text, there are even special options that may only be available in 
the config file and in case of any breakage that cannot be fixed within the 
GUI its nice to be able to fix things on the config file level.

But well, there has been discussion about config file format on kde-pim 
mailing list as well, and whether to store them as binary data or not. And 
granted KMail / Akonadi and others store things in there that seems to me 
to be application *state* not *user configuration* and it may make sense to 
separate those.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

signature.asc
Description: This is a digitally signed message part.

Re: Placement of config files for Plasma 5 and KF5-based applications

[Thomas Pfeiffer]

On Wednesday 28 January 2015 18:07:14 Thomas Lübking wrote:
> On Mittwoch, 28. Januar 2015 08:43:41 CET, Martin Gräßlin wrote:
> > c) I simply don't care whether users have a "problem" with ~/.config
> > containing many files, it's a directory for applications, not for the user
> 
> I don't think this is much about "scaring the user" but how we behave wrt
> and align to xdg habits. To mie it seems the directories (most of them) in
> $HOME/.config specify the company name and there's indeed even a "kde.org"
> directory (contains marble, phonon and kcmshell stuff - no idea whether
> that's dated)

I agree with Thomas: This is not so much about your average user searching for 
config files as it is about being a good Linux (and I suppose POSIX in 
general) citizen and not being the only one who doesn't adhere to the rules 
(even if they're unwritten)

To me, it's also about giving a good impression to distributions and 
sysadmins. We want to appear professional, not chaotic, don't we?
 
> plasma-workspace related applications could redirect that to some
> ~/.config/plasma/ dir and if google starts using KF5, they'd naturally want
> to redirect that to ~/.config/Google - but I would argue that stuff that
> writes via KConfigGroup is (w/o further specification) "related enough" in
> managing it's config through KDE technology to write into some
> "~/.config/kde" dir.

I'll not interfere with the details because you guys know way more about that 
than I do, but we should put our files in _some_ directory below ~/.config

Build dependency issues with kdesrc-build

[Mathieu Tarral]

Hi,

I noticed an issue with the plasmate component, which is build
when you include kf5-workspace-build-include.

It has a build dependency on KDevPlatform, but this component is only
selected in kf5-applications-build-include.

So should we move plasmate into Applications ?
Or move KDevPlatform into Workspace ?

Regards.

-- 
Mathieu Tarral

Re: Another proposal for modernization of our infrastructure

[David Jarvie]

On Sat, January 31, 2015 8:25 pm, Boudewijn Rempt wrote:
> On Sat, 31 Jan 2015, Christoph Feck wrote:
>
>> On Saturday 31 January 2015 20:07:42 Eike Hein wrote:
>>> [...] Qt is using gerrit and we intend to remain a major stakeholde
>>> in Qt development, which means a sizable number of KDE developers
>>> need to be familiar with gerrit anyway [...]
>>
>> Excuse me, but if KDE developers will have to follow equivalent steps
>> as described at http://qt-project.org/wiki/Setting-up-Gerrit to
>> contribute, then I predict another big loss of developers.
>>
>> Christoph Feck (kdepepo)
>>
>
> Maybe quite a few KDE developers would want to contribute to Qt, and maybe
> Qt would like more contributors, but KDE is so much bigger -- I'd like to
> see some numbers, but I seriously doubt that the majority of KDE
> developers are potential Qt developers. Even if we have to work around Qt
> bugs quite often.
>
> In any case, if Qt wants more contributors out of the KDE developer pool,
> they'd better ease up their submission process and drop using gerrit. I
> know that I, and I've been a KDE developer for over a decade, won't do
> anything for Qt in my spare time as long as they have this gerrit-based
> workflow. If people are paying me for it, well, that's different, but no
> way am I going to submit to that process for fun and for for free.
>
> In short, Qt uses gerrit is a bogus argument in favor of gerrit. And I am
> pretty sure that if gerrit becomes a requirement for working on KDE
> projects, KDE will not just lose a lot of developers, it will lose a lot
> of projects.

+1

I occasionally contributed patches in the past to Qt, but since the
current gerrit setup was introduced I've never even contemplated doing so
because it looks too much effort to get to grips with. It's far too
off-putting for occasional contributors.

-- 
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm

Re: Review Request 122330: Associate *.qmltypes and *.qmlproject files with the text/x-qml mime type

[Milian Wolff]

> On Feb. 1, 2015, 8:32 p.m., David Faure wrote:
> > -1 for not submitting this upstream for shared-mime-info.
> > 
> > I took care of it, it's committed, will be in s-m-i 1.4.

Could we add a comment to this file then, telling people to work on upstream 
smi instead then?


- Milian


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


On Feb. 1, 2015, 7:28 p.m., Denis Steckelmacher wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122330/
> ---
> 
> (Updated Feb. 1, 2015, 7:28 p.m.)
> 
> 
> Review request for KDE Frameworks, kdelibs and KDevelop.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> The KDevelop QML/JS plugin sometimes needs to parse .qmltypes files (in order 
> to list the content of installed QML modules, for instance), but KDevelop 
> requires that files parsed using the QML/JS plugin have the text/x-qml mime 
> type.
> 
> Because .qmltypes and .qmlproject files are valid QML files (they follow the 
> standard QML syntax), this patch proposes to add these extensions to the ones 
> associated with the text/x-qml mime type.
> 
> 
> Diffs
> -
> 
>   src/mimetypes/kde5.xml cc9f71e 
> 
> Diff: https://git.reviewboard.kde.org/r/122330/diff/
> 
> 
> Testing
> ---
> 
> Installing kcoreaddons and updating the system MIME database allows KDevelop 
> to detect that files with the .qmltypes and .qmlproject extensions have to be 
> parsed using the QML/JS language support plugin. This allows QML files to use 
> QML modules installed system-wide (and fixes the unit tests of kdev-qmljs).
> 
> 
> Thanks,
> 
> Denis Steckelmacher
> 
>

Re: Another proposal for modernization of our infrastructure

[Jan Kundrát]

On Monday, 2 February 2015 11:22:57 CEST, David Jarvie wrote:

I occasionally contributed patches in the past to Qt, but since the
current gerrit setup was introduced I've never even contemplated doing so
because it looks too much effort to get to grips with. It's far too
off-putting for occasional contributors.


Seems that the Qt project has a big problem in the *perceived* complexity 
of getting involved, then. I'm saying perceived because you said that you 
did not try; the mere fact that they use a tool which has a rumour of being 
hard to use, along with the state of their documentation, suggests to you 
and to others that it is apparently a big pain to get involved. I 
understand that people do not want KDE to end up that way.


However, we also have people with little to no experience using Gerrit just 
fine. Shall we therefore focus on explaining that contributing through 
Gerrit is actually not painful?


The fact that the Qt project uses an obsolete version of Gerrit along with 
a non-stadard workflow and keep changing the branch names certainly doesn't 
help. I can see why it's confusing to "suddenly see no master branch", for 
example.


Anyway, the proposal which I have for solving this problem is about writing 
nice documentation. Maybe even screencasts showing how easy it can be for a 
total beginner to send their first patch.


With kind regards,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Another proposal for modernization of our infrastructure

[Milian Wolff]

On Saturday 31 January 2015 20:56:41 Martin Graesslin wrote:
> On Saturday 31 January 2015 20:37:31 Christoph Feck wrote:
> > On Saturday 31 January 2015 20:07:42 Eike Hein wrote:
> > > [...] Qt is using gerrit and we intend to remain a major stakeholde
> > > in Qt development, which means a sizable number of KDE developers
> > > need to be familiar with gerrit anyway [...]
> > 
> > Excuse me, but if KDE developers will have to follow equivalent steps
> > as described at http://qt-project.org/wiki/Setting-up-Gerrit to
> > contribute, then I predict another big loss of developers.
> 
> I have to agree. Whenever I need to do a change for Qt I need to google for
> how to do it. Including putting serious thought in how the push command must
> look like, how I need to adjust the examples provided and for which
> ref/for/foo it has to be this time. This is something which seriously
> concerns me with the outlook of gerrit. git has a steep learning curve,
> gerrit adds quite some further steepness to it :-(

Just add an alias for the refs, e.g. for 5.4 and dev, then use that in the 
future. `git qpush` and pick one, that's how I do it. E.g.:

[alias]
qpushdev = push gerrit HEAD:refs/for/dev

And yes, this is something that kdesrc-build could automate for us.

The rest of the above is independent of the actual tool. Even with reviewboard 
or phabricator, you'll need to know where to push your change. Bugfix? Latest 
stable release you want to support. New feature? dev.

Bye
-- 
Milian Wolff
m...@milianw.de
http://milianw.de

Re: Another proposal for modernization of our infrastructure

[Milian Wolff]

On Saturday 31 January 2015 21:34:40 Eike Hein wrote:
> On 01/31/2015 09:25 PM, Boudewijn Rempt wrote:
> > In short, Qt uses gerrit is a bogus argument in favor of gerrit.
> 
> The argument isn't so much that gerrit is working well
> for Qt, but more that there's a certain simplicity in
> using the same tooling across the KDE/Qt stack, and
> that KDE benefits from having more KDE people active in
> Qt. But I actually find contributing to Qt pretty frus-
> trating (the infra is flaky, the process tends to break
> down here and there, and I sometimes have to step out-
> side gerrit and side-channel via email to get things
> moving again), yeah.

Sigh, I find it highly sad to read this over and over again. People keep 
confusing the flaky CI and the high quality barrier in Qt with gerrit 
itself... Seriously, gerrit the tool is OK, what makes it hard and what is the 
actual barrier to entry in Qt are the flaky CI which kills productivity and 
then sometimes the odd reviews with a pretty harsh tone that demand an 
extraordinary quality without holding your hand much. But that's not related 
to gerrit... These are different things, so please people - lets not confuse 
these things and say using gerrit means using it exactly like Qt is using it!

Bye
-- 
Milian Wolff
m...@milianw.de
http://milianw.de

Re: Re: Another proposal for modernization of our infrastructure

[Martin Gräßlin]

On Monday 02 February 2015 13:17:21 Milian Wolff wrote:
> On Saturday 31 January 2015 20:56:41 Martin Graesslin wrote:
> > On Saturday 31 January 2015 20:37:31 Christoph Feck wrote:
> > > On Saturday 31 January 2015 20:07:42 Eike Hein wrote:
> > > > [...] Qt is using gerrit and we intend to remain a major stakeholde
> > > > in Qt development, which means a sizable number of KDE developers
> > > > need to be familiar with gerrit anyway [...]
> > > 
> > > Excuse me, but if KDE developers will have to follow equivalent steps
> > > as described at http://qt-project.org/wiki/Setting-up-Gerrit to
> > > contribute, then I predict another big loss of developers.
> > 
> > I have to agree. Whenever I need to do a change for Qt I need to google
> > for
> > how to do it. Including putting serious thought in how the push command
> > must look like, how I need to adjust the examples provided and for which
> > ref/for/foo it has to be this time. This is something which seriously
> > concerns me with the outlook of gerrit. git has a steep learning curve,
> > gerrit adds quite some further steepness to it :-(
> 
> Just add an alias for the refs, e.g. for 5.4 and dev, then use that in the
> future. `git qpush` and pick one, that's how I do it. E.g.:
> 
> [alias]
> qpushdev = push gerrit HEAD:refs/for/dev
> 
> And yes, this is something that kdesrc-build could automate for us.

How would kdesrc-build know that we just created a new branch? To me that 
looks like I would have to manually edit every time we branch in every repo I 
use. meh, meh, meh

Also we do not force new devs to use kdesrc-build. When I see new developers 
submitting there first patch, they hardly use kdesrc-build. So having that as 
a "oh it will be so simple" is something I do not buy :-(

> 
> The rest of the above is independent of the actual tool. Even with
> reviewboard or phabricator, you'll need to know where to push your change.
> Bugfix? Latest stable release you want to support. New feature? dev.

That's true and that's why I want to test out Phabricator to see how good the 
support is there. For review board at least I can just ignore the branch when 
pushing and fill in a free text form in the web ui. And yes, while it means 
interacting with two tools, I consider it as fairly simpler than gerrit's way.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: Another proposal for modernization of our infrastructure

[Luca Beltrame]

Jan Kundrát wrote:


> However, we also have people with little to no experience using Gerrit
> just fine. Shall we therefore focus on explaining that contributing
> through Gerrit is actually not painful?

My two cents here: as an occasional contributor (and one drop in the ocean; 
take what I say with more than one grain of salt), I'm good enough with git, 
but the whole Gerrit approach doesn't feel too natural to me, and for sure, 
I'd prefer simpler ways. 

Not to say that RB was better, because I had my fights with rbt recently. 
BUt in that case at least there's fire and forget, or KDevelop integration 
(at least, used to work). 

The issue is: for people that commit every once in a while, the workflow is 
still a little too complex with Gerrit, at least the "proposed" one. Of 
course, if there are ways around the problem, then it becomes a moot point.

-- 
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: 6E1A4E79

Re: Another proposal for modernization of our infrastructure

[Eike Hein]

On 02/02/2015 01:20 PM, Milian Wolff wrote:

Sigh, I find it highly sad to read this over and over again. People keep
confusing the flaky CI and the high quality barrier in Qt with gerrit
itself... Seriously, gerrit the tool is OK, what makes it hard and what is the
actual barrier to entry in Qt are the flaky CI which kills productivity and
then sometimes the odd reviews with a pretty harsh tone that demand an
extraordinary quality without holding your hand much. But that's not related
to gerrit... These are different things, so please people - lets not confuse
these things and say using gerrit means using it exactly like Qt is using it!


1) I wrote "contribute to Qt" intentionally there,
   not "use gerrit", because I'm aware of the diff.
   Although no, my unhappiness is not limited to the
   CI; many of my problems are actually linked to
   the way JIRA and gerrit have been made to inter-
   play for auth.

2) I've posted other criticizims of gerrit in the
   thread for a fuller picture of how gerrit adds
   to the unhappiness. Jumping on this bit, hand-
   waving it away and claiming we're now left with
   "gerrit is OK" is incorrect.



Bye


Cheers,
Eike

Re: Review Request 122341: Port Thumbnail KIO Slave Away from KDELibs4Support

[David Narváez]

> On Feb. 1, 2015, 2:40 p.m., David Faure wrote:
> > thumbnail/thumbnail.cpp, line 384
> > 
> >
> > Why this change? It's very wrong.
> > 
> > The first arg is a mimetype, therefore you need KMimeTypeTrader.
> > 
> > It compiles with KServiceTypeTrader by stuffing the mimetype into 
> > "const QString& serviceType" and by stuffing the servicetype into "const 
> > QString &constraint"...

So how do you do this in KF5?


- David


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


On Jan. 31, 2015, 11:07 p.m., David Narváez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122341/
> ---
> 
> (Updated Jan. 31, 2015, 11:07 p.m.)
> 
> 
> Review request for kde-workspace, Bhushan Shah and David Faure.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Only major difference would be the lack of fallback to KFMI. Maybe we could 
> implement thumbnail features in KFileMetadata?
> 
> 
> Diffs
> -
> 
>   thumbnail/thumbnail.cpp 39e8de5 
> 
> Diff: https://git.reviewboard.kde.org/r/122341/diff/
> 
> 
> Testing
> ---
> 
> Only tested compilation.
> 
> 
> Thanks,
> 
> David Narváez
> 
>

Re: Review Request 122341: Port Thumbnail KIO Slave Away from KDELibs4Support

[David Faure]

> On fév. 1, 2015, 2:40 après-midi, David Faure wrote:
> > thumbnail/thumbnail.cpp, line 384
> > 
> >
> > Why this change? It's very wrong.
> > 
> > The first arg is a mimetype, therefore you need KMimeTypeTrader.
> > 
> > It compiles with KServiceTypeTrader by stuffing the mimetype into 
> > "const QString& serviceType" and by stuffing the servicetype into "const 
> > QString &constraint"...
> 
> David Narváez wrote:
> So how do you do this in KF5?

err, exactly the same as in kdelibs4...


- David


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


On jan. 31, 2015, 11:07 après-midi, David Narváez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122341/
> ---
> 
> (Updated jan. 31, 2015, 11:07 après-midi)
> 
> 
> Review request for kde-workspace, Bhushan Shah and David Faure.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Only major difference would be the lack of fallback to KFMI. Maybe we could 
> implement thumbnail features in KFileMetadata?
> 
> 
> Diffs
> -
> 
>   thumbnail/thumbnail.cpp 39e8de5 
> 
> Diff: https://git.reviewboard.kde.org/r/122341/diff/
> 
> 
> Testing
> ---
> 
> Only tested compilation.
> 
> 
> Thanks,
> 
> David Narváez
> 
>

Re: make uninstall

[Albert Astals Cid]

El Divendres, 30 de gener de 2015, a les 10:47:22, Alex Merry va escriure:
> On Friday 30 January 2015 10:44:23 Alex Merry wrote:
> > Over on kde-frameworks-devel, there have been several requests to bring
> > back `make uninstall` for KF5 and KF5-based projects.
> > 
> > KDELibs4 used to define this for any dependent projects (it's essentially
> > `xargs rm < install_manifest.txt` under the hood), and we could easily add
> > it to KDECMakeSettings (with an option to disable it).
> 
> We could also easily make it opt-in, either by making a separate module to
> define an uninstall target or by requiring projects or users to set a
> variable/option.

If we know there's people that want it, i guess it's better to make it opt-
out, probably we'll get more homogeinity that way.

Cheers,
  Albert

> 
> Alex
> ___
> Kde-buildsystem mailing list
> kde-buildsys...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem

Review Request 122394: Fix OSX library names in kdeinit5.app

[Jeremy Whiting]

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

Review request for kdelibs, David Faure and Ian Wadham.


Bugs: 343707
https://bugs.kde.org/show_bug.cgi?id=343707


Repository: kinit


Description
---

OSX Doesn't have .so libraries, so use OSX names in kdeinit5.app to load the 
correct libraries needed.


Diffs
-

  src/kdeinit/kinit.cpp 3c3c913 

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


Testing
---

kdeinit5.app no longer complains about the missing .so libraries.


Thanks,

Jeremy Whiting

Re: Review Request 122394: Fix OSX library names in kdeinit5.app

[Jeremy Whiting]

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

(Updated Feb. 2, 2015, 1:51 p.m.)


Review request for KDE Software on Mac OS X, kdelibs, David Faure, and Ian 
Wadham.


Changes
---

added kde-mac group.


Bugs: 343707
https://bugs.kde.org/show_bug.cgi?id=343707


Repository: kinit


Description
---

OSX Doesn't have .so libraries, so use OSX names in kdeinit5.app to load the 
correct libraries needed.


Diffs
-

  src/kdeinit/kinit.cpp 3c3c913 

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


Testing
---

kdeinit5.app no longer complains about the missing .so libraries.


Thanks,

Jeremy Whiting

Re: Review Request 122320: use xcb-screen count instead of qguiapplication.screens

[Nick Shaforostoff]

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

(Updated Feb. 2, 2015, 9:15 p.m.)


Review request for kde-workspace, Martin Gräßlin and Thomas Lübking.


Changes
---

-declare XCB an optional dependency
-add a check of current qt platform (xcb/wayland)


Repository: plasma-workspace


Description
---

this patch makes kcminit behave like in kde4: it uses proper xcb screen count 
which may be different from QGuiApplication::screens().count().

for example when i connext external monitor via vga to my laptop, xcb screen 
count is still '1', while QGuiApplication::screens().count() returns '2'.

switching from QGuiApplication to QCoreApplication still wasn't possible 
because modules like 'mouse' need gui initialized and would crash if kcminit 
uses QCoreApplication.


Diffs (updated)
-

  components/CMakeLists.txt 42c820f 
  startkde/kcminit/CMakeLists.txt b17951f 
  startkde/kcminit/main.cpp 1008966 

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


Testing
---

i have built kcminit on ubuntu vivid alpha 32-bit, replaced binaries and 
libraries in the system and successfuly could run kcminit_startup and reboot 
also went fine.


Thanks,

Nick Shaforostoff

Re: Review Request 122394: Fix OSX library names in kdeinit5.app

[René J . V . Bertin]

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



src/kdeinit/kinit.cpp


These are true shared libraries that are also used for "-l" style linking 
with ld?


- René J.V. Bertin


On Feb. 2, 2015, 9:51 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122394/
> ---
> 
> (Updated Feb. 2, 2015, 9:51 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, kdelibs, David Faure, and Ian 
> Wadham.
> 
> 
> Bugs: 343707
> https://bugs.kde.org/show_bug.cgi?id=343707
> 
> 
> Repository: kinit
> 
> 
> Description
> ---
> 
> OSX Doesn't have .so libraries, so use OSX names in kdeinit5.app to load the 
> correct libraries needed.
> 
> 
> Diffs
> -
> 
>   src/kdeinit/kinit.cpp 3c3c913 
> 
> Diff: https://git.reviewboard.kde.org/r/122394/diff/
> 
> 
> Testing
> ---
> 
> kdeinit5.app no longer complains about the missing .so libraries.
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

Re: Review Request 122394: Fix OSX library names in kdeinit5.app

[Jeremy Whiting]

> On Feb. 2, 2015, 2:56 p.m., René J.V. Bertin wrote:
> > src/kdeinit/kinit.cpp, lines 90-92
> > 
> >
> > These are true shared libraries that are also used for "-l" style 
> > linking with ld?

I'm not sure I understand the question, is there some other type of library on 
OSX besides "true shared libraries that are also used for -l style linking with 
ld"? file says they are Mach-O 64-bit dynamically linked shared library x86_64 
if that helps answer your question.


- Jeremy


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


On Feb. 2, 2015, 1:51 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122394/
> ---
> 
> (Updated Feb. 2, 2015, 1:51 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, kdelibs, David Faure, and Ian 
> Wadham.
> 
> 
> Bugs: 343707
> https://bugs.kde.org/show_bug.cgi?id=343707
> 
> 
> Repository: kinit
> 
> 
> Description
> ---
> 
> OSX Doesn't have .so libraries, so use OSX names in kdeinit5.app to load the 
> correct libraries needed.
> 
> 
> Diffs
> -
> 
>   src/kdeinit/kinit.cpp 3c3c913 
> 
> Diff: https://git.reviewboard.kde.org/r/122394/diff/
> 
> 
> Testing
> ---
> 
> kdeinit5.app no longer complains about the missing .so libraries.
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

Re: Review Request 122394: Fix OSX library names in kdeinit5.app

[René J . V . Bertin]

> On Feb. 2, 2015, 10:56 p.m., René J.V. Bertin wrote:
> > src/kdeinit/kinit.cpp, lines 90-92
> > 
> >
> > These are true shared libraries that are also used for "-l" style 
> > linking with ld?
> 
> Jeremy Whiting wrote:
> I'm not sure I understand the question, is there some other type of 
> library on OSX besides "true shared libraries that are also used for -l style 
> linking with ld"? file says they are Mach-O 64-bit dynamically linked shared 
> library x86_64 if that helps answer your question.

What I mean is if there are applications (or other libraries) that link in 
those libraries using `-lKF5KIOCore`, `-lKF5Parts` or `-lKF5Plasma`. In that 
case, the .dylib extension is obligatory. In all other cases, the extension can 
in fact be anything. Thus, plugins and modules usually have the .so extension 
on OS X, just like on Linux.

Your modification is correct in itself (evidently, if you not longer get 
complaints about libraries not being found). But if those libraries are only 
ever loaded dynamically you could also modify the CMake file so that they are 
created with a .so extension (and leave the C++ code alone).


- René J.V.


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


On Feb. 2, 2015, 9:51 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122394/
> ---
> 
> (Updated Feb. 2, 2015, 9:51 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, kdelibs, David Faure, and Ian 
> Wadham.
> 
> 
> Bugs: 343707
> https://bugs.kde.org/show_bug.cgi?id=343707
> 
> 
> Repository: kinit
> 
> 
> Description
> ---
> 
> OSX Doesn't have .so libraries, so use OSX names in kdeinit5.app to load the 
> correct libraries needed.
> 
> 
> Diffs
> -
> 
>   src/kdeinit/kinit.cpp 3c3c913 
> 
> Diff: https://git.reviewboard.kde.org/r/122394/diff/
> 
> 
> Testing
> ---
> 
> kdeinit5.app no longer complains about the missing .so libraries.
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

Moving KDE Telepathy to kdenetwork

[Martin Klapetek]

Hi,

so we decided with KDE Telepathy to join the big guys and become
part of KDE Applications 15.04. So I'd like to request a move of
KDE Telepathy repos[1] to kdenetwork/. This is also a mail to Urs
Wolfer asking for approval as per the policies.

KDE Telepathy has been through kdereview once and we've kept
the culture of "everything goes through review" pretty high up, but
I guess that move from extragear to main module also must go
through kdereview? The app lifecycle page[2] does not mention
this case.

Another part that KDE Telepathy needs is KAccounts and we'd like
to move that one too, probably to kde-runtime but there seems to be
some disagreements of the purpose of kde-runtime. KAccounts is
basically a KCM, a kded module and a library for writing custom plugins
for various KAccounts functionality. So please advise where to move
that. Also note that this was in kdereview just a month ago so I'd like
to just skip kdereview for this as it didn't have many changes.

[1] KDE Telepathy repos are:
 ktp-accounts-kcm
 ktp-approver
 ktp-auth-handler
 ktp-call-ui*
 ktp-common-internals
 ktp-contact-list
 ktp-contact-runner
 ktp-desktop-applets
 ktp-filetransfer-handler
 ktp-kded-module
 ktp-send-file
 ktp-text-ui

[2] - https://techbase.kde.org/Policies/Application_Lifecycle

*) ktp-call-ui is not yet ported and will most probably be dropped from
the 15.04 release

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Build dependency issues with kdesrc-build

[Albert Astals Cid]

El Dissabte, 31 de gener de 2015, a les 19:20:06, Mathieu Tarral va escriure:
> Hi,
> 
> I noticed an issue with the plasmate component, which is build
> when you include kf5-workspace-build-include.
> 
> It has a build dependency on KDevPlatform, but this component is only
> selected in kf5-applications-build-include.
> 
> So should we move plasmate into Applications ?

I have no idea how kdesrc-build but i'd hope/guess/expect it maps the virtual 
hierarchy of the repos, so probably plasmate should go to something extragear-
ish that can depend on kdevlplatform just fine?

But as said i know not much of kdesrc-build so i could be talking crap :D

> Or move KDevPlatform into Workspace ?

KDevPlatform is not a workspace item for sure

Cheers,
  Albert

> 
> Regards.

Re: Oxygen Icon usage terms

[Albert Astals Cid]

El Dissabte, 31 de gener de 2015, a les 00:51:30, Ben Cooksley va escriure:
> On Sat, Jan 31, 2015 at 12:07 AM, Kevin Krammer  wrote:
> > Hi all,
> 
> Hi Kevin,
> 
> > I've just seen a question on using Oxygen icons on a forum and the poster
> > was wondering about the status of http://www.oxygen-icons.org/
> > 
> > The terms in the wiki https://techbase.kde.org/Projects/Oxygen/Licensing
> > say that one should link to the above site, but there is no content
> > there.
> > 
> > Anyone any idea what we can do about that?
> 
> Last I heard oxygen-icons.org was controlled by Nuno, so you'll need
> to contact him.

Whois says David Vignoni

> I suspect the content of the old site may have been lost though, so we
> may need to see what the distributions publish as LICENSE files
> alongside oxygen-icons - as files such as this should be familiar
> definitive.

Totally, this is proof why links to non .kde.org subdomains should be avoided 
like the plague.

So how do we go on fixing that 
https://techbase.kde.org/Projects/Oxygen/Licensing page?

Cheers,
  Albert

> 
> > Cheers,
> > Kevin
> > --
> > Kevin Krammer, KDE developer, xdg-utils developer
> > KDE user support, developer mentoring
> 
> Thanks,
> Ben

Re: Review Request 122394: Fix OSX library names in kdeinit5.app

[David Faure]

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

Ship it!


René, these are shared libs, not plugins, so their name is correct.

- David Faure


On fév. 2, 2015, 8:51 après-midi, Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122394/
> ---
> 
> (Updated fév. 2, 2015, 8:51 après-midi)
> 
> 
> Review request for KDE Software on Mac OS X, kdelibs, David Faure, and Ian 
> Wadham.
> 
> 
> Bugs: 343707
> https://bugs.kde.org/show_bug.cgi?id=343707
> 
> 
> Repository: kinit
> 
> 
> Description
> ---
> 
> OSX Doesn't have .so libraries, so use OSX names in kdeinit5.app to load the 
> correct libraries needed.
> 
> 
> Diffs
> -
> 
>   src/kdeinit/kinit.cpp 3c3c913 
> 
> Diff: https://git.reviewboard.kde.org/r/122394/diff/
> 
> 
> Testing
> ---
> 
> kdeinit5.app no longer complains about the missing .so libraries.
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

Re: Review Request 122320: use xcb-screen count instead of qguiapplication.screens

[Martin Gräßlin]

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



components/CMakeLists.txt


that seems unrelated change.



startkde/kcminit/CMakeLists.txt


you find optional, but link required. OSX devs won't be happy with that 
change ;-)

you need to do something like:
if (XCB_XCB_FOUND)
target_link_libraries(kdeinit_kcminit XCB::XCB)
endif()



startkde/kcminit/CMakeLists.txt


here the same



startkde/kcminit/main.cpp


the ifdef is wrong: HAVE_X11 is defined as 1 if Xlib is found. It doesn't 
say anything about whether XCB is found. Please introduce a dedicated ifdef for 
it.


- Martin Gräßlin


On Feb. 2, 2015, 10:15 p.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122320/
> ---
> 
> (Updated Feb. 2, 2015, 10:15 p.m.)
> 
> 
> Review request for kde-workspace, Martin Gräßlin and Thomas Lübking.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> this patch makes kcminit behave like in kde4: it uses proper xcb screen count 
> which may be different from QGuiApplication::screens().count().
> 
> for example when i connext external monitor via vga to my laptop, xcb screen 
> count is still '1', while QGuiApplication::screens().count() returns '2'.
> 
> switching from QGuiApplication to QCoreApplication still wasn't possible 
> because modules like 'mouse' need gui initialized and would crash if kcminit 
> uses QCoreApplication.
> 
> 
> Diffs
> -
> 
>   components/CMakeLists.txt 42c820f 
>   startkde/kcminit/CMakeLists.txt b17951f 
>   startkde/kcminit/main.cpp 1008966 
> 
> Diff: https://git.reviewboard.kde.org/r/122320/diff/
> 
> 
> Testing
> ---
> 
> i have built kcminit on ubuntu vivid alpha 32-bit, replaced binaries and 
> libraries in the system and successfuly could run kcminit_startup and reboot 
> also went fine.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>