Re: Review Request 123502: Manually keep track of jobs sources

[Martin Klapetek]

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


Looks good

> indeterminate state of multiple jobs is no longer move in sync

If this is desired, the indet. state could be reset on all the jobs that are in 
that state (like set it again or set different state and right back to 
indeterminate) when new indet. job appears

- Martin Klapetek


On April 26, 2015, 7:24 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123502/
> ---
> 
> (Updated April 26, 2015, 7:24 p.m.)
> 
> 
> Review request for Plasma and Martin Klapetek.
> 
> 
> Bugs: 346673
> https://bugs.kde.org/show_bug.cgi?id=346673
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> DataSource sources is a QStringList property which means changes within 
> cannot be tracked causing all the job delegates to be destroyed and 
> re-created when sourcesChanged it emitted. This is pretty wasteful but also 
> causes the delegate to lose their sate (eg. details expanded).
> 
> 
> Diffs
> -
> 
>   applets/notifications/package/contents/ui/JobDelegate.qml 709b7fd 
>   applets/notifications/package/contents/ui/Jobs.qml 6ecf366 
> 
> Diff: https://git.reviewboard.kde.org/r/123502/diff/
> 
> 
> Testing
> ---
> 
> Adding, removing and pausing jobs works as expected, when a job appears or 
> disappears the other delegates keep their state.
> The only slight imperfection is now that the indeterminate state of multiple 
> jobs is no longer move in sync because the items are no longer created at the 
> same time.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Re: Review Request 123506: Match window switch dialog borders with addwidgets/switch activity

[David Edmundson]

> On April 27, 2015, 5:54 a.m., Martin Gräßlin wrote:
> > will this also look good if it's at the left edge of a right screen in a 
> > multi-screen environment?

yes as almost all monitors have kind of bezel


- David


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


On April 26, 2015, 9:41 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123506/
> ---
> 
> (Updated April 26, 2015, 9:41 p.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Bugs: 345614
> https://bugs.kde.org/show_bug.cgi?id=345614
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> BUG: 345614
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/windowswitcher/WindowSwitcher.qml 
> e4a46366c2a4e157860f55d2cb0e3781a239cb66 
> 
> Diff: https://git.reviewboard.kde.org/r/123506/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request 123506: Match window switch dialog borders with addwidgets/switch activity

[Thomas Lübking]

> On April 27, 2015, 5:54 vorm., Martin Gräßlin wrote:
> > will this also look good if it's at the left edge of a right screen in a 
> > multi-screen environment?
> 
> David Edmundson wrote:
> yes as almost all monitors have kind of bezel

I think Martin meant "when midst of your workspace" - you basically get a 
vertical bar that cuts your workspace in two halfs while the items you control 
(windows) flow across both areas.


- Thomas


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


On April 26, 2015, 9:41 nachm., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123506/
> ---
> 
> (Updated April 26, 2015, 9:41 nachm.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Bugs: 345614
> https://bugs.kde.org/show_bug.cgi?id=345614
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> BUG: 345614
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/windowswitcher/WindowSwitcher.qml 
> e4a46366c2a4e157860f55d2cb0e3781a239cb66 
> 
> Diff: https://git.reviewboard.kde.org/r/123506/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Minutes Monday Plasma Hangout

[Marco Martin]

Monday hangout notes for 27 April 2015

Antonis
* bugfixing
* thinking about porting fonts or icons to QML

Bhushan
* recent media backend to PMC to like know what episode you are in while 
watching a tv show

David E
* long bugfixing week
* hack qt4 apps to correctly load statusnotifiers in Debian
* working to fix a crash in qml animations

David R
* Bluetooth applet
* can control mediaplayer from device, shows current playing
* bugfixing
* next, maybe porting its kcms to qml

Jonathan:
* 5.3 out tomorrow
* please take a look to the announcement/errata, correct if necessary
* https://www.kde.org/announcements/plasma-5.3.0.php
* https://community.kde.org/Plasma/5.3_Errata
* https://www.kde.org/info/plasma-5.3.0.php

Martin G
* worked on managing monitor edid
* code for overriding wrong information from screens
* direct rendering mode for kwin, merged: kwin_wayland --drm --libinput --
xwayland
* hotplugging of outputs, already better than X11
* will continue work on drm backend

Tim Ramms
* fixes for notifications and jobs

Vishesh
* Bugfixes in baloo and krunner
* will merge new indexer in master

Marco
* qml port of mouse KCM: needs a solution to combobox bugs to be merged
* branch in libplasma to port away from sycoca: target is to stop installing 
desktop files in kservices5
* next week will continue on that
* will continue on bugfixes

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

Re: Review Request 123506: Match window switch dialog borders with addwidgets/switch activity

[David Edmundson]

> On April 27, 2015, 5:54 a.m., Martin Gräßlin wrote:
> > will this also look good if it's at the left edge of a right screen in a 
> > multi-screen environment?
> 
> David Edmundson wrote:
> yes as almost all monitors have kind of bezel
> 
> Thomas Lübking wrote:
> I think Martin meant "when midst of your workspace" - you basically get a 
> vertical bar that cuts your workspace in two halfs while the items you 
> control (windows) flow across both areas.

This patch doesn't change the actual position of anything, it just adjusts 
which borders are shown on the frame round that dialog.


- David


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


On April 26, 2015, 9:41 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123506/
> ---
> 
> (Updated April 26, 2015, 9:41 p.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Bugs: 345614
> https://bugs.kde.org/show_bug.cgi?id=345614
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> BUG: 345614
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/windowswitcher/WindowSwitcher.qml 
> e4a46366c2a4e157860f55d2cb0e3781a239cb66 
> 
> Diff: https://git.reviewboard.kde.org/r/123506/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request 123506: Match window switch dialog borders with addwidgets/switch activity

[Martin Gräßlin]

> On April 27, 2015, 7:54 a.m., Martin Gräßlin wrote:
> > will this also look good if it's at the left edge of a right screen in a 
> > multi-screen environment?
> 
> David Edmundson wrote:
> yes as almost all monitors have kind of bezel
> 
> Thomas Lübking wrote:
> I think Martin meant "when midst of your workspace" - you basically get a 
> vertical bar that cuts your workspace in two halfs while the items you 
> control (windows) flow across both areas.
> 
> David Edmundson wrote:
> This patch doesn't change the actual position of anything, it just 
> adjusts which borders are shown on the frame round that dialog.

I think you don't get what I mean. Consider two screens in a left-to-right 
layout. If it opens on the left screen, it'll be OK, but what if it opens on 
the right screen? Will it then also look ok, even if it is not at an actual 
screen border?


- Martin


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


On April 26, 2015, 11:41 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123506/
> ---
> 
> (Updated April 26, 2015, 11:41 p.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Bugs: 345614
> https://bugs.kde.org/show_bug.cgi?id=345614
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> BUG: 345614
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/windowswitcher/WindowSwitcher.qml 
> e4a46366c2a4e157860f55d2cb0e3781a239cb66 
> 
> Diff: https://git.reviewboard.kde.org/r/123506/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request 123506: Match window switch dialog borders with addwidgets/switch activity

[David Edmundson]

> On April 27, 2015, 5:54 a.m., Martin Gräßlin wrote:
> > will this also look good if it's at the left edge of a right screen in a 
> > multi-screen environment?
> 
> David Edmundson wrote:
> yes as almost all monitors have kind of bezel
> 
> Thomas Lübking wrote:
> I think Martin meant "when midst of your workspace" - you basically get a 
> vertical bar that cuts your workspace in two halfs while the items you 
> control (windows) flow across both areas.
> 
> David Edmundson wrote:
> This patch doesn't change the actual position of anything, it just 
> adjusts which borders are shown on the frame round that dialog.
> 
> Martin Gräßlin wrote:
> I think you don't get what I mean. Consider two screens in a 
> left-to-right layout. If it opens on the left screen, it'll be OK, but what 
> if it opens on the right screen? Will it then also look ok, even if it is not 
> at an actual screen border?

You have a multiple monitor system, right click on the right screen and click 
add widgets. It will look like that.


- David


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


On April 26, 2015, 9:41 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123506/
> ---
> 
> (Updated April 26, 2015, 9:41 p.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Bugs: 345614
> https://bugs.kde.org/show_bug.cgi?id=345614
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> BUG: 345614
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/windowswitcher/WindowSwitcher.qml 
> e4a46366c2a4e157860f55d2cb0e3781a239cb66 
> 
> Diff: https://git.reviewboard.kde.org/r/123506/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request 123506: Match window switch dialog borders with addwidgets/switch activity

[Martin Gräßlin]

> On April 27, 2015, 7:54 a.m., Martin Gräßlin wrote:
> > will this also look good if it's at the left edge of a right screen in a 
> > multi-screen environment?
> 
> David Edmundson wrote:
> yes as almost all monitors have kind of bezel
> 
> Thomas Lübking wrote:
> I think Martin meant "when midst of your workspace" - you basically get a 
> vertical bar that cuts your workspace in two halfs while the items you 
> control (windows) flow across both areas.
> 
> David Edmundson wrote:
> This patch doesn't change the actual position of anything, it just 
> adjusts which borders are shown on the frame round that dialog.
> 
> Martin Gräßlin wrote:
> I think you don't get what I mean. Consider two screens in a 
> left-to-right layout. If it opens on the left screen, it'll be OK, but what 
> if it opens on the right screen? Will it then also look ok, even if it is not 
> at an actual screen border?
> 
> David Edmundson wrote:
> You have a multiple monitor system, right click on the right screen and 
> click add widgets. It will look like that.

very well, then +1


- Martin


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


On April 26, 2015, 11:41 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123506/
> ---
> 
> (Updated April 26, 2015, 11:41 p.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Bugs: 345614
> https://bugs.kde.org/show_bug.cgi?id=345614
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> BUG: 345614
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/windowswitcher/WindowSwitcher.qml 
> e4a46366c2a4e157860f55d2cb0e3781a239cb66 
> 
> Diff: https://git.reviewboard.kde.org/r/123506/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Minutes Monday Plasma Hangout

[Eike Hein]

For the record, I'm still somewhat against all of these QML
KCM ports ...

Qt Quick Controls currently:

- Has no form layouts and other problems making it difficult to
  implement good config UIs (e.g. no way to get the metrics to
  do nice hanging indents). Numerous Qt Quick UIs we have are
  really badly laid out compared to their Plasma 4 equivalents.

- No automatic keyboard accelerator management.

- Worse performance.

- Incomplete QStyle support and as a result various visual and
  behavioral integration issues.

- Worse hardware compatibility (Qt Quick 2 requires OpenGL, i.e.
  all of these UIs stop working if GL/llvmpipe breaks).

I also see no real *benefit* right now beyond "Qt Quick Controls
is the future". It may well be, but what matters is the quality
of what's in any given tarball. I understand amassing code using
it generates pressure to get it there, but do we really want to
use the suffering of our userbase as leverage? Have we really
tried everything we can to address these problems before we
expose more users to them yet?

This is going to lower the quality of the software we ship for
a good while. Not to take a cheap shot, but anyone read boud's
recent blog post?


Cheers,
Eike


On 04/27/2015 12:54 PM, Marco Martin wrote:

Monday hangout notes for 27 April 2015

Antonis
* bugfixing
* thinking about porting fonts or icons to QML

Bhushan
* recent media backend to PMC to like know what episode you are in while
watching a tv show

David E
* long bugfixing week
* hack qt4 apps to correctly load statusnotifiers in Debian
* working to fix a crash in qml animations

David R
* Bluetooth applet
* can control mediaplayer from device, shows current playing
* bugfixing
* next, maybe porting its kcms to qml

Jonathan:
* 5.3 out tomorrow
* please take a look to the announcement/errata, correct if necessary
* https://www.kde.org/announcements/plasma-5.3.0.php
* https://community.kde.org/Plasma/5.3_Errata
* https://www.kde.org/info/plasma-5.3.0.php

Martin G
* worked on managing monitor edid
* code for overriding wrong information from screens
* direct rendering mode for kwin, merged: kwin_wayland --drm --libinput --
xwayland
* hotplugging of outputs, already better than X11
* will continue work on drm backend

Tim Ramms
* fixes for notifications and jobs

Vishesh
* Bugfixes in baloo and krunner
* will merge new indexer in master

Marco
* qml port of mouse KCM: needs a solution to combobox bugs to be merged
* branch in libplasma to port away from sycoca: target is to stop installing
desktop files in kservices5
* next week will continue on that
* will continue on bugfixes


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

5.4 kickoff meeting

[Jonathan Riddell]

Let's have a meeting to go over the todo list for Plasma 5.4 and finalise
the release schedule

We normally do this on IRC on #plasma on freenode.

Please select your preferred time

http://doodle.com/z2w2evq6m7h3s88q

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

Review Request 123529: update kmenuedit docbook and screenshots to plasma 5.3

[Burkhard Lück]

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

Review request for Documentation and Plasma.


Repository: kmenuedit


Description
---

see summary


Diffs
-

  doc/done.png 202b4e0 
  doc/index.docbook ebc1e9d 
  doc/selectinternet.png deeb67c 

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


Testing
---

builds


Thanks,

Burkhard Lück

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

Review Request 123530: Improve interactivity for the user icon and search field in kickoff

[Lukáš Tinkl]

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

Review request for Plasma.


Repository: plasma-desktop


Description
---

This patch makes the user icon and search field clickable. Upon clicking the 
former, the User Account kcm is opened, in the latter case the search field 
gets visible and activated.


Diffs
-

  applets/kickoff/package/contents/ui/FullRepresentation.qml 15dde96 
  applets/kickoff/package/contents/ui/Header.qml dfabbe5 

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


Testing
---

Everything works as expected, pressing Esc either cancels the search and/or 
closes the menu popup.


Thanks,

Lukáš Tinkl

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

Review Request 123535: Visible error messagebox on fatal loading errors

[David Edmundson]

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

Review request for Plasma.


Repository: plasma-workspace


Description
---

BUG: 346792


Diffs
-

  shell/shellmanager.cpp c6137ad63346c306adeab8d15fb6914ef2533aa8 

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


Testing
---


Thanks,

David Edmundson

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

Re: Review Request 123530: Improve interactivity for the user icon and search field in kickoff

[David Edmundson]

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


Personally I don't think anyone needs to open the accounts KCM so often we need 
to link to it. I suspect it'll get more accidental opens than legit ones.

The other changes seems good though.

- David Edmundson


On April 27, 2015, 2:31 p.m., Lukáš Tinkl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123530/
> ---
> 
> (Updated April 27, 2015, 2:31 p.m.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch makes the user icon and search field clickable. Upon clicking the 
> former, the User Account kcm is opened, in the latter case the search field 
> gets visible and activated.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/package/contents/ui/FullRepresentation.qml 15dde96 
>   applets/kickoff/package/contents/ui/Header.qml dfabbe5 
> 
> Diff: https://git.reviewboard.kde.org/r/123530/diff/
> 
> 
> Testing
> ---
> 
> Everything works as expected, pressing Esc either cancels the search and/or 
> closes the menu popup.
> 
> 
> Thanks,
> 
> Lukáš Tinkl
> 
>

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

Re: Review Request 123506: Match window switch dialog borders with addwidgets/switch activity

[David Edmundson]

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

(Updated April 27, 2015, 2:58 p.m.)


Status
--

This change has been marked as submitted.


Review request for kwin and Plasma.


Changes
---

Submitted with commit f0d0518a70417b35124c0089325b32a6e6bf8f5e by David 
Edmundson to branch Plasma/5.3.


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


Repository: plasma-workspace


Description
---

BUG: 345614


Diffs
-

  lookandfeel/contents/windowswitcher/WindowSwitcher.qml 
e4a46366c2a4e157860f55d2cb0e3781a239cb66 

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


Testing
---


Thanks,

David Edmundson

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

Re: Review Request 123530: Improve interactivity for the user icon and search field in kickoff

[Kai Uwe Broulik]

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


Good idea!

A couple of nitpicky suggestions below :)


applets/kickoff/package/contents/ui/Header.qml (line 38)


!==

If you change it below, change it here too ;)



applets/kickoff/package/contents/ui/Header.qml (line 95)


Does this need to be duplicated? I suppose the hit area for both items 
should be pretty similar so you could place a single MouseArea one level up.



applets/kickoff/package/contents/ui/Header.qml (line 166)


If you put the TextField outside the MouseArea, you could probably just do

> visible: header.state === "hint"

and safe the cursorShape and enabled dance


- Kai Uwe Broulik


On April 27, 2015, 2:31 nachm., Lukáš Tinkl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123530/
> ---
> 
> (Updated April 27, 2015, 2:31 nachm.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch makes the user icon and search field clickable. Upon clicking the 
> former, the User Account kcm is opened, in the latter case the search field 
> gets visible and activated.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/package/contents/ui/FullRepresentation.qml 15dde96 
>   applets/kickoff/package/contents/ui/Header.qml dfabbe5 
> 
> Diff: https://git.reviewboard.kde.org/r/123530/diff/
> 
> 
> Testing
> ---
> 
> Everything works as expected, pressing Esc either cancels the search and/or 
> closes the menu popup.
> 
> 
> Thanks,
> 
> Lukáš Tinkl
> 
>

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

Re: Review Request 123535: Visible error messagebox on fatal loading errors

[Aleix Pol Gonzalez]

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


Would it make sense to turn these into notifications?

- Aleix Pol Gonzalez


On April 27, 2015, 4:55 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123535/
> ---
> 
> (Updated April 27, 2015, 4:55 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> BUG: 346792
> 
> 
> Diffs
> -
> 
>   shell/shellmanager.cpp c6137ad63346c306adeab8d15fb6914ef2533aa8 
> 
> Diff: https://git.reviewboard.kde.org/r/123535/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request 123473: Port mouse theme kcm to QML

[Marco Martin]

> On April 23, 2015, 11:31 a.m., Eike Hein wrote:
> > > This is more an experiment on how much modules can be closely ported (and 
> > > in how much time).
> > 
> > What's the benefit to the user of merging this version now?
> 
> Marco Martin wrote:
> none.
> not too much pain as well tough.
> all of them have to eventually be ported tough and in order to get done, 
> one has to.. do it
> 
> Eike Hein wrote:
> > all of them have to eventually be ported tough and in order to get 
> done, one has to.. do it
> 
> I'm just not a big fan of putting transitional pain (worse UI from a 
> weaker toolkit) on the user when there's an opportunity to avoid it, I guess 
> ... right now, Qt Quick has worse performance, no keyboard accelerator 
> management, no form layouts, limited widgets, some visual problems, etc. - 
> It's true of course that using it builds greater pressure to get it fixed, 
> but are we *certain* that actively hurting the quality of our releases is the 
> only path available?
> 
> Marco Martin wrote:
> bah, right now accelerators and tab focus kinda works in that module..
> still kinda, but again, if the decision is to go in that direction, of 
> which i remeber it was talked about and decided, otherwise I wouldn't have 
> wasted two days on it ;)
> Now, I'm fine if now we decide to not port modules, but most of them 
> kindof have to be redone anyways, and I would prefer reding them once rather 
> than twice.
> 
> David Edmundson wrote:
> > It's true of course that using it builds greater pressure to get it 
> fixed, but are we certain that actively hurting the quality of our releases 
> is the only path available?
> 
> It's not as simple as saying using new stuff /will/ hurt the quality 
> compared to the current state.
> 
> This KCM wouldn't use form layouts, or any special widgets that we don't 
> have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by 
> the time we finish with this, I think we can make it just as perfect /and/ 
> progress our QQC integration at the same time.
> 
> Also it's not like these KCMs are truly perfect as-is. There are 8 open 
> bugs on the cursor KCM. I'd like to think paying some attention to these KCMs 
> will fix some of them.
> 
> I do completely agree with you that users shouldn't be hurt by porting 
> efforts and we should have an absolutely no regressions at all policy before 
> merging, with no excuses about limitations in QQC.
> 
> Martin Gräßlin wrote:
> I agree with David that we also should see this as a chance. For example 
> I always wondered why there is this "strange" preview area on the top, 
> instead of just previewing all cursors in the list directly. With QQC that 
> becomes quite easier and removes the "it's probably because it would be a 
> nightmare with delegates".
> 
> Marco Martin wrote:
> having all the previews inline could probably be simpler since i could 
> perhaps avoid a custom qquickpainteditem.. however, it would look very 
> crowded i think?
> 
> Martin Gräßlin wrote:
> maybe only show them for the selected or on hover?
> 
> Marco Martin wrote:
> this is very quick and dirty:
> http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png
> 
> with very big delegates, it almost looks nice :)
> 
> Sebastian Kügler wrote:
> I quite like it. Also, it's really not necessary to be able to view 5 or 
> more themes at the same time, this makes comparison already a lot easier.
> 
> Marco Martin wrote:
> this is with a better layout:
> http://wstaw.org/m/2015/04/24/plasma-desktopUj1576.png
> there is still one thing that doesn't logically work too much, that is 
> the size combo box, since it depends from the theme selected (not all themes 
> have all the same sizes available) so that may have to be made inline as 
> well, not sure if it would work well tough
> 
> Martin Gräßlin wrote:
> > so that may have to be made inline as well, not sure if it would work 
> well tough
> 
> Given that it already has this "Available size", I think it could be a 
> neat idea to morph it into the delegate.
> 
> (o) Resolution Dependent
> (o) |Dropdown| available sizes
> 
> Fredrik Höglund wrote:
> > For example I always wondered why there is this "strange" preview area 
> on the top, instead of just previewing all cursors in the list directly. With 
> QQC that becomes quite easier and removes the "it's probably because it would 
> be a nightmare with delegates".
> 
> * So that the appearance and behavior of the KCM is consistent with that 
> of the icon theme KCM.
> * So that the listview looks and behaves identically to other listviews.
> * To enable the user to get a quick overview of the installed themes 
> without having to scroll.
> * Each item in the listview provides three key points of data so as to 
> not overwhelm the user with information;
>   a single large image 

Re: Review Request 123535: Visible error messagebox on fatal loading errors

[Martin Klapetek]

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


+1


shell/shellmanager.cpp (line 187)


"No shell packages have been found ..." reads better I think


- Martin Klapetek


On April 27, 2015, 4:55 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123535/
> ---
> 
> (Updated April 27, 2015, 4:55 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> BUG: 346792
> 
> 
> Diffs
> -
> 
>   shell/shellmanager.cpp c6137ad63346c306adeab8d15fb6914ef2533aa8 
> 
> Diff: https://git.reviewboard.kde.org/r/123535/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request 123473: Port mouse theme kcm to QML

[Marco Martin]

> On April 23, 2015, 11:31 a.m., Eike Hein wrote:
> > > This is more an experiment on how much modules can be closely ported (and 
> > > in how much time).
> > 
> > What's the benefit to the user of merging this version now?
> 
> Marco Martin wrote:
> none.
> not too much pain as well tough.
> all of them have to eventually be ported tough and in order to get done, 
> one has to.. do it
> 
> Eike Hein wrote:
> > all of them have to eventually be ported tough and in order to get 
> done, one has to.. do it
> 
> I'm just not a big fan of putting transitional pain (worse UI from a 
> weaker toolkit) on the user when there's an opportunity to avoid it, I guess 
> ... right now, Qt Quick has worse performance, no keyboard accelerator 
> management, no form layouts, limited widgets, some visual problems, etc. - 
> It's true of course that using it builds greater pressure to get it fixed, 
> but are we *certain* that actively hurting the quality of our releases is the 
> only path available?
> 
> Marco Martin wrote:
> bah, right now accelerators and tab focus kinda works in that module..
> still kinda, but again, if the decision is to go in that direction, of 
> which i remeber it was talked about and decided, otherwise I wouldn't have 
> wasted two days on it ;)
> Now, I'm fine if now we decide to not port modules, but most of them 
> kindof have to be redone anyways, and I would prefer reding them once rather 
> than twice.
> 
> David Edmundson wrote:
> > It's true of course that using it builds greater pressure to get it 
> fixed, but are we certain that actively hurting the quality of our releases 
> is the only path available?
> 
> It's not as simple as saying using new stuff /will/ hurt the quality 
> compared to the current state.
> 
> This KCM wouldn't use form layouts, or any special widgets that we don't 
> have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by 
> the time we finish with this, I think we can make it just as perfect /and/ 
> progress our QQC integration at the same time.
> 
> Also it's not like these KCMs are truly perfect as-is. There are 8 open 
> bugs on the cursor KCM. I'd like to think paying some attention to these KCMs 
> will fix some of them.
> 
> I do completely agree with you that users shouldn't be hurt by porting 
> efforts and we should have an absolutely no regressions at all policy before 
> merging, with no excuses about limitations in QQC.
> 
> Martin Gräßlin wrote:
> I agree with David that we also should see this as a chance. For example 
> I always wondered why there is this "strange" preview area on the top, 
> instead of just previewing all cursors in the list directly. With QQC that 
> becomes quite easier and removes the "it's probably because it would be a 
> nightmare with delegates".
> 
> Marco Martin wrote:
> having all the previews inline could probably be simpler since i could 
> perhaps avoid a custom qquickpainteditem.. however, it would look very 
> crowded i think?
> 
> Martin Gräßlin wrote:
> maybe only show them for the selected or on hover?
> 
> Marco Martin wrote:
> this is very quick and dirty:
> http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png
> 
> with very big delegates, it almost looks nice :)
> 
> Sebastian Kügler wrote:
> I quite like it. Also, it's really not necessary to be able to view 5 or 
> more themes at the same time, this makes comparison already a lot easier.
> 
> Marco Martin wrote:
> this is with a better layout:
> http://wstaw.org/m/2015/04/24/plasma-desktopUj1576.png
> there is still one thing that doesn't logically work too much, that is 
> the size combo box, since it depends from the theme selected (not all themes 
> have all the same sizes available) so that may have to be made inline as 
> well, not sure if it would work well tough
> 
> Martin Gräßlin wrote:
> > so that may have to be made inline as well, not sure if it would work 
> well tough
> 
> Given that it already has this "Available size", I think it could be a 
> neat idea to morph it into the delegate.
> 
> (o) Resolution Dependent
> (o) |Dropdown| available sizes
> 
> Fredrik Höglund wrote:
> > For example I always wondered why there is this "strange" preview area 
> on the top, instead of just previewing all cursors in the list directly. With 
> QQC that becomes quite easier and removes the "it's probably because it would 
> be a nightmare with delegates".
> 
> * So that the appearance and behavior of the KCM is consistent with that 
> of the icon theme KCM.
> * So that the listview looks and behaves identically to other listviews.
> * To enable the user to get a quick overview of the installed themes 
> without having to scroll.
> * Each item in the listview provides three key points of data so as to 
> not overwhelm the user with information;
>   a single large image 

Re: Review Request 123535: Visible error messagebox on fatal loading errors

[Martin Gräßlin]

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


I like the idea of showing such an error message.


shell/shellmanager.cpp (line 186)


you could also use nullptr here to explicitly go into the overload taking a 
QWidget. "0" is a valid window id which most likely doesn't exist.


- Martin Gräßlin


On April 27, 2015, 4:55 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123535/
> ---
> 
> (Updated April 27, 2015, 4:55 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> BUG: 346792
> 
> 
> Diffs
> -
> 
>   shell/shellmanager.cpp c6137ad63346c306adeab8d15fb6914ef2533aa8 
> 
> Diff: https://git.reviewboard.kde.org/r/123535/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request 123530: Improve interactivity for the user icon and search field in kickoff

[Lukáš Tinkl]

> On Dub. 27, 2015, 4:56 odp., David Edmundson wrote:
> > Personally I don't think anyone needs to open the accounts KCM so often we 
> > need to link to it. I suspect it'll get more accidental opens than legit 
> > ones.
> > 
> > The other changes seems good though.

I for one would expect it to be interactive, and it closely matches what 
Windows (and Gnome Shell too afaik) does.


- Lukáš


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


On Dub. 27, 2015, 4:31 odp., Lukáš Tinkl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123530/
> ---
> 
> (Updated Dub. 27, 2015, 4:31 odp.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch makes the user icon and search field clickable. Upon clicking the 
> former, the User Account kcm is opened, in the latter case the search field 
> gets visible and activated.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/package/contents/ui/FullRepresentation.qml 15dde96 
>   applets/kickoff/package/contents/ui/Header.qml dfabbe5 
> 
> Diff: https://git.reviewboard.kde.org/r/123530/diff/
> 
> 
> Testing
> ---
> 
> Everything works as expected, pressing Esc either cancels the search and/or 
> closes the menu popup.
> 
> 
> Thanks,
> 
> Lukáš Tinkl
> 
>

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

Re: Review Request 123535: Visible error messagebox on fatal loading errors

[Martin Gräßlin]

> On April 27, 2015, 5:19 p.m., Aleix Pol Gonzalez wrote:
> > Would it make sense to turn these into notifications?

given that it's plasma which shows notifications - not really ;-)


- Martin


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


On April 27, 2015, 4:55 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123535/
> ---
> 
> (Updated April 27, 2015, 4:55 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> BUG: 346792
> 
> 
> Diffs
> -
> 
>   shell/shellmanager.cpp c6137ad63346c306adeab8d15fb6914ef2533aa8 
> 
> Diff: https://git.reviewboard.kde.org/r/123535/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request 123473: Port mouse theme kcm to QML

[Martin Gräßlin]

> On April 23, 2015, 1:31 p.m., Eike Hein wrote:
> > > This is more an experiment on how much modules can be closely ported (and 
> > > in how much time).
> > 
> > What's the benefit to the user of merging this version now?
> 
> Marco Martin wrote:
> none.
> not too much pain as well tough.
> all of them have to eventually be ported tough and in order to get done, 
> one has to.. do it
> 
> Eike Hein wrote:
> > all of them have to eventually be ported tough and in order to get 
> done, one has to.. do it
> 
> I'm just not a big fan of putting transitional pain (worse UI from a 
> weaker toolkit) on the user when there's an opportunity to avoid it, I guess 
> ... right now, Qt Quick has worse performance, no keyboard accelerator 
> management, no form layouts, limited widgets, some visual problems, etc. - 
> It's true of course that using it builds greater pressure to get it fixed, 
> but are we *certain* that actively hurting the quality of our releases is the 
> only path available?
> 
> Marco Martin wrote:
> bah, right now accelerators and tab focus kinda works in that module..
> still kinda, but again, if the decision is to go in that direction, of 
> which i remeber it was talked about and decided, otherwise I wouldn't have 
> wasted two days on it ;)
> Now, I'm fine if now we decide to not port modules, but most of them 
> kindof have to be redone anyways, and I would prefer reding them once rather 
> than twice.
> 
> David Edmundson wrote:
> > It's true of course that using it builds greater pressure to get it 
> fixed, but are we certain that actively hurting the quality of our releases 
> is the only path available?
> 
> It's not as simple as saying using new stuff /will/ hurt the quality 
> compared to the current state.
> 
> This KCM wouldn't use form layouts, or any special widgets that we don't 
> have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by 
> the time we finish with this, I think we can make it just as perfect /and/ 
> progress our QQC integration at the same time.
> 
> Also it's not like these KCMs are truly perfect as-is. There are 8 open 
> bugs on the cursor KCM. I'd like to think paying some attention to these KCMs 
> will fix some of them.
> 
> I do completely agree with you that users shouldn't be hurt by porting 
> efforts and we should have an absolutely no regressions at all policy before 
> merging, with no excuses about limitations in QQC.
> 
> Martin Gräßlin wrote:
> I agree with David that we also should see this as a chance. For example 
> I always wondered why there is this "strange" preview area on the top, 
> instead of just previewing all cursors in the list directly. With QQC that 
> becomes quite easier and removes the "it's probably because it would be a 
> nightmare with delegates".
> 
> Marco Martin wrote:
> having all the previews inline could probably be simpler since i could 
> perhaps avoid a custom qquickpainteditem.. however, it would look very 
> crowded i think?
> 
> Martin Gräßlin wrote:
> maybe only show them for the selected or on hover?
> 
> Marco Martin wrote:
> this is very quick and dirty:
> http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png
> 
> with very big delegates, it almost looks nice :)
> 
> Sebastian Kügler wrote:
> I quite like it. Also, it's really not necessary to be able to view 5 or 
> more themes at the same time, this makes comparison already a lot easier.
> 
> Marco Martin wrote:
> this is with a better layout:
> http://wstaw.org/m/2015/04/24/plasma-desktopUj1576.png
> there is still one thing that doesn't logically work too much, that is 
> the size combo box, since it depends from the theme selected (not all themes 
> have all the same sizes available) so that may have to be made inline as 
> well, not sure if it would work well tough
> 
> Martin Gräßlin wrote:
> > so that may have to be made inline as well, not sure if it would work 
> well tough
> 
> Given that it already has this "Available size", I think it could be a 
> neat idea to morph it into the delegate.
> 
> (o) Resolution Dependent
> (o) |Dropdown| available sizes
> 
> Fredrik Höglund wrote:
> > For example I always wondered why there is this "strange" preview area 
> on the top, instead of just previewing all cursors in the list directly. With 
> QQC that becomes quite easier and removes the "it's probably because it would 
> be a nightmare with delegates".
> 
> * So that the appearance and behavior of the KCM is consistent with that 
> of the icon theme KCM.
> * So that the listview looks and behaves identically to other listviews.
> * To enable the user to get a quick overview of the installed themes 
> without having to scroll.
> * Each item in the listview provides three key points of data so as to 
> not overwhelm the user with information;
>   a single large image o

Re: Review Request 123473: Port mouse theme kcm to QML

[Marco Martin]

> On April 23, 2015, 11:31 a.m., Eike Hein wrote:
> > > This is more an experiment on how much modules can be closely ported (and 
> > > in how much time).
> > 
> > What's the benefit to the user of merging this version now?
> 
> Marco Martin wrote:
> none.
> not too much pain as well tough.
> all of them have to eventually be ported tough and in order to get done, 
> one has to.. do it
> 
> Eike Hein wrote:
> > all of them have to eventually be ported tough and in order to get 
> done, one has to.. do it
> 
> I'm just not a big fan of putting transitional pain (worse UI from a 
> weaker toolkit) on the user when there's an opportunity to avoid it, I guess 
> ... right now, Qt Quick has worse performance, no keyboard accelerator 
> management, no form layouts, limited widgets, some visual problems, etc. - 
> It's true of course that using it builds greater pressure to get it fixed, 
> but are we *certain* that actively hurting the quality of our releases is the 
> only path available?
> 
> Marco Martin wrote:
> bah, right now accelerators and tab focus kinda works in that module..
> still kinda, but again, if the decision is to go in that direction, of 
> which i remeber it was talked about and decided, otherwise I wouldn't have 
> wasted two days on it ;)
> Now, I'm fine if now we decide to not port modules, but most of them 
> kindof have to be redone anyways, and I would prefer reding them once rather 
> than twice.
> 
> David Edmundson wrote:
> > It's true of course that using it builds greater pressure to get it 
> fixed, but are we certain that actively hurting the quality of our releases 
> is the only path available?
> 
> It's not as simple as saying using new stuff /will/ hurt the quality 
> compared to the current state.
> 
> This KCM wouldn't use form layouts, or any special widgets that we don't 
> have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by 
> the time we finish with this, I think we can make it just as perfect /and/ 
> progress our QQC integration at the same time.
> 
> Also it's not like these KCMs are truly perfect as-is. There are 8 open 
> bugs on the cursor KCM. I'd like to think paying some attention to these KCMs 
> will fix some of them.
> 
> I do completely agree with you that users shouldn't be hurt by porting 
> efforts and we should have an absolutely no regressions at all policy before 
> merging, with no excuses about limitations in QQC.
> 
> Martin Gräßlin wrote:
> I agree with David that we also should see this as a chance. For example 
> I always wondered why there is this "strange" preview area on the top, 
> instead of just previewing all cursors in the list directly. With QQC that 
> becomes quite easier and removes the "it's probably because it would be a 
> nightmare with delegates".
> 
> Marco Martin wrote:
> having all the previews inline could probably be simpler since i could 
> perhaps avoid a custom qquickpainteditem.. however, it would look very 
> crowded i think?
> 
> Martin Gräßlin wrote:
> maybe only show them for the selected or on hover?
> 
> Marco Martin wrote:
> this is very quick and dirty:
> http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png
> 
> with very big delegates, it almost looks nice :)
> 
> Sebastian Kügler wrote:
> I quite like it. Also, it's really not necessary to be able to view 5 or 
> more themes at the same time, this makes comparison already a lot easier.
> 
> Marco Martin wrote:
> this is with a better layout:
> http://wstaw.org/m/2015/04/24/plasma-desktopUj1576.png
> there is still one thing that doesn't logically work too much, that is 
> the size combo box, since it depends from the theme selected (not all themes 
> have all the same sizes available) so that may have to be made inline as 
> well, not sure if it would work well tough
> 
> Martin Gräßlin wrote:
> > so that may have to be made inline as well, not sure if it would work 
> well tough
> 
> Given that it already has this "Available size", I think it could be a 
> neat idea to morph it into the delegate.
> 
> (o) Resolution Dependent
> (o) |Dropdown| available sizes
> 
> Fredrik Höglund wrote:
> > For example I always wondered why there is this "strange" preview area 
> on the top, instead of just previewing all cursors in the list directly. With 
> QQC that becomes quite easier and removes the "it's probably because it would 
> be a nightmare with delegates".
> 
> * So that the appearance and behavior of the KCM is consistent with that 
> of the icon theme KCM.
> * So that the listview looks and behaves identically to other listviews.
> * To enable the user to get a quick overview of the installed themes 
> without having to scroll.
> * Each item in the listview provides three key points of data so as to 
> not overwhelm the user with information;
>   a single large image 

Re: Review Request 123530: Improve interactivity for the user icon and search field in kickoff

[Lukáš Tinkl]

> On Dub. 27, 2015, 4:48 odp., Kai Uwe Broulik wrote:
> > applets/kickoff/package/contents/ui/Header.qml, line 95
> > 
> >
> > Does this need to be duplicated? I suppose the hit area for both items 
> > should be pretty similar so you could place a single MouseArea one level up.

I fail to see how could I refactor this one level up... the MouseArea has to be 
inside the Image/IconItem


> On Dub. 27, 2015, 4:48 odp., Kai Uwe Broulik wrote:
> > applets/kickoff/package/contents/ui/Header.qml, line 166
> > 
> >
> > If you put the TextField outside the MouseArea, you could probably just 
> > do
> > 
> > > visible: header.state === "hint"
> > 
> > and safe the cursorShape and enabled dance

same here


- Lukáš


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


On Dub. 27, 2015, 4:31 odp., Lukáš Tinkl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123530/
> ---
> 
> (Updated Dub. 27, 2015, 4:31 odp.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch makes the user icon and search field clickable. Upon clicking the 
> former, the User Account kcm is opened, in the latter case the search field 
> gets visible and activated.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/package/contents/ui/FullRepresentation.qml 15dde96 
>   applets/kickoff/package/contents/ui/Header.qml dfabbe5 
> 
> Diff: https://git.reviewboard.kde.org/r/123530/diff/
> 
> 
> Testing
> ---
> 
> Everything works as expected, pressing Esc either cancels the search and/or 
> closes the menu popup.
> 
> 
> Thanks,
> 
> Lukáš Tinkl
> 
>

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

Re: Review Request 123530: Improve interactivity for the user icon and search field in kickoff

[Lukáš Tinkl]

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

(Updated Dub. 27, 2015, 7:04 odp.)


Review request for Plasma and KDE Usability.


Changes
---

Fix a problem with the search text field staying visible between menu opens 
plus some minor coding style issues pointed out by Kai.


Repository: plasma-desktop


Description
---

This patch makes the user icon and search field clickable. Upon clicking the 
former, the User Account kcm is opened, in the latter case the search field 
gets visible and activated.


Diffs (updated)
-

  applets/kickoff/package/contents/ui/FullRepresentation.qml 15dde96 
  applets/kickoff/package/contents/ui/Header.qml dfabbe5 

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


Testing
---

Everything works as expected, pressing Esc either cancels the search and/or 
closes the menu popup.


Thanks,

Lukáš Tinkl

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

Re: Review Request 123502: Manually keep track of jobs sources

[Kai Uwe Broulik]

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

(Updated April 27, 2015, 6:10 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Martin Klapetek.


Changes
---

Submitted with commit bc5c47537f3bbb706b3fe7af66508f5ef2fadc6e by Kai Uwe 
Broulik to branch Plasma/5.3.


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


Repository: plasma-workspace


Description
---

DataSource sources is a QStringList property which means changes within cannot 
be tracked causing all the job delegates to be destroyed and re-created when 
sourcesChanged it emitted. This is pretty wasteful but also causes the delegate 
to lose their sate (eg. details expanded).


Diffs
-

  applets/notifications/package/contents/ui/JobDelegate.qml 709b7fd 
  applets/notifications/package/contents/ui/Jobs.qml 6ecf366 

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


Testing
---

Adding, removing and pausing jobs works as expected, when a job appears or 
disappears the other delegates keep their state.
The only slight imperfection is now that the indeterminate state of multiple 
jobs is no longer move in sync because the items are no longer created at the 
same time.


Thanks,

Kai Uwe Broulik

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

Review Request 123537: Add support for menu sections

[Kai Uwe Broulik]

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

Review request for Plasma.


Repository: plasma-framework


Description
---

QMenuItem now has a "section" property that makes it behave like a section. I 
did not find a removeSection method, however.


Diffs
-

  src/declarativeimports/plasmacomponents/qmenu.h a927d12 
  src/declarativeimports/plasmacomponents/qmenu.cpp 0b82a99 
  src/declarativeimports/plasmacomponents/qmenuitem.h f8629f0 
  src/declarativeimports/plasmacomponents/qmenuitem.cpp aa61288 
  tests/components/menu.qml PRE-CREATION 

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


Testing
---

Seems to work fine, icons are not supported, comes with a manual test.


Thanks,

Kai Uwe Broulik

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

Re: Review Request 123537: Add support for menu sections

[Marco Martin]

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

Ship it!


Ship It!

- Marco Martin


On April 27, 2015, 6:44 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123537/
> ---
> 
> (Updated April 27, 2015, 6:44 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> QMenuItem now has a "section" property that makes it behave like a section. I 
> did not find a removeSection method, however.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qmenu.h a927d12 
>   src/declarativeimports/plasmacomponents/qmenu.cpp 0b82a99 
>   src/declarativeimports/plasmacomponents/qmenuitem.h f8629f0 
>   src/declarativeimports/plasmacomponents/qmenuitem.cpp aa61288 
>   tests/components/menu.qml PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/123537/diff/
> 
> 
> Testing
> ---
> 
> Seems to work fine, icons are not supported, comes with a manual test.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Re: Review Request 123537: Add support for menu sections

[Kai Uwe Broulik]

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

(Updated April 27, 2015, 8:20 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 93cf07deac366888fa7e8a06fe7593c1d5a92505 by Kai Uwe 
Broulik to branch master.


Repository: plasma-framework


Description
---

QMenuItem now has a "section" property that makes it behave like a section. I 
did not find a removeSection method, however.


Diffs
-

  src/declarativeimports/plasmacomponents/qmenu.h a927d12 
  src/declarativeimports/plasmacomponents/qmenu.cpp 0b82a99 
  src/declarativeimports/plasmacomponents/qmenuitem.h f8629f0 
  src/declarativeimports/plasmacomponents/qmenuitem.cpp aa61288 
  tests/components/menu.qml PRE-CREATION 

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


Testing
---

Seems to work fine, icons are not supported, comes with a manual test.


Thanks,

Kai Uwe Broulik

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

Re: Review Request 123537: Add support for menu sections

[Kai Uwe Broulik]

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



src/declarativeimports/plasmacomponents/qmenu.cpp (line 196)


I added an isVisible check before this (and above), so you could 
conditionally show sections using bindings, eg. so "Recent documents for" is 
only shown when documents exist.


- Kai Uwe Broulik


On April 27, 2015, 8:20 nachm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123537/
> ---
> 
> (Updated April 27, 2015, 8:20 nachm.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> QMenuItem now has a "section" property that makes it behave like a section. I 
> did not find a removeSection method, however.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qmenu.h a927d12 
>   src/declarativeimports/plasmacomponents/qmenu.cpp 0b82a99 
>   src/declarativeimports/plasmacomponents/qmenuitem.h f8629f0 
>   src/declarativeimports/plasmacomponents/qmenuitem.cpp aa61288 
>   tests/components/menu.qml PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/123537/diff/
> 
> 
> Testing
> ---
> 
> Seems to work fine, icons are not supported, comes with a manual test.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Review Request 123539: Improve visibility of running widget checkmark

[Kai Uwe Broulik]

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

Review request for Plasma, KDE Usability and Andrew Lake.


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


Repository: plasma-desktop


Description
---

As suggested by Andrew show a badge kind of thing with the number of running 
applets inside.


Diffs
-

  desktoppackage/contents/explorer/AppletDelegate.qml 2e53c1e 
  desktoppackage/contents/explorer/WidgetExplorer.qml f164c18 

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


Testing
---

After fixing a nasty bug in the model it shows the proper number now. It also 
doesn't break if you happen to have 10 or more widgets of the same kind. I did 
not know what kind of font color to use.


File Attachments


Badge in action
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/04/27/1b8483bb-fe3b-4701-92d3-02b437e63843__widgetexplorernumber2.jpg


Thanks,

Kai Uwe Broulik

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

Re: Review Request 123473: Port mouse theme kcm to QML

[Andrew Lake]

> On April 23, 2015, 11:31 a.m., Eike Hein wrote:
> > > This is more an experiment on how much modules can be closely ported (and 
> > > in how much time).
> > 
> > What's the benefit to the user of merging this version now?
> 
> Marco Martin wrote:
> none.
> not too much pain as well tough.
> all of them have to eventually be ported tough and in order to get done, 
> one has to.. do it
> 
> Eike Hein wrote:
> > all of them have to eventually be ported tough and in order to get 
> done, one has to.. do it
> 
> I'm just not a big fan of putting transitional pain (worse UI from a 
> weaker toolkit) on the user when there's an opportunity to avoid it, I guess 
> ... right now, Qt Quick has worse performance, no keyboard accelerator 
> management, no form layouts, limited widgets, some visual problems, etc. - 
> It's true of course that using it builds greater pressure to get it fixed, 
> but are we *certain* that actively hurting the quality of our releases is the 
> only path available?
> 
> Marco Martin wrote:
> bah, right now accelerators and tab focus kinda works in that module..
> still kinda, but again, if the decision is to go in that direction, of 
> which i remeber it was talked about and decided, otherwise I wouldn't have 
> wasted two days on it ;)
> Now, I'm fine if now we decide to not port modules, but most of them 
> kindof have to be redone anyways, and I would prefer reding them once rather 
> than twice.
> 
> David Edmundson wrote:
> > It's true of course that using it builds greater pressure to get it 
> fixed, but are we certain that actively hurting the quality of our releases 
> is the only path available?
> 
> It's not as simple as saying using new stuff /will/ hurt the quality 
> compared to the current state.
> 
> This KCM wouldn't use form layouts, or any special widgets that we don't 
> have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by 
> the time we finish with this, I think we can make it just as perfect /and/ 
> progress our QQC integration at the same time.
> 
> Also it's not like these KCMs are truly perfect as-is. There are 8 open 
> bugs on the cursor KCM. I'd like to think paying some attention to these KCMs 
> will fix some of them.
> 
> I do completely agree with you that users shouldn't be hurt by porting 
> efforts and we should have an absolutely no regressions at all policy before 
> merging, with no excuses about limitations in QQC.
> 
> Martin Gräßlin wrote:
> I agree with David that we also should see this as a chance. For example 
> I always wondered why there is this "strange" preview area on the top, 
> instead of just previewing all cursors in the list directly. With QQC that 
> becomes quite easier and removes the "it's probably because it would be a 
> nightmare with delegates".
> 
> Marco Martin wrote:
> having all the previews inline could probably be simpler since i could 
> perhaps avoid a custom qquickpainteditem.. however, it would look very 
> crowded i think?
> 
> Martin Gräßlin wrote:
> maybe only show them for the selected or on hover?
> 
> Marco Martin wrote:
> this is very quick and dirty:
> http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png
> 
> with very big delegates, it almost looks nice :)
> 
> Sebastian Kügler wrote:
> I quite like it. Also, it's really not necessary to be able to view 5 or 
> more themes at the same time, this makes comparison already a lot easier.
> 
> Marco Martin wrote:
> this is with a better layout:
> http://wstaw.org/m/2015/04/24/plasma-desktopUj1576.png
> there is still one thing that doesn't logically work too much, that is 
> the size combo box, since it depends from the theme selected (not all themes 
> have all the same sizes available) so that may have to be made inline as 
> well, not sure if it would work well tough
> 
> Martin Gräßlin wrote:
> > so that may have to be made inline as well, not sure if it would work 
> well tough
> 
> Given that it already has this "Available size", I think it could be a 
> neat idea to morph it into the delegate.
> 
> (o) Resolution Dependent
> (o) |Dropdown| available sizes
> 
> Fredrik Höglund wrote:
> > For example I always wondered why there is this "strange" preview area 
> on the top, instead of just previewing all cursors in the list directly. With 
> QQC that becomes quite easier and removes the "it's probably because it would 
> be a nightmare with delegates".
> 
> * So that the appearance and behavior of the KCM is consistent with that 
> of the icon theme KCM.
> * So that the listview looks and behaves identically to other listviews.
> * To enable the user to get a quick overview of the installed themes 
> without having to scroll.
> * Each item in the listview provides three key points of data so as to 
> not overwhelm the user with information;
>   a single large image 

Re: Review Request 123539: Improve visibility of running widget checkmark

[andreas kainz]

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


colors maybe green and white as used in the mount symbol

- andreas kainz


On April 27, 2015, 9:35 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123539/
> ---
> 
> (Updated April 27, 2015, 9:35 p.m.)
> 
> 
> Review request for Plasma, KDE Usability and Andrew Lake.
> 
> 
> Bugs: 342112
> https://bugs.kde.org/show_bug.cgi?id=342112
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> As suggested by Andrew show a badge kind of thing with the number of running 
> applets inside.
> 
> 
> Diffs
> -
> 
>   desktoppackage/contents/explorer/AppletDelegate.qml 2e53c1e 
>   desktoppackage/contents/explorer/WidgetExplorer.qml f164c18 
> 
> Diff: https://git.reviewboard.kde.org/r/123539/diff/
> 
> 
> Testing
> ---
> 
> After fixing a nasty bug in the model it shows the proper number now. It also 
> doesn't break if you happen to have 10 or more widgets of the same kind. I 
> did not know what kind of font color to use.
> 
> 
> File Attachments
> 
> 
> Badge in action
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/04/27/1b8483bb-fe3b-4701-92d3-02b437e63843__widgetexplorernumber2.jpg
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Re: 5.4 kickoff meeting

[Jonathan Riddell]

The winner is
Thursday 30th 13:00UTC (15:00 central europe)

Jonathan

On 27 April 2015 at 14:22, Jonathan Riddell  wrote:

> Let's have a meeting to go over the todo list for Plasma 5.4 and finalise
> the release schedule
>
> We normally do this on IRC on #plasma on freenode.
>
> Please select your preferred time
>
> http://doodle.com/z2w2evq6m7h3s88q
>
> Jonathan
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123530: Improve interactivity for the user icon and search field in kickoff

[Thomas Pfeiffer]

> On April 27, 2015, 2:56 p.m., David Edmundson wrote:
> > Personally I don't think anyone needs to open the accounts KCM so often we 
> > need to link to it. I suspect it'll get more accidental opens than legit 
> > ones.
> > 
> > The other changes seems good though.
> 
> Lukáš Tinkl wrote:
> I for one would expect it to be interactive, and it closely matches what 
> Windows (and Gnome Shell too afaik) does.

By "User Account kcm" you mean the "Password and User Account" kcm, right? I 
think that's okay, as it lets you edit the information that is shown there. If 
we get lots of bug reports form people accidentally clicking it, we might 
reconsider.


- Thomas


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


On April 27, 2015, 5:04 p.m., Lukáš Tinkl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123530/
> ---
> 
> (Updated April 27, 2015, 5:04 p.m.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch makes the user icon and search field clickable. Upon clicking the 
> former, the User Account kcm is opened, in the latter case the search field 
> gets visible and activated.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/package/contents/ui/FullRepresentation.qml 15dde96 
>   applets/kickoff/package/contents/ui/Header.qml dfabbe5 
> 
> Diff: https://git.reviewboard.kde.org/r/123530/diff/
> 
> 
> Testing
> ---
> 
> Everything works as expected, pressing Esc either cancels the search and/or 
> closes the menu popup.
> 
> 
> Thanks,
> 
> Lukáš Tinkl
> 
>

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

Re: Review Request 123530: Improve interactivity for the user icon and search field in kickoff

[Lukáš Tinkl]

> On Dub. 27, 2015, 4:56 odp., David Edmundson wrote:
> > Personally I don't think anyone needs to open the accounts KCM so often we 
> > need to link to it. I suspect it'll get more accidental opens than legit 
> > ones.
> > 
> > The other changes seems good though.
> 
> Lukáš Tinkl wrote:
> I for one would expect it to be interactive, and it closely matches what 
> Windows (and Gnome Shell too afaik) does.
> 
> Thomas Pfeiffer wrote:
> By "User Account kcm" you mean the "Password and User Account" kcm, 
> right? I think that's okay, as it lets you edit the information that is shown 
> there. If we get lots of bug reports form people accidentally clicking it, we 
> might reconsider.

Yup exactly, it lets you edit what is being shown there - the user name and 
your face/icon.


- Lukáš


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


On Dub. 27, 2015, 7:04 odp., Lukáš Tinkl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123530/
> ---
> 
> (Updated Dub. 27, 2015, 7:04 odp.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch makes the user icon and search field clickable. Upon clicking the 
> former, the User Account kcm is opened, in the latter case the search field 
> gets visible and activated.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/package/contents/ui/FullRepresentation.qml 15dde96 
>   applets/kickoff/package/contents/ui/Header.qml dfabbe5 
> 
> Diff: https://git.reviewboard.kde.org/r/123530/diff/
> 
> 
> Testing
> ---
> 
> Everything works as expected, pressing Esc either cancels the search and/or 
> closes the menu popup.
> 
> 
> Thanks,
> 
> Lukáš Tinkl
> 
>

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