date:20160319

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

(Updated March 16, 2016, 3:56 p.m.)

Status
--

This change has been marked as submitted.

Review request for kde-workspace and Plasma.

Changes
---

Submitted with commit e7f09ba1eb976c4f282145016d34fe87de515a25 by Daniel Faust
to branch master.

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

Jenkins-kde-ci: kdelibs KDE-4.14 stable-qt4 » Linux,gcc - Build # 64 - Unstable!

2016-03-19 Thread no-reply


GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kdelibs%20KDE-4.14%20stable-qt4/PLATFORM=Linux,compiler=gcc/64/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 18 Mar 2016 22:43:22 +
Build duration: 17 min

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 13 test(s), Passed: 150 test(s), Skipped: 0 test(s), 
Total: 163 test(s)Failed: TestSuite.kdecore-kcalendartestFailed: 
TestSuite.kdecore-kmimetypetestFailed: 
TestSuite.kdecore-kstandarddirstestFailed: 
TestSuite.kdeui-kiconloader_unittestFailed: 
TestSuite.kdeui-ktoolbar_unittestFailed: 
TestSuite.kfile-kdiroperatortestFailed: 
TestSuite.kio-clipboardupdatertestFailed: TestSuite.kio-jobremotetestFailed: 
TestSuite.kio-jobtestFailed: TestSuite.kio-kdirlistertestFailed: 
TestSuite.kio-kdirmodeltestFailed: TestSuite.kio-kfilemetainfotestFailed: 
TestSuite.kmimeassociationstest

COBERTURA RESULTS

Cobertura Coverage Report
  

By packages

Re: Open Folder and select file

2016-03-19 Thread Kai Uwe Broulik

Hi,

I've been working on something exactly like this:

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

I want it to support Windows and OS X eventually, too. Haven't found the time 
lately to finish it yet, though. 

Cheers, 
Kai Uwe

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

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

(Updated März 16, 2016, 4:35 nachm.)

Review request for kde-workspace and Plasma.

Changes
---

Use single Date object

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

Repository: plasma-workspace

Description
---

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.

Diffs (updated)
-

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 (updated)

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: [kde-community] Sunsetting of Infrastructure and the Phabricator migration

2016-03-19 Thread Alexander Potashev

Hi Ben,

Please find my questions below.

2016-03-18 9:46 GMT+03:00 Ben Cooksley :
> The XML file upon which numerous utilities (including kdesrc-build)
> depend will continue to be made available. It will instead be
> generated by a Python script periodically, based on the contents of a
> Git repository.

How do we change i18n branches in this XML file after disabling
projects.kde.org?

> I should also note that as a side affect of the Phabricator
> transition, scratch/clone repositories will to a certain extent cease
> to exist - everything will now be a mainline repository. As a

Do I get it right that it will be impossible to create a scratch
repository for a 30-minute task or for a proof-of-concept application
without asking the "majors"?

I think it's totally fine because there are many other Git hostings
where you can do quick-and-dirty development from scratch. And you can
move your repo to git.kde.org as soon as it matures. The main pros of
this approach would be a cleaner quickgit.kde.org page and of course
saving of disk space on servers.

-- 
Alexander Potashev

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


---
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)


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: [kde-community] Sunsetting of Infrastructure and the Phabricator migration

2016-03-19 Thread Jeremy Whiting

Just a note so everyone doesn't need to go google/search this
themselves. To see your scratch repositories look at quickgit.kde.org
and filter by your identity name. To delete old repos, do this:

ssh g...@git.kde.org D unlock scratch//reponame <--
notice no .git on the end, if you put .git it will just say "You are
not authorized"
ssh g...@git.kde.org D rm scratch//reponame

Hope that helps,
Jeremy

On Fri, Mar 18, 2016 at 12:46 AM, Ben Cooksley  wrote:
> == This mail is considered mandatory reading for all KDE Developers.
> Please read this email in whole. ==
>
> Hi all,
>
> As you'll all be aware we are currently in the process of overhauling
> our Git infrastructure, and replacing numerous elements of it.
>
> The first part of this will take place this weekend - with
> projects.kde.org being shutdown. All Git repository browsing from that
> point on should take place through quickgit.kde.org. commits.kde.org
> will also be reconfigured to redirect you exclusively to
> quickgit.kde.org.
>
> As a result the tree structure will only be available from the XML
> file from this point onward. There are no plans to replicate the tree
> structure within Phabricator (although some of the grouping it
> facilitates may be provided through a different mechanism)
>
> The XML file upon which numerous utilities (including kdesrc-build)
> depend will continue to be made available. It will instead be
> generated by a Python script periodically, based on the contents of a
> Git repository.
>
> In terms of Reviewboard, there are no plans to import it's contents
> into Phabricator, as the level of effort required is too high. Once we
> are migrated to Phabricator for reviews, i'm proposing that everyone
> has 4 weeks to finish any final reviews up within Reviewboard before
> it is set to read only by disabling login for everyone. Reviews still
> open at that point would be discarded.
>
> The contents of Kanboard will be migrated into Phabricator, more
> details will come on that over the next few weeks, including details
> of any action people needs to take. As an immediate measure it would
> be appreciated if people could conduct a general cleanup and remove
> tasks and boards they have no intention of using or revisiting in the
> future. Following this migration Kanboard will be shutdown.
>
> In terms of repositories, now would be a good time to look into the
> scratch and clone repositories you have on git.kde.org and perform a
> cleanup of any repositories which are unused, not useful or are
> otherwise no longer needed.
>
> We will be looking into how to import our repositories into
> Phabricator which will include all scratch and clone repositories.
> This means the entire content of these repositories will be indexed,
> and reducing the number of repositories will reduce the amount of
> indexing work which Phabricator needs to complete.
>
> I should also note that as a side affect of the Phabricator
> transition, scratch/clone repositories will to a certain extent cease
> to exist - everything will now be a mainline repository. As a
> consequence force pushes will be disabled for all repositories as part
> of the migration (including scratch repositories). We will be creating
> a mechanism which will allow repositories following certain naming
> conventions to be easily created by developers (although this will
> have to be done through the web interface).
>
> As part of the capabilities of Phabricator, sysadmin will also be
> extending the power to create general purpose mainline repositories
> (and certain other actions within Phabricator) to a number of
> community members. They will be contacted individually over the next
> month or two regarding this.
>
> Comments on the above are welcome (little is in concrete yet), please
> start them in appropriate sub-threads on kde-core-devel (to minimize
> cross-posting, etc).
>
> Thanks,
> Ben Cooksley
> KDE Sysadmin
> ___
> kde-community mailing list
> kde-commun...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community

Re: Review Request 127425: Fix kcoreaddons build with threads


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

(Updated March 19, 2016, 9:12 p.m.)


Status
--

This change has been marked as submitted.


Review request for kdelibs.


Changes
---

Submitted with commit fada5e85585d12efaae2e5bc9f671f8c45462f4a by Allen Winter 
to branch master.


Repository: kcoreaddons


Description
---

CMake 3.0.2 at at least doesn't know what the Threads::Threads library is.


Diffs
-

  src/lib/CMakeLists.txt 44f1516 

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


Testing
---

kcoreaddons build ok now.

was getting the CMake warning:
CMake Warning (dev) at src/lib/CMakeLists.txt:99 (add_library):
  Policy CMP0028 is not set: Double colon in target name means ALIAS or
  IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  Target "KF5CoreAddons" links to target "Threads::Threads" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
  
followed by the linker error:
 /usr/bin/ld: cannot find -lThreads::Threads


Thanks,

Allen Winter

Re: Open Folder and select file

2016-03-19 Thread Emmanuel Pescosta

Hi,

there is a dbus interface (see ShowItems method in [1]) which does exactly
what you want,
at least on platforms with dbus.

But Kai is already working on a nice job API (see [2]) which can do this in
a cross-platform way. :)

Cheers,
Emmanuel

[1] https://www.freedesktop.org/wiki/Specifications/file-manager-interface/
[2] https://git.reviewboard.kde.org/r/127004/

2016-03-19 21:16 GMT+01:00 Dominik Haumann :

> Hi,
>
> in Kate's tab bar I would like to implement a context menu action
> "Open Containing Folder". In KDE, this should open dolphin and
> preselect the specific file. On Windows, it should open the Explorer
> and do the same.
>
> It seems Qt Creator has some code to do exactly this:
> http://stackoverflow.com/questions/3490336
>
> Do we have that already in KDE somewhere?
>
> Please note, I don't want to *open* the file itself, instead, I want
> to open the file browser, and highlight the respective file.
>
> Cheers,
> Dominik
>

Re: Open Folder and select file

2016-03-19 Thread Dominik Haumann

On Sat, Mar 19, 2016 at 9:34 PM, Emmanuel Pescosta
 wrote:
> Hi,
>
> there is a dbus interface (see ShowItems method in [1]) which does exactly
> what you want,
> at least on platforms with dbus.
>
> But Kai is already working on a nice job API (see [2]) which can do this in
> a cross-platform way. :)

Ah, that is cool.

I think I will just say
QDesktopServices::openUrl(doc->url().adjusted(QUrl::RemoveFilename));
then for now.
As soon as Kai's job is ready, I would switch then.

Thanks for the quick reply!

Dominik


> Cheers,
> Emmanuel
>
> [1] https://www.freedesktop.org/wiki/Specifications/file-manager-interface/
> [2] https://git.reviewboard.kde.org/r/127004/
>
> 2016-03-19 21:16 GMT+01:00 Dominik Haumann :
>>
>> Hi,
>>
>> in Kate's tab bar I would like to implement a context menu action
>> "Open Containing Folder". In KDE, this should open dolphin and
>> preselect the specific file. On Windows, it should open the Explorer
>> and do the same.
>>
>> It seems Qt Creator has some code to do exactly this:
>> http://stackoverflow.com/questions/3490336
>>
>> Do we have that already in KDE somewhere?
>>
>> Please note, I don't want to *open* the file itself, instead, I want
>> to open the file browser, and highlight the respective file.
>>
>> Cheers,
>> Dominik
>
>

Open Folder and select file

2016-03-19 Thread Dominik Haumann

Hi,

in Kate's tab bar I would like to implement a context menu action
"Open Containing Folder". In KDE, this should open dolphin and
preselect the specific file. On Windows, it should open the Explorer
and do the same.

It seems Qt Creator has some code to do exactly this:
http://stackoverflow.com/questions/3490336

Do we have that already in KDE somewhere?

Please note, I don't want to *open* the file itself, instead, I want
to open the file browser, and highlight the respective file.

Cheers,
Dominik

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

2016-03-19 Thread Luigi Toscano

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

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

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

Ciao
-- 
Luigi

Re: remove khelpcenter from next Plasma release?

2016-03-19 Thread Luigi Toscano

Luigi Toscano ha scritto:
> Luigi Toscano ha scritto:
>> On Wednesday 09 of March 2016 16:50:39 Sebastian Kügler wrote:
>>> On Wednesday, March 09, 2016 17:30:01 Luigi Toscano wrote:
> Let me cut right to the chase, do you want to maintain it? Does it need
> to
> be in Plasma?

 Yes, I can maintain it. In fact many features come from components I
 already  control.

> You're right that Plasma devs don't seem to want it, I thought my
> initial
> email made that pretty clear. We do think that disconnected systems are
> rather a fringe case, and that our time and effort is better spent on
> other
> things.

 Then the question still holds: with a maintainer, does it have a place in
 Plasma? I'm not talking about an hypothetical time and effort for
 maintaining  this offline use case (which will continue to be 0) but in
 the
 light of the statement above. In other words, if the question mark in the
 subject is real or rhetorical.
 I'm ready for both possible outcomes.
>>>
>>> Ah OK, sorry for misunderstanding it.
>>>
>>> I think there are the following options:
>>>
>>> 1) keeping it in Plasma with maintainer
>>> 2) keeping it outside of Plasma with maintainer
>>> 3) moving it to unmaintained (that's basically killing it)
>>> 4) keeping the status quo (not wanted)
>>>
>>> My personal preference would be an optional component (hence Extragear),
>>> since I think that the vast majority of users has web access, so
>>> khelpcenter isn't necessary and only adds to our maintainance burden
>>> without much gain in those cases.
>>
>> My offer stands and we can rule out 4) and 3).
>> Note that 2) could also mean a move to Applications (from your point of view 
>> it does not matter too much).
>> The case 1) shouldn't add maintenance anyway as the maintainer is identified.
>>
>>>
>>> If we can move from 4) to 1) (so status quo but with maintainer), that would
>>> already be an improvement of course.
>>>
>>> The question mark was honest, we haven't made a decision on it, but
>>> different people do have expressed a preference for not shipping it (as or
>>> by default in Plasma releases). We may have missed important points, and we
>>> don't want to just kick things out unilaterally.
>>
>> I think we can leave some time for other people to comment. The shortest 
>> deadline of all possibilities is the one for moving into Applications, and 
>> there are still 8 days before the dependency freeze and two weeks before the 
>> branch.
> 
> Any other comment from anyone else?
> 

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

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

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

Ciao
-- 
Luigi

Re: remove khelpcenter from next Plasma release?

2016-03-19 Thread Aaron Honeycutt

Kubuntu uses it for our Documentation but our current tools do have a PDF
export option as well as epub so we could use a different tool to read
those files without khelpcenter. I do thank every developer for his/her
work and current work on that package!

On Wed, Mar 16, 2016 at 7:19 PM Luigi Toscano 
wrote:

> Luigi Toscano ha scritto:
> > Luigi Toscano ha scritto:
> >> On Wednesday 09 of March 2016 16:50:39 Sebastian Kügler wrote:
> >>> On Wednesday, March 09, 2016 17:30:01 Luigi Toscano wrote:
> > Let me cut right to the chase, do you want to maintain it? Does it
> need
> > to
> > be in Plasma?
> 
>  Yes, I can maintain it. In fact many features come from components I
>  already  control.
> 
> > You're right that Plasma devs don't seem to want it, I thought my
> > initial
> > email made that pretty clear. We do think that disconnected systems
> are
> > rather a fringe case, and that our time and effort is better spent on
> > other
> > things.
> 
>  Then the question still holds: with a maintainer, does it have a
> place in
>  Plasma? I'm not talking about an hypothetical time and effort for
>  maintaining  this offline use case (which will continue to be 0) but
> in
>  the
>  light of the statement above. In other words, if the question mark in
> the
>  subject is real or rhetorical.
>  I'm ready for both possible outcomes.
> >>>
> >>> Ah OK, sorry for misunderstanding it.
> >>>
> >>> I think there are the following options:
> >>>
> >>> 1) keeping it in Plasma with maintainer
> >>> 2) keeping it outside of Plasma with maintainer
> >>> 3) moving it to unmaintained (that's basically killing it)
> >>> 4) keeping the status quo (not wanted)
> >>>
> >>> My personal preference would be an optional component (hence
> Extragear),
> >>> since I think that the vast majority of users has web access, so
> >>> khelpcenter isn't necessary and only adds to our maintainance burden
> >>> without much gain in those cases.
> >>
> >> My offer stands and we can rule out 4) and 3).
> >> Note that 2) could also mean a move to Applications (from your point of
> view
> >> it does not matter too much).
> >> The case 1) shouldn't add maintenance anyway as the maintainer is
> identified.
> >>
> >>>
> >>> If we can move from 4) to 1) (so status quo but with maintainer), that
> would
> >>> already be an improvement of course.
> >>>
> >>> The question mark was honest, we haven't made a decision on it, but
> >>> different people do have expressed a preference for not shipping it
> (as or
> >>> by default in Plasma releases). We may have missed important points,
> and we
> >>> don't want to just kick things out unilaterally.
> >>
> >> I think we can leave some time for other people to comment. The shortest
> >> deadline of all possibilities is the one for moving into Applications,
> and
> >> there are still 8 days before the dependency freeze and two weeks
> before the
> >> branch.
> >
> > Any other comment from anyone else?
> >
>
> I think I made up my mind. If no one else objects further, I officially ask
> the release team (in CC) if it is possible to accept khelpcenter as part of
> Applications for the upcoming release 16.04, module "applications". No
> dependency changes are planned for the current master branch khelpcenter
> for now.
>
> We will have a bit of overlap for a while (khelpcenter/Plasma5.6 vs
> khelpcenter/Applications16.04), but the version number from Applications is
> higher, so it shouldn't be a problem for packagers (they already handled
> the
> more complicated khelpcenter/kde-runtime vs khelpcenter/Plasma).
>
> If this is accepted, I will manage the various tickets with sysadmins (and
> at
> least move the translations myself).
>
> Ciao
> --
> Luigi
>
> ___
> Plasma-devel mailing list
> plasma-de...@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

Re: remove khelpcenter from next Plasma release?

2016-03-19 Thread Albert Astals Cid

El dijous, 17 de març de 2016, a les 0:18:53 CET, Luigi Toscano va escriure:
> Luigi Toscano ha scritto:
> > Luigi Toscano ha scritto:
> >> On Wednesday 09 of March 2016 16:50:39 Sebastian Kügler wrote:
> >>> On Wednesday, March 09, 2016 17:30:01 Luigi Toscano wrote:
> > Let me cut right to the chase, do you want to maintain it? Does it
> > need
> > to
> > be in Plasma?
>  
>  Yes, I can maintain it. In fact many features come from components I
>  already  control.
>  
> > You're right that Plasma devs don't seem to want it, I thought my
> > initial
> > email made that pretty clear. We do think that disconnected systems
> > are
> > rather a fringe case, and that our time and effort is better spent on
> > other
> > things.
>  
>  Then the question still holds: with a maintainer, does it have a place
>  in
>  Plasma? I'm not talking about an hypothetical time and effort for
>  maintaining  this offline use case (which will continue to be 0) but in
>  the
>  light of the statement above. In other words, if the question mark in
>  the
>  subject is real or rhetorical.
>  I'm ready for both possible outcomes.
> >>> 
> >>> Ah OK, sorry for misunderstanding it.
> >>> 
> >>> I think there are the following options:
> >>> 
> >>> 1) keeping it in Plasma with maintainer
> >>> 2) keeping it outside of Plasma with maintainer
> >>> 3) moving it to unmaintained (that's basically killing it)
> >>> 4) keeping the status quo (not wanted)
> >>> 
> >>> My personal preference would be an optional component (hence Extragear),
> >>> since I think that the vast majority of users has web access, so
> >>> khelpcenter isn't necessary and only adds to our maintainance burden
> >>> without much gain in those cases.
> >> 
> >> My offer stands and we can rule out 4) and 3).
> >> Note that 2) could also mean a move to Applications (from your point of
> >> view it does not matter too much).
> >> The case 1) shouldn't add maintenance anyway as the maintainer is
> >> identified.>> 
> >>> If we can move from 4) to 1) (so status quo but with maintainer), that
> >>> would already be an improvement of course.
> >>> 
> >>> The question mark was honest, we haven't made a decision on it, but
> >>> different people do have expressed a preference for not shipping it (as
> >>> or
> >>> by default in Plasma releases). We may have missed important points, and
> >>> we
> >>> don't want to just kick things out unilaterally.
> >> 
> >> I think we can leave some time for other people to comment. The shortest
> >> deadline of all possibilities is the one for moving into Applications,
> >> and
> >> there are still 8 days before the dependency freeze and two weeks before
> >> the branch.
> > 
> > Any other comment from anyone else?
> 
> I think I made up my mind. If no one else objects further, I officially ask
> the release team (in CC) if it is possible to accept khelpcenter as part of
> Applications for the upcoming release 16.04, module "applications". No
> dependency changes are planned for the current master branch khelpcenter for
> now.
> 
> We will have a bit of overlap for a while (khelpcenter/Plasma5.6 vs
> khelpcenter/Applications16.04), but the version number from Applications is
> higher, so it shouldn't be a problem for packagers (they already handled the
> more complicated khelpcenter/kde-runtime vs khelpcenter/Plasma).
> 
> If this is accepted, I will manage the various tickets with sysadmins (and
> at least move the translations myself).

No objections from my side, please get a decision+moved tuesday the latest.

Cheers,
  Albert

> 
> Ciao

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



> On März 15, 2016, 5:48 nachm., Martin Klapetek wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, lines 565-568
> > 
> >
> > 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.

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
```


- Daniel


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


On März 16, 2016, 4:35 nachm., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127102/
> ---
> 
> (Updated März 16, 2016, 4:35 nachm.)
> 
> 
> 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



> On March 16, 2016, 6:19 p.m., Martin Klapetek wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, line 400
> > 
> >
> > 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: Reviewboard timing (was Re: Sunsetting of Infrastructure and the Phabricator migration)

2016-03-19 Thread Albert Astals Cid

El divendres, 18 de març de 2016, a les 12:12:45 CET, Luigi Toscano va 
escriure:
> On Friday 18 of March 2016 19:46:03 Ben Cooksley wrote:
> > In terms of Reviewboard, there are no plans to import it's contents
> > into Phabricator, as the level of effort required is too high. Once we
> > are migrated to Phabricator for reviews, i'm proposing that everyone
> > has 4 weeks to finish any final reviews up within Reviewboard before
> > it is set to read only by disabling login for everyone. Reviews still
> > open at that point would be discarded.
> 
> (starting a subthread on kde-core-devel as advised)
> 
> I think this timing is too short. I agree with closing down Reviewboard, of
> course, but I would propose something a bit more complicated (it seems that
> reviewboard permissions does not allow to easily set it):
> - close down new submissions (physically remove the pages? Comment out the
> code in reviewboard)
> - leave open the existing reviews for 6 months and add periodic reminders to
> them.

Given the awful speed i have having a look at reviewboard i would also 
appreciate if we had a somehow longer close period for existing reviews.

Cheers,
  Albert

> 
> Ciao

Re: Review Request 127425: Fix kcoreaddons build with threads


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

(Updated March 19, 2016, 2:22 p.m.)


Review request for kdelibs.


Changes
---

removed an extra blank line


Repository: kcoreaddons


Description
---

CMake 3.0.2 at at least doesn't know what the Threads::Threads library is.


Diffs (updated)
-

  src/lib/CMakeLists.txt 44f1516 

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


Testing
---

kcoreaddons build ok now.

was getting the CMake warning:
CMake Warning (dev) at src/lib/CMakeLists.txt:99 (add_library):
  Policy CMP0028 is not set: Double colon in target name means ALIAS or
  IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  Target "KF5CoreAddons" links to target "Threads::Threads" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
  
followed by the linker error:
 /usr/bin/ld: cannot find -lThreads::Threads


Thanks,

Allen Winter

Re: Error buildin KDE

See the fix at https://git.reviewboard.kde.org/r/127425/

On Saturday, March 19, 2016 09:57:53 AM Allen Winter wrote:
> Same here.
> The relevant problem is shown in the cmake.log:
> 
> CMake Warning (dev) at src/lib/CMakeLists.txt:99 (add_library):
>   Policy CMP0028 is not set: Double colon in target name means ALIAS or
>   IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
>   Use the cmake_policy command to set the policy and suppress this warning.
> 
>   Target "KF5CoreAddons" links to target "Threads::Threads" but the target
>   was not found.  Perhaps a find_package() call is missing for an IMPORTED
>   target, or an ALIAS target is missing?
> 
> 
> 
> On Friday, March 18, 2016 10:47:14 PM rafranco.2...@yahoo.it wrote:
> > Hi guys, I' m new to this mailing list and to the KDE community.
> > I' m a newby in KDE development but I have a not so bad knowledge of Linux.
> > I don't know if this is the right place to post these kind of requests and 
> > if it is not the case I'd ask you to point me where can I post it.
> > I was trying to build kde following instructions at
> > 
> > https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source#Run_kdesrc-build
> > 
> > I executed exactly all steps reported there and installed all required 
> > packages from official distro repository except for cmake 2.8.12 that I 
> > found at
> > 
> > https://kojipkgs.fedoraproject.org/packages/cmake/2.8.12/3.fc21/x86_64/cmake-2.8.12-3.fc21.x86_64.rpm
> > 
> > and installed with yum localinstall. My host is a CentOS 7 x64 VMware 
> > virtual machine.
> > 
> > First few modules are built correctly without any problem using 
> > kdesrc-build but build process stops on kcoreaddons with the following 
> > error:
> > 
> > 
> > Building CXX object 
> > src/lib/CMakeFiles/KF5CoreAddons.dir/KF5CoreAddons_automoc.cpp.o
> > Linking CXX shared library libKF5CoreAddons.so
> > /usr/bin/ld: cannot find -lThreads::Threads
> > collect2: error: ld returned 1 exit status
> > gmake[2]: *** [src/lib/libKF5CoreAddons.so.5.21.0] Errore 1
> > gmake[1]: *** [src/lib/CMakeFiles/KF5CoreAddons.dir/all] Errore 2
> > gmake: *** [all] Errore 2
> > 
> > 
> > while the following is the cmake log I find
> > 
> > 
> > # kdesrc-build running: 'cmake' 
> > '/home/lfranco/devel/kde/src/frameworks/kcoreaddons' 
> > '-DCMAKE_BUILD_TYPE:STRING=debug' '-DKDE4_BUILD_TESTS=true' 
> > '-DBUILD_TESTING=TRUE' '-DCMAKE_BUILD_TYPE:STRING=debug' 
> > '-DCMAKE_CXX_FLAGS:STRING=-std=c++11 -pipe -DQT_STRICT_ITERATORS 
> > -DQURL_NO_CAST_FROM_STRING -DQT_NO_HTTP -DQT_NO_FTP -Wformat 
> > -Werror=format-security -Werror=return-type -Wno-variadic-macros 
> > -Wlogical-op -Wmissing-include-dirs ' 
> > '-DCMAKE_INSTALL_PREFIX=/home/lfranco/devel/kde/usr'
> > # from directory: /home/lfranco/devel/kde/build/frameworks/kcoreaddons
> > -- The C compiler identification is GNU 4.8.5
> > -- The CXX compiler identification is GNU 4.8.5
> > -- Check for working C compiler: /usr/bin/cc
> > -- Check for working C compiler: /usr/bin/cc -- works
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- Check for working CXX compiler: /usr/bin/c++
> > -- Check for working CXX compiler: /usr/bin/c++ -- works
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > 
>

Review Request 127425: Fix kcoreaddons build with threads


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

Review request for kdelibs.


Repository: kcoreaddons


Description
---

CMake 3.0.2 at at least doesn't know what the Threads::Threads library is.


Diffs
-

  src/lib/CMakeLists.txt 44f1516 

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


Testing
---

kcoreaddons build ok now.

was getting the CMake warning:
CMake Warning (dev) at src/lib/CMakeLists.txt:99 (add_library):
  Policy CMP0028 is not set: Double colon in target name means ALIAS or
  IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  Target "KF5CoreAddons" links to target "Threads::Threads" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
  
followed by the linker error:
 /usr/bin/ld: cannot find -lThreads::Threads


Thanks,

Allen Winter

Re: Error buildin KDE

Same here.
The relevant problem is shown in the cmake.log:

CMake Warning (dev) at src/lib/CMakeLists.txt:99 (add_library):
  Policy CMP0028 is not set: Double colon in target name means ALIAS or
  IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  Target "KF5CoreAddons" links to target "Threads::Threads" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?



On Friday, March 18, 2016 10:47:14 PM rafranco.2...@yahoo.it wrote:
> Hi guys, I' m new to this mailing list and to the KDE community.
> I' m a newby in KDE development but I have a not so bad knowledge of Linux.
> I don't know if this is the right place to post these kind of requests and if 
> it is not the case I'd ask you to point me where can I post it.
> I was trying to build kde following instructions at
> 
> https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source#Run_kdesrc-build
> 
> I executed exactly all steps reported there and installed all required 
> packages from official distro repository except for cmake 2.8.12 that I found 
> at
> 
> https://kojipkgs.fedoraproject.org/packages/cmake/2.8.12/3.fc21/x86_64/cmake-2.8.12-3.fc21.x86_64.rpm
> 
> and installed with yum localinstall. My host is a CentOS 7 x64 VMware virtual 
> machine.
> 
> First few modules are built correctly without any problem using kdesrc-build 
> but build process stops on kcoreaddons with the following error:
> 
> 
> Building CXX object 
> src/lib/CMakeFiles/KF5CoreAddons.dir/KF5CoreAddons_automoc.cpp.o
> Linking CXX shared library libKF5CoreAddons.so
> /usr/bin/ld: cannot find -lThreads::Threads
> collect2: error: ld returned 1 exit status
> gmake[2]: *** [src/lib/libKF5CoreAddons.so.5.21.0] Errore 1
> gmake[1]: *** [src/lib/CMakeFiles/KF5CoreAddons.dir/all] Errore 2
> gmake: *** [all] Errore 2
> 
> 
> while the following is the cmake log I find
> 
> 
> # kdesrc-build running: 'cmake' 
> '/home/lfranco/devel/kde/src/frameworks/kcoreaddons' 
> '-DCMAKE_BUILD_TYPE:STRING=debug' '-DKDE4_BUILD_TESTS=true' 
> '-DBUILD_TESTING=TRUE' '-DCMAKE_BUILD_TYPE:STRING=debug' 
> '-DCMAKE_CXX_FLAGS:STRING=-std=c++11 -pipe -DQT_STRICT_ITERATORS 
> -DQURL_NO_CAST_FROM_STRING -DQT_NO_HTTP -DQT_NO_FTP -Wformat 
> -Werror=format-security -Werror=return-type -Wno-variadic-macros -Wlogical-op 
> -Wmissing-include-dirs ' '-DCMAKE_INSTALL_PREFIX=/home/lfranco/devel/kde/usr'
> # from directory: /home/lfranco/devel/kde/build/frameworks/kcoreaddons
> -- The C compiler identification is GNU 4.8.5
> -- The CXX compiler identification is GNU 4.8.5
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
>

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


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

(Updated März 19, 2016, 2:16 nachm.)


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 (updated)
-

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



> On März 16, 2016, 9:31 nachm., Martin Klapetek wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, lines 382-383
> > 
> >
> > 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?
> 
> Martin Klapetek wrote:
> 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.

Yeah, you're right.


- Daniel


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


On März 19, 2016, 2:16 nachm., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127393/
> ---
> 
> (Updated März 19, 2016, 2:16 nachm.)
> 
> 
> 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 119890: [Ark] Implement "Add to archive" option when dragging and dropping onto an archive file in dolphin

2016-03-19 Thread Elvis Angelaccio


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



The author seems gone and the patch was lost (due to the ReviewBoard upgrade?).
If there are no objections in the next few days, I will get the sysadmins to 
discard this review (it will happen anyway after the migration to phabricator).

- Elvis Angelaccio


On Aug. 21, 2014, 9:11 p.m., Arjun AK wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119890/
> ---
> 
> (Updated Aug. 21, 2014, 9:11 p.m.)
> 
> 
> Review request for KDE Base Apps and KDE Utils.
> 
> 
> Bugs: 338414
> http://bugs.kde.org/show_bug.cgi?id=338414
> 
> 
> Repository: ark
> 
> 
> Description
> ---
> 
> This patch implements the "Add to archive" option, which is shown when a user 
> drags and drops files onto an existing archive. 
> 
> 
> See also:
> https://git.reviewboard.kde.org/r/119892
> https://bugs.kde.org/show_bug.cgi?id=338414
> 
> 
> Diffs
> -
> 
>   app/CMakeLists.txt f1ef01b 
>   app/addToArchiveDndPlugin.h PRE-CREATION 
>   app/addToArchiveDndPlugin.cpp PRE-CREATION 
>   app/ark_dndaddtoarchive.desktop.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119890/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Arjun AK
> 
>

Re: Product versions on bugs.kde.org

2016-03-19 Thread David Faure

On Wednesday 16 March 2016 21:40:22 Vishesh Handa wrote:
> On Sun, Mar 13, 2016 at 7:57 PM, David Faure  wrote:
> > On Saturday 12 March 2016 20:38:43 Vishesh Handa wrote:
> >>
> >> And from my point of view the user doesn't care if Baloo is part of
> >> something called "Frameworks". There is a bug, they want to report it.
> >> It's just added noise.
> >
> > Typically, users report bugs in the app where they see them, and then
> > the maintainer of the app reassigns to the "guilty" underlying framework.
> >
> > E.g. end users don't report kio bugs, they report dolphin bugs, which then
> > get reassigned to frameworks-kio.
> >
> > So I think frameworks-baloo makes sense (and is consistent). The "users"
> > of the framework are application developers, who know how to find it in 
> > bugzilla.
> 
> Except that Baloo isn't just a library. It provides a daemon, and a
> CLI search interface. I also know a few people running Baloo on
> servers.
> 
> This whole "frameworks-baloo" vs "baloo" seems more pedantic than
> anything else. Specially considering the amount of overhead this is
> actively causing. I just have a crash report from 2 hours ago filed to
> Baloo (not Baloo-frameworks). Bug reports against previous versions of
> Baloo won't automatically go to this new "baloo-frameworks". And I
> have over 130+ new bug emails, which aren't relevant.
> 
> I'm all for consistency, but not when it has a real cost.

I'm stepping out of this discussion, do whatever you want :-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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



> On March 15, 2016, 5:48 p.m., Martin Klapetek wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, lines 565-568
> > 
> >
> > 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: remove khelpcenter from next Plasma release?

2016-03-19 Thread Sebastian Kügler

On Tuesday, March 15, 2016 05:52:55 PM Jeremy Whiting wrote:
> As an application developer I agree it makes sense to have khelpcenter
> released with KDE Applications. I also agree with Albert's point that
> having online documentation isn't the best since it could be newer
> than what's actually running. People using LTS distributions or
> "stable" variants of less often released distributions will have very
> old (to those of us that run from git) versions of stuff. Having
> online documentation for plasma 5.7 to look at while you're running
> plasma 4 would just confuse.

This can be solved, of course, by having versioned documentation online and 
point to that.

> Also, thanks Luigi for stepping up to maintain it.

+1
-- 
sebas

http://www.kde.org | http://vizZzion.org

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



> On März 16, 2016, 6:19 nachm., Martin Klapetek wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, line 400
> > 
> >
> > 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.

This is the result: http://paste.opensuse.org/view/raw/0b724b7b


- Daniel


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


On März 16, 2016, 4:53 nachm., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127393/
> ---
> 
> (Updated März 16, 2016, 4:53 nachm.)
> 
> 
> 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