Re: Review Request 118584: Formats KCM: Use QLocale::name() instead of bcp47Name() when writing to the configuration file

[Luca Beltrame]

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

(Updated June 6, 2014, 6:45 a.m.)


Review request for Plasma, John Layt and Sebastian Kügler.


Changes
---

Fixed description.


Repository: plasma-desktop


Description (updated)
---

Currently the Formats KCM writes its configuration file using the selected 
locale's bcp47Name(). This, at least on my distro, breaks locale loading as 
locales are in the form "foo_FOO" (e.g., "it_IT" for my own locale) and instead 
the Formats KCM exports LANG as "foo" (e.g. "it").

This causes a bunch of runtime warnings and locales don't get actually loaded. 
This patch's approach is naive and likely needs more pairs of eyes on it, as I 
can't test with other distros.

Also we might need "UTF-8" suffix for distros that use UTF-8 locales: or so I 
think, but I'm not knowledgeable enough to tell if this is needed or not.


Diffs
-

  kcms/formats/kcmformats.cpp 4169244 

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


Testing
---

Compiled, ran the Formats KCM, selected my country, inspected the generated 
files.


Thanks,

Luca Beltrame

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 118584: Formats KCM: Use QLocale::name() instead of bcp47Name() when writing to the configuration file

[Luca Beltrame]

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

Review request for Plasma, John Layt and Sebastian Kügler.


Repository: plasma-desktop


Description
---

Currently the Formats KCM writes its configuration file using the selected 
locale's bcp47Name(). This, at least on my distro, breaks locale loading as 
locales are in the form "foo_FOO" (e.g., "it_IT" for my own locale) and instead 
the Formats KCM exports LANG as "foo" (e.g. "it").

This causes a bunch of runtime warnings and locales don't get actually loaded. 
This patch's approach is naive and likely needs more pairs of eyes on it, as I 
can't test with distros.

Also we might need "UTF-8" suffix for distros that use UTF-8 locales: or so I 
think, but I'm not knowledgeable enough to tell if this is needed or not.


Diffs
-

  kcms/formats/kcmformats.cpp 4169244 

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


Testing
---

Compiled, ran the Formats KCM, selected my country, inspected the generated 
files.


Thanks,

Luca Beltrame

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 118583: Fix Comic Strip Installation

[David Narváez]

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

Review request for Plasma.


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


Repository: kdeplasma-addons


Description
---

Use the plasmapkg option to install instead of the one to upgrade. What branch 
should this change go to?


Diffs
-

  applets/comic/comic.knsrc e7a78b9 

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


Testing
---

Repeated the steps in bug 325028


Thanks,

David Narváez

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118574: Adjust componentchooser for renamed KWin binary

[Martin Gräßlin]

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

Ship it!


Ship It!

- Martin Gräßlin


On June 5, 2014, 9:17 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118574/
> ---
> 
> (Updated June 5, 2014, 9:17 p.m.)
> 
> 
> Review request for Plasma and Martin Gräßlin.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> complementary to r118266 & r118482
> 
> 
> Diffs
> -
> 
>   ConfigureChecks.cmake f0a23bf 
>   config-workspace.h.cmake 66c1d63 
>   kcms/componentchooser/componentchooserwm.cpp 22dfa31 
> 
> Diff: https://git.reviewboard.kde.org/r/118574/diff/
> 
> 
> Testing
> ---
> 
> builds, reseting to default one writes in kwin_x11 in ksmserverrc, upon 
> restarting kwin_x11 is invoked.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118548: Port libtaskmanager away from QDesktopWidget

[Martin Gräßlin]

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


> It fudges window geometry by removing 5 pixels from each side of the rect 
> with a note about window decoration overscan. This is likely ancient code, is 
> it still relevant today to do this?

Most likely yes, IIRC this is for handling shadows. Shadows at the border bleed 
into the next screen.

- Martin Gräßlin


On June 5, 2014, 7:12 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118548/
> ---
> 
> (Updated June 5, 2014, 7:12 p.m.)
> 
> 
> Review request for Plasma, Martin Gräßlin, Eike Hein, and Luca Beltrame.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> plasmoid.screen doesn't map to QDesktopWidget indexes anymore, therefore we 
> need to port it.
> 
> This patch uses the screen geometry to figure out what's the screen and then 
> passes around the screen rect so that we can filter out the screens that 
> aren't inside if the user asks for it.
> 
> 
> Diffs
> -
> 
>   libtaskmanager/taskmanager.cpp 27eeed7 
>   libtaskmanager/taskmanager.h e6ca735 
>   libtaskmanager/task.h 13a5a9c 
>   libtaskmanager/task.cpp 50ea1a6 
>   libtaskmanager/launcheritem.cpp 649caca 
>   libtaskmanager/groupmanager.h aa71bac 
>   libtaskmanager/groupmanager.cpp 83b39ef 
> 
> Diff: https://git.reviewboard.kde.org/r/118548/diff/
> 
> 
> Testing
> ---
> 
> I have played with it and seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118573: Some tweaks in the logout screen

[Martin Gräßlin]

> On June 6, 2014, 12:23 a.m., Aleix Pol Gonzalez wrote:
> > ksmserver/shutdowndlg.cpp, line 85
> > 
> >
> > I'm unsure what's the issue here.

this might break the logout effect


- Martin


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


On June 5, 2014, 9:02 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118573/
> ---
> 
> (Updated June 5, 2014, 9:02 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This does two things:
> * some tweaks in the logout theme, partly inverts theme colors and makes the 
> logout/shutdown toolbuttons a group of 3 always visible exclusive-toggle 
> buttons
> * add the flag bypasswindowmanagerhint to the main logout window: seems the 
> only way here to obtain the proper size and position
> 
> (old screenshot to give the idea: 
> http://wstaw.org/m/2014/06/05/plasma-desktopGg1731.png labels are actually of 
> the proper color now)
> 
> 
> Diffs
> -
> 
>   ksmserver/shutdowndlg.cpp 68efcf6 
>   lookandfeel/contents/components/BreezeBlock.qml 4093f5f 
>   lookandfeel/contents/components/LogoutScreen.qml 1f7825d 
> 
> Diff: https://git.reviewboard.kde.org/r/118573/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Plasma 5 Beta 2 tars

[Martin Gräßlin]

On Thursday 05 June 2014 20:19:55 šumski wrote:
> On Thursday 05 of June 2014 16:47:59 Jonathan Riddell wrote:
> > Tars are up for Plasma 5 Beta 2, please try them out and let me know
> > of problems.  I'd especially like to know if translations successfully
> > install as I noticed some not doing so last time.
> 
> Plasma-workspace doesn't build. It is adjusted for new Solid API, which is
> not in KF5 4.100.0. (error: 'const class Solid::Battery' has no member
> named 'isPresent')

can we revert that change in plasma-workspace for the release? I would not 
want to go back further as plasma-workspace also has quite some changes which 
would be good to be tested. E.g. the new lockscreen UI.

> I imagine similar issues with todays changes in kdeclarative and plasma-
> framework. Maybe it would be best to tag from yesterday evening?

no that should be fine. We had only changes in kdeclarative and plasma-
framework and they should not have propagated further down.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 118581: Consider Super_L and Super_R as modifiers

[Sebastian Kügler]

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

Review request for KDE Frameworks, Plasma and Vishesh Handa.


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


Repository: kxmlgui


Description
---

Consider Super_L and Super_R as modifiers

Without this patch, I can't use the meta key to assign shortcuts, as
Super_L and Super_R are not considered as modifiers, so when I press
meta (Super_L on my system), the shortcut is immediately accepted,
before I get the chance to press another key.

This patch requires the fix in
https://bugreports.qt-project.org/browse/QTBUG-38428
to be applied. With both patches, KKeySequenceWidget works for me.

BUG:335316


Diffs
-

  src/kkeysequencewidget.cpp b6fcd207a1d18466f4a747e1a0b4b58107c82871 

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


Testing
---

Tried to assign meta + something in global shortcuts KCM, fails without patch 
(see screenshot in the linked bugreport), works correctly with patch.


Thanks,

Sebastian Kügler

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118573: Some tweaks in the logout screen

[Aleix Pol Gonzalez]

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



ksmserver/shutdowndlg.cpp


I'm unsure what's the issue here.



lookandfeel/contents/components/LogoutScreen.qml


I suggest to create a BreezeLabel component in the components folder and 
use it. There are other labels that will have to be changed.

Same thing with Heading.



lookandfeel/contents/components/LogoutScreen.qml


This has to be changed as well in the LockScreen.

This button row should be probably its own component as well, but I can do 
that tomorrow.


- Aleix Pol Gonzalez


On June 5, 2014, 7:02 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118573/
> ---
> 
> (Updated June 5, 2014, 7:02 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This does two things:
> * some tweaks in the logout theme, partly inverts theme colors and makes the 
> logout/shutdown toolbuttons a group of 3 always visible exclusive-toggle 
> buttons
> * add the flag bypasswindowmanagerhint to the main logout window: seems the 
> only way here to obtain the proper size and position
> 
> (old screenshot to give the idea: 
> http://wstaw.org/m/2014/06/05/plasma-desktopGg1731.png labels are actually of 
> the proper color now)
> 
> 
> Diffs
> -
> 
>   ksmserver/shutdowndlg.cpp 68efcf6 
>   lookandfeel/contents/components/BreezeBlock.qml 4093f5f 
>   lookandfeel/contents/components/LogoutScreen.qml 1f7825d 
> 
> Diff: https://git.reviewboard.kde.org/r/118573/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Icons status

[Ivan Čukić]

> Oxygen, that as fallback is the most complete.
> Both themes would be installed, and oxygen would still be the fallback when
> an icon is not found for the time being

+1 for the oxygen + toolbars breeze

Cheerio,
Ivan


KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/ 
gpg key id: 850B6F76, keyserver.pgp.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Icons status

[Marco Martin]

On Thursday 05 June 2014, Andrew Lake wrote:
> On Thu, Jun 5, 2014 at 12:22 PM, Marco Martin wrote:
> > Hi all,
> > Just relying a message from Uri,
> > toolbars and folders are almost complete, but all devices and mimetypes
> > are still missing, so a little opinion poll is needed.
> > 
> > I think that they should be shipped anyways, but default yes/no ?
> > 
> > Cheers,
> > Marco Martin
> 
> I thought the plan was to use Flattr (or Oxygen?) icons as a base and
> replace with the new icons as we go. That way we'd have something that
> functionally relatively complete, even if they change over time as the new
> icons are completed. I may be entirely mistaken about that though (which
> isn't the most unusual thing in the world).

Oxygen, that as fallback is the most complete.
Both themes would be installed, and oxygen would still be the fallback when an 
icon is not found for the time being

> 
> Anyway to your question, I think we should ship them. If the situation is
> like what I describe above (a version of which I'm using using on my
> current install) then count my vote for defaulting to it. If the situation
> is otherwise then I'm ambivalent.

I would be for setting the default as well, I just want to weigh opinions here 
tough


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Icons status

[Andrew Lake]

On Thu, Jun 5, 2014 at 12:22 PM, Marco Martin wrote:

> Hi all,
> Just relying a message from Uri,
> toolbars and folders are almost complete, but all devices and mimetypes are
> still missing, so a little opinion poll is needed.
>
> I think that they should be shipped anyways, but default yes/no ?
>
> Cheers,
> Marco Martin
>
>
I thought the plan was to use Flattr (or Oxygen?) icons as a base and
replace with the new icons as we go. That way we'd have something that
functionally relatively complete, even if they change over time as the new
icons are completed. I may be entirely mistaken about that though (which
isn't the most unusual thing in the world).

Anyway to your question, I think we should ship them. If the situation is
like what I describe above (a version of which I'm using using on my
current install) then count my vote for defaulting to it. If the situation
is otherwise then I'm ambivalent.

Andrew
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Icons status

[Marco Martin]

Hi all,
Just relying a message from Uri,
toolbars and folders are almost complete, but all devices and mimetypes are 
still missing, so a little opinion poll is needed.

I think that they should be shipped anyways, but default yes/no ?

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 118574: Adjust componentchooser for renamed KWin binary

[Hrvoje Senjan]

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

Review request for Plasma and Martin Gräßlin.


Repository: plasma-desktop


Description
---

complementary to r118266 & r118482


Diffs
-

  ConfigureChecks.cmake f0a23bf 
  config-workspace.h.cmake 66c1d63 
  kcms/componentchooser/componentchooserwm.cpp 22dfa31 

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


Testing
---

builds, reseting to default one writes in kwin_x11 in ksmserverrc, upon 
restarting kwin_x11 is invoked.


Thanks,

Hrvoje Senjan

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Visual design for logout/login/lockscreen

[Marco Martin]

On Thursday 05 June 2014, David Edmundson wrote:
> > 
> > mutually exclusive buttons on one side looks maybe a bit "heavier" but
> > perhaps seems a bit more intuitive.
> 
> That works for me.
> I'll update login next week.

I did a review request
https://git.reviewboard.kde.org/r/118573/

so it can rest a while there a day still ;)

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 118573: Some tweaks in the logout screen

[Marco Martin]

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

Review request for Plasma.


Repository: plasma-workspace


Description
---

This does two things:
* some tweaks in the logout theme, partly inverts theme colors and makes the 
logout/shutdown toolbuttons a group of 3 always visible exclusive-toggle buttons
* add the flag bypasswindowmanagerhint to the main logout window: seems the 
only way here to obtain the proper size and position

(old screenshot to give the idea: 
http://wstaw.org/m/2014/06/05/plasma-desktopGg1731.png labels are actually of 
the proper color now)


Diffs
-

  ksmserver/shutdowndlg.cpp 68efcf6 
  lookandfeel/contents/components/BreezeBlock.qml 4093f5f 
  lookandfeel/contents/components/LogoutScreen.qml 1f7825d 

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


Testing
---


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Visual design for logout/login/lockscreen

[Andrew Lake]

On Thu, Jun 5, 2014 at 10:30 AM, Marco Martin wrote:

> * don't bother wit the background, I think on top of the fullscreen
> blur/darken effect is fine (in this case even better than a background that
> covers everything)
>

Yes, I agree, that was the intention in the proposed visual design (and
intention I poorly communicated, sorry).

Andrew
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Visual design for logout/login/lockscreen

[Marco Martin]

On Thursday 05 June 2014, David Edmundson wrote:
> > * I think is just fine using the default theme and swapping textcolors
> > and backgroundcolors for the rectangles: to me it looks way better if
> > even if is dark, the two buttons still look light/default
> 
> Toolbuttons were the big problem with just hardcoding colours for text
> and background
> 
>  - if the icon is black you can't see it on the background
>  - if the icon is also hardcoded to white, you can't see it when you
> do the mouseover
> 
>  - if you avoid using a toolbutton and load them as images hardcoded
> to white, you have no indication that it's a button, and it's bad to
> have some buttons behaving differently

Another idea, is to use the standard dialog background/shadow, but disable 
left and right borders and maximize horizontally.

and make it a a design pattern for things around like lockscreen prompt, 
alt+tab

just an idea, to explore probably in future releases ;)

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Visual design for logout/login/lockscreen

[David Edmundson]

On Thu, Jun 5, 2014 at 8:13 PM, Marco Martin  wrote:
> On Thursday 05 June 2014, David Edmundson wrote:
>> > * I think is just fine using the default theme and swapping textcolors
>> > and backgroundcolors for the rectangles: to me it looks way better if
>> > even if is dark, the two buttons still look light/default
>>
>> Toolbuttons were the big problem with just hardcoding colours for text
>> and background
>>
>>  - if the icon is black you can't see it on the background
>>  - if the icon is also hardcoded to white, you can't see it when you
>> do the mouseover
>>
>>  - if you avoid using a toolbutton and load them as images hardcoded
>> to white, you have no indication that it's a button, and it's bad to
>> have some buttons behaving differently
>
> I tried making them explicitly visible, don't seem that bad
> http://wstaw.org/m/2014/06/05/plasma-desktopGg1731.png
> (only the test app, so no blur)
>
> mutually exclusive buttons on one side looks maybe a bit "heavier" but perhaps
> seems a bit more intuitive.
>

That works for me.
I'll update login next week.

David
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Visual design for logout/login/lockscreen

[Marco Martin]

On Thursday 05 June 2014, Marco Martin wrote:

> 
> I tried it, I think it's fine, I have just few observations/suggestions:
> * seems that sometimes the window (main qml view) is not correctly resized.
> Oddly tough the test program always resizes/places the window correctly

the resize issue seems to be fixed with (Martin will kill me for it)
setFlags(Qt::BypassWindowManagerHint); on the main window




-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5 Beta 2 tars

[šumski]

On Thursday 05 of June 2014 16:47:59 Jonathan Riddell wrote:
> Tars are up for Plasma 5 Beta 2, please try them out and let me know
> of problems.  I'd especially like to know if translations successfully
> install as I noticed some not doing so last time.
Plasma-workspace doesn't build. It is adjusted for new Solid API, which is not 
in KF5 4.100.0. (error: 'const class Solid::Battery' has no member named 
'isPresent')
I imagine similar issues with todays changes in kdeclarative and plasma-
framework. Maybe it would be best to tag from yesterday evening?


Cheers,
Hrvoje
> Appearing here soon
>  http://download.kde.org/unstable/plasma/4.97.0/src/
> 
> Temporarily here in the mean time
>  http://starsky.19inch.net/~jr/tmp/plasma-4.97.0/
> 
> md5sums
>  http://starsky.19inch.net/~jr/tmp/plasma-4.97.0/4.97.0-release-data
> 
> I've renamed baloo and milou to have -kf5 in the tar name as you may
> well want the kdelibs4 versions around.  Also kfilemetadata as
> kfilemetadata5.
> 
> Jonathan
> ___
> Kde-packager mailing list
> kde-packa...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-packager


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118548: Port libtaskmanager away from QDesktopWidget

[Luca Beltrame]

In data giovedì 05 giugno 2014 00:35:56, Aleix Pol Gonzalez ha scritto:

> This patch uses the screen geometry to figure out what's the screen and then
> passes around the screen rect so that we can filter out the screens that

I have tested it and unfortunately it doesn't really work: now tasks are shown 
always on all screens, regardless of the configuration ("Only show tasks in 
current screen" active).

I will try wiping a task manager's configuration and redoing it to ensure 
there isn't anything borked in the way. 

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


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Visual design for logout/login/lockscreen

[Marco Martin]

On Thursday 05 June 2014, David Edmundson wrote:
> > * I think is just fine using the default theme and swapping textcolors
> > and backgroundcolors for the rectangles: to me it looks way better if
> > even if is dark, the two buttons still look light/default
> 
> Toolbuttons were the big problem with just hardcoding colours for text
> and background
> 
>  - if the icon is black you can't see it on the background
>  - if the icon is also hardcoded to white, you can't see it when you
> do the mouseover
> 
>  - if you avoid using a toolbutton and load them as images hardcoded
> to white, you have no indication that it's a button, and it's bad to
> have some buttons behaving differently

I tried making them explicitly visible, don't seem that bad
http://wstaw.org/m/2014/06/05/plasma-desktopGg1731.png
(only the test app, so no blur)

mutually exclusive buttons on one side looks maybe a bit "heavier" but perhaps 
seems a bit more intuitive.

and yeah, I want in the future to be able to ask Svg for a pixmap of an id 
with a different forced class, so toolbutton can animate between two colors in 
a case like this, but I would prefer doing it after release since if possible, 
is going to be a bit invasive


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Visual design for logout/login/lockscreen

[David Edmundson]

> * I think is just fine using the default theme and swapping textcolors and
> backgroundcolors for the rectangles: to me it looks way better if even if is
> dark, the two buttons still look light/default

Toolbuttons were the big problem with just hardcoding colours for text
and background

 - if the icon is black you can't see it on the background
 - if the icon is also hardcoded to white, you can't see it when you
do the mouseover

 - if you avoid using a toolbutton and load them as images hardcoded
to white, you have no indication that it's a button, and it's bad to
have some buttons behaving differently
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Visual design for logout/login/lockscreen

[Marco Martin]

On Thursday 05 June 2014, Aleix Pol wrote:
> Hi,
> I've been trying to sort these out during this week, together with David.
> I've pushed a new Lock and Logout implementations following these mockups.
> They don't look like that yet but it's quite close and workable. The main
> issue
> being that we cannot hardcode a plasma theme from them, or maybe it's not
> an issue.
> 
> Well, either way it would be interesting if somebody could take a look and
> see what it feels like, then maybe we can iterate it forward.

I tried it, I think it's fine, I have just few observations/suggestions:
* seems that sometimes the window (main qml view) is not correctly resized. 
Oddly tough the test program always resizes/places the window correctly
* don't bother wit the background, I think on top of the fullscreen 
blur/darken effect is fine (in this case even better than a background that 
covers everything)
* I think is just fine using the default theme and swapping textcolors and 
backgroundcolors for the rectangles: to me it looks way better if even if is 
dark, the two buttons still look light/default

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins build is back to stable : plasma-workspace_master_qt5 #365

[KDE CI System]

See 

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins build became unstable: plasma-workspace_master_qt5 #364

[KDE CI System]

See 

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118548: Port libtaskmanager away from QDesktopWidget

[Aleix Pol Gonzalez]

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

(Updated June 5, 2014, 5:12 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma, Martin Gräßlin, Eike Hein, and Luca Beltrame.


Repository: plasma-workspace


Description
---

plasmoid.screen doesn't map to QDesktopWidget indexes anymore, therefore we 
need to port it.

This patch uses the screen geometry to figure out what's the screen and then 
passes around the screen rect so that we can filter out the screens that aren't 
inside if the user asks for it.


Diffs
-

  libtaskmanager/taskmanager.cpp 27eeed7 
  libtaskmanager/taskmanager.h e6ca735 
  libtaskmanager/task.h 13a5a9c 
  libtaskmanager/task.cpp 50ea1a6 
  libtaskmanager/launcheritem.cpp 649caca 
  libtaskmanager/groupmanager.h aa71bac 
  libtaskmanager/groupmanager.cpp 83b39ef 

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


Testing
---

I have played with it and seems to work.


Thanks,

Aleix Pol Gonzalez

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118548: Port libtaskmanager away from QDesktopWidget

[Commit Hook]

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


This review has been submitted with commit 
1f5225d4405df26732fbc22ae1491614bc3a7420 by Aleix Pol to branch master.

- Commit Hook


On June 5, 2014, 4:57 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118548/
> ---
> 
> (Updated June 5, 2014, 4:57 p.m.)
> 
> 
> Review request for Plasma, Martin Gräßlin, Eike Hein, and Luca Beltrame.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> plasmoid.screen doesn't map to QDesktopWidget indexes anymore, therefore we 
> need to port it.
> 
> This patch uses the screen geometry to figure out what's the screen and then 
> passes around the screen rect so that we can filter out the screens that 
> aren't inside if the user asks for it.
> 
> 
> Diffs
> -
> 
>   libtaskmanager/taskmanager.cpp 27eeed7 
>   libtaskmanager/taskmanager.h e6ca735 
>   libtaskmanager/task.h 13a5a9c 
>   libtaskmanager/task.cpp 50ea1a6 
>   libtaskmanager/launcheritem.cpp 649caca 
>   libtaskmanager/groupmanager.h aa71bac 
>   libtaskmanager/groupmanager.cpp 83b39ef 
> 
> Diff: https://git.reviewboard.kde.org/r/118548/diff/
> 
> 
> Testing
> ---
> 
> I have played with it and seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Visual design for logout/login/lockscreen

[Andrew Lake]

On Thu, Jun 5, 2014 at 9:47 AM, Aleix Pol  wrote:

> On Sat, Apr 5, 2014 at 12:32 AM, Andrew Lake  wrote:
>
>> Hello,
>>
>> After reading Aaron's nearly year old blog entry again this week (
>> http://aseigo.blogspot.de/2013/05/visual-harmony-in-plasma-workspaces-2.html)
>> , especially the following quote:
>>
>> > ...the log out dialog still has things that look like little push
>> buttons and it still has inexplicable
>> > picture on the left, despite now being written in QML and having all
>> the power that implies.
>> >
>> > Plasma Workspaces 2 is our opportunity to improve these parts by
>> harmonizing and modernizing
>> > them. The log out interface ought to look like it belongs with the lock
>> screen; the log in screen
>> > ought to mesh with the splash screen...
>> >
>> >We have a couple people who can do this kind of work, but they have lots
>> on their plate already.
>> >This is a great opportunity for someone with a flair for design to get
>> involved...
>>
>> I put a little effort into identifying a visual design that might get us
>> a little bit closer. I apologize that I don't have any idea what work may
>> have already been put into this area, so please don't take my ignorance as
>> a dismissal of any work that has already occurred. I also shared this
>> design with other members of the Visual Design Group and there were no
>> objections to offering these designs here.
>>
>> Anyway here goes:
>> Login: http://wstaw.org/m/2014/04/05/login_mockup.png
>> Logout: http://wstaw.org/m/2014/04/03/logout_mockup.png
>> Unlock: http://wstaw.org/m/2014/04/05/unlock_mockup.png
>> Shutdown: http://wstaw.org/m/2014/04/03/shutdown_mockup2_1.png
>>
>> We're happy to provide any visual assets required, which shouldn't be
>> much. (We already have a few to choose from). I won't speak to architecture
>> since that's your wheelhouse, but my assumption is that the UI layer could
>> be handled by the same QML package with enough hooks for the various
>> existing underlying functionality to use. I would like to have offered up a
>> QML package with this, but it's early days yet for my QML familiarity (but
>> getting better fast). :-)
>>
>> Hope this is helpful and please let me know if there are any questions,
>> Andrew Lake
>> Community designer in the KDE Visual Design Group
>>
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
> Hi,
> I've been trying to sort these out during this week, together with David.
> I've pushed a new Lock and Logout implementations following these mockups.
> They don't look like that yet but it's quite close and workable. The main
> issue
> being that we cannot hardcode a plasma theme from them, or maybe it's not
> an issue.
>
> Well, either way it would be interesting if somebody could take a look and
> see what it feels like, then maybe we can iterate it forward.
>
> Cheers!
> Aleix
>

Exciting! I'll be sure to take a look as soon as I update my daily neon
packages.

Andrew
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Visual design for logout/login/lockscreen

[Marco Martin]

On Thursday 05 June 2014, Aleix Pol wrote:

> Hi,
> I've been trying to sort these out during this week, together with David.
> I've pushed a new Lock and Logout implementations following these mockups.
> They don't look like that yet but it's quite close and workable. The main
> issue
> being that we cannot hardcode a plasma theme from them, or maybe it's not
> an issue.

from c++ you can configure a different theme than the global desktop one 
(setUseGlobalSettings).
for now it should be fine having normal breeze and some inverted colors, like 
the sddm theme tough (not sure how black buttons would work there, on the 
other hand we may want white icons

> Well, either way it would be interesting if somebody could take a look and
> see what it feels like, then maybe we can iterate it forward.

I'll take a look at it now

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118548: Port libtaskmanager away from QDesktopWidget

[Aleix Pol Gonzalez]

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

(Updated June 5, 2014, 4:57 p.m.)


Review request for Plasma, Martin Gräßlin, Eike Hein, and Luca Beltrame.


Changes
---

Note this shouldn't prevent this patch from going in, but: Martin, can you 
please consult on the code in TaskManager::isOnScreen()? It fudges window 
geometry by removing 5 pixels from each side of the rect with a note about 
window decoration overscan. This is likely ancient code, is it still relevant 
today to do this?


Repository: plasma-workspace


Description
---

plasmoid.screen doesn't map to QDesktopWidget indexes anymore, therefore we 
need to port it.

This patch uses the screen geometry to figure out what's the screen and then 
passes around the screen rect so that we can filter out the screens that aren't 
inside if the user asks for it.


Diffs
-

  libtaskmanager/taskmanager.cpp 27eeed7 
  libtaskmanager/taskmanager.h e6ca735 
  libtaskmanager/task.h 13a5a9c 
  libtaskmanager/task.cpp 50ea1a6 
  libtaskmanager/launcheritem.cpp 649caca 
  libtaskmanager/groupmanager.h aa71bac 
  libtaskmanager/groupmanager.cpp 83b39ef 

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


Testing
---

I have played with it and seems to work.


Thanks,

Aleix Pol Gonzalez

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118548: Port libtaskmanager away from QDesktopWidget

[Eike Hein]

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

Ship it!


Looks good.

- Eike Hein


On June 5, 2014, 12:35 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118548/
> ---
> 
> (Updated June 5, 2014, 12:35 a.m.)
> 
> 
> Review request for Plasma, Eike Hein and Luca Beltrame.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> plasmoid.screen doesn't map to QDesktopWidget indexes anymore, therefore we 
> need to port it.
> 
> This patch uses the screen geometry to figure out what's the screen and then 
> passes around the screen rect so that we can filter out the screens that 
> aren't inside if the user asks for it.
> 
> 
> Diffs
> -
> 
>   libtaskmanager/taskmanager.cpp 27eeed7 
>   libtaskmanager/taskmanager.h e6ca735 
>   libtaskmanager/task.h 13a5a9c 
>   libtaskmanager/task.cpp 50ea1a6 
>   libtaskmanager/launcheritem.cpp 649caca 
>   libtaskmanager/groupmanager.h aa71bac 
>   libtaskmanager/groupmanager.cpp 83b39ef 
> 
> Diff: https://git.reviewboard.kde.org/r/118548/diff/
> 
> 
> Testing
> ---
> 
> I have played with it and seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Visual design for logout/login/lockscreen

[Aleix Pol]

On Sat, Apr 5, 2014 at 12:32 AM, Andrew Lake  wrote:

> Hello,
>
> After reading Aaron's nearly year old blog entry again this week (
> http://aseigo.blogspot.de/2013/05/visual-harmony-in-plasma-workspaces-2.html)
> , especially the following quote:
>
> > ...the log out dialog still has things that look like little push
> buttons and it still has inexplicable
> > picture on the left, despite now being written in QML and having all the
> power that implies.
> >
> > Plasma Workspaces 2 is our opportunity to improve these parts by
> harmonizing and modernizing
> > them. The log out interface ought to look like it belongs with the lock
> screen; the log in screen
> > ought to mesh with the splash screen...
> >
> >We have a couple people who can do this kind of work, but they have lots
> on their plate already.
> >This is a great opportunity for someone with a flair for design to get
> involved...
>
> I put a little effort into identifying a visual design that might get us a
> little bit closer. I apologize that I don't have any idea what work may
> have already been put into this area, so please don't take my ignorance as
> a dismissal of any work that has already occurred. I also shared this
> design with other members of the Visual Design Group and there were no
> objections to offering these designs here.
>
> Anyway here goes:
> Login: http://wstaw.org/m/2014/04/05/login_mockup.png
> Logout: http://wstaw.org/m/2014/04/03/logout_mockup.png
> Unlock: http://wstaw.org/m/2014/04/05/unlock_mockup.png
> Shutdown: http://wstaw.org/m/2014/04/03/shutdown_mockup2_1.png
>
> We're happy to provide any visual assets required, which shouldn't be
> much. (We already have a few to choose from). I won't speak to architecture
> since that's your wheelhouse, but my assumption is that the UI layer could
> be handled by the same QML package with enough hooks for the various
> existing underlying functionality to use. I would like to have offered up a
> QML package with this, but it's early days yet for my QML familiarity (but
> getting better fast). :-)
>
> Hope this is helpful and please let me know if there are any questions,
> Andrew Lake
> Community designer in the KDE Visual Design Group
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
Hi,
I've been trying to sort these out during this week, together with David.
I've pushed a new Lock and Logout implementations following these mockups.
They don't look like that yet but it's quite close and workable. The main
issue
being that we cannot hardcode a plasma theme from them, or maybe it's not
an issue.

Well, either way it would be interesting if somebody could take a look and
see what it feels like, then maybe we can iterate it forward.

Cheers!
Aleix
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5 Beta 2 tars

[Matthew Dawson]

On June 5, 2014 03:47:59 PM Jonathan Riddell wrote:
> Tars are up for Plasma 5 Beta 2, please try them out and let me know
> of problems.
> 
> I've renamed baloo and milou to have -kf5 in the tar name as you may
> well want the kdelibs4 versions around.  Also kfilemetadata as
> kfilemetadata5.
Regarding this, for source based distributions baloo/kfilemetadata can't be 
co-installed with there kdelibs4 version as the development files conflict, 
the main problem being the CMake files.  I posted an RR here: 
https://git.reviewboard.kde.org/r/118512/ to try and fix that.  Is this 
acceptable?  Otherwise Plasma Next and the rest of KDE SC 4.x can't really be 
co-installed (especially KDEPIM!)

Thanks,
-- 
Matthew

smime.p7s
Description: S/MIME cryptographic signature
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma 5 Beta 2 tars

[Jonathan Riddell]

Tars are up for Plasma 5 Beta 2, please try them out and let me know
of problems.  I'd especially like to know if translations successfully
install as I noticed some not doing so last time.

Appearing here soon
 http://download.kde.org/unstable/plasma/4.97.0/src/

Temporarily here in the mean time
 http://starsky.19inch.net/~jr/tmp/plasma-4.97.0/

md5sums
 http://starsky.19inch.net/~jr/tmp/plasma-4.97.0/4.97.0-release-data

I've renamed baloo and milou to have -kf5 in the tar name as you may
well want the kdelibs4 versions around.  Also kfilemetadata as
kfilemetadata5.

Jonathan
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118406: Notify the user if the location containing the media is inaccessible.

[Shantanu Tushar]

> On June 5, 2014, 8:36 a.m., Thomas Pfeiffer wrote:
> > Usability review:
> > Since I lack the skills to picture it from the diff: When exactly is the 
> > notification shown? Is it shown as soon as the media is supposed to be 
> > played? If so, I think it could be done in a more subtle way: Grey out the 
> > entry in the playlist and just skip over it to the next entry int he 
> > playlist (like Amarok does) and show the message in a tooltip on mouseover 
> > on a pointer device or on tap on a touch device.
> > If it's already done in a similar way, then it's fine for me ;)
> 
> R.Harish  Navnit wrote:
> I've added a screenshot which should help. This is a little different 
> from the way amarok deals with the same error. If the media is inaccessible, 
> the message is shown in the player screen. 
> Is it okay, If I go ahead in the way I am or should look to implement 
> something similar to what amarok does ??
> 
> Thomas Pfeiffer wrote:
> Does PMC really have to be restarted to detect that the location is now 
> accessible? That's not really a nice situation.
> The whole message seems overly dramatic to me, especially in a playlist. 
> Imagine you have a playlist with 50 songs in it, and three of them are on a 
> location which isn't accessible. What would you prefer?
> a) Having to close PMC, make the location accessible and then restart it
> b) Just skip over those three songs and happily listen to the other 47
> 
> If we're not in a playlist, the problem should rarely occur because the 
> browser only shows currently accessible media anyway, right?
>
> 
> R.Harish  Navnit wrote:
> So, like I'd mentioned in the mail(sorry about that). 
> 
> 1.PMC need not be restarted to get to detect that the location is 
> accessible. I think the message might have been ambiguous. The user is 
> expected to mount   
>   all drives containing media and then run the application again. 
> 2. You can skip over to the next media in a playlist. That's how I 
> envisage the fix.
> 
> Please let me know things have to be done differently.
> 
> Thomas Pfeiffer wrote:
> The problem is that currently, the message is very scary. The skip 
> controls are still active, but the user is presented with that very prominent 
> error message telling her that she has to make sure that the file becomes 
> accessible and restart the application. Plus, the playlist won't continue 
> unless the user actively skips to the next entry, right?
> The way Amarok does it is way less scary and disruptive since it silently 
> skips. The only problem with Amarok's solution is that there is no way to 
> find out why it skipped. That's why I suggested to offer a tooltip so users 
> who wonder why a track was skipped can find out what the problem is. The 
> message showing up in the tooltip could be like the one you've proposed, 
> though I would change it to "Could not open the file [path]. To play this 
> file, make sure it is accessible and restart Plasma Mediacenter"
>

Bah, this skipped me as well. There is absolutely no need to restart the app 
here, if the file is available, simply clicking play again should work.

Also, after Thomas pointed it out, in a playlist it actually makes sense to 
simply skip the missing media. However, if you play a single media (without the 
playlist) then this message seems appropriate.
@Thomas, does that sound right?

Finally, I'd suggest "and try again", insteasd of "and restart the application".


- Shantanu


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


On June 5, 2014, 8:47 a.m., R.Harish  Navnit wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118406/
> ---
> 
> (Updated June 5, 2014, 8:47 a.m.)
> 
> 
> Review request for Plasma, Shantanu Tushar and Sinny Kumari.
> 
> 
> Bugs: 333764
> http://bugs.kde.org/show_bug.cgi?id=333764
> 
> 
> Repository: plasma-mediacenter
> 
> 
> Description
> ---
> 
> If a media(in a playlist) is located in an inaccessible location, then the 
> user is notified about the same. 
> 
> 
> Diffs
> -
> 
>   mediaelements/mediaplayer/MediaPlayer.qml 98f1d2c 
> 
> Diff: https://git.reviewboard.kde.org/r/118406/diff/
> 
> 
> Testing
> ---
> 
> 1. Load media to a playlist.
> 2. Unmount the device containing media.
> 3. Check if the user is notified of the location being inaccessible
>--yes, the user is notified
> 4. Mount the device containing media and play a media from playlist.
>-- The media plays properly.
> 
> 
> File Attachments
> 
> 
> wihtout_i18n.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/20

Re: Review Request 117433: [applets/notifications] Use ::hide() instead of ::close()

[Martin Gräßlin]

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

(Updated June 5, 2014, 2:25 p.m.)


Status
--

This change has been discarded.


Review request for Plasma and Martin Klapetek.


Repository: plasma-workspace


Description
---

[applets/notifications] Use ::hide() instead of ::close()

QWindow::close() is destroying the window directly, while ::hide() just
unmaps the window. The main difference is that with hide() the window
manager can still access the x window in the close handling and with
close that's not possible and KWin generates runtime errors.

@MartinK: was there a specific reason to use QWindow::close()? Will using 
hide() cause problems?


Diffs
-

  applets/notifications/package/contents/ui/NotificationPopup.qml 
f738e000b4a28c8c43cbbb9410a53f8b34e4fc56 
  applets/notifications/plugin/notificationshelper.cpp 
9cc119151232d244b4a05d89f07069a80b1da96c 

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


Testing
---

KWin doesn't print warnings when a notification closes.


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118557: Port PlasmaFramework to i18nd + Add test checking for i18n use

[Commit Hook]

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


This review has been submitted with commit 
73bb587ee95a3117416ca41619b847ee2979f530 by David Edmundson to branch master.

- Commit Hook


On June 5, 2014, 10:12 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118557/
> ---
> 
> (Updated June 5, 2014, 10:12 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Set catalog name in QueryDailog
> 
> Add a test that i18nd is used throughout
> 
> I know I'm definitely going to forget to use i18nd in the near future, I'm 
> sure others will too.
> The test is somewhat naive, (it would fail if you write i18n() in a comment 
> for example), but I think it's going to catch a lot more problems than it 
> causes.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt cda9f03 
>   autotests/i18ndcheck.sh PRE-CREATION 
>   src/declarativeimports/plasmacomponents/qml/QueryDialog.qml a057e72 
> 
> Diff: https://git.reviewboard.kde.org/r/118557/diff/
> 
> 
> Testing
> ---
> 
> Tests pass.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118557: Port PlasmaFramework to i18nd + Add test checking for i18n use

[David Edmundson]

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

(Updated June 5, 2014, 11:20 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

Set catalog name in QueryDailog

Add a test that i18nd is used throughout

I know I'm definitely going to forget to use i18nd in the near future, I'm sure 
others will too.
The test is somewhat naive, (it would fail if you write i18n() in a comment for 
example), but I think it's going to catch a lot more problems than it causes.


Diffs
-

  autotests/CMakeLists.txt cda9f03 
  autotests/i18ndcheck.sh PRE-CREATION 
  src/declarativeimports/plasmacomponents/qml/QueryDialog.qml a057e72 

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


Testing
---

Tests pass.


Thanks,

David Edmundson

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118406: Notify the user if the location containing the media is inaccessible.

[Thomas Pfeiffer]

> On June 5, 2014, 8:36 a.m., Thomas Pfeiffer wrote:
> > Usability review:
> > Since I lack the skills to picture it from the diff: When exactly is the 
> > notification shown? Is it shown as soon as the media is supposed to be 
> > played? If so, I think it could be done in a more subtle way: Grey out the 
> > entry in the playlist and just skip over it to the next entry int he 
> > playlist (like Amarok does) and show the message in a tooltip on mouseover 
> > on a pointer device or on tap on a touch device.
> > If it's already done in a similar way, then it's fine for me ;)
> 
> R.Harish  Navnit wrote:
> I've added a screenshot which should help. This is a little different 
> from the way amarok deals with the same error. If the media is inaccessible, 
> the message is shown in the player screen. 
> Is it okay, If I go ahead in the way I am or should look to implement 
> something similar to what amarok does ??
> 
> Thomas Pfeiffer wrote:
> Does PMC really have to be restarted to detect that the location is now 
> accessible? That's not really a nice situation.
> The whole message seems overly dramatic to me, especially in a playlist. 
> Imagine you have a playlist with 50 songs in it, and three of them are on a 
> location which isn't accessible. What would you prefer?
> a) Having to close PMC, make the location accessible and then restart it
> b) Just skip over those three songs and happily listen to the other 47
> 
> If we're not in a playlist, the problem should rarely occur because the 
> browser only shows currently accessible media anyway, right?
>
> 
> R.Harish  Navnit wrote:
> So, like I'd mentioned in the mail(sorry about that). 
> 
> 1.PMC need not be restarted to get to detect that the location is 
> accessible. I think the message might have been ambiguous. The user is 
> expected to mount   
>   all drives containing media and then run the application again. 
> 2. You can skip over to the next media in a playlist. That's how I 
> envisage the fix.
> 
> Please let me know things have to be done differently.

The problem is that currently, the message is very scary. The skip controls are 
still active, but the user is presented with that very prominent error message 
telling her that she has to make sure that the file becomes accessible and 
restart the application. Plus, the playlist won't continue unless the user 
actively skips to the next entry, right?
The way Amarok does it is way less scary and disruptive since it silently 
skips. The only problem with Amarok's solution is that there is no way to find 
out why it skipped. That's why I suggested to offer a tooltip so users who 
wonder why a track was skipped can find out what the problem is. The message 
showing up in the tooltip could be like the one you've proposed, though I would 
change it to "Could not open the file [path]. To play this file, make sure it 
is accessible and restart Plasma Mediacenter"


- Thomas


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


On June 5, 2014, 8:47 a.m., R.Harish  Navnit wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118406/
> ---
> 
> (Updated June 5, 2014, 8:47 a.m.)
> 
> 
> Review request for Plasma, Shantanu Tushar and Sinny Kumari.
> 
> 
> Bugs: 333764
> http://bugs.kde.org/show_bug.cgi?id=333764
> 
> 
> Repository: plasma-mediacenter
> 
> 
> Description
> ---
> 
> If a media(in a playlist) is located in an inaccessible location, then the 
> user is notified about the same. 
> 
> 
> Diffs
> -
> 
>   mediaelements/mediaplayer/MediaPlayer.qml 98f1d2c 
> 
> Diff: https://git.reviewboard.kde.org/r/118406/diff/
> 
> 
> Testing
> ---
> 
> 1. Load media to a playlist.
> 2. Unmount the device containing media.
> 3. Check if the user is notified of the location being inaccessible
>--yes, the user is notified
> 4. Mount the device containing media and play a media from playlist.
>-- The media plays properly.
> 
> 
> File Attachments
> 
> 
> wihtout_i18n.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/06/05/3dc148a5-c4da-4d27-a713-e63922cbcef8__wihtout_i18n.png
> 
> 
> Thanks,
> 
> R.Harish  Navnit
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118526: Provide i18nd wrappers in kdeclarative

[Martin Gräßlin]

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

(Updated June 5, 2014, 10:59 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Plasma and Marco Martin.


Repository: kdeclarative


Description
---

Provide i18nd wrappers in kdeclarative

As QML might combine multiple modules with different cataloges we need
to be able to specify the translation domain explicitly. If there is a
need to use a specific domain for all i18n calls (e.g. in a library
using QML) there is the possibility to set a global translation domain
through KDeclarative. If such a domain is set all i18n calls delegate
to the i18nd variant.

Due to the nature of KDeclarative we cannot mix i18n calls with
different domains. If two modules would require to set the translation
domain it's bound to fail. Thus the recommendation is to use the i18nd
variants in any QML code which is intended to be used as an import.


Diffs
-

  src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
  src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
  src/kdeclarative/private/kdeclarative_p.h 
6b61d123bf74671b413e4e68bf911bb969fdaf53 
  src/kdeclarative/private/rootcontext.cpp 
12309b096495910b83ed1e388989042b45a1 
  src/kdeclarative/private/rootcontext_p.h 
16694b155c668e11cf7a16549a18cdc89b81b3e2 

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


Testing
---

adjusted kwineffects KCM and run it with the x-test language: the strings with 
i18n from QML side are now picking up the translated strings.


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118526: Provide i18nd wrappers in kdeclarative

[Commit Hook]

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


This review has been submitted with commit 
90c9c6563dbc7e6ad57ab374d2f9cab78ccd367b by Martin Gräßlin to branch master.

- Commit Hook


On June 5, 2014, 10:03 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118526/
> ---
> 
> (Updated June 5, 2014, 10:03 a.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Provide i18nd wrappers in kdeclarative
> 
> As QML might combine multiple modules with different cataloges we need
> to be able to specify the translation domain explicitly. If there is a
> need to use a specific domain for all i18n calls (e.g. in a library
> using QML) there is the possibility to set a global translation domain
> through KDeclarative. If such a domain is set all i18n calls delegate
> to the i18nd variant.
> 
> Due to the nature of KDeclarative we cannot mix i18n calls with
> different domains. If two modules would require to set the translation
> domain it's bound to fail. Thus the recommendation is to use the i18nd
> variants in any QML code which is intended to be used as an import.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
>   src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
>   src/kdeclarative/private/kdeclarative_p.h 
> 6b61d123bf74671b413e4e68bf911bb969fdaf53 
>   src/kdeclarative/private/rootcontext.cpp 
> 12309b096495910b83ed1e388989042b45a1 
>   src/kdeclarative/private/rootcontext_p.h 
> 16694b155c668e11cf7a16549a18cdc89b81b3e2 
> 
> Diff: https://git.reviewboard.kde.org/r/118526/diff/
> 
> 
> Testing
> ---
> 
> adjusted kwineffects KCM and run it with the x-test language: the strings 
> with i18n from QML side are now picking up the translated strings.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins build is back to normal : plasma-workspace_master_qt5 #356

[KDE CI System]

See 

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118180: slideshow BUG patch fix

[TOM Harrison]

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

(Updated June 5, 2014, 10:32 a.m.)


Review request for kde-workspace and Plasma.


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


Repository: kde-workspace


Description
---

bug patch for slideshow dir list missing


Diffs
-

  libs/plasmagenericshell/backgrounddialog.cpp 645de3f 

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


Testing
---


Thanks,

TOM Harrison

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Build failed in Jenkins: plasma-workspace_master_qt5 #355

[KDE CI System]

See 

Changes:

[aleixpol] Remove unused headers

[aleixpol] Fix Plasma build with Review 117339

[aleixpol] Adapt to changes in KCoreAddons.Formats

--
[...truncated 2115 lines...]
[ 59%] Built target krunner_recentdocuments
:151:6:
 warning: unused parameter ‘loc’ [-Wunused-parameter]
 void PlasmoidTask::setLocation(Plasma::Types::Location loc)
  ^
Linking CXX shared module krunner_sessions.so
[ 59%] Built target krunner_sessions
[ 59%] Building CXX object 
applets/systemtray/plugin/CMakeFiles/systemtrayplugin.dir/systemtrayplugin_automoc.cpp.o
[ 59%] Building CXX object 
runners/shell/CMakeFiles/krunner_shell.dir/krunner_shell_automoc.cpp.o
Linking CXX shared module krunner_shell.so
[ 59%] Built target krunner_shell
[ 60%] Building CXX object 
applets/systemtray/plugin/CMakeFiles/systemtrayplugin.dir/protocols/plasmoid/plasmoidprotocol.cpp.o
Scanning dependencies of target plasma_engine_executable
Scanning dependencies of target plasma_engine_dict
[ 60%] Building CXX object 
dataengines/executable/CMakeFiles/plasma_engine_executable.dir/executable.cpp.o
[ 61%] Building CXX object 
dataengines/dict/CMakeFiles/plasma_engine_dict.dir/dictengine.cpp.o
:
 In member function ‘void SystemTray::PlasmoidProtocol::restorePlasmoids()’:
:128:121:
 warning: ‘static KPluginInfo::List KPluginInfo::fromServices(const List&, 
const KConfigGroup&)’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kservice/inst/include/KF5/KService/kplugininfo.h:181)
 [-Wdeprecated-declarations]
 KPluginInfo::List applets = 
KPluginInfo::fromServices(KServiceTypeTrader::self()->query("Plasma/Applet", 
constraint));

 ^
[ 62%] Generating devicenotificationsadaptor.cpp, devicenotificationsadaptor.h
[ 62%] Generating devicenotificationsadaptor.moc
Scanning dependencies of target plasma_engine_devicenotifications
[ 62%] Building CXX object 
dataengines/devicenotifications/CMakeFiles/plasma_engine_devicenotifications.dir/devicenotificationsengine.cpp.o
[ 62%] Building CXX object 
dataengines/executable/CMakeFiles/plasma_engine_executable.dir/plasma_engine_executable_automoc.cpp.o
Linking CXX shared library libsystemtrayplugin.so
[ 62%] Building CXX object 
dataengines/dict/CMakeFiles/plasma_engine_dict.dir/plasma_engine_dict_automoc.cpp.o
[ 62%] Built target systemtrayplugin
[ 62%] Building CXX object 
dataengines/devicenotifications/CMakeFiles/plasma_engine_devicenotifications.dir/devicenotificationsadaptor.cpp.o
Scanning dependencies of target plasma_engine_apps
[ 62%] Building CXX object 
dataengines/apps/CMakeFiles/plasma_engine_apps.dir/appsengine.cpp.o
Linking CXX shared module plasma_engine_executable.so
Linking CXX shared module plasma_engine_dict.so
[ 62%] [ 62%] Generating ActivityRankingInterface.cpp, 
ActivityRankingInterface.h
Built target plasma_engine_executable
[ 63%] Building CXX object 
dataengines/apps/CMakeFiles/plasma_engine_apps.dir/appsource.cpp.o
[ 63%] Warning: deprecated annotation 'com.trolltech.QtDBus.QtTypeName.Out0' 
found; suggest updating to 'org.qtproject.QtDBus.QtTypeName.Out0'
Warning: deprecated annotation 'com.trolltech.QtDBus.QtTypeName.In1' found; 
suggest updating to 'org.qtproject.QtDBus.QtTypeName.In1'
Generating jobviewserveradaptor.cpp, jobviewserveradaptor.h
[ 63%] [ 63%] [ 63%] Generating jobviewadaptor.cpp, jobviewadaptor.h
Generating ActivityRankingInterface.moc
Built target plasma_engine_dict
[ 63%] Generating jobviewadaptor.moc
[ 63%] Building CXX object 
dataengines/apps/CMakeFiles/plasma_engine_apps.dir/appservice.cpp.o
[ 63%] Scanning dependencies of target krunner_services
[ 64%] Building CXX object 
runners/services/CMakeFiles/krunner_services.dir/servicerunner.cpp.o
Generating jobviewserveradaptor.moc
Scanning dependencies of target plasma_engine_activities
[ 64%] Building CXX object 
dataengines/devicenotifications/CMakeFiles/plasma_engine_devicenotifications.dir/plasma_engine_devicenotifications_automoc.cpp.o
[ 65%] Building CXX object 
dataengines/activities/CMakeFiles/plasma_engine_activities.dir/ActivityData.cpp.o
Scanning dependencies of target plasma_engine_applicationjobs
[ 65%] Building CXX object 
dataengines/applicationjobs/CMakeFiles/plasma_engine_applicationjobs.dir/kuiserverengine.cpp.o
[ 65%] Building CXX object 
dataengines/applicationjobs/CMakeFiles/plasma_engine_applicationjobs.dir/jobcontrol.cpp.o
Scanning dependencies of target krunner_placesrunn

Re: Review Request 118558: Fix Plasma build with Review 117339

[Kai Uwe Broulik]

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

(Updated June 5, 2014, 10:24 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Aleix Pol Gonzalez.


Repository: plasma-workspace


Description
---

This patch adjusts the Plasma powermanagement (and soliddevice) dataengine to 
use the renamed isPresent() method instead of isPlugged().
It does not rename the exposed property "Plugged in" to not break its users.


Diffs
-

  dataengines/powermanagement/powermanagementengine.h 9429ade 
  dataengines/powermanagement/powermanagementengine.cpp 1b1cb5e 
  dataengines/soliddevice/soliddeviceengine.cpp 97d7c8d 

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


Testing
---

Builds


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118558: Fix Plasma build with Review 117339

[Commit Hook]

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


This review has been submitted with commit 
45254e4d0aa0af4e9d72d800b11b41ab8b28e537 by Aleix Pol on behalf of Kai Uwe 
Broulik to branch master.

- Commit Hook


On June 5, 2014, 10:01 a.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118558/
> ---
> 
> (Updated June 5, 2014, 10:01 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This patch adjusts the Plasma powermanagement (and soliddevice) dataengine to 
> use the renamed isPresent() method instead of isPlugged().
> It does not rename the exposed property "Plugged in" to not break its users.
> 
> 
> Diffs
> -
> 
>   dataengines/powermanagement/powermanagementengine.h 9429ade 
>   dataengines/powermanagement/powermanagementengine.cpp 1b1cb5e 
>   dataengines/soliddevice/soliddeviceengine.cpp 97d7c8d 
> 
> Diff: https://git.reviewboard.kde.org/r/118558/diff/
> 
> 
> Testing
> ---
> 
> Builds
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118526: Provide i18nd wrappers in kdeclarative

[Marco Martin]

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

Ship it!


Ship it 2.0

- Marco Martin


On June 5, 2014, 10:03 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118526/
> ---
> 
> (Updated June 5, 2014, 10:03 a.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Provide i18nd wrappers in kdeclarative
> 
> As QML might combine multiple modules with different cataloges we need
> to be able to specify the translation domain explicitly. If there is a
> need to use a specific domain for all i18n calls (e.g. in a library
> using QML) there is the possibility to set a global translation domain
> through KDeclarative. If such a domain is set all i18n calls delegate
> to the i18nd variant.
> 
> Due to the nature of KDeclarative we cannot mix i18n calls with
> different domains. If two modules would require to set the translation
> domain it's bound to fail. Thus the recommendation is to use the i18nd
> variants in any QML code which is intended to be used as an import.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
>   src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
>   src/kdeclarative/private/kdeclarative_p.h 
> 6b61d123bf74671b413e4e68bf911bb969fdaf53 
>   src/kdeclarative/private/rootcontext.cpp 
> 12309b096495910b83ed1e388989042b45a1 
>   src/kdeclarative/private/rootcontext_p.h 
> 16694b155c668e11cf7a16549a18cdc89b81b3e2 
> 
> Diff: https://git.reviewboard.kde.org/r/118526/diff/
> 
> 
> Testing
> ---
> 
> adjusted kwineffects KCM and run it with the x-test language: the strings 
> with i18n from QML side are now picking up the translated strings.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118558: Fix Plasma build with Review 117339

[Marco Martin]

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

Ship it!


Ship It!

- Marco Martin


On June 5, 2014, 10:01 a.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118558/
> ---
> 
> (Updated June 5, 2014, 10:01 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This patch adjusts the Plasma powermanagement (and soliddevice) dataengine to 
> use the renamed isPresent() method instead of isPlugged().
> It does not rename the exposed property "Plugged in" to not break its users.
> 
> 
> Diffs
> -
> 
>   dataengines/powermanagement/powermanagementengine.h 9429ade 
>   dataengines/powermanagement/powermanagementengine.cpp 1b1cb5e 
>   dataengines/soliddevice/soliddeviceengine.cpp 97d7c8d 
> 
> Diff: https://git.reviewboard.kde.org/r/118558/diff/
> 
> 
> Testing
> ---
> 
> Builds
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118557: Port PlasmaFramework to i18nd + Add test checking for i18n use

[Marco Martin]

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

Ship it!


Ship It!

- Marco Martin


On June 5, 2014, 10:12 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118557/
> ---
> 
> (Updated June 5, 2014, 10:12 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Set catalog name in QueryDailog
> 
> Add a test that i18nd is used throughout
> 
> I know I'm definitely going to forget to use i18nd in the near future, I'm 
> sure others will too.
> The test is somewhat naive, (it would fail if you write i18n() in a comment 
> for example), but I think it's going to catch a lot more problems than it 
> causes.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt cda9f03 
>   autotests/i18ndcheck.sh PRE-CREATION 
>   src/declarativeimports/plasmacomponents/qml/QueryDialog.qml a057e72 
> 
> Diff: https://git.reviewboard.kde.org/r/118557/diff/
> 
> 
> Testing
> ---
> 
> Tests pass.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 118557: Port PlasmaFramework to i18nd + Add test checking for i18n use

[David Edmundson]

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

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

Set catalog name in QueryDailog

Add a test that i18nd is used throughout

I know I'm definitely going to forget to use i18nd in the near future, I'm sure 
others will too.
The test is somewhat naive, (it would fail if you write i18n() in a comment for 
example), but I think it's going to catch a lot more problems than it causes.


Diffs
-

  autotests/CMakeLists.txt cda9f03 
  autotests/i18ndcheck.sh PRE-CREATION 
  src/declarativeimports/plasmacomponents/qml/QueryDialog.qml a057e72 

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


Testing
---

Tests pass.


Thanks,

David Edmundson

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118526: Provide i18nd wrappers in kdeclarative

[Martin Gräßlin]

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

(Updated June 5, 2014, 12:03 p.m.)


Review request for KDE Frameworks, Plasma and Marco Martin.


Changes
---

changed as suggested.


Repository: kdeclarative


Description
---

Provide i18nd wrappers in kdeclarative

As QML might combine multiple modules with different cataloges we need
to be able to specify the translation domain explicitly. If there is a
need to use a specific domain for all i18n calls (e.g. in a library
using QML) there is the possibility to set a global translation domain
through KDeclarative. If such a domain is set all i18n calls delegate
to the i18nd variant.

Due to the nature of KDeclarative we cannot mix i18n calls with
different domains. If two modules would require to set the translation
domain it's bound to fail. Thus the recommendation is to use the i18nd
variants in any QML code which is intended to be used as an import.


Diffs (updated)
-

  src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
  src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
  src/kdeclarative/private/kdeclarative_p.h 
6b61d123bf74671b413e4e68bf911bb969fdaf53 
  src/kdeclarative/private/rootcontext.cpp 
12309b096495910b83ed1e388989042b45a1 
  src/kdeclarative/private/rootcontext_p.h 
16694b155c668e11cf7a16549a18cdc89b81b3e2 

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


Testing
---

adjusted kwineffects KCM and run it with the x-test language: the strings with 
i18n from QML side are now picking up the translated strings.


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 118558: Fix Plasma build with Review 117339

[Kai Uwe Broulik]

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

Review request for Plasma and Aleix Pol Gonzalez.


Repository: plasma-workspace


Description
---

This patch adjusts the Plasma powermanagement (and soliddevice) dataengine to 
use the renamed isPresent() method instead of isPlugged().
It does not rename the exposed property "Plugged in" to not break its users.


Diffs
-

  dataengines/powermanagement/powermanagementengine.h 9429ade 
  dataengines/powermanagement/powermanagementengine.cpp 1b1cb5e 
  dataengines/soliddevice/soliddeviceengine.cpp 97d7c8d 

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


Testing
---

Builds


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118482: Adjust ksmserver for renamed KWin binary

[Hrvoje Senjan]

> On June 4, 2014, 9:04 a.m., Martin Gräßlin wrote:
> > looks good to me. Where is the KCM living where one can select the window 
> > manager?
> 
> Hrvoje Senjan wrote:
> it is in plasma-desktop repo. but i did not want to add a patch for 
> something that does not build ;-)
> 1) uses Q_WS_X11 (easy to change)
> 2) there's some NETRootInfo usage which got change, and i'd rather leave 
> the port to an expert
> 
> Martin Gräßlin wrote:
> all right, it's on my todo list
> 
> Martin Gräßlin wrote:
> kcm is fixed as of b384cb36f1dff98a97956ad51d9d6f004508b346 - a quick 
> look at the code indicates that some work is needed there as it starts a kwin 
> process.

well, that NETRootInfo looked more scary ;-)
will try to adjust today the kcm


- Hrvoje


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


On June 3, 2014, 3:22 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118482/
> ---
> 
> (Updated June 3, 2014, 3:22 p.m.)
> 
> 
> Review request for Plasma and Martin Gräßlin.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> as per dependant review, adjust ksmserver usage of KWin name. (IOW make sure 
> kwin_x11 is started)
> 
> 
> Diffs
> -
> 
>   ConfigureChecks.cmake 8e6a87a 
>   ksmserver/config-ksmserver.h.cmake 939632c 
>   ksmserver/server.cpp 644013b 
>   ksmserver/startup.cpp 6f5d502 
> 
> Diff: https://git.reviewboard.kde.org/r/118482/diff/
> 
> 
> Testing
> ---
> 
> using it for some ~10 days, noticed no regression.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118406: Notify the user if the location containing the media is inaccessible.

[R.Harish Navnit]

> On June 5, 2014, 8:36 a.m., Thomas Pfeiffer wrote:
> > Usability review:
> > Since I lack the skills to picture it from the diff: When exactly is the 
> > notification shown? Is it shown as soon as the media is supposed to be 
> > played? If so, I think it could be done in a more subtle way: Grey out the 
> > entry in the playlist and just skip over it to the next entry int he 
> > playlist (like Amarok does) and show the message in a tooltip on mouseover 
> > on a pointer device or on tap on a touch device.
> > If it's already done in a similar way, then it's fine for me ;)
> 
> R.Harish  Navnit wrote:
> I've added a screenshot which should help. This is a little different 
> from the way amarok deals with the same error. If the media is inaccessible, 
> the message is shown in the player screen. 
> Is it okay, If I go ahead in the way I am or should look to implement 
> something similar to what amarok does ??
> 
> Thomas Pfeiffer wrote:
> Does PMC really have to be restarted to detect that the location is now 
> accessible? That's not really a nice situation.
> The whole message seems overly dramatic to me, especially in a playlist. 
> Imagine you have a playlist with 50 songs in it, and three of them are on a 
> location which isn't accessible. What would you prefer?
> a) Having to close PMC, make the location accessible and then restart it
> b) Just skip over those three songs and happily listen to the other 47
> 
> If we're not in a playlist, the problem should rarely occur because the 
> browser only shows currently accessible media anyway, right?
>

So, like I'd mentioned in the mail(sorry about that). 

1.PMC need not be restarted to get to detect that the location is accessible. I 
think the message might have been ambiguous. The user is expected to mount   
  all drives containing media and then run the application again. 
2. You can skip over to the next media in a playlist. That's how I envisage the 
fix.

Please let me know things have to be done differently.


- R.Harish


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


On June 5, 2014, 8:47 a.m., R.Harish  Navnit wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118406/
> ---
> 
> (Updated June 5, 2014, 8:47 a.m.)
> 
> 
> Review request for Plasma, Shantanu Tushar and Sinny Kumari.
> 
> 
> Bugs: 333764
> http://bugs.kde.org/show_bug.cgi?id=333764
> 
> 
> Repository: plasma-mediacenter
> 
> 
> Description
> ---
> 
> If a media(in a playlist) is located in an inaccessible location, then the 
> user is notified about the same. 
> 
> 
> Diffs
> -
> 
>   mediaelements/mediaplayer/MediaPlayer.qml 98f1d2c 
> 
> Diff: https://git.reviewboard.kde.org/r/118406/diff/
> 
> 
> Testing
> ---
> 
> 1. Load media to a playlist.
> 2. Unmount the device containing media.
> 3. Check if the user is notified of the location being inaccessible
>--yes, the user is notified
> 4. Mount the device containing media and play a media from playlist.
>-- The media plays properly.
> 
> 
> File Attachments
> 
> 
> wihtout_i18n.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/06/05/3dc148a5-c4da-4d27-a713-e63922cbcef8__wihtout_i18n.png
> 
> 
> Thanks,
> 
> R.Harish  Navnit
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118406: Notify the user if the location containing the media is inaccessible.

[R.Harish Navnit]

On Thu, Jun 5, 2014 at 2:59 PM, Thomas Pfeiffer 
wrote:

>This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118406
>
>
>  Does PMC really have to be restarted to detect that the location is now 
> accessible? That's not really a nice situation.
> The whole message seems overly dramatic to me, especially in a playlist. 
> Imagine you have a playlist with 50 songs in it, and three of them are on a 
> location which isn't accessible. What would you prefer?
> a) Having to close PMC, make the location accessible and then restart it
>
> You could still skip over to the next songs even in this case. Just that,
whenever you stumble upon inaccessible media you'll get the error message
as shown in the screenshot. The next and prev buttons do retain their
functionalities ;)
Well, that's what I intent to implement as a fix for this bug.

> b) Just skip over those three songs and happily listen to the other 47
>
> Yes, you can skip over those songs and listen to other songs.  But for the
3 songs that are inaccessible, the application has to be restarted after
mounting(if unmounted) the device/drive containing it.

> If we're not in a playlist, the problem should rarely occur because the 
> browser only shows currently accessible media anyway, right?
>
> Yes, I can't think of any other situation when this might be required.


R.Harish Navnit
The Enigma 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118538: Add a property containing the real edge a dialog is shown on

[Marco Martin]

> On June 4, 2014, 7:30 p.m., Marco Martin wrote:
> > what is a valid use case where qml needs to know where the dialog actually 
> > is?(not hypothetical please)
> > doing the animation on the proper direction can be tracked completely 
> > internally
> > 
> > also, plasmoids should never ever do a screen edge animation when in the 
> > middle of the desktop, the animation looks bad where it's clipped if it's 
> > not against a panel or a screen edge
> 
> David Edmundson wrote:
> Milou places the most relevant item closest to the launcher.
> 
>
> 
> Marco Martin wrote:
> Hmm, it would be relevant only in the case milou is iconified and in the 
> desktop, that seems quite a narrow case.
> api wise it may make sense a Plasma::Types::Direction 
> visualParentDirection, *but* it would have to be exported in plasmoid as 
> well, and I don't want anything like that here.
> API that is added ad hoc for a single, extremely narrow use case is never 
> a good idea.
> 
> David Edmundson wrote:
> kickoff changes direction too so the toolbar is closest to the launcher.
> 
> However, I'm not too fussed about the new property, I can remove the 
> Q_PROPERTY and add it if we decide it's needed. The important part for me is 
> making it show the correct borders and animate in the right direction.

I don't think animating or borders is a problem, because the location dependent 
borders should be disabled only when at screen edges, when the location is the 
real one, and the animation as well should be done only when at screen edge or 
in panel as well.

If the property ends up being really needed, i can see it working as a 
direction (instead of location enum), without any setter.
To be usable in applets however, it would still need a plasmoid property, like 
popupsDirection, wouldn't even be that bad, but for it to work it would need to 
track the scene position of the applet, thing that seems possible in 5.3 but 
heavy on cpu


- Marco


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


On June 4, 2014, 10:43 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118538/
> ---
> 
> (Updated June 4, 2014, 10:43 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Add a property containing the real edge a dialog is shown on.
> 
> If a dialog is meant to be shown on the left of an item, if there is not
> enough space it will be shown on the right.
> 
> We need to keep track of where we're actually shown in order to show the
> correct borders and perform the animation in the correct direction.
> 
> It is exposed as a property in case the dialog itself needs to know
> which side of the parent item it is, for example if needs to show an
> arrow to the parent.
> 
> --
> 
> Fixed some serious copy + paste fails in the hitting the bottom edge of
> the screen check.
> 
> 
> Diffs
> -
> 
>   src/plasmaquick/dialog.cpp 2f8227c 
>   src/plasmaquick/dialog.h 4009222 
> 
> Diff: https://git.reviewboard.kde.org/r/118538/diff/
> 
> 
> Testing
> ---
> 
> Ran dialog_positioning.qml in all 8 combinations of edges + preferred 
> locations.
> (i.e placed near left edge, showed item with location set to both left and 
> right)
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118406: Notify the user if the location containing the media is inaccessible.

[Thomas Pfeiffer]

> On June 5, 2014, 8:36 a.m., Thomas Pfeiffer wrote:
> > Usability review:
> > Since I lack the skills to picture it from the diff: When exactly is the 
> > notification shown? Is it shown as soon as the media is supposed to be 
> > played? If so, I think it could be done in a more subtle way: Grey out the 
> > entry in the playlist and just skip over it to the next entry int he 
> > playlist (like Amarok does) and show the message in a tooltip on mouseover 
> > on a pointer device or on tap on a touch device.
> > If it's already done in a similar way, then it's fine for me ;)
> 
> R.Harish  Navnit wrote:
> I've added a screenshot which should help. This is a little different 
> from the way amarok deals with the same error. If the media is inaccessible, 
> the message is shown in the player screen. 
> Is it okay, If I go ahead in the way I am or should look to implement 
> something similar to what amarok does ??

Does PMC really have to be restarted to detect that the location is now 
accessible? That's not really a nice situation.
The whole message seems overly dramatic to me, especially in a playlist. 
Imagine you have a playlist with 50 songs in it, and three of them are on a 
location which isn't accessible. What would you prefer?
a) Having to close PMC, make the location accessible and then restart it
b) Just skip over those three songs and happily listen to the other 47

If we're not in a playlist, the problem should rarely occur because the browser 
only shows currently accessible media anyway, right?


- Thomas


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


On June 5, 2014, 8:47 a.m., R.Harish  Navnit wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118406/
> ---
> 
> (Updated June 5, 2014, 8:47 a.m.)
> 
> 
> Review request for Plasma, Shantanu Tushar and Sinny Kumari.
> 
> 
> Bugs: 333764
> http://bugs.kde.org/show_bug.cgi?id=333764
> 
> 
> Repository: plasma-mediacenter
> 
> 
> Description
> ---
> 
> If a media(in a playlist) is located in an inaccessible location, then the 
> user is notified about the same. 
> 
> 
> Diffs
> -
> 
>   mediaelements/mediaplayer/MediaPlayer.qml 98f1d2c 
> 
> Diff: https://git.reviewboard.kde.org/r/118406/diff/
> 
> 
> Testing
> ---
> 
> 1. Load media to a playlist.
> 2. Unmount the device containing media.
> 3. Check if the user is notified of the location being inaccessible
>--yes, the user is notified
> 4. Mount the device containing media and play a media from playlist.
>-- The media plays properly.
> 
> 
> File Attachments
> 
> 
> wihtout_i18n.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/06/05/3dc148a5-c4da-4d27-a713-e63922cbcef8__wihtout_i18n.png
> 
> 
> Thanks,
> 
> R.Harish  Navnit
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118526: Provide i18nd wrappers in kdeclarative

[Marco Martin]

> On June 5, 2014, 8:58 a.m., Chusslove Illich wrote:
> > src/kdeclarative/private/rootcontext.cpp, line 48
> > 
> >
> > (And at other places like this.)
> > 
> > If I understand, any of the parameters can be not given (isNull()) in 
> > the call, and therefore the original code does ki18n() followed by checks 
> > and .subs(). The patch should then behave in the same way, i.e.
> > 
> > KLocalizedString trMessage;
> > if (!m_translationDomain.isNull()) {
> > trMessage = ki18nd(m_translationDomain, 
> > message.toUtf8().constData());
> > } else {
> > trMessage = ki18n(message.toUtf8().constData());
> > }
> >

Seems a good point


- Marco


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


On June 4, 2014, 1:06 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118526/
> ---
> 
> (Updated June 4, 2014, 1:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Provide i18nd wrappers in kdeclarative
> 
> As QML might combine multiple modules with different cataloges we need
> to be able to specify the translation domain explicitly. If there is a
> need to use a specific domain for all i18n calls (e.g. in a library
> using QML) there is the possibility to set a global translation domain
> through KDeclarative. If such a domain is set all i18n calls delegate
> to the i18nd variant.
> 
> Due to the nature of KDeclarative we cannot mix i18n calls with
> different domains. If two modules would require to set the translation
> domain it's bound to fail. Thus the recommendation is to use the i18nd
> variants in any QML code which is intended to be used as an import.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
>   src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
>   src/kdeclarative/private/kdeclarative_p.h 
> 6b61d123bf74671b413e4e68bf911bb969fdaf53 
>   src/kdeclarative/private/rootcontext.cpp 
> 12309b096495910b83ed1e388989042b45a1 
>   src/kdeclarative/private/rootcontext_p.h 
> 16694b155c668e11cf7a16549a18cdc89b81b3e2 
> 
> Diff: https://git.reviewboard.kde.org/r/118526/diff/
> 
> 
> Testing
> ---
> 
> adjusted kwineffects KCM and run it with the x-test language: the strings 
> with i18n from QML side are now picking up the translated strings.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118526: Provide i18nd wrappers in kdeclarative

[Marco Martin]

> On June 5, 2014, 8:29 a.m., David Edmundson wrote:
> > src/kdeclarative/kdeclarative.cpp, line 120
> > 
> >
> > Can we warn if this is already set to something else.
> > 
> > If two QML files try to do it to different paths it means something has 
> > gone horribly wrong (or is just about to).
> 
> Martin Gräßlin wrote:
> As the method is only supposed to be called before setupBindings I'm not 
> sure whether a warning will help anything. @Marco: your opinion on it?
> 
> David Edmundson wrote:
> Oh yeah, the property isn't writeable.
> Probably isn't worth it then.

things loaded from c++ like plasmoids and other packages will have the proper 
domain set.

but anyhthing in imports will always be out of luck and can only use explicitly 
i18nd, i don't see any other solution sadly


- Marco


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


On June 4, 2014, 1:06 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118526/
> ---
> 
> (Updated June 4, 2014, 1:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Provide i18nd wrappers in kdeclarative
> 
> As QML might combine multiple modules with different cataloges we need
> to be able to specify the translation domain explicitly. If there is a
> need to use a specific domain for all i18n calls (e.g. in a library
> using QML) there is the possibility to set a global translation domain
> through KDeclarative. If such a domain is set all i18n calls delegate
> to the i18nd variant.
> 
> Due to the nature of KDeclarative we cannot mix i18n calls with
> different domains. If two modules would require to set the translation
> domain it's bound to fail. Thus the recommendation is to use the i18nd
> variants in any QML code which is intended to be used as an import.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
>   src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
>   src/kdeclarative/private/kdeclarative_p.h 
> 6b61d123bf74671b413e4e68bf911bb969fdaf53 
>   src/kdeclarative/private/rootcontext.cpp 
> 12309b096495910b83ed1e388989042b45a1 
>   src/kdeclarative/private/rootcontext_p.h 
> 16694b155c668e11cf7a16549a18cdc89b81b3e2 
> 
> Diff: https://git.reviewboard.kde.org/r/118526/diff/
> 
> 
> Testing
> ---
> 
> adjusted kwineffects KCM and run it with the x-test language: the strings 
> with i18n from QML side are now picking up the translated strings.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118526: Provide i18nd wrappers in kdeclarative

[David Edmundson]

> On June 5, 2014, 8:29 a.m., David Edmundson wrote:
> > src/kdeclarative/kdeclarative.cpp, line 120
> > 
> >
> > Can we warn if this is already set to something else.
> > 
> > If two QML files try to do it to different paths it means something has 
> > gone horribly wrong (or is just about to).
> 
> Martin Gräßlin wrote:
> As the method is only supposed to be called before setupBindings I'm not 
> sure whether a warning will help anything. @Marco: your opinion on it?

Oh yeah, the property isn't writeable.
Probably isn't worth it then.


- David


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


On June 4, 2014, 1:06 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118526/
> ---
> 
> (Updated June 4, 2014, 1:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Provide i18nd wrappers in kdeclarative
> 
> As QML might combine multiple modules with different cataloges we need
> to be able to specify the translation domain explicitly. If there is a
> need to use a specific domain for all i18n calls (e.g. in a library
> using QML) there is the possibility to set a global translation domain
> through KDeclarative. If such a domain is set all i18n calls delegate
> to the i18nd variant.
> 
> Due to the nature of KDeclarative we cannot mix i18n calls with
> different domains. If two modules would require to set the translation
> domain it's bound to fail. Thus the recommendation is to use the i18nd
> variants in any QML code which is intended to be used as an import.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
>   src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
>   src/kdeclarative/private/kdeclarative_p.h 
> 6b61d123bf74671b413e4e68bf911bb969fdaf53 
>   src/kdeclarative/private/rootcontext.cpp 
> 12309b096495910b83ed1e388989042b45a1 
>   src/kdeclarative/private/rootcontext_p.h 
> 16694b155c668e11cf7a16549a18cdc89b81b3e2 
> 
> Diff: https://git.reviewboard.kde.org/r/118526/diff/
> 
> 
> Testing
> ---
> 
> adjusted kwineffects KCM and run it with the x-test language: the strings 
> with i18n from QML side are now picking up the translated strings.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118526: Provide i18nd wrappers in kdeclarative

[Chusslove Illich]

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



src/kdeclarative/private/rootcontext.cpp


(And at other places like this.)

If I understand, any of the parameters can be not given (isNull()) in the 
call, and therefore the original code does ki18n() followed by checks and 
.subs(). The patch should then behave in the same way, i.e.

KLocalizedString trMessage;
if (!m_translationDomain.isNull()) {
trMessage = ki18nd(m_translationDomain, message.toUtf8().constData());
} else {
trMessage = ki18n(message.toUtf8().constData());
}



- Chusslove Illich


On June 4, 2014, 3:06 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118526/
> ---
> 
> (Updated June 4, 2014, 3:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Provide i18nd wrappers in kdeclarative
> 
> As QML might combine multiple modules with different cataloges we need
> to be able to specify the translation domain explicitly. If there is a
> need to use a specific domain for all i18n calls (e.g. in a library
> using QML) there is the possibility to set a global translation domain
> through KDeclarative. If such a domain is set all i18n calls delegate
> to the i18nd variant.
> 
> Due to the nature of KDeclarative we cannot mix i18n calls with
> different domains. If two modules would require to set the translation
> domain it's bound to fail. Thus the recommendation is to use the i18nd
> variants in any QML code which is intended to be used as an import.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
>   src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
>   src/kdeclarative/private/kdeclarative_p.h 
> 6b61d123bf74671b413e4e68bf911bb969fdaf53 
>   src/kdeclarative/private/rootcontext.cpp 
> 12309b096495910b83ed1e388989042b45a1 
>   src/kdeclarative/private/rootcontext_p.h 
> 16694b155c668e11cf7a16549a18cdc89b81b3e2 
> 
> Diff: https://git.reviewboard.kde.org/r/118526/diff/
> 
> 
> Testing
> ---
> 
> adjusted kwineffects KCM and run it with the x-test language: the strings 
> with i18n from QML side are now picking up the translated strings.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118406: Notify the user if the location containing the media is inaccessible.

[R.Harish Navnit]

> On June 5, 2014, 8:36 a.m., Thomas Pfeiffer wrote:
> > Usability review:
> > Since I lack the skills to picture it from the diff: When exactly is the 
> > notification shown? Is it shown as soon as the media is supposed to be 
> > played? If so, I think it could be done in a more subtle way: Grey out the 
> > entry in the playlist and just skip over it to the next entry int he 
> > playlist (like Amarok does) and show the message in a tooltip on mouseover 
> > on a pointer device or on tap on a touch device.
> > If it's already done in a similar way, then it's fine for me ;)

I've added a screenshot which should help. This is a little different from the 
way amarok deals with the same error. If the media is inaccessible, the message 
is shown in the player screen. 
Is it okay, If I go ahead in the way I am or should look to implement something 
similar to what amarok does ?? 


- R.Harish


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


On June 5, 2014, 8:47 a.m., R.Harish  Navnit wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118406/
> ---
> 
> (Updated June 5, 2014, 8:47 a.m.)
> 
> 
> Review request for Plasma, Shantanu Tushar and Sinny Kumari.
> 
> 
> Bugs: 333764
> http://bugs.kde.org/show_bug.cgi?id=333764
> 
> 
> Repository: plasma-mediacenter
> 
> 
> Description
> ---
> 
> If a media(in a playlist) is located in an inaccessible location, then the 
> user is notified about the same. 
> 
> 
> Diffs
> -
> 
>   mediaelements/mediaplayer/MediaPlayer.qml 98f1d2c 
> 
> Diff: https://git.reviewboard.kde.org/r/118406/diff/
> 
> 
> Testing
> ---
> 
> 1. Load media to a playlist.
> 2. Unmount the device containing media.
> 3. Check if the user is notified of the location being inaccessible
>--yes, the user is notified
> 4. Mount the device containing media and play a media from playlist.
>-- The media plays properly.
> 
> 
> File Attachments
> 
> 
> wihtout_i18n.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/06/05/3dc148a5-c4da-4d27-a713-e63922cbcef8__wihtout_i18n.png
> 
> 
> Thanks,
> 
> R.Harish  Navnit
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118526: Provide i18nd wrappers in kdeclarative

[Marco Martin]

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

Ship it!


Great! I'll try to make plasmoids and shells packages around use it

- Marco Martin


On June 4, 2014, 1:06 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118526/
> ---
> 
> (Updated June 4, 2014, 1:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Provide i18nd wrappers in kdeclarative
> 
> As QML might combine multiple modules with different cataloges we need
> to be able to specify the translation domain explicitly. If there is a
> need to use a specific domain for all i18n calls (e.g. in a library
> using QML) there is the possibility to set a global translation domain
> through KDeclarative. If such a domain is set all i18n calls delegate
> to the i18nd variant.
> 
> Due to the nature of KDeclarative we cannot mix i18n calls with
> different domains. If two modules would require to set the translation
> domain it's bound to fail. Thus the recommendation is to use the i18nd
> variants in any QML code which is intended to be used as an import.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
>   src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
>   src/kdeclarative/private/kdeclarative_p.h 
> 6b61d123bf74671b413e4e68bf911bb969fdaf53 
>   src/kdeclarative/private/rootcontext.cpp 
> 12309b096495910b83ed1e388989042b45a1 
>   src/kdeclarative/private/rootcontext_p.h 
> 16694b155c668e11cf7a16549a18cdc89b81b3e2 
> 
> Diff: https://git.reviewboard.kde.org/r/118526/diff/
> 
> 
> Testing
> ---
> 
> adjusted kwineffects KCM and run it with the x-test language: the strings 
> with i18n from QML side are now picking up the translated strings.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118406: Notify the user if the location containing the media is inaccessible.

[R.Harish Navnit]

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

(Updated June 5, 2014, 8:47 a.m.)


Review request for Plasma, Shantanu Tushar and Sinny Kumari.


Changes
---

Notification shown after the inaccessible media is selected(for playing). 


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


Repository: plasma-mediacenter


Description
---

If a media(in a playlist) is located in an inaccessible location, then the user 
is notified about the same. 


Diffs
-

  mediaelements/mediaplayer/MediaPlayer.qml 98f1d2c 

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


Testing
---

1. Load media to a playlist.
2. Unmount the device containing media.
3. Check if the user is notified of the location being inaccessible
   --yes, the user is notified
4. Mount the device containing media and play a media from playlist.
   -- The media plays properly.


File Attachments (updated)


wihtout_i18n.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/06/05/3dc148a5-c4da-4d27-a713-e63922cbcef8__wihtout_i18n.png


Thanks,

R.Harish  Navnit

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118526: Provide i18nd wrappers in kdeclarative

[David Edmundson]

> On June 5, 2014, 8:29 a.m., David Edmundson wrote:
> > +1 from me.
> > The i18nd is definitely useful.
> > 
> > The setTranslationDomain isn't ideal, but there's no 100% nice solution to 
> > it.
> >

Brainstorming:

There is one other possible way we could have i18n automatically select the 
right catalog, even if you have imports from QML files all over the place.

 - define all i18n functions in javascript instead of C++
 - have them do something like
  function i18n(text) { i18nd(__catalogName, text);

then imports or applications or whatever need to declare a:
 readonly property string __catalogName: "catalogName"
somewhere in the root file qml file, as well as in any imported file.

Because JS would then be evaluating the catalog name, it would find the 
variable in the right scope, and thus the right catalogName.


- David


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


On June 4, 2014, 1:06 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118526/
> ---
> 
> (Updated June 4, 2014, 1:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Provide i18nd wrappers in kdeclarative
> 
> As QML might combine multiple modules with different cataloges we need
> to be able to specify the translation domain explicitly. If there is a
> need to use a specific domain for all i18n calls (e.g. in a library
> using QML) there is the possibility to set a global translation domain
> through KDeclarative. If such a domain is set all i18n calls delegate
> to the i18nd variant.
> 
> Due to the nature of KDeclarative we cannot mix i18n calls with
> different domains. If two modules would require to set the translation
> domain it's bound to fail. Thus the recommendation is to use the i18nd
> variants in any QML code which is intended to be used as an import.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
>   src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
>   src/kdeclarative/private/kdeclarative_p.h 
> 6b61d123bf74671b413e4e68bf911bb969fdaf53 
>   src/kdeclarative/private/rootcontext.cpp 
> 12309b096495910b83ed1e388989042b45a1 
>   src/kdeclarative/private/rootcontext_p.h 
> 16694b155c668e11cf7a16549a18cdc89b81b3e2 
> 
> Diff: https://git.reviewboard.kde.org/r/118526/diff/
> 
> 
> Testing
> ---
> 
> adjusted kwineffects KCM and run it with the x-test language: the strings 
> with i18n from QML side are now picking up the translated strings.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118526: Provide i18nd wrappers in kdeclarative

[Martin Gräßlin]

> On June 5, 2014, 10:29 a.m., David Edmundson wrote:
> > +1 from me.
> > The i18nd is definitely useful.
> > 
> > The setTranslationDomain isn't ideal, but there's no 100% nice solution to 
> > it.
> >
> 
> David Edmundson wrote:
> Brainstorming:
> 
> There is one other possible way we could have i18n automatically select 
> the right catalog, even if you have imports from QML files all over the place.
> 
>  - define all i18n functions in javascript instead of C++
>  - have them do something like
>   function i18n(text) { i18nd(__catalogName, text);
> 
> then imports or applications or whatever need to declare a:
>  readonly property string __catalogName: "catalogName"
> somewhere in the root file qml file, as well as in any imported file.
> 
> Because JS would then be evaluating the catalog name, it would find the 
> variable in the right scope, and thus the right catalogName.
>

it has a disadvantage: if one uses the QML in an application one doesn't want 
the i18n calls to go through i18nd as KLocalizedString::setApplicationDomain 
was called.


- Martin


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


On June 4, 2014, 3:06 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118526/
> ---
> 
> (Updated June 4, 2014, 3:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Provide i18nd wrappers in kdeclarative
> 
> As QML might combine multiple modules with different cataloges we need
> to be able to specify the translation domain explicitly. If there is a
> need to use a specific domain for all i18n calls (e.g. in a library
> using QML) there is the possibility to set a global translation domain
> through KDeclarative. If such a domain is set all i18n calls delegate
> to the i18nd variant.
> 
> Due to the nature of KDeclarative we cannot mix i18n calls with
> different domains. If two modules would require to set the translation
> domain it's bound to fail. Thus the recommendation is to use the i18nd
> variants in any QML code which is intended to be used as an import.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
>   src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
>   src/kdeclarative/private/kdeclarative_p.h 
> 6b61d123bf74671b413e4e68bf911bb969fdaf53 
>   src/kdeclarative/private/rootcontext.cpp 
> 12309b096495910b83ed1e388989042b45a1 
>   src/kdeclarative/private/rootcontext_p.h 
> 16694b155c668e11cf7a16549a18cdc89b81b3e2 
> 
> Diff: https://git.reviewboard.kde.org/r/118526/diff/
> 
> 
> Testing
> ---
> 
> adjusted kwineffects KCM and run it with the x-test language: the strings 
> with i18n from QML side are now picking up the translated strings.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118406: Notify the user if the location containing the media is inaccessible.

[Thomas Pfeiffer]

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


Usability review:
Since I lack the skills to picture it from the diff: When exactly is the 
notification shown? Is it shown as soon as the media is supposed to be played? 
If so, I think it could be done in a more subtle way: Grey out the entry in the 
playlist and just skip over it to the next entry int he playlist (like Amarok 
does) and show the message in a tooltip on mouseover on a pointer device or on 
tap on a touch device.
If it's already done in a similar way, then it's fine for me ;)

- Thomas Pfeiffer


On June 3, 2014, 5:05 p.m., R.Harish  Navnit wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118406/
> ---
> 
> (Updated June 3, 2014, 5:05 p.m.)
> 
> 
> Review request for Plasma, Shantanu Tushar and Sinny Kumari.
> 
> 
> Bugs: 333764
> http://bugs.kde.org/show_bug.cgi?id=333764
> 
> 
> Repository: plasma-mediacenter
> 
> 
> Description
> ---
> 
> If a media(in a playlist) is located in an inaccessible location, then the 
> user is notified about the same. 
> 
> 
> Diffs
> -
> 
>   mediaelements/mediaplayer/MediaPlayer.qml 98f1d2c 
> 
> Diff: https://git.reviewboard.kde.org/r/118406/diff/
> 
> 
> Testing
> ---
> 
> 1. Load media to a playlist.
> 2. Unmount the device containing media.
> 3. Check if the user is notified of the location being inaccessible
>--yes, the user is notified
> 4. Mount the device containing media and play a media from playlist.
>-- The media plays properly.
> 
> 
> Thanks,
> 
> R.Harish  Navnit
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118526: Provide i18nd wrappers in kdeclarative

[Martin Gräßlin]

> On June 5, 2014, 10:29 a.m., David Edmundson wrote:
> > src/kdeclarative/kdeclarative.cpp, line 120
> > 
> >
> > Can we warn if this is already set to something else.
> > 
> > If two QML files try to do it to different paths it means something has 
> > gone horribly wrong (or is just about to).

As the method is only supposed to be called before setupBindings I'm not sure 
whether a warning will help anything. @Marco: your opinion on it?


- Martin


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


On June 4, 2014, 3:06 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118526/
> ---
> 
> (Updated June 4, 2014, 3:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Provide i18nd wrappers in kdeclarative
> 
> As QML might combine multiple modules with different cataloges we need
> to be able to specify the translation domain explicitly. If there is a
> need to use a specific domain for all i18n calls (e.g. in a library
> using QML) there is the possibility to set a global translation domain
> through KDeclarative. If such a domain is set all i18n calls delegate
> to the i18nd variant.
> 
> Due to the nature of KDeclarative we cannot mix i18n calls with
> different domains. If two modules would require to set the translation
> domain it's bound to fail. Thus the recommendation is to use the i18nd
> variants in any QML code which is intended to be used as an import.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
>   src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
>   src/kdeclarative/private/kdeclarative_p.h 
> 6b61d123bf74671b413e4e68bf911bb969fdaf53 
>   src/kdeclarative/private/rootcontext.cpp 
> 12309b096495910b83ed1e388989042b45a1 
>   src/kdeclarative/private/rootcontext_p.h 
> 16694b155c668e11cf7a16549a18cdc89b81b3e2 
> 
> Diff: https://git.reviewboard.kde.org/r/118526/diff/
> 
> 
> Testing
> ---
> 
> adjusted kwineffects KCM and run it with the x-test language: the strings 
> with i18n from QML side are now picking up the translated strings.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118526: Provide i18nd wrappers in kdeclarative

[David Edmundson]

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


+1 from me.
The i18nd is definitely useful.

The setTranslationDomain isn't ideal, but there's no 100% nice solution to it.



src/kdeclarative/kdeclarative.cpp


Can we warn if this is already set to something else.

If two QML files try to do it to different paths it means something has 
gone horribly wrong (or is just about to).


- David Edmundson


On June 4, 2014, 1:06 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118526/
> ---
> 
> (Updated June 4, 2014, 1:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Provide i18nd wrappers in kdeclarative
> 
> As QML might combine multiple modules with different cataloges we need
> to be able to specify the translation domain explicitly. If there is a
> need to use a specific domain for all i18n calls (e.g. in a library
> using QML) there is the possibility to set a global translation domain
> through KDeclarative. If such a domain is set all i18n calls delegate
> to the i18nd variant.
> 
> Due to the nature of KDeclarative we cannot mix i18n calls with
> different domains. If two modules would require to set the translation
> domain it's bound to fail. Thus the recommendation is to use the i18nd
> variants in any QML code which is intended to be used as an import.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/kdeclarative.h b4a274b710f4de7ffbfc275d1e9a0a93be283053 
>   src/kdeclarative/kdeclarative.cpp a35dac5cfbd42e75e892d4ad88c491345be4a1b0 
>   src/kdeclarative/private/kdeclarative_p.h 
> 6b61d123bf74671b413e4e68bf911bb969fdaf53 
>   src/kdeclarative/private/rootcontext.cpp 
> 12309b096495910b83ed1e388989042b45a1 
>   src/kdeclarative/private/rootcontext_p.h 
> 16694b155c668e11cf7a16549a18cdc89b81b3e2 
> 
> Diff: https://git.reviewboard.kde.org/r/118526/diff/
> 
> 
> Testing
> ---
> 
> adjusted kwineffects KCM and run it with the x-test language: the strings 
> with i18n from QML side are now picking up the translated strings.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118547: Expose Formats as singleton

[David Edmundson]

> On June 5, 2014, 3:44 a.m., Bhushan Shah wrote:
> > src/qmlcontrols/kcoreaddons/kcoreaddonsplugin.cpp, line 40
> > 
> >
> > Err no, this will fail when using formatRelativeDate and 
> > formatRelativeDateTime

good catch. That was an accidental delete


- David


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


On June 5, 2014, 12:03 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118547/
> ---
> 
> (Updated June 5, 2014, 12:03 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Expose Formats as singleton
> 
> Formats is basically just a collection of invokable static methods.
> This saves creating a few objects and makes for a a nicer API.
> 
> Without it you have to have a bit of code like:
> 
> -KCoreAddons.Formats {
> -id: formats
> -}
> then do text:formats.formatData(...) in your labels
> 
> this becomes now
> 
> KCoreAddons.Format.formatData(...) 
> 
> 
> Diffs
> -
> 
>   src/qmlcontrols/kcoreaddons/kcoreaddonsplugin.cpp 65dd75f 
> 
> Diff: https://git.reviewboard.kde.org/r/118547/diff/
> 
> 
> Testing
> ---
> 
> Made the two changes needed in plasma-workspace. Everything seemed to be ok.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel