kdereview: breeze-grub & breeze-plymouth

[Harald Sitter]

Salut!

As mentioned yesterday by Andreas Kainz, the VDG is working on a
unified design from boot to shutdown. To facilitate this we started
working on a GRUB and Plymouth theme that can now be found in
kdereview for your review pleasure.

GRUB is ready for review.
Plymouth is still in development as the design is not finalized.

It was suggested that we release both alongside Plasma so we can
easily enable distributions to brand coherent theme versions and don't
have to jump through git to find matching revisions of grub/plymouth
themes, hence the reviewing.

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

Re: Review Request 126151: Port avatar gallery from kcm_useraccounts to user-manager

[Marco Martin]

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


Ship it!




Ship It!

- Marco Martin


On Nov. 23, 2015, 9:50 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126151/
> ---
> 
> (Updated Nov. 23, 2015, 9:50 p.m.)
> 
> 
> Review request for Plasma, KDE Usability and Jonathan Riddell.
> 
> 
> Bugs: 354001
> http://bugs.kde.org/show_bug.cgi?id=354001
> 
> 
> Repository: user-manager
> 
> 
> Description
> ---
> 
> Including the avatars, that are no longer installed into /usr/share/kdm/icons 
> but /usr/share/user-manager/avatars. I don't know if there's a FDO location 
> for these.
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt 7267d24 
>   src/accountinfo.h c6e70b3 
>   src/accountinfo.cpp 878f683 
>   src/avatargallery.h PRE-CREATION 
>   src/avatargallery.cpp PRE-CREATION 
>   src/avatargallery.ui PRE-CREATION 
>   src/pics/Ada Lovelace.png PRE-CREATION 
>   src/pics/Alice in Wonderland.png PRE-CREATION 
>   src/pics/Blackbox.png PRE-CREATION 
>   src/pics/CMakeLists.txt PRE-CREATION 
>   src/pics/Dragon.png PRE-CREATION 
>   src/pics/Grace Hopper.png PRE-CREATION 
>   src/pics/Green.png PRE-CREATION 
>   src/pics/Happy.png PRE-CREATION 
>   src/pics/Kati.png PRE-CREATION 
>   src/pics/Konqui.png PRE-CREATION 
>   src/pics/Leonardo da Vinci.png PRE-CREATION 
>   src/pics/Listening.png PRE-CREATION 
>   src/pics/Logger.png PRE-CREATION 
>   src/pics/Mahatma Gandhi.png PRE-CREATION 
>   src/pics/Mowgli jungle book.png PRE-CREATION 
>   src/pics/Notme.png PRE-CREATION 
>   src/pics/Parley.png PRE-CREATION 
>   src/pics/Rekonqui.png PRE-CREATION 
>   src/pics/TV.png PRE-CREATION 
>   src/pics/User.png PRE-CREATION 
>   src/pics/bomb.png PRE-CREATION 
>   src/pics/sources/Ada Lovelace.svg PRE-CREATION 
>   src/pics/sources/Alice in Wonderland.svg PRE-CREATION 
>   src/pics/sources/Dragon.svg PRE-CREATION 
>   src/pics/sources/Grace Hopper.svg PRE-CREATION 
>   src/pics/sources/Kati.svg PRE-CREATION 
>   src/pics/sources/Konqui.svg PRE-CREATION 
>   src/pics/sources/Leonardo da Vinci.svg PRE-CREATION 
>   src/pics/sources/Logger.svg PRE-CREATION 
>   src/pics/sources/Mahatma Gandhi.svg PRE-CREATION 
>   src/pics/sources/Mowgli jungle book.svg PRE-CREATION 
>   src/pics/sources/Parley.svg PRE-CREATION 
>   src/pics/sources/Rekonqui.svg PRE-CREATION 
>   src/pics/sources/User.svg PRE-CREATION 
>   src/pics/sources/blackbox.svgz PRE-CREATION 
>   src/pics/sources/bomb.svgz PRE-CREATION 
>   src/pics/sources/green.svgz PRE-CREATION 
>   src/pics/sources/happy.svgz PRE-CREATION 
>   src/pics/sources/listening.svgz PRE-CREATION 
>   src/pics/sources/notme.svgz PRE-CREATION 
>   src/pics/sources/tv.svgz PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126151/diff/
> 
> 
> Testing
> ---
> 
> Opened user manager, clicked my icon, clicked "Choose from Gallery", chose an 
> icon, OK. It prompted me three times for Polkit authentication for some 
> reason but in the end it worked, Kickoff also immediately updated its icon.
> 
> 
> File Attachments
> 
> 
> New menu option
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/11/23/d91c818f-5051-4857-beb2-b2727614f187__usermanageravatar.png
> Avatar gallery
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/11/23/2f16fa25-5eac-4e6a-b24d-7d47ff560ce4__usermanageravatar2.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Review Request 127112: Reparse svgElementsCache instead of deleting it in discardCache

[David Rosca]

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

Review request for Plasma.


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


Repository: plasma-framework


Description
---

svgElementsCache may be created on render thread and deleted on main thread, 
which will make KSharedConfig crash (it uses per-thread storage).


Diffs
-

  src/plasma/private/theme_p.h 69a8934 
  src/plasma/private/theme_p.cpp 2faced8 

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


Testing
---

I couldn't reproduce the crash, even with QSG_RENDER_LOOP=threaded (on Intel 
GPU).

I think we can't just call reparseConfiguration in discardCache, because there 
will be race condititon (reparseConfiguration running on main thread and config 
being accessed from render thread).


Thanks,

David Rosca

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

Re: Review Request 127079: fix uninitialised var

[David Edmundson]

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

(Updated Feb. 19, 2016, 11:46 a.m.)


Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

Valgrind pointed this out whilst debugging something else.

(though I'm not sure what on the desktop creates an Application object)


Diffs (updated)
-

  src/declarativeimports/platformcomponents/application.cpp 
a3aecc4a13541d41136fd0b34e58b3107eda060f 

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


Testing
---


Thanks,

David Edmundson

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

Re: Review Request 127112: Reparse svgElementsCache instead of deleting it in discardCache

[Marco Martin]

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


Ship it!




Ship It!

- Marco Martin


On Feb. 19, 2016, 11:34 a.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127112/
> ---
> 
> (Updated Feb. 19, 2016, 11:34 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 359539
> http://bugs.kde.org/show_bug.cgi?id=359539
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> svgElementsCache may be created on render thread and deleted on main thread, 
> which will make KSharedConfig crash (it uses per-thread storage).
> 
> 
> Diffs
> -
> 
>   src/plasma/private/theme_p.h 69a8934 
>   src/plasma/private/theme_p.cpp 2faced8 
> 
> Diff: https://git.reviewboard.kde.org/r/127112/diff/
> 
> 
> Testing
> ---
> 
> I couldn't reproduce the crash, even with QSG_RENDER_LOOP=threaded (on Intel 
> GPU).
> 
> I think we can't just call reparseConfiguration in discardCache, because 
> there will be race condititon (reparseConfiguration running on main thread 
> and config being accessed from render thread).
> 
> 
> Thanks,
> 
> David Rosca
> 
>

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

Re: Review Request 127112: Reparse svgElementsCache instead of deleting it in discardCache

[David Rosca]

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

(Updated Feb. 19, 2016, 11:56 a.m.)


Review request for Plasma.


Changes
---

Now that I think about it again, the race condition doesn't really matter here. 
It won't be the only place where the shared config would be accessed from 
different threads.

Just from a quick look:
IconItem - queries theme in updatePolish = main thread
SvgItem - queries theme in updatePaintNode = render thread

So I think we should fix the other items with this in mind = don't access 
Plasma::Theme from render thread.


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


Repository: plasma-framework


Description
---

svgElementsCache may be created on render thread and deleted on main thread, 
which will make KSharedConfig crash (it uses per-thread storage).


Diffs (updated)
-

  src/plasma/private/theme_p.cpp 2faced8 

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


Testing
---

I couldn't reproduce the crash, even with QSG_RENDER_LOOP=threaded (on Intel 
GPU).

I think we can't just call reparseConfiguration in discardCache, because there 
will be race condititon (reparseConfiguration running on main thread and config 
being accessed from render thread).


Thanks,

David Rosca

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

Re: Review Request 127073: AppletQuickItem: Fix finding own attached layout

[David Edmundson]

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


Fix it, then Ship it!





src/plasmaquick/appletquickitem.cpp (lines 572 - 573)


can you get rid of this. 

I think it's trying to do what your patch does, only it doesn't work. 
(p.isValid() is always false)


- David Edmundson


On Feb. 13, 2016, 11:48 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127073/
> ---
> 
> (Updated Feb. 13, 2016, 11:48 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 358849
> http://bugs.kde.org/show_bug.cgi?id=358849
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Regression from 344dbeb938
> 
> BUG: 358849
> 
> 
> Diffs
> -
> 
>   src/plasmaquick/appletquickitem.h 1e0174a 
>   src/plasmaquick/appletquickitem.cpp 28f1eb5 
>   src/plasmaquick/private/appletquickitem_p.h 1f99d2f 
> 
> Diff: https://git.reviewboard.kde.org/r/127073/diff/
> 
> 
> Testing
> ---
> 
> Fixed for example plasmoid from bug.
> Would be better if there was a way to fix it without adding another timer, 
> though.
> 
> 
> Thanks,
> 
> David Rosca
> 
>

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

Re: RFC: Put notifications in sidepanel like widget explorer

[Thomas Pfeiffer]

On Donnerstag, 18. Februar 2016 11:28:27 CET Marco Martin wrote:
> On Thursday 18 February 2016 02:03:08 Thomas Pfeiffer wrote:
> > The thing is: When you open the popup, your attention is focused on it,
> > anyway, regardless of its size. It would feel clunky if we opened it with
> > a
> > long animation like we still do far too often in Plasma, but if it opened
> > and closed quickly enough, I'm convinced that the benefit of not having to
> > scroll so much would outweigh the "cost" of it covering more of the screen
> > which you don't have your attention on anyway.
> 
> I don't think the cost is much the increased screen usage.
> I think the major cost is having the overwhelm of all the information at
> once fitted in that sidebar.
> 
> We can have 2 scenarios:
> a) all the information  at once (ie all plasmoids open in the side panel: it
> would be cluttered beyond imaginable (and no, you can't control too much
> what's inside the single modules so if one goes this way it *will* be an
> information orgy, no mattter how hard you try to impose design on the
> single modules)
> 
> b) all possible thing still by itself, tabbed interface or whatever, so
> notifications alone, networkmanager alone etc. in most cases the sidebar
> will be a desolation of emptyness (with possible increased mouse travel
> distance even)

I would really encourage you (and everyone else who is skeptical about our 
suggestion) to give deepin or Budgie a quick try (they each have their own 
distros, but are available on other distros like Arch as well, and Manjaro has 
community spins for both).
(Don't worry, I wouldn't dare asking you to try out Windows 10, though ;) )

They both have a quite powerful sidebar (they both actually do their whole 
system configuration in there, which I find a bit extreme, but it seems to be 
working out pretty well for them).

Just for a quick glance, feel free to look at this screenshot from the Budgie 
sidebar:
http://i1-news.softpedia-static.com/images/news2/solus-linux-os-gets-new-daily-iso-budgie-next-improvements-updated-installer-496874-2.jpg

The first columns shows applets, the second shows notifications. Both of those 
look neither "cluttered beyond imaginable" nor like "a desolation of 
emptyness" to me.

I can fully understand the fear that it may look too full or too empty, but to 
me, Budge and deepin are living proof that a sidebar can be designed in a way 
that it doesn't.

Also, our task/Activity switcher sidebar doesn't look desolate to me if there 
are only two tasks/Activities to switch between, either.

> Note that since I'm rewriting the systray from scratch, I'm quite affected
> by wether the decision is, I need to take the "proper" architecture, I
> don't want to rewrite it a 3rd time that's for sure!

Yes, you're absolutely right. If there is a time to decide this, it's 
definitely now!
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 127073: AppletQuickItem: Fix finding own attached layout

[David Rosca]

> On Feb. 19, 2016, 12:02 p.m., David Edmundson wrote:
> > src/plasmaquick/appletquickitem.cpp, lines 572-573
> > 
> >
> > can you get rid of this. 
> > 
> > I think it's trying to do what your patch does, only it doesn't work. 
> > (p.isValid() is always false)

Yes, I guess it tries to create the Layout, but it doesn't really work. I think 
it was valid for some items when I tested it, but it still didn't have any 
effect.


- David


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


On Feb. 13, 2016, 11:48 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127073/
> ---
> 
> (Updated Feb. 13, 2016, 11:48 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 358849
> http://bugs.kde.org/show_bug.cgi?id=358849
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Regression from 344dbeb938
> 
> BUG: 358849
> 
> 
> Diffs
> -
> 
>   src/plasmaquick/appletquickitem.h 1e0174a 
>   src/plasmaquick/appletquickitem.cpp 28f1eb5 
>   src/plasmaquick/private/appletquickitem_p.h 1f99d2f 
> 
> Diff: https://git.reviewboard.kde.org/r/127073/diff/
> 
> 
> Testing
> ---
> 
> Fixed for example plasmoid from bug.
> Would be better if there was a way to fix it without adding another timer, 
> though.
> 
> 
> Thanks,
> 
> David Rosca
> 
>

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

Re: Review Request 127112: Reparse svgElementsCache instead of deleting it in discardCache

[David Rosca]

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

(Updated Feb. 19, 2016, 12:27 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit a8e54e15e13653290ca4a49a38fae742e3825d04 by David Rosca 
to branch master.


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


Repository: plasma-framework


Description
---

svgElementsCache may be created on render thread and deleted on main thread, 
which will make KSharedConfig crash (it uses per-thread storage).


Diffs
-

  src/plasma/private/theme_p.cpp 2faced8 

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


Testing
---

I couldn't reproduce the crash, even with QSG_RENDER_LOOP=threaded (on Intel 
GPU).

I think we can't just call reparseConfiguration in discardCache, because there 
will be race condititon (reparseConfiguration running on main thread and config 
being accessed from render thread).


Thanks,

David Rosca

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

Re: Review Request 127073: AppletQuickItem: Fix finding own attached layout

[David Rosca]

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

(Updated Feb. 19, 2016, 12:27 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 82e172cc9e96bb530a591310ba6d8c294dc9f597 by David Rosca 
to branch master.


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


Repository: plasma-framework


Description
---

Regression from 344dbeb938

BUG: 358849


Diffs
-

  src/plasmaquick/appletquickitem.h 1e0174a 
  src/plasmaquick/appletquickitem.cpp 28f1eb5 
  src/plasmaquick/private/appletquickitem_p.h 1f99d2f 

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


Testing
---

Fixed for example plasmoid from bug.
Would be better if there was a way to fix it without adding another timer, 
though.


Thanks,

David Rosca

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

Re: RFC: Put notifications in sidepanel like widget explorer

[Marco Martin]

On Friday 19 February 2016 13:06:28 Thomas Pfeiffer wrote:
> They both have a quite powerful sidebar (they both actually do their whole
> system configuration in there, which I find a bit extreme, but it seems to
> be working out pretty well for them).
> 
> Just for a quick glance, feel free to look at this screenshot from the
> Budgie sidebar:
> http://i1-news.softpedia-static.com/images/news2/solus-linux-os-gets-new-dai
> ly-iso-budgie-next-improvements-updated-installer-496874-2.jpg

Apart that he has my approval for the choice of music :p, I really feel this 
proves *exactly* what I was fearing:
The first column is really, really cluttered. It's pretty much the image and 
reputation KDE software has been fighting the past 10+ years to get away from, 
I would find this really a step in the opposite direction to what we should go.

Imagine it from the UX perspective: I want to connect to a wifi network, I see 
the wifi icon shows it's not connected, I click it and I am presented with the 
first column... whhaaat? i then have to search for a while that in the middle 
of all that stuff oh yeah, there are wifi settings as well.. phew! (and the 
"simple by default" just flew out of the window, just because we feel is safer 
to follow instead than to lead [1])

While the second column is indeed desolately empty (in that case, having by 
default the panel at the bottom, has an huge mouse travel distance (can be 
flipped in this case, but then you have an huge empty area at the top that 
looks really sore)

And what if the systray is not at the bottom-right or top-right of the screen?
the visual disconnect grows even more.

To me it really seems a case of OSX does that [1], therefore is correct

>> Note that since I'm rewriting the systray from scratch, I'm quite affected
>> by wether the decision is, I need to take the "proper" architecture, I
>> don't want to rewrite it a 3rd time that's for sure!
>
>Yes, you're absolutely right. If there is a time to decide this, it's 
>definitely now!

btw with the new architecture (that is almost ready and I want to merge like 
the day after of 5.6 branching) it would be "slightly" easier to do something 
like that, even tough not without significant challenges.

[1] 
http://www.macworld.com/article/2364274/hands-on-with-os-x-yosemite-widgets-by-any-other-name.html

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

Re: Review Request 127035: Show Frameworks version next to Qt Version

[David Edmundson]

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

(Updated Feb. 19, 2016, 12:57 p.m.)


Review request for Plasma.


Repository: kinfocenter


Description
---

Show Frameworks version next to Qt Version


Diffs
-

  Modules/about-distro/src/Module.cpp bec3a3668d907f2ea3ad494a168a451e3c5e7da3 
  Modules/about-distro/src/Module.ui ec87d8756b726dec9831ae92368afbe0ca1dada4 

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


Testing
---


File Attachments (updated)


snapshot_KP3549.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/02/19/798899cf-d050-40c7-99ea-43de239661e0__snapshot_KP3549.png


Thanks,

David Edmundson

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

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

[Daniel Faust]

> On Feb. 18, 2016, 1:05 vorm., David Edmundson wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, line 555
> > 
> >
> > rather than looping, can we use FontMetric's maximumCharacterWidth
> > 
> >  * numChars.
> > 
> > Then we could kill sizeHelper competely (FontMetric's didn't exist when 
> > this was written)
> 
> Marco Martin wrote:
> hoping maximumCharacterWidth is reliable for all fonts, this loop really 
> needs to go
> 
> Daniel Faust wrote:
> As far as I understand maximumCharacterWidth returns the width of the 
> widest character of the font - which can be ridiculously wide given that the 
> font supports some wild unicode characters.
> I did a quick test and maximumCharacterWidth returned about twice the 
> width actually needed.
> 
> Martin Klapetek wrote:
> You still don't need this whole loop though, just find the biggest in 0-9 
> and use that for all the numbers (except year).
> 
> Daniel Faust wrote:
> Since I don't know the time format in advance, I have to construct 
> different times and process them with Qt.formatTime.
> That means, I have to test 0-9 for hours/minutes/seconds, 0-2 for tens of 
> hours and 0-5 for tens of minutes/seconds. Otherwise the constructed times 
> will be invalid.
> This can be done with three loops and it would bring down the amount of 
> advanceWidth and formatTime calls from 24+60=84 to 3+6+10=19.
> 
> Martin Klapetek wrote:
> You don't actually need them as a time, you just need them as a 
> placeholder. At which point it doesn't matter if it's a valid time or not. 
> You can even format 12:12 with Qt.formatTime and then replace the numbers 
> with your placeholder number.
> 
> In other words, the time format /is/ known in advance.
> 
> Daniel Faust wrote:
> I'm not sure if I understand you, I just tried it with a single loop from 
> 0-9 to construct the time strings:
> 
> for (var i=0; i<=9; i++) {
>   var str = Qt.formatTime(new Date(2000, 0, 1, i*10 + i, i*10 + i, i*10 + 
> i), main.timeFormat);
>   console.log("hour: " + (i*10 + i) + ", minute: " + (i*10 + i) + " -> " 
> + str);
> }
> 
> qml: hour: 0, minute: 0 -> 00:00
> qml: hour: 11, minute: 11 -> 11:11
> qml: hour: 22, minute: 22 -> 22:22
> qml: hour: 33, minute: 33 -> 09:33
> qml: hour: 44, minute: 44 -> 20:44
> qml: hour: 55, minute: 55 -> 07:55
> qml: hour: 66, minute: 66 -> 19:07
> qml: hour: 77, minute: 77 -> 06:18
> qml: hour: 88, minute: 88 -> 17:29
> qml: hour: 99, minute: 99 -> 04:40
> 
> Thomas Lübking wrote:
> Forget about the timeFormat - you iterate from 0-9 and figure the widest 
> glyphs in [0,1], [0,5] and [0,9] - let's reasonably say "0,3 and 7".
> Then you check the width for 00:37
> 
> (If you also need the date, you also need to check for the widest glyph 
> in [0,3])

That would work if it wasn't for 12 hour time formats.
For 24 hour formats you actually need [0,2], [0,3] and [0,9] for the hour and 
[0,5] and [0,9] for the minutes/seconds.
For 12 hour formats AM you need [0,1], [0,2] and [0,9] for the hour and [0,5] 
and [0,9] for the minutes/seconds.
For 12 hour formats PM you need [1,2], [3,9] and [0,3] for the hour and [0,5] 
and [0,9] for the minutes/seconds.
On top of that you need to account for format changes like hour=0, minute=0 -> 
"12:00 AM".

The code for this logic would be hard to maintain.


- Daniel


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


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

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

[Daniel Faust]

> On Feb. 18, 2016, 1:05 vorm., David Edmundson wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, line 555
> > 
> >
> > rather than looping, can we use FontMetric's maximumCharacterWidth
> > 
> >  * numChars.
> > 
> > Then we could kill sizeHelper competely (FontMetric's didn't exist when 
> > this was written)
> 
> Marco Martin wrote:
> hoping maximumCharacterWidth is reliable for all fonts, this loop really 
> needs to go
> 
> Daniel Faust wrote:
> As far as I understand maximumCharacterWidth returns the width of the 
> widest character of the font - which can be ridiculously wide given that the 
> font supports some wild unicode characters.
> I did a quick test and maximumCharacterWidth returned about twice the 
> width actually needed.
> 
> Martin Klapetek wrote:
> You still don't need this whole loop though, just find the biggest in 0-9 
> and use that for all the numbers (except year).
> 
> Daniel Faust wrote:
> Since I don't know the time format in advance, I have to construct 
> different times and process them with Qt.formatTime.
> That means, I have to test 0-9 for hours/minutes/seconds, 0-2 for tens of 
> hours and 0-5 for tens of minutes/seconds. Otherwise the constructed times 
> will be invalid.
> This can be done with three loops and it would bring down the amount of 
> advanceWidth and formatTime calls from 24+60=84 to 3+6+10=19.
> 
> Martin Klapetek wrote:
> You don't actually need them as a time, you just need them as a 
> placeholder. At which point it doesn't matter if it's a valid time or not. 
> You can even format 12:12 with Qt.formatTime and then replace the numbers 
> with your placeholder number.
> 
> In other words, the time format /is/ known in advance.
> 
> Daniel Faust wrote:
> I'm not sure if I understand you, I just tried it with a single loop from 
> 0-9 to construct the time strings:
> 
> for (var i=0; i<=9; i++) {
>   var str = Qt.formatTime(new Date(2000, 0, 1, i*10 + i, i*10 + i, i*10 + 
> i), main.timeFormat);
>   console.log("hour: " + (i*10 + i) + ", minute: " + (i*10 + i) + " -> " 
> + str);
> }
> 
> qml: hour: 0, minute: 0 -> 00:00
> qml: hour: 11, minute: 11 -> 11:11
> qml: hour: 22, minute: 22 -> 22:22
> qml: hour: 33, minute: 33 -> 09:33
> qml: hour: 44, minute: 44 -> 20:44
> qml: hour: 55, minute: 55 -> 07:55
> qml: hour: 66, minute: 66 -> 19:07
> qml: hour: 77, minute: 77 -> 06:18
> qml: hour: 88, minute: 88 -> 17:29
> qml: hour: 99, minute: 99 -> 04:40
> 
> Thomas Lübking wrote:
> Forget about the timeFormat - you iterate from 0-9 and figure the widest 
> glyphs in [0,1], [0,5] and [0,9] - let's reasonably say "0,3 and 7".
> Then you check the width for 00:37
> 
> (If you also need the date, you also need to check for the widest glyph 
> in [0,3])
> 
> Daniel Faust wrote:
> That would work if it wasn't for 12 hour time formats.
> For 24 hour formats you actually need [0,2], [0,3] and [0,9] for the hour 
> and [0,5] and [0,9] for the minutes/seconds.
> For 12 hour formats AM you need [0,1], [0,2] and [0,9] for the hour and 
> [0,5] and [0,9] for the minutes/seconds.
> For 12 hour formats PM you need [1,2], [3,9] and [0,3] for the hour and 
> [0,5] and [0,9] for the minutes/seconds.
> On top of that you need to account for format changes like hour=0, 
> minute=0 -> "12:00 AM".
> 
> The code for this logic would be hard to maintain.

Ok, what about this?
Find the widest glyph between 0 and 9.
Use a regex to replace [hmsz] from the format string with the widest number. 
(This will produce strings like "44:44")
Use Qt.formatTime once with an AM time and once with a PM time and choose the 
widest of the produced strings.
This code is fairly short and overestimates the total width only slightly.


- Daniel


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


On Feb. 17, 2016, 5:23 nachm., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127102/
> ---
> 
> (Updated Feb. 17, 2016, 5:23 nachm.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Bugs: 347724
> https://bugs.kde.org/show_bug.cgi?id=347724
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the width of the date label is not fixed but changes depending on 
> the text. This causes the entire applet to change its width (if the time is 
> the widest displayed item). This in turn can cause all other applets in the 
> same panel t

Re: Review Request 127035: Show Frameworks version next to Qt Version

[Martin Gräßlin]

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


Ship it!




Ship It!

- Martin Gräßlin


On Feb. 19, 2016, 1:57 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127035/
> ---
> 
> (Updated Feb. 19, 2016, 1:57 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: kinfocenter
> 
> 
> Description
> ---
> 
> Show Frameworks version next to Qt Version
> 
> 
> Diffs
> -
> 
>   Modules/about-distro/src/Module.cpp 
> bec3a3668d907f2ea3ad494a168a451e3c5e7da3 
>   Modules/about-distro/src/Module.ui ec87d8756b726dec9831ae92368afbe0ca1dada4 
> 
> Diff: https://git.reviewboard.kde.org/r/127035/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> snapshot_KP3549.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/19/798899cf-d050-40c7-99ea-43de239661e0__snapshot_KP3549.png
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Review Request 127115: SvgItem: Don't use Plasma::Theme from rendering thread

[David Rosca]

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

Review request for Plasma.


Repository: plasma-framework


Description
---

Logic is similar to IconItem - rendered image is updated in updatePolish().


Diffs
-

  src/declarativeimports/core/svgitem.h 7f9e44c 
  src/declarativeimports/core/svgitem.cpp 849c85f 

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


Testing
---

scheduleImageUpdate() is called wherever m_textureChanged is set to true + when 
geometry changes, so it should be identical to old code.


Thanks,

David Rosca

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

Re: Review Request 127115: SvgItem: Don't use Plasma::Theme from rendering thread

[David Edmundson]

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


Fix it, then Ship it!





src/declarativeimports/core/svgitem.cpp (line 221)


if we move m_textureChanged = true into here we can remove it from 
everywhere else.

same for moving update() into scheduleImageUpdate()



src/declarativeimports/core/svgitem.cpp (line 227)


&& newGeometry.isValid()


- David Edmundson


On Feb. 19, 2016, 3:01 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127115/
> ---
> 
> (Updated Feb. 19, 2016, 3:01 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Logic is similar to IconItem - rendered image is updated in updatePolish().
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/svgitem.h 7f9e44c 
>   src/declarativeimports/core/svgitem.cpp 849c85f 
> 
> Diff: https://git.reviewboard.kde.org/r/127115/diff/
> 
> 
> Testing
> ---
> 
> scheduleImageUpdate() is called wherever m_textureChanged is set to true + 
> when geometry changes, so it should be identical to old code.
> 
> 
> Thanks,
> 
> David Rosca
> 
>

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

[Differential] [Request, 3 lines] D991: TaskManager: Don't use Plasma theme icons in task icon

[drosca (David Rosca)]

drosca created this revision.
drosca added reviewers: Plasma, hein.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.

REVISION SUMMARY
  Also disable animation for icon in tooltip (normal Plasma tooltips
  no longer have animated icon too).
  
  BUG: 359387

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

BRANCH
  tasks-iconitem (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D991

AFFECTED FILES
  applets/taskmanager/package/contents/ui/Task.qml
  applets/taskmanager/package/contents/ui/ToolTipDelegate.qml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, Plasma, hein
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: RFC: Put notifications in sidepanel like widget explorer

[Thomas Pfeiffer]

On Freitag, 19. Februar 2016 13:36:33 CET Marco Martin wrote:
> On Friday 19 February 2016 13:06:28 Thomas Pfeiffer wrote:
> > They both have a quite powerful sidebar (they both actually do their whole
> > system configuration in there, which I find a bit extreme, but it seems to
> > be working out pretty well for them).
> > 
> > Just for a quick glance, feel free to look at this screenshot from the
> > Budgie sidebar:
> > http://i1-news.softpedia-static.com/images/news2/solus-linux-os-gets-new-d
> > ai ly-iso-budgie-next-improvements-updated-installer-496874-2.jpg
> 
> Apart that he has my approval for the choice of music :p, I really feel this
> proves *exactly* what I was fearing:
> The first column is really, really cluttered. It's pretty much the image and
> reputation KDE software has been fighting the past 10+ years to get away
> from, I would find this really a step in the opposite direction to what we
> should go.

Ask people how they see Budgie. I'm quite sure that "Cluttered" is not the 
impression the majority have of it. Really, give it a try. Not just showing 
them this screenshot, but ask them about the overall impression of the 
desktop.

> Imagine it from the UX perspective: I want to connect to a wifi network, I
> see the wifi icon shows it's not connected, I click it and I am presented
> with the first column... whhaaat? i then have to search for a while that in
> the middle of all that stuff oh yeah, there are wifi settings as well..
> phew! (and the "simple by default" just flew out of the window, just
> because we feel is safer to follow instead than to lead [1])

Yes, the first time you look at it, it might be a bit more difficult to find 
the 
module you're looking for, but since the modules stay at the same position, 
it's easy to remember them and soon, you know instantly where to look.

An important benefit of it is also that you need only one keyboard shortcut to 
open it and see everything.
Remembering the position of a module in a sidebar is much easier than 
remembering a different keyboard shortcut for every applet.
 
> While the second column is indeed desolately empty (in that case, having by
> default the panel at the bottom, has an huge mouse travel distance (can be
> flipped in this case, but then you have an huge empty area at the top that
> looks really sore)

Have you brought up that same concern against the task/Activity switcher 
sidebar? If not, you should, because it's the same situation.
 
> And what if the systray is not at the bottom-right or top-right of the
> screen? the visual disconnect grows even more.

True, but I've looked at enough "show your Plasma" screenshots to have a 
feeling that this is really a rare case.
 
> To me it really seems a case of OSX does that [1], therefore is correct

Only that Deepin had that sidebar since long before OSX had it. So who is 
leading and who is following now?

> >> Note that since I'm rewriting the systray from scratch, I'm quite
> >> affected
> >> by wether the decision is, I need to take the "proper" architecture, I
> >> don't want to rewrite it a 3rd time that's for sure!
> >
> >Yes, you're absolutely right. If there is a time to decide this, it's
> >definitely now!
> 
> btw with the new architecture (that is almost ready and I want to merge like
> the day after of 5.6 branching) it would be "slightly" easier to do
> something like that, even tough not without significant challenges.

Honestly: I'm not hell-bent on having a sidebar, to be honest. It would be 
great to allow users to have a sidebar, but we don't have to force it on 
everybody.

What I am hell-bent on, though, is not confining popups whose content are lists 
to a really small vertical space. You want UIs to feel less cluttered? Then 
having them cramped in a small-fixed size popup is certainly not the way to go.

Contact list, NM, Klipper, they would all greatly benefit from having more 
vertical space.
If we find a way to give them that which is not a sidebar, then I'm fine with 
that as well.

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

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

[Thomas Lübking]

> On Feb. 18, 2016, 12:05 a.m., David Edmundson wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, line 555
> > 
> >
> > rather than looping, can we use FontMetric's maximumCharacterWidth
> > 
> >  * numChars.
> > 
> > Then we could kill sizeHelper competely (FontMetric's didn't exist when 
> > this was written)
> 
> Marco Martin wrote:
> hoping maximumCharacterWidth is reliable for all fonts, this loop really 
> needs to go
> 
> Daniel Faust wrote:
> As far as I understand maximumCharacterWidth returns the width of the 
> widest character of the font - which can be ridiculously wide given that the 
> font supports some wild unicode characters.
> I did a quick test and maximumCharacterWidth returned about twice the 
> width actually needed.
> 
> Martin Klapetek wrote:
> You still don't need this whole loop though, just find the biggest in 0-9 
> and use that for all the numbers (except year).
> 
> Daniel Faust wrote:
> Since I don't know the time format in advance, I have to construct 
> different times and process them with Qt.formatTime.
> That means, I have to test 0-9 for hours/minutes/seconds, 0-2 for tens of 
> hours and 0-5 for tens of minutes/seconds. Otherwise the constructed times 
> will be invalid.
> This can be done with three loops and it would bring down the amount of 
> advanceWidth and formatTime calls from 24+60=84 to 3+6+10=19.
> 
> Martin Klapetek wrote:
> You don't actually need them as a time, you just need them as a 
> placeholder. At which point it doesn't matter if it's a valid time or not. 
> You can even format 12:12 with Qt.formatTime and then replace the numbers 
> with your placeholder number.
> 
> In other words, the time format /is/ known in advance.
> 
> Daniel Faust wrote:
> I'm not sure if I understand you, I just tried it with a single loop from 
> 0-9 to construct the time strings:
> 
> for (var i=0; i<=9; i++) {
>   var str = Qt.formatTime(new Date(2000, 0, 1, i*10 + i, i*10 + i, i*10 + 
> i), main.timeFormat);
>   console.log("hour: " + (i*10 + i) + ", minute: " + (i*10 + i) + " -> " 
> + str);
> }
> 
> qml: hour: 0, minute: 0 -> 00:00
> qml: hour: 11, minute: 11 -> 11:11
> qml: hour: 22, minute: 22 -> 22:22
> qml: hour: 33, minute: 33 -> 09:33
> qml: hour: 44, minute: 44 -> 20:44
> qml: hour: 55, minute: 55 -> 07:55
> qml: hour: 66, minute: 66 -> 19:07
> qml: hour: 77, minute: 77 -> 06:18
> qml: hour: 88, minute: 88 -> 17:29
> qml: hour: 99, minute: 99 -> 04:40
> 
> Thomas Lübking wrote:
> Forget about the timeFormat - you iterate from 0-9 and figure the widest 
> glyphs in [0,1], [0,5] and [0,9] - let's reasonably say "0,3 and 7".
> Then you check the width for 00:37
> 
> (If you also need the date, you also need to check for the widest glyph 
> in [0,3])
> 
> Daniel Faust wrote:
> That would work if it wasn't for 12 hour time formats.
> For 24 hour formats you actually need [0,2], [0,3] and [0,9] for the hour 
> and [0,5] and [0,9] for the minutes/seconds.
> For 12 hour formats AM you need [0,1], [0,2] and [0,9] for the hour and 
> [0,5] and [0,9] for the minutes/seconds.
> For 12 hour formats PM you need [1,2], [3,9] and [0,3] for the hour and 
> [0,5] and [0,9] for the minutes/seconds.
> On top of that you need to account for format changes like hour=0, 
> minute=0 -> "12:00 AM".
> 
> The code for this logic would be hard to maintain.
> 
> Daniel Faust wrote:
> Ok, what about this?
> Find the widest glyph between 0 and 9.
> Use a regex to replace [hmsz] from the format string with the widest 
> number. (This will produce strings like "44:44")
> Use Qt.formatTime once with an AM time and once with a PM time and choose 
> the widest of the produced strings.
> This code is fairly short and overestimates the total width only slightly.

As long as the formatter accepts invalid times, that's certainly the most 
straight forward solution, yes.


- Thomas


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


On Feb. 17, 2016, 4:23 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127102/
> ---
> 
> (Updated Feb. 17, 2016, 4:23 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Bugs: 347724
> https://bugs.kde.org/show_bug.cgi?id=347724
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the width of the date label is not fixed but changes depending on 
> the text

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

[Daniel Faust]

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

(Updated Feb. 19, 2016, 6:11 nachm.)


Review request for kde-workspace and Plasma.


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


Repository: plasma-workspace


Description
---

Currently the width of the date label is not fixed but changes depending on the 
text. This causes the entire applet to change its width (if the time is the 
widest displayed item). This in turn can cause all other applets in the same 
panel to move whenever the displayed time changes.

This patch uses FontMetrics to iterate over all possible time strings (with 
different width) and chooses the widest of them as reference for the fixed 
width of the time label.

This way the width of the applet stays the same (unless the date is displayed 
and changes). The text remains centered though, which means that it can still 
move within the applet when the time changes.


Diffs (updated)
-

  applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 

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


Testing
---

Works with horizontal and vertical panel.
Also displaying different combinations of "seconds", "date" and "timezone" 
works.


Thanks,

Daniel Faust

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

Re: Review Request 127115: SvgItem: Don't use Plasma::Theme from rendering thread

[David Rosca]

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

(Updated Feb. 19, 2016, 5:22 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 596fa082ddd065d216de794a9d9177d79e03b7a3 by David Rosca 
to branch master.


Repository: plasma-framework


Description
---

Logic is similar to IconItem - rendered image is updated in updatePolish().


Diffs
-

  src/declarativeimports/core/svgitem.h 7f9e44c 
  src/declarativeimports/core/svgitem.cpp 849c85f 

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


Testing
---

scheduleImageUpdate() is called wherever m_textureChanged is set to true + when 
geometry changes, so it should be identical to old code.


Thanks,

David Rosca

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

Re: kdereview: breeze-grub & breeze-plymouth

[Martin Klapetek]

Hi,

On Fri, Feb 19, 2016 at 3:43 AM, Harald Sitter  wrote:

> Salut!
>
> As mentioned yesterday by Andreas Kainz, the VDG is working on a
> unified design from boot to shutdown. To facilitate this we started
> working on a GRUB and Plymouth theme that can now be found in
> kdereview for your review pleasure.
>
> GRUB is ready for review.
> Plymouth is still in development as the design is not finalized.
>
> It was suggested that we release both alongside Plasma so we can
> easily enable distributions to brand coherent theme versions and don't
> have to jump through git to find matching revisions of grub/plymouth
> themes, hence the reviewing.
>

Are these the blue/last mockups from here:
https://forum.kde.org/viewtopic.php?f=285&t=130271 ?

I don't think this resembles "breeze" much (the screen-wide half-transparent
bar with that tiny line near the bottom). Should this whole set of design
be named
something else while the old ones are kept (somewhere) as "breeze"?

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: kdereview: breeze-grub & breeze-plymouth

[kainz.a]

hi

no the up to date stuff is in this wiki https://

community.kde.org

/KDE_Visual_Design_
Group
/
Unified
_Login
 and here
https://share.kde.org/index.php/s/ar8AoTUmMGNGOGf

there is no breeze grub or Plymouth theme but I don't have problems when
the unified design stuff had a new name you only have to be carefull to
maintain everything.

my name suggestion would be mailüfterl (
https://en.m.wikipedia.org/wiki/Mail%C3%BCfterl)

cheers
Andreas
Hi,

On Fri, Feb 19, 2016 at 3:43 AM, Harald Sitter  wrote:

> Salut!
>
> As mentioned yesterday by Andreas Kainz, the VDG is working on a
> unified design from boot to shutdown. To facilitate this we started
> working on a GRUB and Plymouth theme that can now be found in
> kdereview for your review pleasure.
>
> GRUB is ready for review.
> Plymouth is still in development as the design is not finalized.
>
> It was suggested that we release both alongside Plasma so we can
> easily enable distributions to brand coherent theme versions and don't
> have to jump through git to find matching revisions of grub/plymouth
> themes, hence the reviewing.
>

Are these the blue/last mockups from here:
https://forum.kde.org/viewtopic.php?f=285&t=130271 ?

I don't think this resembles "breeze" much (the screen-wide half-transparent
bar with that tiny line near the bottom). Should this whole set of design
be named
something else while the old ones are kept (somewhere) as "breeze"?

Cheers
-- 
Martin Klapetek | KDE Developer

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

Re: kdereview: breeze-grub & breeze-plymouth

[Martin Klapetek]

On Fri, Feb 19, 2016 at 3:24 PM, kainz.a  wrote:

> hi
>
> no the up to date stuff is in this wiki https://
> 
> community.kde.org
> 
> /KDE_Visual_Design_
> Group
> /
> Unified
> _Login
>  and
> here https://share.kde.org/index.php/s/ar8AoTUmMGNGOGf
>
> there is no breeze grub or Plymouth theme but I don't have problems when
> the unified design stuff had a new name you only have to be carefull to
> maintain everything.
>
> my name suggestion would be mailüfterl (
> https://en.m.wikipedia.org/wiki/Mail%C3%BCfterl)
>

Yeah, maybe something more like what the 98% of the world can pronounce :P

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated] D986: Revamp of the activity switcher backend

[Ivan Čukić]

ivan marked an inline comment as done.

INLINE COMMENTS
  imports/activitymanager/sortedactivitiesmodel.cpp:228 This will go away - we 
are planning to make wallpaper exposed via dbus api because basing this code on 
config files is not really robust.
  imports/activitymanager/sortedactivitiesmodel.cpp:354 rowChanged checks that 
(it is technically not a signal, but semantically it is - that is why I'm using 
emit rowChanged)

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D986

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ivan, davidedmundson, sebas, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 127118: ToolTip: Don't change geometry twice when repositioning

[David Rosca]

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

Review request for Plasma.


Repository: plasma-framework


Description
---

Dialog::setLocation and Dialog::setVisualParent both calls syncWithItem which 
changes the dialog's geometry.
Unsetting the mainItem and setting it back after location and visual parent is 
updated defers the call to syncWithItem and updates the geometry only once.


Diffs
-

  src/declarativeimports/core/tooltip.cpp 3d2e7da 

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


Testing
---

Tested with morphing popups effect, only one geometry change event is sent when 
tooltip slides to new position.


Thanks,

David Rosca

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

Re: kdereview: breeze-grub & breeze-plymouth

[kainz.a]

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

Re: Review Request 127118: ToolTip: Don't change geometry twice when repositioning

[David Rosca]

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

(Updated Feb. 19, 2016, 10:21 p.m.)


Status
--

This change has been discarded.


Review request for Plasma.


Repository: plasma-framework


Description
---

Dialog::setLocation and Dialog::setVisualParent both calls syncWithItem which 
changes the dialog's geometry.
Unsetting the mainItem and setting it back after location and visual parent is 
updated defers the call to syncWithItem and updates the geometry only once.


Diffs
-

  src/declarativeimports/core/tooltip.cpp 3d2e7da 

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


Testing
---

Tested with morphing popups effect, only one geometry change event is sent when 
tooltip slides to new position.


Thanks,

David Rosca

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

Re: Review Request 127079: fix uninitialised var

[Milian Wolff]

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


Ship it!




Ship It!

- Milian Wolff


On Feb. 19, 2016, 11:46 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127079/
> ---
> 
> (Updated Feb. 19, 2016, 11:46 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Valgrind pointed this out whilst debugging something else.
> 
> (though I'm not sure what on the desktop creates an Application object)
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/platformcomponents/application.cpp 
> a3aecc4a13541d41136fd0b34e58b3107eda060f 
> 
> Diff: https://git.reviewboard.kde.org/r/127079/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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