Re: Is there (going to be) an auto-retracer service for KDE?

[Martin Klapetek]

On Mon, Apr 26, 2021 at 7:07 AM Harald Sitter  wrote:

>
> Also going off on a tangent: On windows I understand the store already
> has crash tracking and all that stuff implemented, I expect the same
> is true for OSX? No idea about android


Just chiming in about Android - if an app is installed from Play Store,
the store itself will collect crash traces, both Java and native ones.
However those traces will have the same issue - they won't have
the debug stuff for native ones; they will for Java crashes unless
the code has been obfuscated in the release build, which is actually
very common. To deobfuscate those traces, the debug symbols can
be uploaded to the Play Store (or the mapping file in case of Java),
but it's a manual process which must be done for every single release.

There are also alternatives to Play Store's traces collecting - there are
many SDKs that can be integrated into the app code that will collect
all crashes and upload them to a web service (basically a DrKonqi
equivalent...maybe DrKonqi could be turned into Android framework
for crash reporting?), but then the same debug symbols issue will exist
there. Some of these SDKs also provide a simple gradle task (build
system step) that will auto-upload those debug symbols to their web
service as part of the release build, sorta automating that process.
But these are generally closed/paid 3rd party services, so not entirely
useful for KDE. There may be open alternatives, but I haven't really
looked into that.
Finally, setting these up is usually a single line in the (Android) App's
onCreate(),
so this could potentially work with Qt apps on Android too.

Cheers
--
Martin Klapetek

Re: Taking over maintainership of the kaccounts-* repos

[Martin Klapetek]

On Fri, Sep 13, 2019 at 4:21 AM Bhushan Shah  wrote:

> Hello!
>
> At akademy we talked about the KAccounts and realized that kaccounts is
> unmaintained and/or Martin is not active.
>

https://martys.typepad.com/blog/2016/06/new-maintainers-wanted-kde-telepathy-kaccounts-plasma-notifications-and-others.html

You 'realized' after three years? :P


>
> So I propose to take over maintainership of the following repositories.
>
> - kaccounts-integration
> - kaccounts-providers
> - kaccounts-mobile
>
> If you have any concerns/objections with this, let me know.
>

Yes please, go ahead!

Cheers
--
Martin Klapetek

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

[Martin Klapetek]

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



Worth noting that "Czechia" in the ISO is just the "short name", not the full 
name which actually remains "Czech Republic". See 
https://www.iso.org/obp/ui/#iso:code:3166:CZ for reference.

That said, being a Czech myself, I prefer "Czech Republic" over "Czechia", but 
that comes down to personal preference I guess and so I won't block this if 
anyone gives it a Ship It.

- Martin Klapetek


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: Review Request 127393: digital-clock: Fix font size of date label in small panels

[Martin Klapetek]

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


Ship it!




Thanks!

- Martin Klapetek


On March 19, 2016, 2:16 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127393/
> ---
> 
> (Updated March 19, 2016, 2:16 p.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Bugs: 360059
> https://bugs.kde.org/show_bug.cgi?id=360059
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the digital clock applet uses a fixed font size for the date label 
> when it's placed in a narrow horizontal panel.
> Example: http://paste.opensuse.org/view/raw/f8ba5d0d
> 
> With this patch the same font size is used as for the time label.
> 
> As mentioned at https://git.reviewboard.kde.org/r/127102/ I'm not sure if the 
> current design is a bug or intentional.
> On the one hand having a smaller font size reduces the width of the applet, 
> on the other hand having the same font size is more consistent.
> I would prefer a consistent look however.
> 
> This patch creates one problem though. Currently the height of the 
> date-time-separator is set to the height of the (fixed) date label font size.
> With this patch I set the separator height to 70% of the applet height.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 02d55a9 
> 
> Diff: https://git.reviewboard.kde.org/r/127393/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: Review Request 127102: Use fixed width for digital clock applet

[Martin Klapetek]

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


Ship it!




Ship It!

- Martin Klapetek


On March 16, 2016, 4:35 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127102/
> ---
> 
> (Updated March 16, 2016, 4:35 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Bugs: 347724
> https://bugs.kde.org/show_bug.cgi?id=347724
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the width of the date label is not fixed but changes depending on 
> the text. This causes the entire applet to change its width (if the time is 
> the widest displayed item). This in turn can cause all other applets in the 
> same panel to move whenever the displayed time changes.
> 
> This patch uses FontMetrics to iterate over all possible time strings (with 
> different width) and chooses the widest of them as reference for the fixed 
> width of the time label.
> 
> This way the width of the applet stays the same (unless the date is displayed 
> and changes). The text remains centered though, which means that it can still 
> move within the applet when the time changes.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 
> 
> Diff: https://git.reviewboard.kde.org/r/127102/diff/
> 
> 
> Testing
> ---
> 
> Works with horizontal and vertical panel.
> Also displaying different combinations of "seconds", "date" and "timezone" 
> works.
> 
> 
> File Attachments
> 
> 
> 0001-Use-fixed-width-for-digital-clock-applet.patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/03/16/81b4a902-1454-4155-9fda-552b8acba1a8__0001-Use-fixed-width-for-digital-clock-applet.patch
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: Review Request 127393: digital-clock: Fix font size of date label in small panels

[Martin Klapetek]

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


Fix it, then Ship it!




Thanks!

For future reference, the proper group to add to Plasma/workspace reviews is 
"plasma".


applets/digital-clock/package/contents/ui/DigitalClock.qml (lines 382 - 383)
<https://git.reviewboard.kde.org/r/127393/#comment63848>

You can't set both, it will print an error that you can't and one is ignored

Also leave this in the font { } format please


- Martin Klapetek


On March 16, 2016, 4:53 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127393/
> ---
> 
> (Updated March 16, 2016, 4:53 p.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the digital clock applet uses a fixed font size for the date label 
> when it's placed in a narrow horizontal panel.
> Example: http://paste.opensuse.org/view/raw/f8ba5d0d
> 
> With this patch the same font size is used as for the time label.
> 
> As mentioned at https://git.reviewboard.kde.org/r/127102/ I'm not sure if the 
> current design is a bug or intentional.
> On the one hand having a smaller font size reduces the width of the applet, 
> on the other hand having the same font size is more consistent.
> I would prefer a consistent look however.
> 
> This patch creates one problem though. Currently the height of the 
> date-time-separator is set to the height of the (fixed) date label font size.
> With this patch I set the separator height to 70% of the applet height.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 
> 
> Diff: https://git.reviewboard.kde.org/r/127393/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: Review Request 127393: digital-clock: Fix font size of date label in small panels

[Martin Klapetek]

> On March 16, 2016, 6:19 p.m., Martin Klapetek wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, line 400
> > <https://git.reviewboard.kde.org/r/127393/diff/1/?file=453347#file453347line400>
> >
> > Have you tried dateLabelLeft.paintedHeight?
> 
> Daniel Faust wrote:
> I think that would be the same as dateLabelLeft.height, but the separator 
> is meant to have the same height as the font, not the label.
> I would need something like "paintedFontPixelSize".
> Alternatively I could calculate the font.pixelSize as a percentage of the 
> label height and use that as a scaling factor.
> 
> Martin Klapetek wrote:
> > I think that would be the same as dateLabelLeft.height ... I would need 
> something like "paintedFontPixelSize".
> 
> paintedHeight is the actual height that the painted text has in pixels.
> 
> Daniel Faust wrote:
> I had a second look at your screen shot, I thought that the separator had 
> the exact height as the rendered text, but it really has the height of the 
> label.
> After my changes I thought that the separator was too high, so I scaled 
> it down to 70%. But it seems that leaving it at 100% is like it was before.
> Since it seems too complicated to calculate the rendered text height, 
> leaving it at 100% height might be the better choice.
> 
> Martin Klapetek wrote:
> > Since it seems too complicated to calculate the rendered text height
> 
> That's exactly what .paintedHeight property is for. Just try it.
> 
> Daniel Faust wrote:
> This is the result: http://paste.opensuse.org/view/raw/0b724b7b

Hah, interesting. Ok, let's go with your patch then.


- Martin


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


On March 16, 2016, 4:53 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127393/
> ---
> 
> (Updated March 16, 2016, 4:53 p.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the digital clock applet uses a fixed font size for the date label 
> when it's placed in a narrow horizontal panel.
> Example: http://paste.opensuse.org/view/raw/f8ba5d0d
> 
> With this patch the same font size is used as for the time label.
> 
> As mentioned at https://git.reviewboard.kde.org/r/127102/ I'm not sure if the 
> current design is a bug or intentional.
> On the one hand having a smaller font size reduces the width of the applet, 
> on the other hand having the same font size is more consistent.
> I would prefer a consistent look however.
> 
> This patch creates one problem though. Currently the height of the 
> date-time-separator is set to the height of the (fixed) date label font size.
> With this patch I set the separator height to 70% of the applet height.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 
> 
> Diff: https://git.reviewboard.kde.org/r/127393/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: Review Request 127102: Use fixed width for digital clock applet

[Martin Klapetek]

> On March 15, 2016, 5:48 p.m., Martin Klapetek wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, lines 565-568
> > <https://git.reviewboard.kde.org/r/127102/diff/3/?file=448492#file448492line565>
> >
> > Can't we just compare "A" and "P" width's and use that? Would spare 
> > creating two Date objects and two calls to Qt.formatTime
> 
> Daniel Faust wrote:
> No, because eg. in german the strings for am and pm are "vorm." and 
> "nachm.".
> 
> Martin Klapetek wrote:
> Ah, good. Haven't thought of that. Those germans...
> 
> (on the other hand, I wouldn't expect anyone in Germany to actually not 
> use 24h clock format, but oh well)
> 
> One other thing - create just a single Date object and then call 
> setHours(13) on it for the second format.
> 
> Daniel Faust wrote:
> As you wish. But keep in mind that this is not a performance bottleneck.
> I added some debug outputs to see where setupLabels is called from and it 
> gets called 10 times when initializing the applet, including 3 times in the 
> onCompleted method.
> Even if it is a little bit off topic, here is the log (indentation was 
> done manually and is somewhat guessed):
> 
> ```
> onShowDateChanged
>   timeFormatCorrection
> onShowSecondsChanged
>   timeFormatCorrection
> setupLabels
>   00:00:00 NACHM.
> setupLabels
>   00:00:00 NACHM.
> 
> onDateFormatChanged
>   setupLabels
> 00:00:00 NACHM.
> 
> onLastSelectedTimezoneChanged
>   timeFormatCorrection
> setupLabels
>   00:00:00 NACHM.
> 
> onDisplayTimezoneAsCodeChanged
>   setupLabels
> 00:00:00 NACHM.
> 
> onUse24hFormatChanged
>   timeFormatCorrection
> setupLabels
>   00:00:00
> 
> onStateChanged
>   setupLabels
> 00:00:00
> 
> onCompleted
>   onSelectedTimeZonesChanged
> setupLabels
>   00:00:00
>   dateTimeChanged
> timeFormatCorrection
>   setupLabels
> 00:00:00
>   timeFormatCorrection
> setupLabels
>   00:00:00
> ```

> But keep in mind that this is not a performance bottleneck

I didn't claim it is. But there's no reason to not write
new code in an efficient way ;)

About the call numbers, yes, I'm aware of that. I wanted
to go over the whole applet and fix it, but then I was
assigned a different project and time was lacking.

Patches welcome for that too, of course :)


- Martin


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


On March 16, 2016, 4:35 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127102/
> ---
> 
> (Updated March 16, 2016, 4:35 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Bugs: 347724
> https://bugs.kde.org/show_bug.cgi?id=347724
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the width of the date label is not fixed but changes depending on 
> the text. This causes the entire applet to change its width (if the time is 
> the widest displayed item). This in turn can cause all other applets in the 
> same panel to move whenever the displayed time changes.
> 
> This patch uses FontMetrics to iterate over all possible time strings (with 
> different width) and chooses the widest of them as reference for the fixed 
> width of the time label.
> 
> This way the width of the applet stays the same (unless the date is displayed 
> and changes). The text remains centered though, which means that it can still 
> move within the applet when the time changes.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 
> 
> Diff: https://git.reviewboard.kde.org/r/127102/diff/
> 
> 
> Testing
> ---
> 
> Works with horizontal and vertical panel.
> Also displaying different combinations of "seconds", "date" and "timezone" 
> works.
> 
> 
> File Attachments
> 
> 
> 0001-Use-fixed-width-for-digital-clock-applet.patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/03/16/81b4a902-1454-4155-9fda-552b8acba1a8__0001-Use-fixed-width-for-digital-clock-applet.patch
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: Review Request 127393: digital-clock: Fix font size of date label in small panels

[Martin Klapetek]

> On March 16, 2016, 6:19 p.m., Martin Klapetek wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, line 400
> > <https://git.reviewboard.kde.org/r/127393/diff/1/?file=453347#file453347line400>
> >
> > Have you tried dateLabelLeft.paintedHeight?
> 
> Daniel Faust wrote:
> I think that would be the same as dateLabelLeft.height, but the separator 
> is meant to have the same height as the font, not the label.
> I would need something like "paintedFontPixelSize".
> Alternatively I could calculate the font.pixelSize as a percentage of the 
> label height and use that as a scaling factor.
> 
> Martin Klapetek wrote:
> > I think that would be the same as dateLabelLeft.height ... I would need 
> something like "paintedFontPixelSize".
> 
> paintedHeight is the actual height that the painted text has in pixels.
> 
> Daniel Faust wrote:
> I had a second look at your screen shot, I thought that the separator had 
> the exact height as the rendered text, but it really has the height of the 
> label.
> After my changes I thought that the separator was too high, so I scaled 
> it down to 70%. But it seems that leaving it at 100% is like it was before.
> Since it seems too complicated to calculate the rendered text height, 
> leaving it at 100% height might be the better choice.

> Since it seems too complicated to calculate the rendered text height

That's exactly what .paintedHeight property is for. Just try it.


- Martin


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


On March 16, 2016, 4:53 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127393/
> ---
> 
> (Updated March 16, 2016, 4:53 p.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the digital clock applet uses a fixed font size for the date label 
> when it's placed in a narrow horizontal panel.
> Example: http://paste.opensuse.org/view/raw/f8ba5d0d
> 
> With this patch the same font size is used as for the time label.
> 
> As mentioned at https://git.reviewboard.kde.org/r/127102/ I'm not sure if the 
> current design is a bug or intentional.
> On the one hand having a smaller font size reduces the width of the applet, 
> on the other hand having the same font size is more consistent.
> I would prefer a consistent look however.
> 
> This patch creates one problem though. Currently the height of the 
> date-time-separator is set to the height of the (fixed) date label font size.
> With this patch I set the separator height to 70% of the applet height.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 
> 
> Diff: https://git.reviewboard.kde.org/r/127393/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: Review Request 127393: digital-clock: Fix font size of date label in small panels

[Martin Klapetek]

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



> I would prefer a consistent look however.

This.


applets/digital-clock/package/contents/ui/DigitalClock.qml (line 400)
<https://git.reviewboard.kde.org/r/127393/#comment63839>

Have you tried dateLabelLeft.paintedHeight?


- Martin Klapetek


On March 16, 2016, 4:53 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127393/
> ---
> 
> (Updated March 16, 2016, 4:53 p.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the digital clock applet uses a fixed font size for the date label 
> when it's placed in a narrow horizontal panel.
> Example: http://paste.opensuse.org/view/raw/f8ba5d0d
> 
> With this patch the same font size is used as for the time label.
> 
> As mentioned at https://git.reviewboard.kde.org/r/127102/ I'm not sure if the 
> current design is a bug or intentional.
> On the one hand having a smaller font size reduces the width of the applet, 
> on the other hand having the same font size is more consistent.
> I would prefer a consistent look however.
> 
> This patch creates one problem though. Currently the height of the 
> date-time-separator is set to the height of the (fixed) date label font size.
> With this patch I set the separator height to 70% of the applet height.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 
> 
> Diff: https://git.reviewboard.kde.org/r/127393/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: Review Request 127393: digital-clock: Fix font size of date label in small panels

[Martin Klapetek]

> On March 16, 2016, 9:31 p.m., Martin Klapetek wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, lines 382-383
> > <https://git.reviewboard.kde.org/r/127393/diff/1/?file=453347#file453347line382>
> >
> > You can't set both, it will print an error that you can't and one is 
> > ignored
> > 
> > Also leave this in the font { } format please
> 
> Daniel Faust wrote:
> Yes, I copy'n'pasted it. How about I throw in an additional commit to fix 
> it everywhere in the file?

Well changing code just for the sake of change is not
really worth it as it makes looking up history of that
line, the actual change, needlessly harder.


- Martin


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


On March 16, 2016, 4:53 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127393/
> ---
> 
> (Updated March 16, 2016, 4:53 p.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the digital clock applet uses a fixed font size for the date label 
> when it's placed in a narrow horizontal panel.
> Example: http://paste.opensuse.org/view/raw/f8ba5d0d
> 
> With this patch the same font size is used as for the time label.
> 
> As mentioned at https://git.reviewboard.kde.org/r/127102/ I'm not sure if the 
> current design is a bug or intentional.
> On the one hand having a smaller font size reduces the width of the applet, 
> on the other hand having the same font size is more consistent.
> I would prefer a consistent look however.
> 
> This patch creates one problem though. Currently the height of the 
> date-time-separator is set to the height of the (fixed) date label font size.
> With this patch I set the separator height to 70% of the applet height.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 
> 
> Diff: https://git.reviewboard.kde.org/r/127393/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: Review Request 127102: Use fixed width for digital clock applet

[Martin Klapetek]

> On March 15, 2016, 5:48 p.m., Martin Klapetek wrote:
> > I've tested it extensively and it works great. Thanks a lot!
> > 
> > There's one more issue - http://paste.opensuse.org/view/raw/f8ba5d0d - the 
> > same font size should also be applied to the left date label (there are; 
> > the bottom should stay as is). Do you think you could include it as part of 
> > this patch?
> 
> Daniel Faust wrote:
> I changed it, but now I'm not so sure anymore if the fixed font size 
> wasn't intentional.
> It would be a separate issue anyway and not connected to this one, so if 
> you want, I can upload the patch to a new review request.

Yeah, that'd be great. Thanks!


> On March 15, 2016, 5:48 p.m., Martin Klapetek wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, lines 565-568
> > <https://git.reviewboard.kde.org/r/127102/diff/3/?file=448492#file448492line565>
> >
> > Can't we just compare "A" and "P" width's and use that? Would spare 
> > creating two Date objects and two calls to Qt.formatTime
> 
> Daniel Faust wrote:
> No, because eg. in german the strings for am and pm are "vorm." and 
> "nachm.".

Ah, good. Haven't thought of that. Those germans...

(on the other hand, I wouldn't expect anyone in Germany to actually not use 24h 
clock format, but oh well)

One other thing - create just a single Date object and then call setHours(13) 
on it for the second format.


- Martin


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


On March 8, 2016, 6:53 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127102/
> ---
> 
> (Updated March 8, 2016, 6:53 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Bugs: 347724
> https://bugs.kde.org/show_bug.cgi?id=347724
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the width of the date label is not fixed but changes depending on 
> the text. This causes the entire applet to change its width (if the time is 
> the widest displayed item). This in turn can cause all other applets in the 
> same panel to move whenever the displayed time changes.
> 
> This patch uses FontMetrics to iterate over all possible time strings (with 
> different width) and chooses the widest of them as reference for the fixed 
> width of the time label.
> 
> This way the width of the applet stays the same (unless the date is displayed 
> and changes). The text remains centered though, which means that it can still 
> move within the applet when the time changes.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 
> 
> Diff: https://git.reviewboard.kde.org/r/127102/diff/
> 
> 
> Testing
> ---
> 
> Works with horizontal and vertical panel.
> Also displaying different combinations of "seconds", "date" and "timezone" 
> works.
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: Review Request 127102: Use fixed width for digital clock applet

[Martin Klapetek]

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



I've tested it extensively and it works great. Thanks a lot!

There's one more issue - http://paste.opensuse.org/view/raw/f8ba5d0d - the same 
font size should also be applied to the left date label (there are; the bottom 
should stay as is). Do you think you could include it as part of this patch?


applets/digital-clock/package/contents/ui/DigitalClock.qml (line 554)
<https://git.reviewboard.kde.org/r/127102/#comment63784>

spaces around operators



applets/digital-clock/package/contents/ui/DigitalClock.qml (lines 564 - 567)
<https://git.reviewboard.kde.org/r/127102/#comment63785>

Can't we just compare "A" and "P" width's and use that? Would spare 
creating two Date objects and two calls to Qt.formatTime


- Martin Klapetek


On March 8, 2016, 6:53 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127102/
> ---
> 
> (Updated March 8, 2016, 6:53 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Bugs: 347724
> https://bugs.kde.org/show_bug.cgi?id=347724
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the width of the date label is not fixed but changes depending on 
> the text. This causes the entire applet to change its width (if the time is 
> the widest displayed item). This in turn can cause all other applets in the 
> same panel to move whenever the displayed time changes.
> 
> This patch uses FontMetrics to iterate over all possible time strings (with 
> different width) and chooses the widest of them as reference for the fixed 
> width of the time label.
> 
> This way the width of the applet stays the same (unless the date is displayed 
> and changes). The text remains centered though, which means that it can still 
> move within the applet when the time changes.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 
> 
> Diff: https://git.reviewboard.kde.org/r/127102/diff/
> 
> 
> Testing
> ---
> 
> Works with horizontal and vertical panel.
> Also displaying different combinations of "seconds", "date" and "timezone" 
> works.
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: remove khelpcenter from next Plasma release?

[Martin Klapetek]

On Wed, Mar 9, 2016 at 11:20 AM, Martin Gräßlin <mgraess...@kde.org> wrote:

> Am 2016-03-09 16:43, schrieb Yuri Chornoivan:
>
>>
>> Hi,
>>
>> Just of curiosity, what is the next thing, after documentation (as
>> Plasma  almost does not have it), to get rid from Plasma? Is it
>> Okular, Krusader,  something else? Just to make simple, sleek and
>> unintrusive.
>>
>> Thanks in advance for your answer.
>>
>
> Neither Okular, nor Krusader are part of Plasma. So what is that? Trying
> to create a flamewar?
>
> This is highly non-constructive, highly disrespectful towards the
> developers caring about our user experience. This is absolutely not
> acceptable.
>
> Seriosuly pissed
> Martin
>

I think there's a simple misunderstanding here.

Sebas meant removing the code from plasma repo in order to not having
to maintain the code as part of plasma-the-code while Yuri probably thought
this is about removing it from plasma-the-shell, ie. from kicker/kickoff
etc.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Google Summer of Code 2016 - C# bindings for Qt

[Martin Klapetek]

Hi,

On Sat, Mar 5, 2016 at 5:25 AM, Valorie Zimmerman <
valorie.zimmer...@gmail.com> wrote:

> Hi all,
>
> I've invited Joao to the webapp and approved the list subscription and
> post, and answered a bit there. However, since Joao and the student
> are both new to KDE, I would like to ask another experienced KDE
> mentor to step up to co-mentor this task.
>
> If you are not already invited to the webapp, please send me your
> google-connected account, and sub to KDE-Soc-Mentor ML.
>
> We always like to have co-mentors for GSoC, but I think it is
> mandatory for this proposal.
>

While I cannot really co-mentor on the technical level for lack
of knowledge of C#, I'm happy to be the KDE "guide-mentor"
for this task if nobody with better knowledge of C# steps up.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: [Kde-pim] PIM dependency metadata

[Martin Klapetek]

On Mon, Feb 29, 2016 at 2:46 AM, David Faure <fa...@kde.org> wrote:

> On Sunday 28 February 2016 08:09:38 Ben Cooksley wrote:
> > On Sun, Feb 28, 2016 at 1:51 AM, Sandro Knauß <skna...@kde.org> wrote:
> > > Hey,
> > >
> > >> There are a couple of issues, namely:
> > >> a) For some reason it depends on plasma-workspace - this seems
> > >> completely wrong to me. Please be careful when adding items to the
> > >> dependency chain
> > >
> > > this was added because of ktimezoned, that is part of
> plasma-workspace to run
> > > tests in kcalccore successfully. For further discussion see:
> > > https://phabricator.kde.org/T1147
> >
> > ktimezoned needs to move out of Plasma then, or the relevant classes
> > need to be rewritten
>
> Yep, this sounds like ktimezoned should move to KF5.
>
> How are non-plasma users supposed to get correct timezones in e.g. PIM
> apps otherwise?
>

Note that this daemon is used these days only to signal a timezone change
iirc,
you can get current/any timezone by using QTimeZone.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Review Request 127102: Use fixed width for digital clock applet

[Martin Klapetek]

> On Feb. 18, 2016, 1:05 a.m., David Edmundson wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, line 555
> > <https://git.reviewboard.kde.org/r/127102/diff/1/?file=444552#file444552line555>
> >
> > rather than looping, can we use FontMetric's maximumCharacterWidth
> > 
> >  * numChars.
> > 
> > Then we could kill sizeHelper competely (FontMetric's didn't exist when 
> > this was written)
> 
> Marco Martin wrote:
> hoping maximumCharacterWidth is reliable for all fonts, this loop really 
> needs to go
> 
> Daniel Faust wrote:
> As far as I understand maximumCharacterWidth returns the width of the 
> widest character of the font - which can be ridiculously wide given that the 
> font supports some wild unicode characters.
> I did a quick test and maximumCharacterWidth returned about twice the 
> width actually needed.
> 
> Martin Klapetek wrote:
> You still don't need this whole loop though, just find the biggest in 0-9 
> and use that for all the numbers (except year).
> 
> Daniel Faust wrote:
> Since I don't know the time format in advance, I have to construct 
> different times and process them with Qt.formatTime.
> That means, I have to test 0-9 for hours/minutes/seconds, 0-2 for tens of 
> hours and 0-5 for tens of minutes/seconds. Otherwise the constructed times 
> will be invalid.
> This can be done with three loops and it would bring down the amount of 
> advanceWidth and formatTime calls from 24+60=84 to 3+6+10=19.

You don't actually need them as a time, you just need them as a placeholder. At 
which point it doesn't matter if it's a valid time or not. You can even format 
12:12 with Qt.formatTime and then replace the numbers with your placeholder 
number.

In other words, the time format /is/ known in advance.


- Martin


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


On Feb. 17, 2016, 5:23 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127102/
> ---
> 
> (Updated Feb. 17, 2016, 5:23 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Bugs: 347724
> https://bugs.kde.org/show_bug.cgi?id=347724
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the width of the date label is not fixed but changes depending on 
> the text. This causes the entire applet to change its width (if the time is 
> the widest displayed item). This in turn can cause all other applets in the 
> same panel to move whenever the displayed time changes.
> 
> This patch uses FontMetrics to iterate over all possible time strings (with 
> different width) and chooses the widest of them as reference for the fixed 
> width of the time label.
> 
> This way the width of the applet stays the same (unless the date is displayed 
> and changes). The text remains centered though, which means that it can still 
> move within the applet when the time changes.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 
> 
> Diff: https://git.reviewboard.kde.org/r/127102/diff/
> 
> 
> Testing
> ---
> 
> Works with horizontal and vertical panel.
> Also displaying different combinations of "seconds", "date" and "timezone" 
> works.
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: Review Request 127102: Use fixed width for digital clock applet

[Martin Klapetek]

> On Feb. 18, 2016, 1:05 a.m., David Edmundson wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, line 555
> > 
> >
> > rather than looping, can we use FontMetric's maximumCharacterWidth
> > 
> >  * numChars.
> > 
> > Then we could kill sizeHelper competely (FontMetric's didn't exist when 
> > this was written)
> 
> Marco Martin wrote:
> hoping maximumCharacterWidth is reliable for all fonts, this loop really 
> needs to go
> 
> Daniel Faust wrote:
> As far as I understand maximumCharacterWidth returns the width of the 
> widest character of the font - which can be ridiculously wide given that the 
> font supports some wild unicode characters.
> I did a quick test and maximumCharacterWidth returned about twice the 
> width actually needed.

You still don't need this whole loop though, just find the biggest in 0-9 and 
use that for all the numbers (except year).


- Martin


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


On Feb. 17, 2016, 5:23 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127102/
> ---
> 
> (Updated Feb. 17, 2016, 5:23 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Bugs: 347724
> https://bugs.kde.org/show_bug.cgi?id=347724
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the width of the date label is not fixed but changes depending on 
> the text. This causes the entire applet to change its width (if the time is 
> the widest displayed item). This in turn can cause all other applets in the 
> same panel to move whenever the displayed time changes.
> 
> This patch uses FontMetrics to iterate over all possible time strings (with 
> different width) and chooses the widest of them as reference for the fixed 
> width of the time label.
> 
> This way the width of the applet stays the same (unless the date is displayed 
> and changes). The text remains centered though, which means that it can still 
> move within the applet when the time changes.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 
> 
> Diff: https://git.reviewboard.kde.org/r/127102/diff/
> 
> 
> Testing
> ---
> 
> Works with horizontal and vertical panel.
> Also displaying different combinations of "seconds", "date" and "timezone" 
> works.
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: PSA: KAccounts now requires two env vars set

[Martin Klapetek]

On Tue, Jan 19, 2016 at 12:18 AM, Weng Xuetian <wen...@gmail.com> wrote:

> I just wonder whether it is some work for startkde or something to be
> installed under /etc/xdg/plasma-workspace/env/ . If so maybe add a
> file to kaccounts and install it under /etc/xdg/plasma-workspace/env/
> then you won't need to bother packagers to figure out how to make it
> work.
>

Yeah, that could be done. I'll have a look.

Cheers
-- 
Martin Klapetek | KDE Developer

PSA: KAccounts now requires two env vars set

[Martin Klapetek]

Because of a co-installability issue with other DEs [1]
that use the accounts-sso tech, I had to change the location
of the provider and service files we ship. This was decided
after discussing with upstream.

To make KAccounts/libaccounts actually read those from
the new locations, two new env variables will be needed:

AG_PROVIDERS=/path/to/providers
AG_SERVICES=/path/to/services

So please make sure you add them to your systems.
Distro people - please make sure this is set in Plasma
sessions (and ideally in Plasma sessions only).

Your existing accounts should not be affected by this change.

However you won't be able to add new or change accounts
if you don't have these two env vars set. It's recommended
to clean rebuild all things installing providers or services
(currently known to me are ktp-accounts-kcm, kaccounts-providers
and purpose iirc).

This change will affect the Applications 16.04 release.

[1] - https://bugs.kde.org/show_bug.cgi?id=347219

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Review Request 126627: Replace screensaver inhibition by direct dbus calls

[Martin Klapetek]

> On Jan. 4, 2016, 9:18 p.m., Kai Uwe Broulik wrote:
> > app/mainwindow.cpp, line 738
> > <https://git.reviewboard.kde.org/r/126627/diff/1/?file=428424#file428424line738>
> >
> > Is this check neccessary?

Probably not, but then if you think about Gwenview
actually being used outside of Plasma and whoknows
in what environments, I thought it's better to be 
safe.


- Martin


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


On Jan. 4, 2016, 9:07 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126627/
> ---
> 
> (Updated Jan. 4, 2016, 9:07 p.m.)
> 
> 
> Review request for Gwenview, KDE Base Apps and Kai Uwe Broulik.
> 
> 
> Bugs: 334525
> http://bugs.kde.org/show_bug.cgi?id=334525
> 
> 
> Repository: gwenview
> 
> 
> Description
> ---
> 
> This is a better approach to fix bug 334525 than
> https://git.reviewboard.kde.org/r/125910/ which forces
> a default reason (which is user visible).
> 
> With this new patch Gwenview will set a proper reason
> why is it inhibitting the screensaver ("Full Screen Presentation")
> and will use the DBus directly rather than the obsolete
> KNotificationRestrictions API.
> 
> 
> Diffs
> -
> 
>   app/mainwindow.cpp 7b30c4e 
> 
> Diff: https://git.reviewboard.kde.org/r/126627/diff/
> 
> 
> Testing
> ---
> 
> PowerDevil correctly shows that Gwenview is inhibitting
> the PM because "Full Screen Presentation".
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

Re: Review Request 126627: Replace screensaver inhibition by direct dbus calls

[Martin Klapetek]

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

(Updated Jan. 4, 2016, 9:07 p.m.)


Review request for Gwenview, KDE Base Apps and Kai Uwe Broulik.


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


Repository: gwenview


Description
---

This is a better approach to fix bug 334525 than
https://git.reviewboard.kde.org/r/125910/ which forces
a default reason (which is user visible).

With this new patch Gwenview will set a proper reason
why is it inhibitting the screensaver ("Full Screen Presentation")
and will use the DBus directly rather than the obsolete
KNotificationRestrictions API.


Diffs
-

  app/mainwindow.cpp 7b30c4e 

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


Testing
---

PowerDevil correctly shows that Gwenview is inhibitting
the PM because "Full Screen Presentation".


Thanks,

Martin Klapetek

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

[Martin Klapetek]

> On Dec. 30, 2015, 3:48 p.m., Luigi Toscano wrote:
> > For the record: this was submitted to the knotifications frameworks, not to 
> > kdelibs.

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.


- Martin


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


On Dec. 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 Dec. 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

[Martin Klapetek]

> On Dec. 30, 2015, 3:52 p.m., Kai Uwe Broulik wrote:
> > kdeui/notifications/knotificationrestrictions.cpp, line 50
> > <https://git.reviewboard.kde.org/r/125910/diff/2/?file=414354#file414354line50>
> >
> > Note that this string can be shown to the user (we do this in Battery 
> > Monitor), so it should be a translatable proper string.

Is there a value for "no reason" that will not print any reason?


- Martin


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


On Dec. 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 Dec. 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

[Martin Klapetek]

> On Nov. 20, 2015, 8:51 p.m., Johannes Stefan wrote:
> > Ping

There are no more kdelibs releases planned, but I'll push this to frameworks 
for you.


- Martin


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


On Dec. 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 Dec. 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

[Martin Klapetek]

> On Dec. 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.

Ah, do we have any records for that? Also when would the next release be?


- Martin


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


On Dec. 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 Dec. 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: Move ktp-call-ui to kdenetwork

[Martin Klapetek]

On Mon, Dec 28, 2015 at 9:42 AM, Albert Astals Cid <aa...@kde.org> wrote:

> I think there's two separate questions that need answering here:
>
> A) The desire to move ktp-call-ui to KDE Applications is because you don't
> want to do a release and want someone else to do it?
>

No. It is because ktp-call-ui was part of KDE Telepathy suite
since it got written. With frameworks porting it got dropped
because nobody could be bothered to port all the gstreamer
stuff. Now it's ported and it's just being moved back together
with the rest of KDE Telepathy, where it was always intended.

B) Is the quality good enough to move to KDE Applications?
>

It's as good as the rest of KDE Telepathy that is already in
KDE Applications. I vouch for that as the KDE Telepathy
maintainer.

Btw. my KTp-maintainer's condition for including ktp-call-ui
back with the rest was that it must have an active maintainer.
Which it now has.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Move ktp-call-ui to kdenetwork

[Martin Klapetek]

On Mon, Dec 14, 2015 at 4:45 PM, Albert Astals Cid <aa...@kde.org> wrote:

>
> Noone has tested it doesn't sound like "shipping quality ready" for me.
>
> Are you sure we want to ship this to all our users like that? Can we maybe
> get
> some testing first?
>

I would say that's what beta releases are for. We could however
release it say a month before KDE Apps 16.04 beta to give it more
testing time, call it an alpha release.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Please review Snorenotify (Finish Incubating)

[Martin Klapetek]

On Thu, Nov 19, 2015 at 7:51 PM, Aleix Pol <aleix...@kde.org> wrote:

> Hi Hannah,
> I'm happy that you're decided to push this forward, I think it's a
> framework that could be definitely useful. In KDE Connect we'd like to
> be able to use it instead of KNotifications because it's leaner and
> more straightforward to our notifications use-case.


Can you be more specific? Could help improving KNotification for
other users, perhaps.

Cheers
-- 
Martin Klapetek | KDE Developer

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

[Martin Klapetek]

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


Looks good to me


kdeui/notifications/knotificationrestrictions.cpp (lines 48 - 50)
<https://git.reviewboard.kde.org/r/125910/#comment60329>

Btw. the commas are put in the beginning of the lines to have an easy way 
to comment that particular line; you can just comment the whole line and don't 
have to worry about the comma at the end of the previous line.

This is not an issue, I'm just explaining why it was at the beginning of 
the line (or why I think it was) :)


- Martin Klapetek


On Nov. 1, 2015, 10:50 p.m., Johannes Stefan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125910/
> ---
> 
> (Updated Nov. 1, 2015, 10:50 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 125539: [kio-mtp] Add file system freespace retrieval to mtp kioslave

[Martin Klapetek]

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

Ship it!



mtp/kio_mtp.cpp (line 926)
<https://git.reviewboard.kde.org/r/125539/#comment59804>

This doesn't seem useful?


- Martin Klapetek


On Oct. 6, 2015, 9:15 a.m., Emmanuel Pescosta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125539/
> ---
> 
> (Updated Oct. 6, 2015, 9:15 a.m.)
> 
> 
> Review request for kde-workspace and Philipp Schmidt.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Provides total and available space of mtp devices
> 
> 
> Diffs
> -
> 
>   mtp/kio_mtp.h 65ef734 
>   mtp/kio_mtp.cpp 466e4b3 
> 
> Diff: https://git.reviewboard.kde.org/r/125539/diff/
> 
> 
> Testing
> ---
> 
> Works fine
> 
> 
> Thanks,
> 
> Emmanuel Pescosta
> 
>

Re: Review Request 125452: This is a patch for KImgIO that handles xcfgz / xcfbz2 (compressed GIMP) images in KDE (read-only).

[Martin Klapetek]

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


Thanks for your patch!

Unforunately kdelibs is closed for new features and is in maintenance mode 
only. You'd need to port your code to Qt5 and include it in KImageFormats 
framework to get it released.

- Martin Klapetek


On Sept. 29, 2015, 7:56 p.m., Tudor PRISTAVU wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125452/
> ---
> 
> (Updated Sept. 29, 2015, 7:56 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Bugs: 126072
> http://bugs.kde.org/show_bug.cgi?id=126072
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Add support for GIMP's compressed xcf files (xcfgz / xcfbz2).
> 
> 
> Diffs
> -
> 
>   kimgio/CMakeLists.txt bffe44ffb2802c80e9106ab96358ecdab9193c29 
>   kimgio/xcf_compressed.cpp PRE-CREATION 
>   kimgio/xcf_compressed.desktop PRE-CREATION 
>   kimgio/xcf_compressed.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125452/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tudor PRISTAVU
> 
>

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Martin Klapetek]

On Thu, Sep 24, 2015 at 5:54 PM, Boudhayan Gupta <bgu...@kde.org> wrote:

> So I've gone ahead and implemented the DBus bits, and launching via
> "qdbus org.freedesktop.Screenshot / StartAgent" launches Spectacle
> just great.
>
> Is this the command that khotkeys should execute, or is there a more
> genetic dbus command that I can invoke?
>

I don't know about khotkeys, but are QDbus* classes not an option?
Seems better than depending on qdbus (or any other command for
that matter).

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Martin Klapetek]

On Fri, Sep 25, 2015 at 10:54 AM, Boudhayan Gupta <bgu...@kde.org> wrote:

>
> In other *unrelated* news, I've woken up to certain disaster on the
> dbus mailing list, so for now I'll move it to the org.kde namespace.
>

It's not a disaster, people are just telling you "think the interface
through
and then propose it on a correct list (xdg), not on dbus list". Far from
disaster :P

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Martin Klapetek]

On Thu, Sep 24, 2015 at 10:08 AM, Boudhayan Gupta <bgu...@kde.org> wrote:

>
> This does make more sense, but wouldn't an interface under the
> org.freedesktop namespace need to be vetted by Freedesktop?
>

Not really, you can use whatever namespace you want.
You could use the freedesktop one and then inform the
xdg list about it, maybe others would join with the idea.

Or you can just start with org.kde.screenshot and add it
to KSnapshot (tho that would require another release of
it).

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Review Request 125056: Fix build on OS X

[Martin Klapetek]

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


Looks good to me


CMakeLists.txt (line 45)
<https://git.reviewboard.kde.org/r/125056/#comment58729>

This change is already preceeded with 
https://git.reviewboard.kde.org/r/124962/


- Martin Klapetek


On Sept. 5, 2015, 1:47 a.m., Samuel Gaist wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125056/
> ---
> 
> (Updated Sept. 5, 2015, 1:47 a.m.)
> 
> 
> Review request for kde-workspace and Jonathan Riddell.
> 
> 
> Repository: kwallet-pam
> 
> 
> Description
> ---
> 
> Add include dir setup to gcrypt find cmake module
> 
> Added implementation of pam_syslog and pam_vsyslog for OS X
> 
> 
> add reviewboardrc
> 
> 
> Diffs
> -
> 
>   .reviewboardrc PRE-CREATION 
>   CMakeLists.txt f60ac4121c793d62a7471074c1d4ea687360557c 
>   cmake/modules/FindLibGcrypt.cmake 27de0b46a82e92a24734476ea32401bef01a8ca8 
>   pam_darwin.h PRE-CREATION 
>   pam_darwin.c PRE-CREATION 
>   pam_kwallet.c a84585ef1fc3f4aeac728e707d52479ec85b5300 
> 
> Diff: https://git.reviewboard.kde.org/r/125056/diff/
> 
> 
> Testing
> ---
> 
> Build on OS X 10.8
> 
> 
> Thanks,
> 
> Samuel Gaist
> 
>

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

[Martin Klapetek]

> On Sept. 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.
> 
> Luigi Toscano wrote:
> Exactly, a separate repository with patches does not make sense (git 
> already manages patches).
> 
> René J.V. Bertin wrote:
> Git doesn't make it particularly easy to keep patches (or patch sets) 
> separate once they're committed (and a couple other things have been 
> committed too), or does it?

Sure it does. Here is a random git commit from plasma-workspace -- 
https://quickgit.kde.org/?p=plasma-workspace.git=commit=e2df9af6e2df4ba1c07dc40d43ecd591584db498
 - you can get the diff with "git show 
e2df9af6e2df4ba1c07dc40d43ecd591584db498", you can get a diff from that commit 
to HEAD by "git diff e2df9af6e2df4ba1c07dc40d43ecd591584db498" or diff set 
between two commits - "git diff 
e2df9af6e2df4ba1c07dc40d43ecd591584db498..6ee0d63af943526e2453631c6c709861061f08ac"


- Martin


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


On Sept. 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 Sept. 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: Moving KScreenGenie out of Review and replacing KSnapshot

[Martin Klapetek]

On Sat, Aug 22, 2015 at 9:37 AM, Boudhayan Gupta bgu...@kde.org wrote:

 Hi,

 Now that Applications 15.08 is out of the door, can I begin the
 process of renaming KScreenGenie to KSnapshot, moving it to KDE
 Graphics and replacing the current KSnapshot?

 Also, how would such a move be done?


Since the review is done, currently the process is that you need to get
permission from the module maintainer to move it to the intended module
and then just request the move with sysadmin.

Be sure to keep i18n teams in the loop too.

https://techbase.kde.org/Projects/Release_Team#Module_Coordinators

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Plasma Applet for Audio Volume for kdereview

[Martin Klapetek]

On Wed, Aug 5, 2015 at 4:24 PM, Martin Steigerwald mar...@lichtvoll.de
wrote:

 Hi.

 Am Mittwoch, 5. August 2015, 12:45:01 schrieb Jonathan Riddell:
  plasma-pa is a new volume manager and is intended to be a replacement for
  KMix in Plasma.

 Will that make PulseAudio mandatory?

 It is still not working for me in all cases (stuttering sound with
 PlaneShift
 OpenAL sound output as one of the last issues) and am I happy that Plasma 5
 and KMix still work without it.


You can still use kmix with Plasma, there is even a port to kf5 though I'm
not
sure what's its state.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Replacement for KDateTime

[Martin Klapetek]

On Sun, Aug 2, 2015 at 7:36 PM, Thiago Macieira thi...@kde.org wrote:

 If the format you're looking for is in the CLDR, you're welcome to add the
 support to QLocale.


It's not really about any missing locale, it's about setting different
parameters
for the given locale. For example David Edmundson (a brit) repeatedly tells
me
that en_GB (cldr) uses 12h clock format but pretty much any clock is
guaranteed
to be 24h clock format.

So what is missing/wanted is telling QLocale to use en_GB *but* return
any time string in 24h format for example. Or to use ISO date format
by default. The stuff coming from cldr might not always be what
the user wants. And there's no easy and global way to override it
other than setting different LC_TIME value, which is less than ideal
as it can give you 24h clock format but will leave you with different
date format too, so it's a hit'n'miss game.

If the format you're looking for requires support from translators, please
 add
 a new class to QtCore.


Suppose there's such QLocale setting as described above, then it would
be just a matter of some regexp inside the time formatting function which
would add/remove the ap/AP strings for the clock. I imagine.


  Alternatively, do you John have any roadmap about QLocale? Perhaps
  we could help with filling the missing bits into QLocale directly too.

 The roadmap currently stands as follows:


Does this mean there is no roadmap? :)

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Replacement for KDateTime

[Martin Klapetek]

On Mon, Aug 3, 2015 at 6:34 PM, Thiago Macieira thi...@kde.org wrote:

 On Monday 03 August 2015 08:33:54 Martin Klapetek wrote:
   If the format you're looking for requires support from translators,
 please
   add
   a new class to QtCore.
 
  Suppose there's such QLocale setting as described above, then it would
  be just a matter of some regexp inside the time formatting function which
  would add/remove the ap/AP strings for the clock. I imagine.

 How would that setting be set? Who would set it? Is that something that the
 clock app would use and allow the user to set?

 If so, why not extract the time format and show that to the user? Or, at
 least, parse it to set the default of Use 24-hour clock? If the user
 wants
 to toggle 24-hour, save the new time format in the config file and use it
 to
 format the time next time.


I may have explained it poorly, so let me try again. tl;dr at the bottom :)

I can put a checkbox to the Plasma panel clock which would either
enable or disable 24h clock format. And in fact we do exactly that.
If the user wants to see 24h clock format in the panel, he can check
that checkbox. If he wants AM/PM clock, he can uncheck the checkbox.
Simple as that.

The implementation takes the Qt.locale().timeFormat(Locale.ShortFormat)
(it's QML), checks for the 24h clock option and either adds AP
or removes AP from the format string returned by Qt.locale().
The actual clock on the panel is then printed using
Qt.formatTime(currentTimeObject, thatModifiedTimeFormatString).

Now, this will affect _only_ the Plasma panel clock. This will _not_
affect Dolphin's time stamps, Gwenview's picture-taken times,
this won't affect anything else but the panel clock and the panel clock
alone. But if I want to have 24h clock format, I want it everywhere,
in all apps, system-wide, not _only_ in the panel clock. Everything
else will be however using time formatted by the LC_TIME locale
default format.

Currently each and every application would have to implement similar
code as the Plasma panel clock - get the locale's time format string,
check for some config, add/remove AP from the format string, print
the time using QDateTime().toString(theModifiedTimeFormatString).
Or each application would have to read the date/time format string
from somewhere, some global config in order to have the same time
format everywhere.

Is it clear now? Do you see what I'm getting at?

Setting different LC_TIME values proven to not be feasible, because
very often users want just 24h clock format _and_ their locale's
date format. Or some date format and their locale's time format.

Ideally there would be a global setting, set from System Settings,
perhaps written into ~/.config/QtProject.conf, which QLocale could
internally read and return the time formatted according to that setting
already. This would spare every single application doing it on its own.
Then, calling QDateTime().toString() or QLocale().toString(QDateTime)
would return the time formatted by user preference already and it would
return it in all apps, uniformly, same format.

I guess such feature might not be feasible for QLocale, hence my
suggestion to bring back KLocale in a limited form, purely for global
date/time formatting purposes around KDE apps, to have the same
date/time format everywhere around.

As a side note, missing global date/time format setting is a regression
from the kde4 times.

---

tl;dr - it'd be nice to be able to set a custom time format for all
QDateTime/
QLocale users without them needing to do anything at all.

Hope it's clear now :)

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Replacement for KDateTime

[Martin Klapetek]

On Sun, Aug 2, 2015 at 3:26 PM, John Layt j...@layt.net wrote:

 If you do this you also need all of KLocale again which we also
 do not want. Don't even go there, we changed it for a purpose.


Fwiw, over the year(s) of Plasma5, many times it was expressed
that KLocale is greatly missed, especially when it comes to date/time
formatting. QLocale just doesn't cut it and the digital clock applet is
doing many tricks to get the stuff formatted as wanted. The biggest
downside is that it applies to the clock applet only, so there can't be
a single system-wide Use 24h-clock format switch. Clock in panel
can/will be 24h format while everything else will be LC_TIME format
(time stamps in Dolphin eg).

There are some other examples where KLocale was missed in Plasma
but I can't remember which ones that was right now, maybe someone
will fill it.

Maybe it could be worth bringing KLocale back in some limited form
as an intermediate solution?

Alternatively, do you John have any roadmap about QLocale? Perhaps
we could help with filling the missing bits into QLocale directly too.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: RFC: KDE Bugzilla Bugs Expiration

[Martin Klapetek]

On Fri, Jul 31, 2015 at 11:02 AM, Dominik Haumann dhaum...@kde.org wrote:


 Of course, some wishes and valid bugs would be automatically closed then,
 too.
 But this is probably not a big issue, since a wish that will never get
 implemented
 is useful neither for us as developers nor for the users at all.


I'd like to disagree with that^, in kde-telepathy we have many valid
bug reports/wishes which we would want to have/implement when
there will be that day when you have all the time you need. But we
just struggle to find the time.

They are useful for developers/maintainers because if a newcomer
shows up, you can just tell him look at all the opened wishes,
pick one and work on it (which we do regularly). It's also useful
when you have a free weekend and want to work on some of those
opened reports. Which you wouldn't be able if they would be all
closed.

They are also useful for users so they don't get reported again and
again.


 And if there are bug reports that from a developer's perspective should
 not be
 auto-closed, then we could attach a custom tag 'no-auto-close' or so to
 the bug.
 Then this script could ignore the tagged ones.


Yeah, this would be great.


 Comments? Strong objections? ;)


Personally I prefer the Dan's version with the EOL, but in general +1
to the idea.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Notes from the Phabricator BoF

[Martin Klapetek]

One thing that bothers me a bit is the commits shas having format like
rKONVERSATIONc64d1cd32445f6921109fdbdb17ae44378d404c5

Can something be done about the rPROJECTNAME prefix? I find it
quite confusing and hard to read; if you're looking at commits in
a specific repo, I think it's clear to which project/repo it belongs.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: [Development] Please help me get my pending review count down

[Martin Klapetek]

On Wed, Jul 29, 2015 at 11:47 AM, Marc Mutz marc.m...@kdab.com wrote:

 On Wednesday 29 July 2015 09:04:42 Martin Klapetek wrote:
  Can you perhaps create a single diff against 5.5/dev/master
  which could be easily applied? That should make things
  much easier to help :)

 Assuming you're talking about the dbus changes, wouldn't you actually want
 to
 cherry-pick them one by one and see which one breaks?


Perhaps that should be done as well, yes, although Thiago requested the
/whole set of changes/ to be tested:

I need someone to take the whole set of changes, apply to their Qt 5.5 build
 and test KF5-powered applications to see what gets broken and why. Please
 provide patches to either QtDBus, KF5 or the applications.


Which would be much simpler with a single diff.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: KDE Applications Versioning

[Martin Klapetek]

On Wed, Jul 8, 2015 at 1:24 PM, Aleix Pol aleix...@kde.org wrote:

 On Wed, Jul 8, 2015 at 11:43 AM, Martin Klapetek
 martin.klape...@gmail.com wrote:
  As the KDE Apps release is getting near, is this being
 considered/deployed?
  Should we be setting some CMake variables?
 
  Cheers
  --
  Martin Klapetek | KDE Developer

 Yes, that's why Albert was asking for a blog/wiki documentation.


...on a release-team mailing list to which I guess most of us are not
subscribed ;)

Cheers
-- 
Martin Klapetek | KDE Developer

Re: KDE Applications Versioning

[Martin Klapetek]

As the KDE Apps release is getting near, is this being considered/deployed?
Should we be setting some CMake variables?

Cheers
-- 
Martin Klapetek | KDE Developer

PSA: KDE Telepathy master now must have new plugin installed

[Martin Klapetek]

Hello,

to all KDE Telepathy users compiling from master - with today's changes
you must install new additional Telepathy plugin in order for KDE Telepathy
to work at all. This plugin is currently located at github[1] and will
hopefully
move soon somewhere upstream at freedesktop.org.

This is a runtime-only dependency and it's a must have. KDE Telepathy will
not
work without it at all. I'll be adding it to kdesrc-build too. It requires
libmission-control-plugins-dev (or equivalent), libsignon-glib[-dev] and
libaccounts-glib[-dev].

For packagers, there is a find-package call in ktp-common-internals marked
as RUNTIME. There will be a release prior to KDE Applications 15.08 release,
but if you're providing nightly builds, you must include this new package,
ideally mark it as a hard dependency of ktp-common-internals.

One more note - if you're building Ubuntu's signon-ui by hand, it tries to
install
some files to /etc. These files must be present in /etc and not in any
other folder
otherwise Google authentication will not work; apparently this is a
signon-ui limitation
which I'll be looking into at some point.

[1] - https://github.com/mck182/telepathy-accounts-signon

Cheers
-- 
Martin Klapetek | KDE Developer

Re: KDE Applications Versioning

[Martin Klapetek]

On Tue, Jun 9, 2015 at 11:35 AM, David Jarvie djar...@kde.org wrote:


 There has been debate about this for frameworks, and there is an argument
 there (not agreed by everybody) for making all frameworks have the same
 version, since framework libraries are dependencies for other software.

 The same arguments don't apply to applications, which in general are not
 dependencies. Other than convenience for maintainers who forget to update
 version numbers, I can see no good reason for forcing applications to have
 a uniform version number. I prefer using the version number to reflect the
 development status of the application (by use of major, minor and patch
 version numbers), as in the past. This makes it easier when dealing with
 bug reports, to know the state of the program at the version in question.
 For maintainers who want to use some other scheme, that's also fine. The
 important thing is to leave the choice.


Personally I prefer having the application versions matching the release
version
(ie. 15.04.x) so that there is no additional versions mapping required (is
version 3.4
part of KDE Applications 15.04 or 15.08 or..?).

So I for one would also welcome such feature, but can absolutely relate to
David's
position too; the versioning should not be forced on Applications. So this
could be
easily made opt-in by using some predefined CMake variable and projects
having
such var would get the version raised by the scripts.

+1 to that idea.

Cheers
-- 
Martin Klapetek | KDE Developer

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

[Martin Klapetek]

On Tue, Apr 21, 2015 at 10:45 PM, Scarlett Clark sgcl...@kubuntu.org
wrote:

 kaccount-integration:

 https://build-sandbox.kde.org/job/kaccounts-integration%20stable%20stable-qt4/PLATFORM=Linux,compiler=gcc/19/console


There is no kaccounts-integration kde4/qt4 version and should not be.

I've removed it from kde-build-metadata, please discard this job.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: KF5-QT5 branchgroup - jobs that need developeer attention

[Martin Klapetek]

On Wed, Apr 15, 2015 at 9:44 AM, Scarlett Clark sgcl...@kubuntu.org wrote:

 Here is a list of mostly compile failures and other tid bits that need to
 be
 resolved by the respective developers. If you know the developer of a
 project
 and they are not on this list please forward this. All jobs can be viewed
 at :
 https://build-sandbox.kde.org/
 Most of these are osx failures. If osx is not to be supported, I need to
 know
 that too. Questions - concerns - just ask.
 Thanks,
 Scarlett

 ktp-common-internals -Linux compile failure breaks: ktp*


It's trying to build branch frameworks, which should not happen, everything
for ktp* is in master.

Where does it get the branch info from?


Cheers

-- 
Martin Klapetek | KDE Developer

Re: KF5-QT5 branchgroup - jobs that need developeer attention

[Martin Klapetek]

On Wed, Apr 15, 2015 at 12:02 PM, Ben Cooksley bcooks...@kde.org wrote:

 On Wed, Apr 15, 2015 at 9:58 PM, Martin Klapetek
 martin.klape...@gmail.com wrote:
  On Wed, Apr 15, 2015 at 9:44 AM, Scarlett Clark sgcl...@kubuntu.org
 wrote:
 
  Here is a list of mostly compile failures and other tid bits that need
 to
  be
  resolved by the respective developers. If you know the developer of a
  project
  and they are not on this list please forward this. All jobs can be
 viewed
  at :
  https://build-sandbox.kde.org/
  Most of these are osx failures. If osx is not to be supported, I need to
  know
  that too. Questions - concerns - just ask.
  Thanks,
  Scarlett
 
  ktp-common-internals -Linux compile failure breaks: ktp*
 
 
  It's trying to build branch frameworks, which should not happen,
 everything
  for ktp* is in master.
 
  Where does it get the branch info from?

 kde-build-metadata.


The logical-module-structure? Must be old or something,
I've changed it back in February to use master, see

http://quickgit.kde.org/?p=kde-build-metadata.gita=commith=6494c5f8466d32e53a189c66fc071c91ac08062c

Cheers
-- 
Martin Klapetek | KDE Developer

Re: The Future or KDE PIM Releases

[Martin Klapetek]

On Sun, Apr 12, 2015 at 11:31 AM, Daniel Vrátil dvra...@kde.org wrote:


 With regard to Akonadi resources, we will NOT release KDE Accounts


What's meant by KDE Accounts?


  Facebook


Facebook can be pretty much dropped. Their new API is now
so limiting, there's hardly any use for having a resource for it.

The only useful bit I see is to have the posts synced but there's
no app that would take advantage of that data so even that has
no real use...

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Help please with some builds in the new jenkins-ci for KDE Cont..

[Martin Klapetek]

On Apr 9, 2015 6:31 AM, sgcl...@kubuntu.org wrote:

 On Thursday, April 09, 2015 12:54:40 AM Martin Klapetek wrote:
  Hey,
 
  On Wed, Apr 8, 2015 at 10:08 PM, Scarlett Clark
 sgcl...@kubuntu.org wrote:
   Hello all,
   I am to the point now with my ci that I just need help with some
 of
   these builds. While I am learning fast,
   some of these failures are stumpers.
  
   I have been fighting with kaccounts-integration much to long. I
 did
   finally
   get it to find all its dependencies, including akonadi kf5,
 however...
  
   compile failure:
   19:56:27 In file included from /home/jenkins/builds/kaccounts-
   integration/tests/testakonadiaccounts.cpp:19:0:
   19:56:27 /home/jenkins/builds/kaccounts-
  
 integration/tests/../src/daemon/akonadi/akonadiaccounts.h:25:33:
 fatal
   error:
   AkonadiCore/Attribute: No such file or directory
   19:56:27  #include AkonadiCore/Attribute
   19:56:27  ^
   19:56:27 compilation terminated.
 
  Akonadi is only optional in kaccounts-integration and given the
 current
  status
  of KF5 Akonadi (unreleased with no plans), I would just not bother
 with
  trying
  fix this particular issue.
 
  Cheers
  CMake Warning at CMakeLists.txt:20 (find_package):
 17:54:41   By not providing FindKF5Akonadi.cmake in
 CMAKE_MODULE_PATH this project
 17:54:41   has asked CMake to find a package configuration file
 provided by
 17:54:41   KF5Akonadi, but CMake did not find one.
 17:54:41
 17:54:41   Could not find a package configuration file provided by
 KF5Akonadi with
 17:54:41   any of the following names:
 17:54:41
 17:54:41 KF5AkonadiConfig.cmake
 17:54:41 kf5akonadi-config.cmake
 17:54:41
 17:54:41   Add the installation prefix of KF5Akonadi to
 CMAKE_PREFIX_PATH or set
 17:54:41   KF5Akonadi_DIR to a directory containing one of the
 above files.  If
 17:54:41   KF5Akonadi provides a separate development package or
 SDK, be sure it has
 17:54:41   been installed.
 17:54:41

 Is the result without akonadi. Either way I am dead in the water with
 this build and it is holding up quite alot :(

▼ Hide quoted text

On Apr 9, 2015 6:31 AM, sgcl...@kubuntu.org wrote:

 On Thursday, April 09, 2015 12:54:40 AM Martin Klapetek wrote:
  Hey,
 
  On Wed, Apr 8, 2015 at 10:08 PM, Scarlett Clark
 sgcl...@kubuntu.org wrote:
   Hello all,
   I am to the point now with my ci that I just need help with some
 of
   these builds. While I am learning fast,
   some of these failures are stumpers.
  
   I have been fighting with kaccounts-integration much to long. I
 did
   finally
   get it to find all its dependencies, including akonadi kf5,
 however...
  
   compile failure:
   19:56:27 In file included from /home/jenkins/builds/kaccounts-
   integration/tests/testakonadiaccounts.cpp:19:0:
   19:56:27 /home/jenkins/builds/kaccounts-
  
 integration/tests/../src/daemon/akonadi/akonadiaccounts.h:25:33:
 fatal
   error:
   AkonadiCore/Attribute: No such file or directory
   19:56:27  #include AkonadiCore/Attribute
   19:56:27  ^
   19:56:27 compilation terminated.
 
  Akonadi is only optional in kaccounts-integration and given the
 current
  status
  of KF5 Akonadi (unreleased with no plans), I would just not bother
 with
  trying
  fix this particular issue.
 
  Cheers
  CMake Warning at CMakeLists.txt:20 (find_package):
 17:54:41   By not providing FindKF5Akonadi.cmake in
 CMAKE_MODULE_PATH this project
 17:54:41   has asked CMake to find a package configuration file
 provided by
 17:54:41   KF5Akonadi, but CMake did not find one.
 17:54:41
 17:54:41   Could not find a package configuration file provided by
 KF5Akonadi with
 17:54:41   any of the following names:
 17:54:41
 17:54:41 KF5AkonadiConfig.cmake
 17:54:41 kf5akonadi-config.cmake
 17:54:41
 17:54:41   Add the installation prefix of KF5Akonadi to
 CMAKE_PREFIX_PATH or set
 17:54:41   KF5Akonadi_DIR to a directory containing one of the
 above files.  If
 17:54:41   KF5Akonadi provides a separate development package or
 SDK, be sure it has
 17:54:41   been installed.
 17:54:41

 Is the result without akonadi. Either way I am dead in the water with
 this build and it is holding up quite alot :(

But that's just a warning which is perfectly fine when it doesn't find
optional dependency.

Or is that treated as an error (the log says just warning)?

Cheers
--
Martin Klapetek | KDE Developer

Re: Help please with some builds in the new jenkins-ci for KDE Cont..

[Martin Klapetek]

Hey,

On Wed, Apr 8, 2015 at 10:08 PM, Scarlett Clark sgcl...@kubuntu.org wrote:

 Hello all,
 I am to the point now with my ci that I just need help with some of
 these builds. While I am learning fast,
 some of these failures are stumpers.

 I have been fighting with kaccounts-integration much to long. I did finally
 get it to find all its dependencies, including akonadi kf5, however...

 compile failure:
 19:56:27 In file included from /home/jenkins/builds/kaccounts-
 integration/tests/testakonadiaccounts.cpp:19:0:
 19:56:27 /home/jenkins/builds/kaccounts-
 integration/tests/../src/daemon/akonadi/akonadiaccounts.h:25:33: fatal
 error:
 AkonadiCore/Attribute: No such file or directory
 19:56:27  #include AkonadiCore/Attribute
 19:56:27  ^
 19:56:27 compilation terminated.


Akonadi is only optional in kaccounts-integration and given the current
status
of KF5 Akonadi (unreleased with no plans), I would just not bother with
trying
fix this particular issue.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: KDE Telepathy has an unreleased dependency

[Martin Klapetek]

On Fri, Feb 27, 2015 at 2:07 AM, Albert Astals Cid aa...@kde.org wrote:


 So we still need a KPeople release, which is still in playground so noone
 has
 properly reviewed it, and you want to speed-turn it into a frameworks in 1
 day. Do you actually have anyone to review it in such notice? At least
 sanitize the headers?


It was requested on February 13th for KPeople to be reviewed and joined
frameworks for 5.8. Today the 2 weeks review period is over so if there
are no outstanding issues it should be moved today. The only issue is
that the release won't be available for the first two betas while we could
simply release KPeople a bit sooner so KDE Telepathy would be in the betas.


 This feels like rush, rush and rush. KDE Applications schedule has been set
 for months, I've sent various reminders about the freeze dates, and yet,
 here
 we are, post freeze with unresolved issues, why are we doing this now and
 not
 last week?


I've started the discussion about moving it on February 3rd. There's about
15
repos and about 3000 dependencies. I'm sorry if I managed to miss one while
trying to fix everything for the release (and mind you that the number of
KTp
developers pretty much reduced to one). I'm sorry that nobody caught this
in the review period for about a month. We're clearly all just people with
just
enough free time.

If you feel like it should not be part of KDE Apps 15.04, fine, just say so
and
I'll request a move of everything back.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: KDE Telepathy has an unreleased dependency

[Martin Klapetek]

On Thu, Feb 26, 2015 at 4:22 PM, Vishesh Handa m...@vhanda.in wrote:


 On Wed, Feb 25, 2015 at 6:39 PM, Martin Klapetek 
 martin.klape...@gmail.com wrote:

 As I said it's not even being used right now, so imho would be fine if it
 got
 removed/disabled altogether.


 Also, it will never work. Baloo KF5, has no knowledge about emails. That
 code also uses Akonadi APIs.


There, I fixed it.

https://git.reviewboard.kde.org/r/122729/

Cheers
-- 
Martin Klapetek | KDE Developer

Re: KDE Telepathy has an unreleased dependency

[Martin Klapetek]

On Wed, Feb 25, 2015 at 6:33 PM, David Faure fa...@kde.org wrote:

 On Wednesday 25 February 2015 15:38:19 Aleix Pol wrote:
  At the moment KPeople is an optional dependency, there's still the
  possibility to use it without KPeople.

 I guess you mean s/KPeople/Baloo/g here.


No this was actually KPeople being optional dep of KTp, but the truth is
that
all the code is actually only tested with KPeople as that's pretty much what
we're aiming for in the past couple years (but KPeople went through many
many changes, it started as Nepomuk thing, then akonadi, now it's
self-contained,
so we never wanted to hard-depend on it). Now we've optimized everything
for KPeople usage so imho it makes only sense to not discard it now and
in fact make it finally a hard-dependency of KDE Telepathy.


 The problem is: Baloo depends on a few frameworks,
 and now we would have KPeople depending on Baloo.
 So it wouldn't be possible to build all of frameworks together, one would
 need
 to interject Baloo in the middle of it, in order to be able to build with
 all
 options i.e. with this optional dependency.

 The reason it's optional so it doesn't matter means you might as well
 delete
 the code, since it becomes impractical to build it anyway.
 More seriously I would suggest moving the plugin to Baloo maybe, if it
 makes
 sense for it to depend on KPeople, or moving it in workspace maybe (but
 then
 it's not available in other workspaces). Or to this new product (set of
 modules) that I think we should have to host drkonqi, kio-extras etc., i.e.
 the set of runtime deps common to workspace and applications. This issue
 keeps
 popping up.

 If you want a short term solution, I'd say the plugin should stay in
 playground somewhere.
 I don't like the optional dependency thing because it will still show up in
 dependency diagrams, making a mess with baloo being in the middle of
 frameworks while it was decided that it's not.


As I said it's not even being used right now, so imho would be fine if it
got
removed/disabled altogether.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: KDE Telepathy has an unreleased dependency

[Martin Klapetek]

On Wed, Feb 25, 2015 at 9:15 AM, David Faure fa...@kde.org wrote:

 On Wednesday 25 February 2015 02:04:58 Albert Astals Cid wrote:
  El Dimarts, 24 de febrer de 2015, a les 11:52:55, Martin Klapetek va
 escriure:
   I just realized that one of the main dependencies, KPeople, will be
   released only after KDE Applications Beta 2 as it's targeting KF 5.8
   (released 12th March
   while KDE Apps Beta 2 is released 11th March).
  
   I'm not sure what should be done in this case; we could perhaps move
 the
   5.8 release two days earlier, but this would still miss Beta 1.
  
   So uhh...what should we do?
 
  I can see three options:
  a) Do not release KPeople as part of frameworks but as part of KDE
  Applications 15.04 (and move it later to frameworks)
  b) Do not release KDE Telepathy as part of KDE Applications 15.04
  c) Give KDE Telepathy an exception to only join on Beta 3 of KDE
  Applications 15.04

 I see a fourth option:
 d) make a KPeople 5.7 release NOW

 If it's ready, I can make that happen with two commands or so.


I had this very idea in the morning. Aleix is the maintainer so he
should +2 this but definitely +1 from me.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Moving KDE Telepathy to kdenetwork

[Martin Klapetek]

On Mon, Feb 23, 2015 at 11:29 PM, Albert Astals Cid aa...@kde.org wrote:

 El Dilluns, 23 de febrer de 2015, a les 17:31:47, Martin Klapetek va
 escriure:
  Follow up: as there were no objections, I've just requested a move of
 these
  repos:

 Can you please go to the settings-repository in projects.kde.org and make
 sure the i18n branches are correctly set? master is set as kdelibs4 trunk
 branch when it should be set to KF5 trunk branch, no?


Yes, done.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Moving KDE Telepathy to kdenetwork

[Martin Klapetek]

On Tue, Feb 24, 2015 at 7:46 PM, Albert Astals Cid aa...@kde.org wrote:


  kaccounts-providers is just data repository, there's no building
 involved.
  But if you feel like there should be one, I'll do.

 Well i see a CMakeLists.txt so it does build stuff (Even if not much),
 please
 let's have it in.


Yeah, it's for installing the files into proper places.


  signon-kwallet-extension will be in the same situation as
  kaccounts-integration,
  it won't build until we manage to get the newer accounts-sso stack
 building
  on jenkins (which I was told to wait for jenkins revamping, I'm not sure
  what's the
  state of that though).

 Well let's have the build in even if it's red, as a reminder that stuff
 needs
 fixing.


Ok.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Moving KDE Telepathy to kdenetwork

[Martin Klapetek]

(we should also keep this on kde-core-devel)

On Fri, Feb 20, 2015 at 1:49 AM, Scott Lerman smler...@gmail.com wrote:


 On Thu, Feb 19, 2015 at 5:49 PM, Martin Klapetek 
 martin.klape...@gmail.com wrote:

 Hey,

 As was said in the main thread already, KDE Telepathy does not try to be
 swiss army knife and doitall, we also don't want to copy all features of
 Kopete
 (what would be the point of that :) We also prefer to keep the amount of
 options
 to be as minimal as possible.


 I could be wrong, but I think this discussion started with the idea of
 retiring Kopete completely, in which case it would be nice to have KDE
 Telepathy be as close as to matching Kopete's features as is reasonable.


Yeah, moreless. But if there's big interest in all those Kopete features, I
think Kopete should continue to be released, even if from extragear (and so
it would be in fact only retired from the KDE Apps release bulk). But if
you guys think otherwise, that's fine.


 As far as keeping the number of options minimal, my issue with that is
 that the reason I like KDE so much more than other desktops is that it's
 configurable. At this point, KDE seems to be the only desktop that doesn't
 enforce The One True Way to do everything, and I would hate to see the
 ability to configure KDE applications go away.


Right, but one also needs to keep a good balance and not provide an option
for every single possible thing. KTp really always aimed to be simple Chat
application and our target users are ordinary users. That's our mission
from the start and I'd like to keep it that way.




 
  Manual sorting of groups in the contact list
  Disable automatic resizing of text entry area
  Disable sound notifications when away (ideally only with an explicit
 away
  setting and not idle/auto-away)


 These^ all fall into the category of what I wrote above. Maybe the last
 one
 could be done, if someones finds the time (manpower is scarce).



 The reason I like manual sorting of groups is that it lets me put my
 Google contacts at the top of the list and my Facebook contacts at the
 bottom. Maybe I'm the only person that wants to do that, so I assume I can
 fake it with putting underscores at the beginning of the names.

 If the time to learn the code isn't too bad, I'd be happy to try to help
 implement stuff. I haven't done much C++ since college, and I've never
 really done anything with Qt or KDE, but if it's worth the trouble I'm sure
 I'd cause, I can give it a shot.


Sure, help is always welcome. But please do get in touch at
kde-telepa...@kde.org first, we hate to say no to already written code :)




  No system tray icon when there's a new message from a contact with an
 open
  chat window


 Yes, well, there should be blinking taskbar entry, no reason to blink at
 two places
 really :)



 Yeah, I know, but for some weird reason I always found the spinning Kopete
 icon easier to notice than the blinking taskbar entry. I can keep dreaming,
 though, right?


Well we should really improve the taskbar then, if it does not do its job
that well :) Creating another solutions is just working around the original
problem.

But let's move actual issues reporting to bugzilla.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Applications/libraries that want to be in KDE Applications 15.04

[Martin Klapetek]

On Tue, Feb 17, 2015 at 10:51 PM, Albert Astals Cid aa...@kde.org wrote:

 This Applications/libraries want to be in KDE Applications 15.04 but as
 far as
 i see they have not been moved/agreed yet:

  * libkgeomap to kdegraphics
http://lists.kde.org/?l=kde-core-develm=141863095618592w=2
  * KDE Telepathy to kdenetwork
http://lists.kde.org/?l=kde-core-develm=142292100526542w=2


And also KAccounts (kaccounts-integration, kaccounts-providers,
signon-kwallet-extension)
to kdenetwork.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Moving KDE Telepathy to kdenetwork

[Martin Klapetek]

On Sat, Feb 7, 2015 at 5:04 PM, Albert Astals Cid aa...@kde.org wrote:


 Speaking of releases, you guys understand you'll be in a bigger release
 schedule and will have to follow its rules, right?


Yes, obviously.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Moving KDE Telepathy to kdenetwork

[Martin Klapetek]

On Thu, Feb 5, 2015 at 10:24 PM, Sune Vuorela nos...@vuorela.dk wrote:

 On 2015-02-02, Martin Klapetek martin.klape...@gmail.com wrote:
  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

 I'm pretty sure that everything in kde-runtime is only for kdelibs. in
 Frameworks, everything has been moved into the framework it is a part
 of.

 KAccounts sounds mostly like a network thing to me, at least so far. If
 it becomes more than a network accounts thing, maybe it should become a
 framework ?


At this point it's really about the KCM and the kded module, doesn't
sound too frameworky to me...


  [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

 would this also be a time to maybe reconsider if one went a bit
 overboard with the original repository splitting?


This follows the upstream Telepathy philosophy (and hey, also unix), where
everything is fully standalone component and can work without the others.

Also kinda follows the frameworks, this way anyone can pick the component
that they need/want (like the auth handler or filetransfer handler) and not
have
to drag the whole stuff.

Personally I find the structure like that better (as someone who works with
the code everyday); these days everything is/can be scripted anyway.


 Having a libkdetelepathyinternalsprivate as a *public* available library
 somehow
 smells like a bit wrong to me.


Right, this has been one of the #1 goals back in the times, to have this
a proper public library. But everyone from the original team is now gone,
raising the question wasn't really a success [1]. But I agree this should
be done.


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

 So that one is staying in ... playground ... so far?


Extragear.

[1] - http://mail.kde.org/pipermail/kde-telepathy/2014-October/012250.html

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Moving KDE Telepathy to kdenetwork

[Martin Klapetek]

On Thu, Feb 5, 2015 at 11:33 PM, Albert Astals Cid aa...@kde.org wrote:

 El Dijous, 5 de febrer de 2015, a les 21:24:10, Sune Vuorela va escriure:
  On 2015-02-02, Martin Klapetek martin.klape...@gmail.com wrote:
   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
 
  I'm pretty sure that everything in kde-runtime is only for kdelibs. in
  Frameworks, everything has been moved into the framework it is a part
  of.
 
  KAccounts sounds mostly like a network thing to me, at least so far. If
  it becomes more than a network accounts thing, maybe it should become a
  framework ?
 
   [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
 
  would this also be a time to maybe reconsider if one went a bit
  overboard with the original repository splitting?  Having a
  libkdetelepathyinternalsprivate as a *public* available library somehow
  smells like a bit wrong to me.

 +1 all that many ktp repositories always seemed more a hassle than a
 benefit
 to me. What's the benefit of such high granularity?


As responded to Sune, this follow the upstream philosophy/hierarchy. And
also what frameworks does. Each of these components can work fully
standalone
(just with ktp-common-internals) and allows anyone to take that component
without dragging all 200k LOC, much of they don't need.

I don't think it's a hassle really...possibly for packagers, I could see
that.
But as a developer...all you need is kdesrc-build, releasing is also
scripted...

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Moving KDE Telepathy to kdenetwork

[Martin Klapetek]

On Fri, Feb 6, 2015 at 12:21 AM, Aleix Pol aleix...@kde.org wrote:


 Getting more pragmatic, I think the clear distinction between Kopete
 and KTp is that Kopete is a KDE application by the book (kxmlgui, a
 main window, integrates on the system tray etc.) and KTp will blend in
 your Plasma, which is a feature I value very positively.


I'd just like to clarify that a bit - KTp offers sets of (optional) applets
which
allows you to use KTp from Plasma only, ie. there's a presence applet
(kinda like a systray icon), which expands into a contact list if clicked
and you can also have a chat applet (kinda like facebook chat). Besides
that it also has full QWidget based stuff too (also kxmlgui and friends).

Of course this can all be mixed and thanks to the architecture, new
completely different clients/UIs can exist and be mixed in too
(theoretically
one could use the Empathy for audio/video calls, for example).

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Moving KDE Telepathy to kdenetwork

[Martin Klapetek]

On Wed, Feb 4, 2015 at 1:51 AM, Albert Astals Cid aa...@kde.org wrote:

 El Dimarts, 3 de febrer de 2015, a les 00:49:17, Martin Klapetek va
 escriure:
  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.

 KTP is all KF5 based at the moment, right?


Correct.


 Not being a IM user myself, how does KTP compare to kopete feature wise?


I'm not sure to be honest as I don't know what Kopete can all do. KTp does
not try
to be a swiss army knife of IM, that's for sure, the main objectives are
ease of use,
simple UIs with powerful features underneath and providing good integration
in Plasma.

The main advantage is the architecture and backends - it's all DBus
activated (and
stateless) components, super easy to extend with new protocols support
using Qt,
GLib or Python. Plus the Telepathy project is widely adopted in the world -
Unity,
Ubuntu Phone, Gnome, Jolla, N9 and maybe in other places, making it proven
by usage.
Small downside is that it is developed mostly by Gnome folks and can suffer
from
being bent to their needs only.


 Kopete mailing list: is there any work happening in kopete? Are you even
 thinking on a port to KF5?

  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.

 I'd say that given it had review already and we deemed it was good enough,
 we
 can just skip the code review and focus on more administrative stuff :D


Worksforme :)



  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.

 Was thinking, why not kdenetwork? I mean what kind of non network related
 account would you add to KAccounts?


Well I don't have a strong opinion either way. If you think it suits better
in kdenetwork,
then ok. And yes at this point all accounts are network related.

Cheers
-- 
Martin Klapetek | KDE Developer

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: Another proposal for modernization of our infrastructure

[Martin Klapetek]

Hey,

On Tue, Jan 27, 2015 at 11:08 AM, Jan Kundrát j...@kde.org wrote:

 Hi,
 as promised, here is a proposal on how our infrastructure can be improved,
 with emphasis on service integration. There are screenshots inside.

 Feedback is very welcome.


Thanks for putting that together.

One thing I still haven't seen anywhere in these threads is anything from
the people
currently testing the Gerrit on kio and plasma-framework and how they find
that
instance for usage in KDE. Their input should be quite valuable as they
have real
world experience with KDE + Gerrit which is the subject of this proposal.

I would be quite interested to hear those experiences and opinions - guys,
can you
please write something up?

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Feature matrix for future infrastructure

[Martin Klapetek]

On Thu, Jan 22, 2015 at 2:20 PM, Milian Wolff m...@milianw.de wrote:

 Hey all,

 I started this page just now:

 https://community.kde.org/Sysadmin/FutureInfrastructure

 It's pretty limited, so far. I hope everyone could help out and extend it
 and
 fill it with the information and verify that each contestant is displayed
 in a
 fair light. Please add links, comments etc. pp. wherever possible.


I've added two things - ability to download patches directly from web
and ability to merge patches directly from web (so you don't need to
download them, apply and then push).

But I'm unsure of these features on either side, so I left it blank
and would like to ask someone in more knowledge to fill those in.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Sysadmin report on the modernization of our infrastructure

[Martin Klapetek]

On Wed, Jan 21, 2015 at 5:12 AM, Ben Cooksley bcooks...@kde.org wrote:

 Hi all,

 As promised in the earlier thread, i'd like to present the sysadmin
 report on the state of the infrastructure surrounding our code.

 It contains a detailed summary of what is broken with our existing
 systems, why change is necessary and an evaluation of the options we
 considered. We have also made a proposal based on our evaluations and
 the wishlist of functionality drawn up the community.

 Please find it attached - and let us know what you think. Feedback is
 welcome.


Thanks a lot Ben for this, very comprehensive document.

One question about Phabricator - in the discussions before the RB web UI
and uploading patches via web was mentioned a lot, will uploading diff
through
web interface still be possible via Phabricator or is the Arcanist thing a
must?
This isn't clear from the report.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Review Request 110083: Make kdepim libs optional dependency for libkfbapi

[Martin Klapetek]

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

(Updated Jan. 20, 2015, 4:24 p.m.)


Status
--

This change has been discarded.


Review request for kdelibs and KDEPIM-Libraries.


Repository: libkfbapi


Description
---

kdepim-libs are needed in the facebook library only to return user info as 
KABC::Addressee and note as KMime::Message, plus events use KCalCore classes. 
This patch makes dependency on kdepim-libs optional and disables building the 
event classes completely in case kdepim-libs was not found.


Diffs
-

  CMakeLists.txt 5aefdcf 
  LibKFbAPI-KDEPIM.pc.in PRE-CREATION 
  LibKFbAPI-KDEPIMConfig.cmake.in PRE-CREATION 
  LibKFbAPI.pc.in af537d1 
  libkfbapi/CMakeLists.txt dac62bc 
  libkfbapi/commentinfo.h e5578c7 
  libkfbapi/kdepim-utils.h PRE-CREATION 
  libkfbapi/kdepim-utils.cpp PRE-CREATION 
  libkfbapi/likeinfo.h e06052e 
  libkfbapi/noteinfo.h 2492db1 
  libkfbapi/noteinfo.cpp 154593d 
  libkfbapi/notificationinfo.h a882694 
  libkfbapi/userinfo.h ac22a7e 
  libkfbapi/userinfo.cpp 26c64da 
  libkfbapi/userinfoparser_p.h 0189a17 

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


Testing
---

Builds correctly here in both cases


Thanks,

Martin Klapetek

Re: kdesrc-build: how to set cmake options for one specific framework?

[Martin Klapetek]

On Wed, Jan 14, 2015 at 8:08 PM, Mark Gaiser mark...@gmail.com wrote:

 On Wed, Jan 14, 2015 at 7:36 PM, Martin Klapetek 
 martin.klape...@gmail.com wrote:

 On Wed, Jan 14, 2015 at 7:31 PM, Mark Gaiser mark...@gmail.com wrote:

 Hi,

 Kdesrc-build uses (right?) projects.kde.org to get a list of frameworks
 and compile them. That works great :)

 However, a few hours ago David Faure pushed something rather cool in KIO
 [1] that i would like to play with. It adds the KIOCORE_ONLY cmake define.
 Sure, i can compile KIO without kdesrc-build and just add -DKIOCORE_ONLY
 to the cmake step.

 I prefer to keep using kdesrc-build so i wonder how to add a cmake
 define for just the kio framework.


 You can put it locally into your kdesrc-buildrc with cmake-options,
 something like:

 module kio
 repository kde-projects
 cmake-options -DKIOCORE_ONLY=true
 end module

 You can even name the module kio-coreonly and then do kdesrc-build
 kio-coreonly to get the core only.

 Cheers
 --
 Martin Klapetek | KDE Developer


 Hi Martin,

 Thank you for the hints. The first solution works, but is not ideal. When
 i do that then typing: kdesrc-build kio will compile that kio you just
 added. However, when just typing kdesrc-build it only compiles the kio
 from frameworks, not the one added in a later kdesrc-build include file.
 I'm guessing this is a bug?

 The second solution also works, but results in KIO being compiled twice.
 Once for frameworks and once where added.

 Do you know another way? :)


If you look at kf5-frameworks-build-include at the bottom, there's an
example
of how to set an option just for one module. You can either edit that file
directly
or just add it to your kdesrc-buildrc (if you have none put one in
~/.kdesrc-build)

Cheers
-- 
Martin Klapetek | KDE Developer

Re: kdesrc-build: how to set cmake options for one specific framework?

[Martin Klapetek]

On Wed, Jan 14, 2015 at 7:31 PM, Mark Gaiser mark...@gmail.com wrote:

 Hi,

 Kdesrc-build uses (right?) projects.kde.org to get a list of frameworks
 and compile them. That works great :)

 However, a few hours ago David Faure pushed something rather cool in KIO
 [1] that i would like to play with. It adds the KIOCORE_ONLY cmake define.
 Sure, i can compile KIO without kdesrc-build and just add -DKIOCORE_ONLY
 to the cmake step.

 I prefer to keep using kdesrc-build so i wonder how to add a cmake define
 for just the kio framework.


You can put it locally into your kdesrc-buildrc with cmake-options,
something like:

module kio
repository kde-projects
cmake-options -DKIOCORE_ONLY=true
end module

You can even name the module kio-coreonly and then do kdesrc-build
kio-coreonly to get the core only.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: libkgeomap

[Martin Klapetek]

On Sun, Jan 4, 2015 at 8:21 PM, Michael G. Hansen m...@mghansen.de wrote:


 We also had a Google Summer of Code student work on the library, and the
 project was not rejected by Google.


I would actually be surprised if it was. GSoC is run by the Google Open
Source Office
and this program particularly is done by about 3 people; I don't believe
they are actually
reviewing all the applications, that's up to the mentoring orgs (KDE). Then
Google has
tens of thousands employees, I also don't believe everyone of them knows
terms to 3rd
party usage of some of their products.

Just sayin... :)

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Changes to our Git infrastructure

[Martin Klapetek]

On Sun, Dec 28, 2014 at 11:23 PM, Ben Cooksley bcooks...@kde.org wrote:

 Hi all,

 Based on the current feedback:

 1) It seems people see no use in clone repositories.
 2) Little commentary has been made on the merits of scratch
 repositories, with some dismissing them as pointless.


 Therefore sysadmin proposes that both clone and scratch repositories
 be eliminated as a concept with the next iteration of our Git
 infrastructure.


N not scratch repos. I can see clones being useless as branches
in the actual repos should be used instead, but I personally consider
scratch repos a very useful thing, for example to host simple projects
that shouldn't be part of any main/big module - they are much more
easier to set up than proper repositories - mostly because they don't
require manual sysadmin actions (and fileing tickets by the developer),
it's a personal git space readily available.

The negative side is the repo propagation - it does take a while
for the repo to appear for example in quickgit - so links cannot be
posted for viewing online immediately. Imo if this is solved, scratch
repos would be quite useful.

Also just looking at quickgit.k.o, there is about 1000 scratch repos
currently, so it looks it's in a good use (though granted, many of the
repos may be outdated and are just overdue for removal).

Cheers
-- 
Martin Klapetek | KDE Developer

Re: [Kde-pim] Problems with infrastructure

[Martin Klapetek]

On Mon, Dec 15, 2014 at 2:58 AM, Kevin Kofler kevin.kof...@chello.at
wrote:

 Albert Astals Cid wrote:
  It also puts the discussion about a possible switch to gerrit in a weird
  situaion since we either all switch and have uniformity or we don't and
  then we end up with reviewborad+gerrit :/

 Or we just stop the Gerrit experiment in the core KDE projects as a failure
 (it was always made clear that it is only an experiment and can be ended at
 any moment), and kick out Trojitá from KDE if Jan absolutely wants to use
 Gerrit. (It's not even a KF5 or kdelibs application, but a Qt-only one.)
 Then he can use whatever tools he wants. Problem solved.


Our very own manifesto, which we've established not so long ago, does not
dictate that a project must be kf5 or kdelibs based application to be
considered a KDE project.

Also, this is a horrendous and concerning way of speaking, please don't do
that again.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: [Kde-pim] kdepimlibs splitting done

[Martin Klapetek]

On Fri, Dec 12, 2014 at 1:52 PM, Daniel Vrátil dvra...@redhat.com wrote:


 I guess the next steps are to review them, find maintainers and decide when
 they will get released. I would propose that this is discussed on the next
 IRC
 meeting on Monday (I'll send a separate email about that).


Just fyi, there's a Plasma meeting on Monday from 12:00 - ~13:00 CET,
so watch our for timing collisions :)

Cheers
-- 
Martin Klapetek | KDE Developer

Re: KAccounts move into extragear/base

[Martin Klapetek]

On Wed, Dec 10, 2014 at 12:43 AM, Albert Astals Cid aa...@kde.org wrote:


 I'm missing some documentation in the .h files you install from lib.


All .h are now fully documented.



 Also it seems
 private Q_SLOTS:
 void getCredentials();
 could go into the d pointer via the Q_PRIVATE_SLOT magic?


Done.



 
  KAccounts-providers is only a data repository, it contains the various
 XML
  files needed for some basic accounts like Google and Facebook.
 
  Signon-kwallet-extension is a plugin for signond (the upstream daemon) to
  store secretes in kwallet.

 Maybe the construct/destruct qDebugs you can turn into qcDebugs? Or plain
 remove them?


Yeah, not too useful. Removed.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: API Breakage?: Re: [kcmutils] src: Fix typo in headers generation

[Martin Klapetek]

On Wed, Dec 10, 2014 at 9:56 AM, Raymond Wooninck tittiatc...@gmail.com
wrote:

 On Tuesday 9 December 2014 16:16:23 Martin Klapetek wrote:
  Git commit 0256b80e9ac7c1459afe0ac021d27e985cba14d3 by Martin Klapetek.
  Committed on 09/12/2014 at 16:16.
  Pushed by mklapetek into branch 'master'.
 
  Fix typo in headers generation
 
  Also install to properly capitalized subdirectory

 And it seems that we have our first breakage in Frameworks.  Programs that
 compile against Frameworks 5.5, will no longer compile against Frameworks
 5.6
 and vice versa.

 The change of the directoryname causes issues as that for 5.5 you need to
 have
 the ksettings/includefile.h, but this will fail on 5.6 as that one would
 require KSettings/includefile.h.

 I was hoping that the camelcase headers could help out here, but they are
 installed in the same directoy.


Ah hmm...I did this because at some other places there are
KSettings/includefile.h and the build was failing.

I guess I'll just revert the directory capitalization then, but leave the
typo fix itself.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: API Breakage?: Re: [kcmutils] src: Fix typo in headers generation

[Martin Klapetek]

On Thu, Dec 11, 2014 at 12:09 AM, Albert Astals Cid aa...@kde.org wrote:


 Can we get both the correct and the old way and mark it as deprecated?

 the correct way is cool since it helps us by having the same way of using
 stuff on all frameworks, predictibility is awesome.


And it eases up porting from kdelibs4support but not having to change all
the includes.



 the old way gives us the compatibility we promise.

 Now, i've no clue what i'm talking about so excuse me if i'm suggesting
 something stupid :D


I was acutally thinking about the same, would mean the headers are
duplicated
though. Additionally the old headers could have some #pragma message
so it tells people while building.

The argument against was that whatever would use the correct wouldn't
build
against older frameworks...which in the cases I know about wouldn't be a
problem
because they depend on master anyway, so bumping the min version in their
find_package(..) wouldn't be a problem.

Cheers
-- 
Martin Klapetek | KDE Developer

KAccounts move into extragear/base

[Martin Klapetek]

Hello,

I'd like to move the KAccounts project out of playground into
extragear/base (with a stop in kdereview), more precisely the repositories
kaccounts-integration, kaccounts-providers and signon-kwallet-extension
(all at kde: ).

KAccounts is the continuation of WebAccounts/KDE Accounts/Accounts project
started by Alex Fiestas. It's a suite of kded module, kcm module, a support
library and some plugins to provide a one single central place to set up
any kinds of accounts, build on top of Accounts-SSO project [1]. This will
be used as the only way to set up KDE Telepathy accounts in its frameworks
version and is intended to handle PIM/Akonadi accounts as well (currently
it's tested on the Facebook resource and I need to talk with the PIM team
about how it will fit into the new Akonadi rewrite). Adding new account
types is easy, it's just a matter of two XML files and a UI plugin.

KAccounts-providers is only a data repository, it contains the various XML
files needed for some basic accounts like Google and Facebook.

Signon-kwallet-extension is a plugin for signond (the upstream daemon) to
store secretes in kwallet.

There's a guide how to set it all up at
https://community.kde.org/KTp/Setting_up_KAccounts

Ticket for move into kdereview has been filed, so please give it a look

[1] - http://code.google.com/p/accounts-sso/

Cheers
-- 
Martin Klapetek | KDE Developer

Re: libkface

[Martin Klapetek]

On Tue, Sep 30, 2014 at 7:44 AM, Gilles Caulier caulier.gil...@gmail.com
wrote:

 2014-09-30 3:06 GMT+02:00 Vishesh Handa m...@vhanda.in:
  Hey Tobias
 
  Some comments about the code -
 
  1. The code seems to be licensed under GPL. In order to make it into a
  framework, it will need to be re-licensed. This library seems like an
 ideal
  candidate for becoming a framework.

 libkface have been writted in same way than libkipi, libkexiv2, and
 libkdcraw, already in KDEGraphics.


The thing is - if libkface is set to become a framework and be part of the
KDE Frameworks effort, it has to follow KDE Frameworks policies and rules.
One of those is that the code is licensed under LGPLv2.1+ (I think, someone
correct me if I'm wrong). So libkface would have to be relicensed.
Unfortunately same for the other listed libraries if they should become
frameworks. And we would most certainly welcome that ;)


  2. The copyright header seems to say Part of the Digikam Project. You
 may
  want to change that.

 Idem here. libkface follow exactly the same way than libkipi,
 libkexiv2, libkdcraw.


Personally I see nothing wrong with the Part of the Digikam Project; if
that framework is being developed as part of Digikam project, then why not
(we still have many files with this is part of kdelibs project btw).


 
  4. The coding style uses seems a little unorthdox. Could you perhaps add
 a
  link to where one can know what style is being followed? Maybe this
 could go
  in the README file.

 coding style follow instructions from digiKam project :


That's another policy of the Frameworks - we try to have a consistent
coding style all over Frameworks, that means that libkface would have to
start following the same style in order to be included in Frameworks.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Review Request 119594: ensure there's ::windowHandle() and then restore the a file dialogs size before calling ::exec()

[Martin Klapetek]

 On Aug. 4, 2014, 1:13 a.m., Lukáš Tinkl wrote:
  No change here, ie. it doesn't restore the file dialog geometry.
 
 Thomas Lübking wrote:
 what is your precise testcase?
 a bit remote because of your other patches: did you check that the 
 correct platformtheme lib is used? (ran into this in a custom installation. 
 self compiled plugin ended up in a different path than the distro qt5 plugin 
 path)
 is the size data updated in kdeglobals?
 
 Lukáš Tinkl wrote:
 Testcase: opening a filedialog in any Qt/KDE app, restarting the app - 
 default file/window size
 
 I guess I'm using the correct platformtheme, otherwise I wouldn't be 
 seeing KDE fialogs right? Also, toplevel windows are not restored either
 
 Yup, the size is always correctly saved to the config files

I can also confirm that file dialogs do not have their size restored with this 
patch (using tests/qfiledialogtest and also real dialogs around the workspace), 
however testing the dir selection does give me properly restored size dialog 
(./qfiledialogtest --staticFunction getExistingDirectory --modal on). Qt 5.3.1 
here.


- Martin


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


On Aug. 3, 2014, 9:16 p.m., Thomas Lübking wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119594/
 ---
 
 (Updated Aug. 3, 2014, 9:16 p.m.)
 
 
 Review request for KDE Frameworks, kdelibs, Aleix Pol Gonzalez, Lukáš Tinkl, 
 and Martin Klapetek.
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 summarized
 
 
 Diffs
 -
 
   src/platformtheme/kdeplatformfiledialoghelper.cpp 520b6f5 
 
 Diff: https://git.reviewboard.kde.org/r/119594/diff/
 
 
 Testing
 ---
 
 See
 https://git.reviewboard.kde.org/r/119512/
 
 
 Thanks,
 
 Thomas Lübking
 

Re: Review Request 119594: ensure there's ::windowHandle() and then restore the a file dialogs size before calling ::exec()

[Martin Klapetek]

 On Aug. 4, 2014, 1:13 a.m., Lukáš Tinkl wrote:
  No change here, ie. it doesn't restore the file dialog geometry.
 
 Thomas Lübking wrote:
 what is your precise testcase?
 a bit remote because of your other patches: did you check that the 
 correct platformtheme lib is used? (ran into this in a custom installation. 
 self compiled plugin ended up in a different path than the distro qt5 plugin 
 path)
 is the size data updated in kdeglobals?
 
 Lukáš Tinkl wrote:
 Testcase: opening a filedialog in any Qt/KDE app, restarting the app - 
 default file/window size
 
 I guess I'm using the correct platformtheme, otherwise I wouldn't be 
 seeing KDE fialogs right? Also, toplevel windows are not restored either
 
 Yup, the size is always correctly saved to the config files
 
 Martin Klapetek wrote:
 I can also confirm that file dialogs do not have their size restored with 
 this patch (using tests/qfiledialogtest and also real dialogs around the 
 workspace), however testing the dir selection does give me properly restored 
 size dialog (./qfiledialogtest --staticFunction getExistingDirectory --modal 
 on). Qt 5.3.1 here.
 
 Lukáš Tinkl wrote:
 Because KDirSelectDialog doesn't use KWindowConfig:
 
 
 void KDirSelectDialog::Private::readConfig(const KSharedConfig::Ptr 
 config, const QString group)   
 { 

 m_urlCombo-clear();  

   

 KConfigGroup conf(config, group); 

 m_urlCombo-setHistoryItems(conf.readPathEntry(History Items, 
 QStringList())); 
   

 const QSize size = conf.readEntry(DirSelectDialog Size, QSize());   

 if (size.isValid()) { 

 m_parent-resize(size);   

 } 

 }

Yup, didn't know that. Disabling this^ code breaks the resizing in dir 
selection too.


- Martin


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


On Aug. 3, 2014, 9:16 p.m., Thomas Lübking wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119594/
 ---
 
 (Updated Aug. 3, 2014, 9:16 p.m.)
 
 
 Review request for KDE Frameworks, kdelibs, Aleix Pol Gonzalez, Lukáš Tinkl, 
 and Martin Klapetek.
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 summarized
 
 
 Diffs
 -
 
   src/platformtheme/kdeplatformfiledialoghelper.cpp 520b6f5 
 
 Diff: https://git.reviewboard.kde.org/r/119594/diff/
 
 
 Testing
 ---
 
 See
 https://git.reviewboard.kde.org/r/119512/
 
 
 Thanks,
 
 Thomas Lübking
 

Re: Review Request 119593: Ensure there's a plastform window before restoring the window geometry

[Martin Klapetek]

 On Aug. 4, 2014, 1:13 a.m., Lukáš Tinkl wrote:
  No change here, ie. it doesn't restore the window geometry.

Same here, Qt 5.3.1. Thomas, which Qt are you using?

Nevertheless, as your knowledge about windows stuff is much better and if you 
think this patch is needed anyway, go for it.


- Martin


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


On Aug. 3, 2014, 9:13 p.m., Thomas Lübking wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119593/
 ---
 
 (Updated Aug. 3, 2014, 9:13 p.m.)
 
 
 Review request for KDE Frameworks, kdelibs, Aleix Pol Gonzalez, Lukáš Tinkl, 
 and Martin Klapetek.
 
 
 Repository: kconfig
 
 
 Description
 ---
 
 summarized
 
 
 Diffs
 -
 
   src/gui/kwindowconfig.cpp c3cefb7 
 
 Diff: https://git.reviewboard.kde.org/r/119593/diff/
 
 
 Testing
 ---
 
 See
 https://git.reviewboard.kde.org/r/119512/
 
 
 Thanks,
 
 Thomas Lübking
 

Re: Review Request 119594: fix FileDialog size restorage

[Martin Klapetek]

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

Ship it!


This does fix the issue here; +1 from me

Also, are you investigating/reporting the bug to Qt devs?

- Martin Klapetek


On Aug. 4, 2014, 1:57 p.m., Thomas Lübking wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119594/
 ---
 
 (Updated Aug. 4, 2014, 1:57 p.m.)
 
 
 Review request for KDE Frameworks, kdelibs, Aleix Pol Gonzalez, Lukáš Tinkl, 
 and Martin Klapetek.
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 - saving in the deconstrutor is insufficient,
   the dialog might survive the runtime
   - needs to be saved when the dialog is finished or just closed
   (the closeEvent is not invoked if at least a sync dialog is finished)
 
 - ensure a windowHandle and then restore the window size before calling 
 ::exec()
 
 - workaround an apparent QWidget QPA bug where even for a created platform 
 window
   the QWindow geometry is not applied on the QWidget
 
 
 Diffs
 -
 
   src/platformtheme/kdeplatformfiledialogbase.cpp b823bc7 
   src/platformtheme/kdeplatformfiledialogbase_p.h 8ef5b1e 
   src/platformtheme/kdeplatformfiledialoghelper.h 406a4f1 
   src/platformtheme/kdeplatformfiledialoghelper.cpp 520b6f5 
 
 Diff: https://git.reviewboard.kde.org/r/119594/diff/
 
 
 Testing
 ---
 
 See
 https://git.reviewboard.kde.org/r/119512/
 
 
 Thanks,
 
 Thomas Lübking
 

Re: Review Request 119512: Fix saving/loading of file dialog sizes

[Martin Klapetek]

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


+1, looks good to me

- Martin Klapetek


On July 28, 2014, 11:35 a.m., Lukáš Tinkl wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119512/
 ---
 
 (Updated July 28, 2014, 11:35 a.m.)
 
 
 Review request for kdelibs, Aleix Pol Gonzalez and Martin Klapetek.
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 This patch tries to fix saving/restoring file dialog sizes. Using 
 KWindowConfig::restoreWindowSize() doesn't work here with the modal exec() 
 methods. Instead, the patch uses the same method as KDirSelectDialog. 
 
 
 Diffs
 -
 
   src/platformtheme/kdeplatformfiledialoghelper.h 406a4f1 
   src/platformtheme/kdeplatformfiledialoghelper.cpp 520b6f5 
   src/platformtheme/kdirselectdialog.cpp 9a4082a 
   src/platformtheme/kdirselectdialog_p.h 5a8e758 
 
 Diff: https://git.reviewboard.kde.org/r/119512/diff/
 
 
 Testing
 ---
 
 Current Plasma 5, working fine :)
 
 
 Thanks,
 
 Lukáš Tinkl
 

Re: Review Request 119512: Fix saving/loading of file dialog sizes

[Martin Klapetek]

On July 28, 2014, 12:17 p.m., Lukáš Tinkl wrote:
  If the only issue is the open ::exec() TODO, you might trick it by 
  calling ::winId(), then restore the size and ultimately ::exec()
  
  Otherwise you could open an own nested eventloop instead of relying on the 
  dialogs exec, but that'd be less elegant.
  
  In either case I don't see why bringing your own config re/storage.
 
 Lukáš Tinkl wrote:
 The trick with winId() unfortunately doesn't work, the dialog gets 
 restored to the default size, not the saved one... :/ Any other ideas?
 
 Thomas Lübking wrote:
 I'm not gonna say impossible, but the reason could then not be the 
 absence of a windowHandle()
 Eventually sth. alters the window size post the restore.
 
 Have you checked for presence of a m_dialog-windowHandle() after calling 
 m_dialog-winId() and m_dialog-size() after calling 
 KWindowConfig::restoreWindowSize(m_dialog-windowHandle(), 
 conf-group(FileDialogSize)); and before calling m_dialog-exec() ?

KWindowConfig::restoreWindowSize is broken for some reason.

I did some investigation and basically what happens is this:
 - KWindowConfig::restoreWindowSize resutls in QXcbWindow::setGeometry call
 - geometry is set to the QWindow, but no to its QWidgets (no idea why)
 - when event loop hits next loop, widgets are checked if their size = their 
min size
 - because they didn't receive the updated geometry, this^ is not true
 - the widgets get resized to their min size
 - the window has a wrong geometry

I don't know why the widgets don't receive the event however, my knowledge in 
this is lacking.


- Martin


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


On July 28, 2014, 12:21 p.m., Lukáš Tinkl wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119512/
 ---
 
 (Updated July 28, 2014, 12:21 p.m.)
 
 
 Review request for KDE Frameworks, kdelibs, Aleix Pol Gonzalez, and Martin 
 Klapetek.
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 This patch tries to fix saving/restoring file dialog sizes. Using 
 KWindowConfig::restoreWindowSize() doesn't work here with the modal exec() 
 methods. Instead, the patch uses the same method as KDirSelectDialog. 
 
 
 Diffs
 -
 
   src/platformtheme/kdeplatformfiledialoghelper.h 406a4f1 
   src/platformtheme/kdeplatformfiledialoghelper.cpp 520b6f5 
   src/platformtheme/kdirselectdialog.cpp 9a4082a 
   src/platformtheme/kdirselectdialog_p.h 5a8e758 
 
 Diff: https://git.reviewboard.kde.org/r/119512/diff/
 
 
 Testing
 ---
 
 Current Plasma 5, working fine :)
 
 
 Thanks,
 
 Lukáš Tinkl
 

Re: Review Request 113419: Remove the upper-half white gradient from KSplash Minimalistic theme

[Martin Klapetek]

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

(Updated May 9, 2014, 4:29 p.m.)


Status
--

This change has been discarded.


Review request for kde-workspace and Plasma.


Repository: kde-workspace


Description
---

NOTE: This is intended for the PW2, not current 4.x series.

Removes the white-black gradient spreading through the upper-half of the 
screen. IMHO it looks more elegant when it's just plain black.


Diffs
-

  ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 

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


Testing
---


File Attachments


Before
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/10/24/32c5b408-0d3e-4639-b2ae-18f1a8dbd699__ksp_old.png
After
  
https://git.reviewboard.kde.org/media/uploaded/files/2013/10/24/d494e4b4-6e13-4ee8-934c-6ff7ac21bc33__ksp_new.png


Thanks,

Martin Klapetek

Re: KDE Frameworks Release Cycle

[Martin Klapetek]

On Sun, May 4, 2014 at 6:36 PM, David Faure fa...@kde.org wrote:

 [Cross posting against my will...]

 On Sunday 04 May 2014 16:27:44 Luigi Toscano wrote:
  I understand that the big concern was about the testing: stable branches
 did
  not receive the same attention

 This is not the main concern.

 My main concern is that application developers prefer to work around bugs
 in
 KF5 (previously: kdelibs) rather than fix things at the right level,
 because
 fixes in KF5 will only be available in 6 months, and I want the bug fixed
 now.

 Your suggestion (6-months stable release) brings us back to exactly that.

 We'd like to try something better. Monthly small increments.
 Never big changes that break things, they get cut into small increments
 too.
 So no reason to buffer changes for 6 months.


However this highly depends on the distro policies - if some of the big
distros say we will not update KF5 every month because our policies, then
the 6 months buffer is just moved elsewhere, at the distro level because
they will update only with the new release. If the application makes a hard
requirement on some specific version (which would be the point of this),
then distros would not package that fixed app before there would be that
particular version of KF5, so I imagine the app developers would still work
around the bugs in their own code and release a minor version which the
distro would package. Or worse there would be patches at distro level.

Imho distributions' opinion should be highly taken into consideration
because these are the people actually delivering our code to 98% of users.

I like the original proposal, but I also think we need to stay pragmatic
and work with real world facts.

Cheers
-- 
Martin Klapetek | KDE Developer

Default bugzilla asignees for frameworks

[Martin Klapetek]

Hey,

As we now have people stepping up as frameworks maintainers, I think part
of that maintainership should be becoming the default assignee for given
framework on bugzilla.

For example I filed a bug against KIO and that was assigned to
kdelibs-b...@kde.org, where I imagine it gets drowned among other kdelibs
bugs.

Given we're going big with frameworks now, we /need to/ make our bug
handling better than sending them to kdelibs-bugs.

If there are no objections, I'll assign frameworks bugs to people as per
the table here: https://community.kde.org/Frameworks/List

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Default bugzilla asignees for frameworks

[Martin Klapetek]

On Tue, Apr 15, 2014 at 9:13 PM, Albert Astals Cid aa...@kde.org wrote:


 So how does one get all the bugs about kdelibs (including frameworks)?


For what purpose? If you just want an overview, you can do advanced search
and select all the frameworks- products (simple click on first framework
and shift-click on last; see [1]).

Also note that not all frameworks have bugzilla products yet.

[1] - http://bit.ly/1kuDo59

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Default bugzilla asignees for frameworks

[Martin Klapetek]

On Tue, Apr 15, 2014 at 9:56 PM, Albert Astals Cid aa...@kde.org wrote:


 If you want to change the default assignee, that's fine, but then maybe add
 kdelibs-b...@kde.org as Default CC List: ?


Sure, good point. Should it go to kdelibs-bugs though? Wouldn't something
like frameworks-bugs be better so it's not mixed with kdelibs4 bugs?

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Help splitting kde-workspace

[Martin Klapetek]

On Mon, Mar 31, 2014 at 6:50 AM, Aleix Pol aleix...@kde.org wrote:


 Hi,
 I've been looking into the issue with Nicolás (aka PovAddict) and we
 managed to figure out all repositories history except for plasma-workspace
 and plasma-desktop. The problem was that not only they were moved now, but
 they were moved back in the day from kde-base when kde-workspace was
 created. It seems like something possible to solve but it didn't look like
 something that would pay off, so I decided to graft those. If somebody has
 great problems, I'd suggest to use the occasion and suggest a sane solution
 before we all start working on it, otherwise I think that grafts are a good
 solution (you can use the time I'm sending this e-mail as a proof we tried
 otherwise).

 Other than that, the rest of repositories have been pushed with full
 history (AFAIK) and it seems to work well. If there's any left-over issue,
 there will always be the kde-workspace repository for reference.

 I just pushed as well changes in the dependency-data-kf5-qt5 file so that
 when one tries to compile plasma-desktop gets the correct dependencies;
 note that you shouldn't be building kde-workspace anymore. It worked on my
 system, I hope it will work on most systems.

 I hope this doesn't distort your workflow too much and that we can soon
 start to take advantage of the new, leaner, organization of the project.


Thanks for your hard work guys (you too Alex), well done.

Kudos  cookies

Cheers
-- 
Martin Klapetek | KDE Developer

Re: Review Request 115695: Rework KNotification to work without KNotify daemon

[Martin Klapetek]

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

(Updated Feb. 26, 2014, 4:53 p.m.)


Status
--

This change has been discarded.


Review request for kde-workspace, KDE Frameworks, Plasma, and Sune Vuorela.


Repository: knotifications


Description
---

This patch merges KNotify daemon into KNotificationManager to have less daemons 
running and less dbus traffic. The patch is not yet finished (and for now it's 
full of QDebugs, that will all be removed and FIXMEs to indicate what needs 
doing), but as the Alpha2 is quite soon, I'd like to start the general review 
asap so some more changes can be done if needed.

Now it's KNotificationManager that handles the KNotifyPlugin-s and hands them 
the notification directly. KNotifyConfig was repurposed a bit, now it serves 
mostly just as the .notifyrc wrapper, all the rest is reused from the 
KNotification object. There are some changes in the KNotification API - id() 
and appName() are now exposed to public and slotReceivedId(int) is now also 
public so that KNotificationManager can directly give it an id. I'd like to 
rename this and make it a non-slot. It's not the DBus/Galago server ID anymore, 
that is handled in NotifyByPopup which is responsible for communicating with 
the galago server (all the methods there were renamed to actually have *galago* 
in the name so it's clear), therefore the mapping of DBus/Galago Server ids is 
managed only there as it is actually only needed here. KNotitification::id() is 
assigned by the KNotificationManager and it's a simple increasing counter.

The UI/Plasmoid changes will come next - basically the plan is to put only the 
Persistent notifications in the notifications history.


Diffs
-

  src/knotifyconfig.h PRE-CREATION 
  src/knotifyconfig.cpp PRE-CREATION 
  src/knotifyplugin.h PRE-CREATION 
  src/knotifyplugin.cpp PRE-CREATION 
  src/notifybypopup.h PRE-CREATION 
  src/notifybypopup.cpp PRE-CREATION 
  src/notifybypopupgrowl.h PRE-CREATION 
  src/notifybypopupgrowl.cpp PRE-CREATION 
  CMakeLists.txt 63ebf71 
  src/CMakeLists.txt a81b913 
  src/knotification.h 00554ba 
  src/knotification.cpp 5d7405b 
  src/knotificationmanager.cpp a4d0dfa 
  src/knotificationmanager_p.h 81d962d 

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


Testing
---

Works perfectly with both plasma notifications and kpassivepopup.


Thanks,

Martin Klapetek

Re: Review Request 115695: Rework KNotification to work without KNotify daemon

[Martin Klapetek]

 On Feb. 19, 2014, 11:06 a.m., Aleix Pol Gonzalez wrote:
  src/knotification.cpp, line 333
  https://git.reviewboard.kde.org/r/115695/diff/3/?file=243840#file243840line333
 
  remove qDebugs?

As the description says - and for now it's full of QDebugs, that will all be 
removed - so I'll drop all the qdebug issues


- Martin


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


On Feb. 13, 2014, 11:14 a.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/115695/
 ---
 
 (Updated Feb. 13, 2014, 11:14 a.m.)
 
 
 Review request for kde-workspace, KDE Frameworks, Plasma, and Sune Vuorela.
 
 
 Repository: knotifications
 
 
 Description
 ---
 
 This patch merges KNotify daemon into KNotificationManager to have less 
 daemons running and less dbus traffic. The patch is not yet finished (and for 
 now it's full of QDebugs, that will all be removed and FIXMEs to indicate 
 what needs doing), but as the Alpha2 is quite soon, I'd like to start the 
 general review asap so some more changes can be done if needed.
 
 Now it's KNotificationManager that handles the KNotifyPlugin-s and hands them 
 the notification directly. KNotifyConfig was repurposed a bit, now it serves 
 mostly just as the .notifyrc wrapper, all the rest is reused from the 
 KNotification object. There are some changes in the KNotification API - id() 
 and appName() are now exposed to public and slotReceivedId(int) is now also 
 public so that KNotificationManager can directly give it an id. I'd like to 
 rename this and make it a non-slot. It's not the DBus/Galago server ID 
 anymore, that is handled in NotifyByPopup which is responsible for 
 communicating with the galago server (all the methods there were renamed to 
 actually have *galago* in the name so it's clear), therefore the mapping of 
 DBus/Galago Server ids is managed only there as it is actually only needed 
 here. KNotitification::id() is assigned by the KNotificationManager and it's 
 a simple increasing counter.
 
 The UI/Plasmoid changes will come next - basically the plan is to put only 
 the Persistent notifications in the notifications history.
 
 
 Diffs
 -
 
   src/knotifyconfig.h PRE-CREATION 
   src/knotifyconfig.cpp PRE-CREATION 
   src/knotifyplugin.h PRE-CREATION 
   src/knotifyplugin.cpp PRE-CREATION 
   src/notifybypopup.h PRE-CREATION 
   src/notifybypopup.cpp PRE-CREATION 
   src/notifybypopupgrowl.h PRE-CREATION 
   src/notifybypopupgrowl.cpp PRE-CREATION 
   CMakeLists.txt 63ebf71 
   src/CMakeLists.txt a81b913 
   src/knotification.h 00554ba 
   src/knotification.cpp 5d7405b 
   src/knotificationmanager.cpp a4d0dfa 
   src/knotificationmanager_p.h 81d962d 
 
 Diff: https://git.reviewboard.kde.org/r/115695/diff/
 
 
 Testing
 ---
 
 Works perfectly with both plasma notifications and kpassivepopup.
 
 
 Thanks,
 
 Martin Klapetek
 

Re: Review Request 115695: Rework KNotification to work without KNotify daemon

[Martin Klapetek]

 On Feb. 19, 2014, 11:06 a.m., Aleix Pol Gonzalez wrote:
  src/knotificationmanager.cpp, line 66
  https://git.reviewboard.kde.org/r/115695/diff/3/?file=243841#file243841line66
 
  This will be done in the future? Maybe it would be better to commit 
  when there are no regressions?

Yes it will..again, as said in the description - but as the Alpha2 is quite 
soon, I'd like to start the general review asap so some more changes can be 
done if needed.

...so this is more about the general change rather than the final code ;)


 On Feb. 19, 2014, 11:06 a.m., Aleix Pol Gonzalez wrote:
  src/knotificationmanager.cpp, line 180
  https://git.reviewboard.kde.org/r/115695/diff/3/?file=243841#file243841line180
 
  ?

Yet once again the description xD - it's full of ... FIXMEs to indicate what 
needs doing


 On Feb. 19, 2014, 11:06 a.m., Aleix Pol Gonzalez wrote:
  src/notifybypopupgrowl.h, line 37
  https://git.reviewboard.kde.org/r/115695/diff/3/?file=243849#file243849line37
 
  Is growl still the thing for MacOS X?

I'm not sure to be honest...I've heard they reworked it and I've no idea if 
they still support Growl...also Growl used to be on Windows afair, but have no 
idea about it there either...I'd personally be in favor of dropping this as I 
have no way to test


- Martin


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


On Feb. 13, 2014, 11:14 a.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/115695/
 ---
 
 (Updated Feb. 13, 2014, 11:14 a.m.)
 
 
 Review request for kde-workspace, KDE Frameworks, Plasma, and Sune Vuorela.
 
 
 Repository: knotifications
 
 
 Description
 ---
 
 This patch merges KNotify daemon into KNotificationManager to have less 
 daemons running and less dbus traffic. The patch is not yet finished (and for 
 now it's full of QDebugs, that will all be removed and FIXMEs to indicate 
 what needs doing), but as the Alpha2 is quite soon, I'd like to start the 
 general review asap so some more changes can be done if needed.
 
 Now it's KNotificationManager that handles the KNotifyPlugin-s and hands them 
 the notification directly. KNotifyConfig was repurposed a bit, now it serves 
 mostly just as the .notifyrc wrapper, all the rest is reused from the 
 KNotification object. There are some changes in the KNotification API - id() 
 and appName() are now exposed to public and slotReceivedId(int) is now also 
 public so that KNotificationManager can directly give it an id. I'd like to 
 rename this and make it a non-slot. It's not the DBus/Galago server ID 
 anymore, that is handled in NotifyByPopup which is responsible for 
 communicating with the galago server (all the methods there were renamed to 
 actually have *galago* in the name so it's clear), therefore the mapping of 
 DBus/Galago Server ids is managed only there as it is actually only needed 
 here. KNotitification::id() is assigned by the KNotificationManager and it's 
 a simple increasing counter.
 
 The UI/Plasmoid changes will come next - basically the plan is to put only 
 the Persistent notifications in the notifications history.
 
 
 Diffs
 -
 
   src/knotifyconfig.h PRE-CREATION 
   src/knotifyconfig.cpp PRE-CREATION 
   src/knotifyplugin.h PRE-CREATION 
   src/knotifyplugin.cpp PRE-CREATION 
   src/notifybypopup.h PRE-CREATION 
   src/notifybypopup.cpp PRE-CREATION 
   src/notifybypopupgrowl.h PRE-CREATION 
   src/notifybypopupgrowl.cpp PRE-CREATION 
   CMakeLists.txt 63ebf71 
   src/CMakeLists.txt a81b913 
   src/knotification.h 00554ba 
   src/knotification.cpp 5d7405b 
   src/knotificationmanager.cpp a4d0dfa 
   src/knotificationmanager_p.h 81d962d 
 
 Diff: https://git.reviewboard.kde.org/r/115695/diff/
 
 
 Testing
 ---
 
 Works perfectly with both plasma notifications and kpassivepopup.
 
 
 Thanks,
 
 Martin Klapetek
 

Re: Review Request 115695: Rework KNotification to work without KNotify daemon

[Martin Klapetek]

 On Feb. 19, 2014, 11:06 a.m., Aleix Pol Gonzalez wrote:
  src/knotificationmanager.cpp, line 180
  https://git.reviewboard.kde.org/r/115695/diff/3/?file=243841#file243841line180
 
  ?
 
 Martin Klapetek wrote:
 Yet once again the description xD - it's full of ... FIXMEs to indicate 
 what needs doing
 
 Aleix Pol Gonzalez wrote:
 Still you shouldn't ship such comments, so it's probably why nobody 
 checked the ship it thing.

I'm not expecting the ship is as much just yet, but rather comments on how the 
new architecture without knotify looks  works. I put it up early on as Kevin 
wanted to have this in Alpha2, which is in 10 days from now. So I wanted to get 
comments on the general approach asap so I could still manage to handle any 
wanted changes in the arch before Alpha2.


- Martin


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


On Feb. 13, 2014, 11:14 a.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/115695/
 ---
 
 (Updated Feb. 13, 2014, 11:14 a.m.)
 
 
 Review request for kde-workspace, KDE Frameworks, Plasma, and Sune Vuorela.
 
 
 Repository: knotifications
 
 
 Description
 ---
 
 This patch merges KNotify daemon into KNotificationManager to have less 
 daemons running and less dbus traffic. The patch is not yet finished (and for 
 now it's full of QDebugs, that will all be removed and FIXMEs to indicate 
 what needs doing), but as the Alpha2 is quite soon, I'd like to start the 
 general review asap so some more changes can be done if needed.
 
 Now it's KNotificationManager that handles the KNotifyPlugin-s and hands them 
 the notification directly. KNotifyConfig was repurposed a bit, now it serves 
 mostly just as the .notifyrc wrapper, all the rest is reused from the 
 KNotification object. There are some changes in the KNotification API - id() 
 and appName() are now exposed to public and slotReceivedId(int) is now also 
 public so that KNotificationManager can directly give it an id. I'd like to 
 rename this and make it a non-slot. It's not the DBus/Galago server ID 
 anymore, that is handled in NotifyByPopup which is responsible for 
 communicating with the galago server (all the methods there were renamed to 
 actually have *galago* in the name so it's clear), therefore the mapping of 
 DBus/Galago Server ids is managed only there as it is actually only needed 
 here. KNotitification::id() is assigned by the KNotificationManager and it's 
 a simple increasing counter.
 
 The UI/Plasmoid changes will come next - basically the plan is to put only 
 the Persistent notifications in the notifications history.
 
 
 Diffs
 -
 
   src/knotifyconfig.h PRE-CREATION 
   src/knotifyconfig.cpp PRE-CREATION 
   src/knotifyplugin.h PRE-CREATION 
   src/knotifyplugin.cpp PRE-CREATION 
   src/notifybypopup.h PRE-CREATION 
   src/notifybypopup.cpp PRE-CREATION 
   src/notifybypopupgrowl.h PRE-CREATION 
   src/notifybypopupgrowl.cpp PRE-CREATION 
   CMakeLists.txt 63ebf71 
   src/CMakeLists.txt a81b913 
   src/knotification.h 00554ba 
   src/knotification.cpp 5d7405b 
   src/knotificationmanager.cpp a4d0dfa 
   src/knotificationmanager_p.h 81d962d 
 
 Diff: https://git.reviewboard.kde.org/r/115695/diff/
 
 
 Testing
 ---
 
 Works perfectly with both plasma notifications and kpassivepopup.
 
 
 Thanks,
 
 Martin Klapetek