D28172: [applets/digital-clock] Fix date sizing in vertical panel

2020-03-23 Thread Christian Muehlhaeuser
muesli added a comment.


  While it's not completely consistent yet, it still's an improvement that 
reverts the recent regression. As such, I'm tempted to say LGTM.

REPOSITORY
  R120 Plasma Workspace

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

To: ngraham, #vdg, #plasma
Cc: muesli, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D28172: [applets/digital-clock] Fix date sizing in vertical panel

2020-03-21 Thread Christian Muehlhaeuser
muesli added a comment.


  Your patch indeed makes the date behave like in previous releases again! 
However I noticed it's still not quite consistent in its behavior: when I start 
plasmashell freshly, the date is a lot wider than after resizing it to roughly 
the same width. I've added a new attachment, which hopefully explains what I'm 
trying to say.
  
  F8191155: 2020-03-21 01-12-05.mkv 

REPOSITORY
  R120 Plasma Workspace

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

To: ngraham, #vdg, #plasma
Cc: muesli, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D28083: Use methods in KF5-activities to switch to previous/next activity

2020-03-17 Thread Christian Muehlhaeuser
This revision was automatically updated to reflect the committed changes.
Closed by commit R120:805e70bb6e75: Use methods in KF5-activities to switch to 
previous/next activity (authored by muesli).

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28083?vs=77780&id=77820

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

AFFECTED FILES
  shell/shellcorona.cpp

To: muesli, ngraham, ivan, apol
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D28083: Use methods in KF5-activities to switch to previous/next activity

2020-03-16 Thread Christian Muehlhaeuser
muesli created this revision.
muesli added reviewers: ngraham, ivan.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
muesli requested review of this revision.

REVISION SUMMARY
  Since the release of KDE Frameworks 5.68.0 we can now
  use the methods exposed in KActivities::Controller to trigger a
  switch to the previous or next activity from ShellCorona.

REPOSITORY
  R120 Plasma Workspace

BRANCH
  master

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

AFFECTED FILES
  shell/shellcorona.cpp

To: muesli, ngraham, ivan
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D26861: [Applet/Task Manager] Move audio indicator to the corner

2020-01-23 Thread Christian
Fuchs added a comment.


  Looks good to me, thank you very much for the work :-)
  
  Sidesnotes that I mentioned in the group, just so they are documented here:
  
  - I think for a clickable action it can become too small, so it takes too 
much aiming. However, it doesn't get in the way, and people annoyed by it can 
just disable it completely, so that's probably fine
  
  - Icon wise, given that it can still overlap with the app icon, I would 
prefer something that has a contrasting border, so e.g. a dark audio indicator 
is still visible on a dark app icon. But that can probably be addressed in a 
separate task, especially as it also affects other icons we have

REPOSITORY
  R119 Plasma Desktop

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

To: gvgeo, #vdg, #plasma, hein, ngraham
Cc: broulik, Fuchs, ndavis, filipf, cblack, plasma-devel, Orage, LeGast00n, 
The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, 
ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, ahiemstra, mart


D22382: Add global shortcuts for switching to the previous/next activity

2020-01-13 Thread Christian Muehlhaeuser
This revision was automatically updated to reflect the committed changes.
Closed by commit R120:1d6b5376eaa7: Add global shortcuts for switching to the 
previous/next activity (authored by muesli).

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22382?vs=73412&id=73418

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

AFFECTED FILES
  shell/shellcorona.cpp

To: muesli, apol, davidedmundson, #vdg, #plasma, ngraham
Cc: ngraham, romangg, ivan, plasma-devel, LeGast00n, The-Feren-OS-Dev, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, alexeymin, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D22382: Add global shortcuts for switching to the previous/next activity

2020-01-13 Thread Christian Muehlhaeuser
muesli added a comment.


  Alright, I think this looks sane again. @ngraham Mind if I land this in its 
current state?

REPOSITORY
  R120 Plasma Workspace

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

To: muesli, apol, davidedmundson, #vdg, #plasma
Cc: ngraham, romangg, ivan, plasma-devel, LeGast00n, The-Feren-OS-Dev, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, alexeymin, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D22382: Add global shortcuts for switching to the previous/next activity

2020-01-13 Thread Christian Muehlhaeuser
muesli updated this revision to Diff 73412.
muesli added a comment.


  Hopefully fix phabricator getting out of sync with the changeset.

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22382?vs=73354&id=73412

BRANCH
  shortcut-prevnext-activity (branched from master)

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

AFFECTED FILES
  shell/shellcorona.cpp

To: muesli, apol, davidedmundson, #vdg, #plasma
Cc: ngraham, romangg, ivan, plasma-devel, LeGast00n, The-Feren-OS-Dev, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, alexeymin, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D22382: Add global shortcuts for switching to the previous/next activity

2020-01-12 Thread Christian Muehlhaeuser
muesli added a comment.


  Oops, I'm not sure what I've did here was what I intended: I rebased master 
(>800 commits since my original changeset) into my feature branch because I 
otherwise couldn't build/test my changes anymore, but obviously I didn't 
touch/change > 600 files.
  Is this how phabricator is supposed to look in such a scenario, or how should 
I have resolved this scenario?

REPOSITORY
  R120 Plasma Workspace

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

To: muesli, apol, davidedmundson, #vdg, #plasma
Cc: ngraham, romangg, ivan, plasma-devel, LeGast00n, The-Feren-OS-Dev, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, alexeymin, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D22382: Add global shortcuts for switching to the previous/next activity

2020-01-12 Thread Christian Muehlhaeuser
muesli updated this revision to Diff 73354.
muesli added a comment.


  - Remove default key-sequence for "Previous/Next Activity" shortcut

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22382?vs=61521&id=73354

BRANCH
  shortcut-prevnext-activity (branched from master)

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

AFFECTED FILES
  .gitignore
  CMakeLists.txt
  applets/CMakeLists.txt
  applets/activitybar/metadata.desktop
  applets/analog-clock/metadata.desktop
  applets/appmenu/lib/appmenuapplet.cpp
  applets/appmenu/package/contents/ui/main.qml
  applets/appmenu/package/metadata.desktop
  applets/appmenu/plugin/appmenumodel.cpp
  applets/batterymonitor/package/contents/ui/BatteryItem.qml
  applets/batterymonitor/package/contents/ui/BrightnessItem.qml
  applets/batterymonitor/package/contents/ui/CompactRepresentation.qml
  applets/batterymonitor/package/contents/ui/PopupDialog.qml
  applets/batterymonitor/package/contents/ui/batterymonitor.qml
  applets/batterymonitor/package/contents/ui/logic.js
  applets/batterymonitor/package/metadata.desktop
  applets/calendar/package/metadata.desktop
  applets/clipboard/contents/ui/ClipboardPage.qml
  applets/clipboard/contents/ui/ImageItemDelegate.qml
  applets/clipboard/metadata.desktop
  applets/devicenotifier/package/contents/ui/devicenotifier.qml
  applets/devicenotifier/package/metadata.desktop
  applets/devicenotifier/test-predicate-openinwindow.desktop
  applets/digital-clock/package/contents/config/config.qml
  applets/digital-clock/package/contents/ui/CalendarView.qml
  applets/digital-clock/package/contents/ui/DigitalClock.qml
  applets/digital-clock/package/contents/ui/configAppearance.qml
  applets/digital-clock/package/contents/ui/configTimeZones.qml
  applets/digital-clock/package/contents/ui/main.qml
  applets/digital-clock/package/metadata.desktop
  applets/digital-clock/plugin/CMakeLists.txt
  applets/digital-clock/plugin/clipboardmenu.cpp
  applets/icon/iconapplet.cpp
  applets/icon/package/metadata.desktop
  applets/kicker/CMakeLists.txt
  applets/kicker/Messages.sh
  applets/kicker/plugin/abstractentry.cpp
  applets/kicker/plugin/abstractentry.h
  applets/kicker/plugin/abstractmodel.cpp
  applets/kicker/plugin/abstractmodel.h
  applets/kicker/plugin/actionlist.cpp
  applets/kicker/plugin/actionlist.h
  applets/kicker/plugin/appentry.cpp
  applets/kicker/plugin/appentry.h
  applets/kicker/plugin/appsmodel.cpp
  applets/kicker/plugin/appsmodel.h
  applets/kicker/plugin/computermodel.cpp
  applets/kicker/plugin/computermodel.h
  applets/kicker/plugin/contactentry.cpp
  applets/kicker/plugin/contactentry.h
  applets/kicker/plugin/containmentinterface.cpp
  applets/kicker/plugin/containmentinterface.h
  applets/kicker/plugin/dashboardwindow.cpp
  applets/kicker/plugin/dashboardwindow.h
  applets/kicker/plugin/draghelper.cpp
  applets/kicker/plugin/draghelper.h
  applets/kicker/plugin/fileentry.cpp
  applets/kicker/plugin/fileentry.h
  applets/kicker/plugin/forwardingmodel.cpp
  applets/kicker/plugin/forwardingmodel.h
  applets/kicker/plugin/funnelmodel.cpp
  applets/kicker/plugin/funnelmodel.h
  applets/kicker/plugin/kastatsfavoritesmodel.cpp
  applets/kicker/plugin/kastatsfavoritesmodel.h
  applets/kicker/plugin/kickerplugin.cpp
  applets/kicker/plugin/kickerplugin.h
  applets/kicker/plugin/menuentryeditor.cpp
  applets/kicker/plugin/menuentryeditor.h
  applets/kicker/plugin/placeholdermodel.cpp
  applets/kicker/plugin/placeholdermodel.h
  applets/kicker/plugin/processrunner.cpp
  applets/kicker/plugin/processrunner.h
  applets/kicker/plugin/qmldir
  applets/kicker/plugin/recentcontactsmodel.cpp
  applets/kicker/plugin/recentcontactsmodel.h
  applets/kicker/plugin/recentusagemodel.cpp
  applets/kicker/plugin/recentusagemodel.h
  applets/kicker/plugin/rootmodel.cpp
  applets/kicker/plugin/rootmodel.h
  applets/kicker/plugin/runnermatchesmodel.cpp
  applets/kicker/plugin/runnermatchesmodel.h
  applets/kicker/plugin/runnermodel.cpp
  applets/kicker/plugin/runnermodel.h
  applets/kicker/plugin/simplefavoritesmodel.cpp
  applets/kicker/plugin/simplefavoritesmodel.h
  applets/kicker/plugin/submenu.cpp
  applets/kicker/plugin/submenu.h
  applets/kicker/plugin/systementry.cpp
  applets/kicker/plugin/systementry.h
  applets/kicker/plugin/systemmodel.cpp
  applets/kicker/plugin/systemmodel.h
  applets/kicker/plugin/systemsettings.cpp
  applets/kicker/plugin/systemsettings.h
  applets/kicker/plugin/wheelinterceptor.cpp
  applets/kicker/plugin/wheelinterceptor.h
  applets/kicker/plugin/windowsystem.cpp
  applets/kicker/plugin/windowsystem.h
  applets/lock_logout/contents/config/config.qml
  applets/lock_logout/metadata.desktop
  applets/mediacontroller/contents/ui/main.qml
  applets/mediacontroller/metadata.desktop
  applets/notifications/CMakeLists.txt
  applets/notifications/globalshortcuts.cpp
  applets/notifications/globalshortcuts.h
  applets/notifications/notificationapplet.cpp
  applets/notifications

D22382: Add global shortcuts for switching to the previous/next activity

2020-01-11 Thread Christian Muehlhaeuser
muesli added a comment.


  While waiting for that separate discussion and decision, does anyone mind if 
I land this _without_ default shortcuts set?
  
  At least it enables people to switch to the previous/next activity when they 
configure a shortcut manually. Currently that's not possible, as one can only 
define shortcuts for specific activities.

REPOSITORY
  R120 Plasma Workspace

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

To: muesli, apol, davidedmundson, #vdg, #plasma
Cc: ngraham, romangg, ivan, plasma-devel, LeGast00n, The-Feren-OS-Dev, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, alexeymin, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D25873: [KCMs/Workspace] Add explanatory labels for click-related settings

2019-12-27 Thread Christian
Fuchs accepted this revision.
Fuchs added a comment.
This revision is now accepted and ready to land.


  Good for me, hopefully the upstream bug will be fixed, too :)

REPOSITORY
  R119 Plasma Desktop

BRANCH
  explanatory-text (branched from master)

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

To: ngraham, #vdg, #plasma, Fuchs
Cc: davidedmundson, ndavis, plasma-devel, LeGast00n, The-Feren-OS-Dev, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, 
ahiemstra, mart


D12463: Add support for icon-only tasks (what browsers call pinned tabs)

2019-12-14 Thread Christian
Fuchs added a comment.


  Then as soon as you actually run the app there will be a duplicate, the 
launcher and the entry in the task manager. If I understood correctly, pinned 
tabs in browsers avoid that. You have a small, icon only variant when not open 
and a full variant (at the same position) when open.

REPOSITORY
  R119 Plasma Desktop

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

To: Fuchs, hein
Cc: fabianr, ngraham, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, ZrenBot, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D12463: Add support for icon-only tasks (what browsers call pinned tabs)

2019-12-14 Thread Christian
Fuchs added a comment.


  If I remember correctly, the main argument against the launcher was that 
pinned apps should be pinned and thus not change their location / order, but 
exactly that would happen with a launcher once you open the app (that, or a 
duplicate entry in the window list)

REPOSITORY
  R119 Plasma Desktop

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

To: Fuchs, hein
Cc: fabianr, ngraham, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, ZrenBot, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D25873: [KCMs/Workspace] Add explanatory labels for click-related settings

2019-12-11 Thread Christian
Fuchs added a comment.


  Sidenote, maybe an upstream bug / wish can be added about
  
  > Oh darn, so it does. I checked the docs and tried setting 
SH_ScrollBar_MiddleClickAbsolutePosition explicitly, but it looks like there's 
actually no option to do page-by-page navigation for clicking in the scroll 
track when using the left-click-warps-slider style :/
  
  Thanks for adding the help text :)

REPOSITORY
  R119 Plasma Desktop

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

To: ngraham, #vdg, #plasma, Fuchs
Cc: ndavis, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, 
GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D22382: Add global shortcuts for switching to the previous/next activity

2019-10-22 Thread Christian Muehlhaeuser
muesli added a comment.


  Would love to finish this one up! :)
  Any suggestions how to move forward?

REPOSITORY
  R120 Plasma Workspace

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

To: muesli, apol, davidedmundson, #vdg, #plasma
Cc: ngraham, romangg, ivan, plasma-devel, LeGast00n, The-Feren-OS-Dev, 
jraleigh, fbampaloukas, GB_2, ragreen, ZrenBot, alexeymin, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D22381: Add previous-/nextActivity methods

2019-10-03 Thread Christian Muehlhaeuser
This revision was automatically updated to reflect the committed changes.
muesli marked an inline comment as done.
Closed by commit R161:e3a7cb2f1b18: Add previous-/nextActivity methods 
(authored by muesli).

REPOSITORY
  R161 KActivity Manager Service

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22381?vs=67276&id=67278

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

AFFECTED FILES
  src/common/dbus/org.kde.ActivityManager.Activities.xml
  src/service/Activities.cpp
  src/service/Activities.h
  src/service/Activities_p.h

To: muesli, ivan
Cc: ivan, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, 
GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D22381: Add previous-/nextActivity methods

2019-10-03 Thread Christian Muehlhaeuser
muesli updated this revision to Diff 67276.
muesli added a comment.


  Fix typo in 'nameBasedOrdering'

REPOSITORY
  R161 KActivity Manager Service

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22381?vs=61590&id=67276

BRANCH
  prevnext-activity (branched from master)

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

AFFECTED FILES
  src/common/dbus/org.kde.ActivityManager.Activities.xml
  src/service/Activities.cpp
  src/service/Activities.h
  src/service/Activities_p.h

To: muesli, ivan
Cc: ivan, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, 
GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D22382: Add global shortcuts for switching to the previous/next activity

2019-10-03 Thread Christian Muehlhaeuser
muesli added a comment.


  In D22382#541626 , @ivan wrote:
  
  > I'm not thrilled about having default shortcuts set. We have the shortcuts 
space quite polluted as it is.
  
  
  I'm happy to remove the defaults (even though I consider them fairly 
consistent with our other defaults), but at least users can still define their 
own global shortcuts then.
  
  > Maybe the text should explicitly state what 'next' means in this case.
  
  Like: "switch to next activity (in alphabetical order)"?

REPOSITORY
  R120 Plasma Workspace

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

To: muesli, apol, davidedmundson
Cc: ivan, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, 
GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D22381: Add previous-/nextActivity methods

2019-07-11 Thread Christian Muehlhaeuser
muesli updated this revision to Diff 61590.
muesli added a comment.


  Move nameBaseOrdering to an anonymous namespace and mark it as inline.

REPOSITORY
  R161 KActivity Manager Service

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22381?vs=61589&id=61590

BRANCH
  prevnext-activity (branched from master)

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

AFFECTED FILES
  src/common/dbus/org.kde.ActivityManager.Activities.xml
  src/service/Activities.cpp
  src/service/Activities.h
  src/service/Activities_p.h

To: muesli, ivan
Cc: ivan, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D22381: Add previous-/nextActivity methods

2019-07-11 Thread Christian Muehlhaeuser
muesli updated this revision to Diff 61589.
muesli added a comment.


  Addressed @ivan's change requests
  
  Summary:
  
  - Renamed sorting method to nameBaseOrdering
  - Remove activity from sorted cache without re-sorting the entire list
  - Switch to prev/next running activity, skipping other states

REPOSITORY
  R161 KActivity Manager Service

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22381?vs=61588&id=61589

BRANCH
  prevnext-activity (branched from master)

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

AFFECTED FILES
  src/common/dbus/org.kde.ActivityManager.Activities.xml
  src/service/Activities.cpp
  src/service/Activities.h
  src/service/Activities_p.h

To: muesli, ivan
Cc: ivan, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D22381: Add previous-/nextActivity methods

2019-07-11 Thread Christian Muehlhaeuser
muesli updated this revision to Diff 61588.
muesli added a comment.


  Use a QVector instead of a QList to store sorted activities.

REPOSITORY
  R161 KActivity Manager Service

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22381?vs=61579&id=61588

BRANCH
  prevnext-activity (branched from master)

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

AFFECTED FILES
  src/common/dbus/org.kde.ActivityManager.Activities.xml
  src/service/Activities.cpp
  src/service/Activities.h
  src/service/Activities_p.h

To: muesli, ivan
Cc: ivan, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D22396: Fix typo in CREATE_GETTER_AND_SETTER

2019-07-11 Thread Christian Muehlhaeuser
This revision was automatically updated to reflect the committed changes.
Closed by commit R161:d15446776e23: Fix typo in CREATE_GETTER_AND_SETTER 
(authored by muesli).

REPOSITORY
  R161 KActivity Manager Service

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22396?vs=61581&id=61586

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

AFFECTED FILES
  src/service/Activities.cpp

To: muesli, ivan, davidedmundson
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart


D22396: Fix typo in CREATE_GETTER_AND_SETTER

2019-07-11 Thread Christian Muehlhaeuser
muesli created this revision.
muesli added a reviewer: ivan.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
muesli requested review of this revision.

REVISION SUMMARY
  Fix typo when undefining CREATE_GETTER_AND_SETTER.

REPOSITORY
  R161 KActivity Manager Service

BRANCH
  undef-typo (branched from master)

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

AFFECTED FILES
  src/service/Activities.cpp

To: muesli, ivan
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart


D22381: Add previous-/nextActivity methods

2019-07-11 Thread Christian Muehlhaeuser
muesli updated this revision to Diff 61579.
muesli added a comment.


  Keep an alphabetically sorted list of activities
  
  Summary:
  Instead of re-sorting the activity list every time previous-/nextActivity gets
  called, maintain a sorted list.

REPOSITORY
  R161 KActivity Manager Service

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22381?vs=61517&id=61579

BRANCH
  prevnext-activity (branched from master)

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

AFFECTED FILES
  src/common/dbus/org.kde.ActivityManager.Activities.xml
  src/service/Activities.cpp
  src/service/Activities.h
  src/service/Activities_p.h

To: muesli, ivan
Cc: ivan, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D22381: Add previous-/nextActivity methods

2019-07-10 Thread Christian Muehlhaeuser
muesli added inline comments.

INLINE COMMENTS

> ivan wrote in Activities.cpp:218
> I don't like the fact that it constantly resorts the activities.
> 
> The second problem is that ListActivities returns a list in one order, and 
> this traverses activities in another order. If this will work by name, 
> probably the List functions should as well.

List probably returns a fairly randomized (per session) list, seeing how it's 
returning keys() from a QHash. Maybe I misunderstood you on IRC, I thought 
you'd rather not store a sorted list here. Instead of keeping a sorted cache 
though, maybe we should just keep the original list in a sorted order?

REPOSITORY
  R161 KActivity Manager Service

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

To: muesli, ivan
Cc: ivan, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D22382: Add global shortcuts for switching to the previous/next activity

2019-07-10 Thread Christian Muehlhaeuser
muesli created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
muesli requested review of this revision.

REVISION SUMMARY
  We currently have a mouse-wheel action to switch to the previous/next desktop,
  but it wasn't possible to assign a global keyboard shortcut to these actions.
  
  I've assigned Ctrl-Meta-Left and Ctrl-Meta-Right respectively as the default
  shortcuts to these actions, as they seem to fit and are currently unused.

REPOSITORY
  R120 Plasma Workspace

BRANCH
  shortcut-prevnext-activity (branched from master)

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

AFFECTED FILES
  shell/shellcorona.cpp

To: muesli
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart


D22381: Add previous-/nextActivity methods

2019-07-10 Thread Christian Muehlhaeuser
muesli created this revision.
muesli added a reviewer: ivan.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
muesli requested review of this revision.

REVISION SUMMARY
  These two methods can be used to switch to the previous/next activity in
  alphabetical order. They are exposed via the DBus interface. This
  functionality can also be accessed by kactivities(-cli) and plasmashell, which
  currently both implement their own separate versions of it.
  
  @Ivan mentioned being a bit wary of keeping a sorted activity list in
  kactivitymanagerd, so I've opted to only retrieve and sort the list on demand
  here.

REPOSITORY
  R161 KActivity Manager Service

BRANCH
  prevnext-activity (branched from master)

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

AFFECTED FILES
  src/common/dbus/org.kde.ActivityManager.Activities.xml
  src/service/Activities.cpp
  src/service/Activities.h
  src/service/Activities_p.h

To: muesli, ivan
Cc: ivan, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D20569: RFC: Use more compact OSD

2019-04-15 Thread Christian
Fuchs added a comment.


  In D20569#450462 , @broulik wrote:
  
  > >   No matter where you place it, given that you can e.g. press the volume 
button multiple times whilst notifications are incoming, placement will be 
tricky and, depending on how it is solved, jumpy.
  >
  > With the new system shouldn't it be too bad. I can stick the OSD at the 
position closest to the panel so it never moves as notifications come and go, 
they would just be positioned above/below the sticky OSD. That's what I'm doing 
with critical notifications and job progress there and it works well. Changing 
the sort order to prioritize "OSDs" even more than critical notifications is 
easy. The OSD will not jump, the notifications that are shifted ouf of the way 
might move, yes, but I don't think that's gonna be too awful.
  
  
  I consider things with clickable controls (notifications, in this case) 
jumping to rather be awful, so personally I'd prefer to keep notifications and 
OSD seperate, as they have separate purposes, lifetime and behaviour. 
  Especially as notifications are something you can only click on (touch or 
pointer device). It's already not 100% reliable as new notifications can pop 
in, but I'd like to not make this worse by also moving OSDs in there, if 
possible.
  
  I prefer the first, more centered approach for that.

REPOSITORY
  R120 Plasma Workspace

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

To: broulik, #plasma, #vdg
Cc: Codezela, Fuchs, filipf, zzag, plasma-devel, jraleigh, GB_2, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, 
mart


D20569: RFC: Use more compact OSD

2019-04-15 Thread Christian
Fuchs added a comment.


  I like the first, small but centered variant.
  
  But I can see how people might want it differently: most of the time I use my 
PC for work. I assume if you are watching movies on it, a centered design is 
more of a bother than a corner one, whilst for work the center one is easier to 
spot.
  
  Center also is rather sure to not clash with regular notifications, and I 
would not treat the OSD the same as notifications. No matter where you place 
it, given that you can e.g. press the volume button multiple times whilst 
notifications are incoming, placement will be tricky and, depending on how it 
is solved, jumpy.

REPOSITORY
  R120 Plasma Workspace

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

To: broulik, #plasma, #vdg
Cc: Fuchs, filipf, zzag, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart


D19257: [Task Manager] Fix virtual desktops subtext on task tooltip

2019-02-23 Thread Christian
Fuchs added a comment.


  One minor nitpick: if it is on all virtual desktops there is no text shown, 
maybe some "is on all virtual desktops" or so would be nice, for consistency.
  
  But it might entirely be that it didn't do that before either, at least the 
code looks like it. Also this would introduce a new string to translate. 
  Maybe in a second patch?

REPOSITORY
  R119 Plasma Desktop

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

To: hein, #plasma
Cc: Fuchs, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart


D19257: [Task Manager] Fix virtual desktops subtext on task tooltip

2019-02-23 Thread Christian
Fuchs added a comment.


  Yep, that works here, even with groups spanning multiple desktops. Thanks for 
the quick fix!

REPOSITORY
  R119 Plasma Desktop

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

To: hein, #plasma
Cc: Fuchs, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart


D16988: [Kickoff] Make the visible search field unfocused by default

2018-11-19 Thread Christian Hempfling
chempfling added a comment.


  In D16988#362160 , @rooty wrote:
  
  > Okay so from what I can tell:
  >
  > (1) Kicker takes the focus off the search field when you go through the 
results by either mouse or keyboard. This makes it easy to go back to the 
search field by typing or using the arrow keys (to add more words etc.)
  >  (2) Krunner becomes unfocused if you use the arrow keys, **but not if you 
hover over the search results with your mouse**, and it's still possible in 
either case to append your search same as in Kickoff.
  >  (3) Kickoff (the old, the master and this patch) seems to leave the search 
field focused at all times while you go through the results, and it's possible 
to add more characters to the search like in (1) and (2).
  >  (4) Clipboard behaves pretty much like this patch except //pressing the 
Esc key doesn't make it unfocused again//.
  >
  > Any thoughts on how to reconcile all these differences? It might take some 
doing 😅
  
  
  Howdy,
  
  just for clearification :). With focus and unfocuse we talk about "focus: 
true", not only an highlighting effect?

REPOSITORY
  R119 Plasma Desktop

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

To: rooty, #plasma, #vdg, romangg, ngraham, davidedmundson
Cc: gladhorn, chempfling, filipf, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart


D16309: Add accessibility information to desktop icons

2018-10-22 Thread Christian Hempfling
chempfling added a comment.


  In D16309#347071 , @hein wrote:
  
  > I'll land it for you (it needs a manual step, which requires a dev account 
- which you should eventually apply for if you wind up contributing regularly!).
  
  
  Ok Thanks,
  I ll try to get an dev acount. let me check how to i get one.

REPOSITORY
  R119 Plasma Desktop

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

To: chempfling, hein, gladhorn
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D16309: Add accessibility information to desktop icons

2018-10-19 Thread Christian Hempfling
chempfling added a comment.


  Ok, so nothing to do then.   Is this merged automatically once  per day or 
something? Or how do i get the patch into master now? I mark the task as done.

REPOSITORY
  R119 Plasma Desktop

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

To: chempfling, hein, gladhorn
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D16309: Add accessibility information to desktop icons

2018-10-19 Thread Christian Hempfling
chempfling added a comment.


  Do i need to do anythin else to get it into master?

REPOSITORY
  R119 Plasma Desktop

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

To: chempfling, hein, gladhorn
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D16309: Add accessibility information to desktop icons

2018-10-19 Thread Christian Hempfling
chempfling added inline comments.

INLINE COMMENTS

> gladhorn wrote in FolderItemDelegate.qml:45
> Is Canvas what Gnome uses for desktop icons? I'm fine with this, since I 
> don't have a better suggestion.

Canvas is used by Nautilus. The default filemanager.

Joanie would prefer the Role „Icon“ what we didn’t find in the documentation.
Just „Graphics“ what is to be assumed as image or picture.

See joanies answer:
https://mail.gnome.org/archives/orca-list/2018-October/msg00215.html

Canvas works as exceped, i tried.

REPOSITORY
  R119 Plasma Desktop

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

To: chempfling, hein, gladhorn
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D14105: Use a broom-style icon for clearing clipboard and notification history

2018-07-15 Thread Christian
Fuchs accepted this revision.
Fuchs added a comment.


  if it falls back then all is perfect :)

REPOSITORY
  R120 Plasma Workspace

BRANCH
  broom-style-clear-history-icon (branched from master)

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

To: ngraham, broulik, Fuchs, #plasma, davidedmundson
Cc: Zren, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D14105: Use a broom-style icon for clearing clipboard and notification history

2018-07-15 Thread Christian
Fuchs added a comment.


  In D14105#292183 , @ngraham wrote:
  
  > Thanks! @fuchs and/or @broulik?
  
  
  Can't test it currently, looks fine, just one question: did you test what 
happens on other icon sets than breeze? 
  If that doesn't work, I'd say we should fix it in the icon theme, but that 
would be something that would make me think don't ship yet.
  
  Otherwise I'd say ship :)

REPOSITORY
  R120 Plasma Workspace

BRANCH
  broom-style-clear-history-icon (branched from master)

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

To: ngraham, broulik, Fuchs, #plasma, davidedmundson
Cc: Zren, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D13593: [Fonts KCM] Improve user-friendliness of some anti-aliasing strings

2018-06-19 Thread Christian
Fuchs added a comment.


  In D13593#280112 , @ngraham wrote:
  
  > How about in a tooltip?
  
  
  whatever is search- and findable, I guess.

REPOSITORY
  R119 Plasma Desktop

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

To: ngraham, #plasma, #vdg
Cc: Fuchs, abetts, nicolasfella, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart


D13593: [Fonts KCM] Improve user-friendliness of some anti-aliasing strings

2018-06-19 Thread Christian
Fuchs added a comment.


  Maybe add the technical term in brackets though, for those people who search 
for the technical term and don't find it otherwise?

REPOSITORY
  R119 Plasma Desktop

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

To: ngraham, #plasma, #vdg
Cc: Fuchs, abetts, nicolasfella, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart


D12969: [Kicker] Only show "Add to Panel (Widget)" When there's no Task Manager

2018-05-22 Thread Christian
Fuchs added a comment.


  In D12969#266503 , @hein wrote:
  
  >
  
  
  
  
  > In that case I would honestly argument for dropping Task Manager pinning 
entirely: I've never entirely liked that it complicates the Task Manager toward 
doing multiple things, and that makes it have to contend with having 
different-sized items, and that means launchers aren't just straight-forward 
panel items that can be moved anywhere (this gets a lot of user bug reports too 
btw).
  
  Oof. As a user of icon-only task manager I heavily rely on pinned tasks, as 
they work great for muscle memory and otherwise the task manager is just an 
empty waste of space. 
  And I don't think it's only a lack of feature parity, if you have launchers 
and a task manager you end up with two entries if the application is running, 
and for icon-only task manager both of them will look almost the same  (except 
the little bar showing it is a window).
  
  Personally I'd rather get rid of the launcher widget thing, since this is 
also what Windows does and, as far as I am aware, what Mac OS does (I don't use 
a Mac, but I think the dock there is mostly this)
  
  I assume this is one of the areas where lot of people have different 
workflows  (i.e. I would never use the "icon only" thing I wrote myself, but 
multiple people asked for it and it seems to greatly improve their efficiency) 
and thus we have loads of options. 
  Personally I am in favour of keeping most of them if possible, just with sane 
defaults and also (more) sane ways of accessing them.
  
  So I would prefer some discussion and mind-mapping before throwing more 
patches at it, as this will spread the discussion over various places.

REPOSITORY
  R119 Plasma Desktop

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

To: ngraham, #plasma, mart
Cc: sharvey, Fuchs, hein, mart, davidedmundson, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol


D12969: [Kicker] Only show "Add to Panel (Widget)" When there's no Task Manager

2018-05-22 Thread Christian
Fuchs added a comment.


  Maybe we need to discuss things, especially also with 
https://phabricator.kde.org/D12463 where I have an interest in, on a broader 
scale.
  
  I agree that both need to exist and have different use cases, personally I 
think I'd only show the task manager pin in the context menu though, since the 
widgets are likely to be used by power users and placed manually where wanted.
  
  Note that I am only somewhat happy with the task manager pinning as well, 
since in task manager you are forced to choose which activities it shall be 
pinned on, whilst in the context menu of kicker you only have the possibility 
to pin it to all of them. 
  (And personally I consider pinning to be activity dependant way more 
complicated than having both options to pin and have a launcher)

REPOSITORY
  R119 Plasma Desktop

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

To: ngraham, #plasma, mart
Cc: Fuchs, hein, mart, davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol


D12462: Add support for icon-only tasks (what browsers call pinned tabs)

2018-05-02 Thread Christian
Fuchs added a comment.


  In D12462#257021 , @mart wrote:
  
  > In D12462#252987 , @Fuchs wrote:
  >
  > > In D12462#252982 , @mart wrote:
  > >
  > > > I like the idea a lot,
  > > >  tough i am not sure i like the implementation: right now is kindof 
hortogonal to pinned tasks and gets confusing as it has a partial, but not 
complete overlap.
  > > >  I think this should just be the behavior for pinned tasks, in order to 
map perfectly to the workflow of browser pinned tasks (and have only one 
option, pin task, instead of pin task and remove text)
  > >
  > >
  > > Pinned tasks, right now, are bound to activities iff the amount of 
activities is >= 2. So these do different things  (arguably current "pin" is 
badly named):
  >
  >
  > a task still, can be pinned to all activities, so still seems like an 
useless complication to me.
  >
  > to me pinning should mean:
  >
  > - i say what are the most important tasks to me (regardless if it's for one 
activity or for all activities)
  > - i want them always there, no matter whether running or not
  > - they stay always exactly in the same place (muscle memory) therefore 
can't have text and never move when they are started
  >
  >   to achieve that, i should do one action, not 2, it looks like bad UI for 
me otherwise.
  
  
  Personally I think that "don't show label" and "always show entry" are two 
entirely different use cases, especially as "don't show label" simply does not 
exist in icons-only taskmanager, whilst "always show entry" does. Calling 
either of them pinned is, imho, a bad idea. 
  Whether it should or should not be bound to activities is not something I can 
comment on, since I simply don't use activities.
  
  Muscle memory is why I use icons only task manager, the "do not show label" 
thing is more for users who use the "regular" task manager, and I think for a 
majority of them it's indeed two different use cases. 
  Maybe one could have something a bit more smart, similar to sorting, where 
you can decide whether you want to manually tell which labels not to show, or 
all matching a specific rule, e.g.  "has a launcher".

REPOSITORY
  R120 Plasma Workspace

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

To: Fuchs, hein
Cc: mart, fabianr, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol


D12462: Add support for icon-only tasks (what browsers call pinned tabs)

2018-04-24 Thread Christian
Fuchs added a comment.


  In D12462#252982 , @mart wrote:
  
  > I like the idea a lot,
  >  tough i am not sure i like the implementation: right now is kindof 
hortogonal to pinned tasks and gets confusing as it has a partial, but not 
complete overlap.
  >  I think this should just be the behavior for pinned tasks, in order to map 
perfectly to the workflow of browser pinned tasks (and have only one option, 
pin task, instead of pin task and remove text)
  
  
  Pinned tasks, right now, are bound to activities iff the amount of activities 
is >= 2. So these do different things  (arguably current "pin" is badly named):
  
  1. The current "pin" is based on activities, whilst my "always show only 
icon" is completely unrelated to activities. There are proper usecases for the 
former.
  2. My "always show only ucib" is only available in regular task manager, 
whilst current "pin" is obviously available in icon only task manager, as it is 
a seperate use case  ("launcher")
  
  So they can't be fusioned easily.
  
  I agree that a launcher (currently called pin) looks, when not running, 
almost the same as "always show only icon". The difference is the small bar on 
top (bottom if your panel is top), which correctly makes it look like an open 
window (which it is) and it's state  (active, demands attention., minimized, 
whatnot)
  
  I think both have valid use cases and potentially both are needed, but maybe 
they could both be polished a bit so they are aptly named and look and act 
distinguishable.

REPOSITORY
  R120 Plasma Workspace

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

To: Fuchs, hein
Cc: mart, fabianr, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol


D12462: Add support for icon-only tasks (what browsers call pinned tabs)

2018-04-23 Thread Christian
Fuchs added a comment.


  On the existing bug: it's related to the TODO, changing that to
  
for (int i = 0; i < d->concatProxyModel->rowCount(); ++i) {
const QModelIndex &itIndex = d->concatProxyModel->index(i, 0);

// Launchers can't be pinned / unpinned
if (itIndex.data(AbstractTasksModel::IsLauncher).toBool()) {
continue;
}

dataChanged(itIndex, itIndex, 
QVector{AbstractTasksModel::IsPinned});

}
  
  fixes the bug, but of course that goes through all items and not only the 
needed ones, so it's bad performance-wise.
  

  
  Oddly enough, changing the second part to
  
// Check all windows if they match, then update the isPinned for them too. 
// This is needed so if you pin / unpin an app that has multiple instances 
open, all are updated.
if (appsMatch(index, itIndex)) {
dataChanged(itIndex, itIndex, 
QVector{AbstractTasksModel::IsPinned});
}
  
  matched only parts of the same window, so if I e.g. had 3 konsole instances 
open, it affected 2/3 sometimes.
  
  No idea what I am doing wrong here, hopefully @hein  will know what list I 
best iterate over and how to best compare them, so it's not only fixed, but 
fixed without performance impact.

REPOSITORY
  R120 Plasma Workspace

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

To: Fuchs, hein
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D12463: Add support for icon-only tasks (what browsers call pinned tabs)

2018-04-23 Thread Christian
Fuchs added a comment.


  In D12463#252419 , @ngraham wrote:
  
  > This is a neat feature, but I worry that it would muddy the difference 
between the regular task manager and the icons-only task manager. It's not 
inconceivable that a user wanting to get an IOTM-style panel would resort to 
using this feature to force every single window to be icon-only.
  
  
  Well, personally I am not going to use it as I use icon tasks, but the people 
who wished for it seem to not want icon tasks,
  
  Initial discussion  in the VDG group was (anonymized, for now):
  
  anon1, [08.03.18 16:06]
  [In reply to KDE IRC Relay Service]
  if you "pin" an app you get an starter icon, if the app is not running, but a 
full task bar entry, if the app is running.
  
  But there is no way to "pin" like in a browser, icon only even when running.
  
  KDE IRC Relay Service, [08.03.18 16:06]
   ah that
   yeah I wish we had that
   (and no, I dont want to change to icon tasks)
  
  anon1, [08.03.18 16:07]
  then there would be far less need to minimize to systray
  
  KDE IRC Relay Service, [08.03.18 16:08]
   KMail shows unread mail count in task bar, has "check for mail" 
option in the menu, so I dont see a reason for kmail tray icon for instance
  
  anon1, [08.03.18 16:09]
  I only show windows from the current screen in the task bar
  
  anon1, [08.03.18 16:09]
  current virtual desktop *
  
  and https://forum.kde.org/viewtopic.php?f=285&t=136113  was thrown at me, 
which has some discussion as well.
  
  I can see definitely some valid points, e.g. having it for applications you 
only have one instance (which makes the window title irrelevant in most cases) 
and basically only care about the notification, kmail/kontact was named as an 
example, but I could see the same apply to chat / instant messaging systems.
  
  As said, personally I am not going to use it, but I definitely see good use 
cases which separates this from icon only(icon only is a massive pain if 
you often have multiple windows of the same application you need to be able to 
quickly distinguish)

REPOSITORY
  R119 Plasma Desktop

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

To: Fuchs, hein
Cc: ngraham, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D12462: Add support for icon-only tasks (what browsers call pinned tabs)

2018-04-22 Thread Christian
Fuchs added a comment.


  Also needs https://phabricator.kde.org/D12463
  
  What it does: adds a new menu entry for the non-icon-only task manager which 
allows to set an application "icon only", so it will always be displayed 
without label (like a launcher) even if in running state. 
  Both sorting and grouping are not affected and behave the same as they would 
for unpinned.
  
  currently looks like this: F5818318: pinned.png 

  
  Known issue:  if there are multiple windows of the same application, 
unpinning will leave the other instances without label. Didn't find out what 
causes this yet, would be happy for input. Newly created windows of the same 
type are not affected.

REPOSITORY
  R120 Plasma Workspace

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

To: Fuchs, hein
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D12463: Add support for icon-only tasks (what browsers call pinned tabs)

2018-04-22 Thread Christian
Fuchs created this revision.
Fuchs added a reviewer: hein.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
Fuchs requested review of this revision.

REVISION SUMMARY
  Frontend part for https://phabricator.kde.org/D12462, please check that as 
well for known issues and so on

REPOSITORY
  R119 Plasma Desktop

BRANCH
  taskmanager-pin (branched from master)

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

AFFECTED FILES
  applets/taskmanager/package/contents/config/main.xml
  applets/taskmanager/package/contents/ui/ContextMenu.qml
  applets/taskmanager/package/contents/ui/Task.qml
  applets/taskmanager/package/contents/ui/code/layout.js
  applets/taskmanager/package/contents/ui/main.qml

To: Fuchs, hein
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D12462: Add support for icon-only tasks (what browsers call pinned tabs)

2018-04-22 Thread Christian
Fuchs created this revision.
Fuchs added a reviewer: hein.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
Fuchs requested review of this revision.

REVISION SUMMARY
  This adds backend support for pinned tasks, which will only show an icon in 
the regular task manager (no impact on icons-only).

REPOSITORY
  R120 Plasma Workspace

BRANCH
  taskmanager-pin (branched from master)

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

AFFECTED FILES
  libtaskmanager/abstracttasksmodel.h
  libtaskmanager/taskgroupingproxymodel.cpp
  libtaskmanager/tasksmodel.cpp
  libtaskmanager/tasksmodel.h

To: Fuchs, hein
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D12161: [Kickoff] Support non-square icons

2018-04-12 Thread Christian
Fuchs added a comment.


  happy fox now happy, says thanks :)

REPOSITORY
  R119 Plasma Desktop

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

To: broulik, #plasma, #vdg, Fuchs, davidedmundson
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D11308: Use the default Plasma wallpaper on the lock screen

2018-03-16 Thread Christian
Fuchs added a comment.


  Personal opinions, based on discussions here and on TG
  
  - fixed, (default) wallpaper has the advantage of not risking privacy, not 
munching power and being usable in, at least from login to desktop to lock 
screen, have a consistent feel for new users. Downside is that it needs to be 
ensured, on every single new wallpaper release, that it looks good and is 
perfectly readable
  
  - slideshow: looks nice, but eats battery and is rarely ever seen, since the 
default use case of a lock screen is  "I am away from my device". Also in this 
case it has to look good and be readable on every potential wallpaper that 
might show up.
  
  - fixed colour: consistent from boot to desktop, simple, efficient. But 
apparently some people think it's not sexy.
  
  My personal preference is thus, in that order, default wallpaper, fixed 
colour, slide show.  Assuming we test and ensure that the default wallpaper 
looks good and all text is easy to read.

REPOSITORY
  R133 KScreenLocker

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

To: ngraham, #plasma, #vdg, graesslin, abetts
Cc: Fuchs, broulik, davidedmundson, zzag, Pitel, progwolff, abetts, hein, mart, 
graesslin, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol


D11356: [Media Controller] Show track length if available even if seeking isn't possible

2018-03-15 Thread Christian
Fuchs accepted this revision.
Fuchs added a comment.
This revision is now accepted and ready to land.


  +1, looks great to me. 
  Bit of duplicate control, but given there can be one at most, that seems fine 
to me.
  
  Also progress bar makes sense, since a playing track is progress, so it 
should even look good if other plasma themes decide to use something completely 
different looking for that compared to the slider.

REPOSITORY
  R120 Plasma Workspace

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

To: broulik, #plasma, #vdg, kossebau, Fuchs
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D11306: Give the "Clear History" button some text

2018-03-14 Thread Christian
Fuchs added a comment.


  In D11306#225695 , @ngraham wrote:
  
  > I agree that consistency is important! For that reason, I would propose 
adding text everywhere. Buttons without text are inherently ambiguous unless 
their icons are //perfect// (and even a broom icon doesn't quite get there 
IMHO, though it's better). I know designers hate excessive text, but users 
appreciate the clarity and obviousness of buttons with text.
  
  
  I'm willing to nod off (even though there I have no say in it there) a patch 
which adds it to all places  ( e.g. the klipper I linked) if reasonably sure 
that it works across languages  (so we don't have half of text in some 
languages, which is arguably worse than no text at all), but I'd like to give a 
clear, recognizable icon a try first.
  
  We have lots of other icons in plasmoids  (close notifications, mute, copy, 
menu, ...) that work well without text, some of them also destructive actions, 
so I'd like to give that a try first for the sake of space and not-clutterednes.
  
  I will comment on the clear-all bug and hope that something great comes out 
of this, then we can re-evaluate this one here :)

REPOSITORY
  R120 Plasma Workspace

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

To: ngraham, #plasma, Fuchs
Cc: broulik, zzag, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D11306: Give the "Clear History" button some text

2018-03-14 Thread Christian
Fuchs added a comment.


  In D11306#225691 , @ngraham wrote:
  
  > How about just "Clear" for the text? That should be short enough even in 
German, no? The word "history" is pretty redundant anyway.
  
  
  Actually the oppposite, if you only do "clear" it might become unclear in a 
few languages. I think the text is fine, really. I'd just prefer to have no 
text at all, consistent with the klipper one.
  
  > And yeah, I agree that we need a better icon for these. For that, I've 
filed https://bugs.kde.org/show_bug.cgi?id=391855.
  
  Wonderful, thank you. I still think a broom might do, it's what tango does, 
it doesn't depend on position of to-be-cleared icons and it is rather cultural 
independent. But that's something to discuss there.
  
  I'm afraid that I am going to be very strict on  "have a solution that is 
consistent with the rest", so I will reject all proposed changes that are not 
consistent across the board, which includes, right now, any kind of text. 
Sorry. For once I'd love to have a global solution and not partial solutions in 
some and not in other places. 
  As in: I see it as a valid problem, but I don't see adding this change here 
as a solution, so I stay with "no"
  
  Once we have a proper, recognizable icon I think we can use that in the cases 
named and do not need text, hopefully.

REPOSITORY
  R120 Plasma Workspace

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

To: ngraham, #plasma, Fuchs
Cc: broulik, zzag, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D11306: Give the "Clear History" button some text

2018-03-14 Thread Christian
Fuchs added a subscriber: broulik.
Fuchs added a comment.


  In D11306#225671 , @broulik wrote:
  
  > Do whatever you want with this button.
  
  
  Okay, recommendation: due to all plasma buttons that have an icon having it 
on the left (see e.g. F5753917: btns1.png 
) and klipper having a clear history 
functionality  (see F5753919: btn2.png )  
find a proper solution that works for both, e.g. an icon that is clear to 
understand, and then implement in both.
  
  Until then: leave the clear notification history as is.

REPOSITORY
  R120 Plasma Workspace

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

To: ngraham, #plasma, Fuchs
Cc: broulik, zzag, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart


D11306: Give the "Clear History" button some text

2018-03-14 Thread Christian
Fuchs added a comment.


  In D11306#225667 , @broulik wrote:
  
  > Either remove the icon or put it on the right, then I wouldn't really mind 
this change.
  
  
  putting it on the right would make it inconsistent with every single plasma 
and KDE button I am aware of, so I'd still mind.
  
  Removing the icon would make it inconsistent with the klipper plasmoid.
  
  I still think the proper solution is to have a proper, understandable icon 
which is used consistently across plasmoids, either of the three changes would 
do the exact opposite of that.

REPOSITORY
  R120 Plasma Workspace

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

To: ngraham, #plasma, broulik, Fuchs
Cc: zzag, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart


D11306: Give the "Clear History" button some text

2018-03-13 Thread Christian
Fuchs added a comment.


  Sorry, but clear -1 from me for the reasons outlined in the Telegram channel.
  
  It looks cluttered, and with the very limited space in plasmoids it becomes 
unpredictable with translations. 
  It removes the very alignment that broulik and I worked hard to achieve. 
  It is inconsistent with the klipper plasmoid, which had that exact 
functionality for years, so I think we can live with it until we fixed the 
actual problem, which is "we need a better, more clear icon".

REPOSITORY
  R120 Plasma Workspace

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

To: ngraham, #plasma, broulik, Fuchs
Cc: zzag, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart


D11261: Add a button to clear the notification history

2018-03-12 Thread Christian
Fuchs added a comment.


  In D11261#224058 , @abetts wrote:
  
  > In D11261#224056 , @Fuchs wrote:
  >
  > > In D11261#224054 , @abetts 
wrote:
  > >
  > > > We have discussed something like this before. My only worry with this 
implementation is that we have so much red on the screen that it becomes 
distracting. Not the fault of this patch, but I am wondering if there is a way 
that we can use a monochrome X button?
  > >
  > >
  > > Both broulik and I would have prefered the trash icon, however, due to 
consistency ...
  > >
  > > red, on the other hand, is good. It is a destructive action which can't 
be undone, so a bit of red doesn't hurt.
  >
  >
  > Then please use the same X icon at the top of the list, to clear all.
  
  
  I am definitely not going to use the same icon for different actions, sorry. 
That goes against everything I've been taught in UX and, for destructive 
actions, is in my opinion quite catastrophic. If two buttons do different 
things, they should not have the same icon.
  
  What should be fixed is that action-delete is something else in plasma (see 
screenshot) than in non-plasma (where it is a trash can, which would work).  If 
that is fixed, the icon also looks better, and fixed across every piece of qml 
that uses it. But that's a different bug.
  
  A different icon that has been proposed is "clear-all", however, due to the 
nature of that icon  (a left pointing arrow) it also looks wrong. Once that is 
fixed, I'd be willing to change to clear-all, but then as well it should be 
fixed across plasma, and not only in this plasmoid here.
  
  tl;dr:   until some icons are fixed and more global discussions have been 
held, I am not going to alter this change further.

REPOSITORY
  R120 Plasma Workspace

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

To: Fuchs, broulik
Cc: abetts, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol, mart


D11261: Add a button to clear the notification history

2018-03-12 Thread Christian
Fuchs added a comment.


  In D11261#224054 , @abetts wrote:
  
  > We have discussed something like this before. My only worry with this 
implementation is that we have so much red on the screen that it becomes 
distracting. Not the fault of this patch, but I am wondering if there is a way 
that we can use a monochrome X button?
  
  
  Both broulik and I would have prefered the trash icon, however, due to 
consistency ...
  
  red, on the other hand, is good. It is a destructive action which can't be 
undone, so a bit of red doesn't hurt.

REPOSITORY
  R120 Plasma Workspace

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

To: Fuchs, broulik
Cc: abetts, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol, mart


D11261: Add a button to clear the notification history

2018-03-12 Thread Christian
Fuchs closed this revision.

REPOSITORY
  R120 Plasma Workspace

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

To: Fuchs, broulik
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D11261: Add a button to clear the notification history

2018-03-12 Thread Christian
Fuchs added a comment.


  New screenshot with fixes F5750621: clearhistory.png 


REPOSITORY
  R120 Plasma Workspace

BRANCH
  fuchs-notification-clearhistory (branched from master)

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

To: Fuchs, broulik
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D11261: Add a button to clear the notification history

2018-03-12 Thread Christian
Fuchs updated this revision to Diff 29325.
Fuchs added a comment.


  - Better hack for placement

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11261?vs=29321&id=29325

BRANCH
  fuchs-notification-clearhistory (branched from master)

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

AFFECTED FILES
  applets/notifications/package/contents/ui/Notifications.qml

To: Fuchs, broulik
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D11261: Add a button to clear the notification history

2018-03-12 Thread Christian
Fuchs updated this revision to Diff 29321.
Fuchs added a comment.


  - Change the layout import according to kbroulik

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11261?vs=29320&id=29321

BRANCH
  fuchs-notification-clearhistory (branched from master)

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

AFFECTED FILES
  applets/notifications/package/contents/ui/Notifications.qml

To: Fuchs, broulik
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D11261: Add a button to clear the notification history

2018-03-12 Thread Christian
Fuchs updated this revision to Diff 29320.
Fuchs added a comment.


  - Use Math.round() as per discussion

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11261?vs=29319&id=29320

BRANCH
  fuchs-notification-clearhistory (branched from master)

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

AFFECTED FILES
  applets/notifications/package/contents/ui/Notifications.qml

To: Fuchs, broulik
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D11261: Add a button to clear the notification history

2018-03-12 Thread Christian
Fuchs updated this revision to Diff 29319.
Fuchs added a comment.


  - Capitalized History in the tooltip label as per discussion

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11261?vs=29318&id=29319

BRANCH
  fuchs-notification-clearhistory (branched from master)

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

AFFECTED FILES
  applets/notifications/package/contents/ui/Notifications.qml

To: Fuchs, broulik
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D11261: Add a button to clear the notification historyBUG: 386068FIXED-IN: 5.13.0

2018-03-12 Thread Christian
Fuchs added a comment.


  Screenshot:
  
  F5750498: clear_history.png 

REPOSITORY
  R120 Plasma Workspace

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

To: Fuchs, broulik
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D11261: Add a button to clear the notification historyBUG: 386068FIXED-IN: 5.13.0

2018-03-12 Thread Christian
Fuchs created this revision.
Fuchs added a reviewer: broulik.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
Fuchs requested review of this revision.

REVISION SUMMARY
  Adds a button in the plasmoid header to clear the history, same as the 
context menu

REPOSITORY
  R120 Plasma Workspace

BRANCH
  fuchs-notification-clearhistory (branched from master)

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

AFFECTED FILES
  applets/notifications/package/contents/ui/Notifications.qml

To: Fuchs, broulik
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D10901: Add "move to device" functionality to hamburger menu

2018-02-27 Thread Christian
Fuchs updated this revision to Diff 28221.
Fuchs added a comment.


  Adapt code style.
  
  With regards to wording: even if we can't guarantee that audio is playing / 
being recorded, the wording is still correct. 
  Since if there will be audio played / recorded, it will be on the device the 
user chooses. So it makes sense.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10901?vs=28219&id=28221

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

AFFECTED FILES
  applet/contents/ui/ListItemBase.qml

To: Fuchs, broulik, drosca
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart


D10901: Add "move to device" functionality to hamburger menu

2018-02-27 Thread Christian
Fuchs marked an inline comment as done.
Fuchs added a comment.


  In D10901#215274 , @ngraham wrote:
  
  > You're definitely not the only one who wants this. See:
  >
  > - 
https://www.reddit.com/r/kde/comments/7yrkmt/my_one_and_only_wish_please_excuse_the_terrible/
  > - https://bugs.kde.org/show_bug.cgi?id=384292
  >
  >   In fact, because this implements that feature, would you mind adding 
"FEATURE: 384292" into the Summary section on its own line, below other text? 
That's a special keyword that will make that bug get closed once this lands. 
See also 
https://community.kde.org/Infrastructure/Phabricator#Add_special_keywords
  
  
  Yeah, I read about these, I was simply too lazy to see if someone wanted 
that. Anyway, added in the summary plus commented on the bug report.
  
  The screenshot now is lost somehwere in phab backlog as it is no longer 
regarding the latest revision, but I assume you can find that :)

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

To: Fuchs, broulik, drosca
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart


D10901: Add "move to device" functionality to hamburger menu

2018-02-27 Thread Christian
Fuchs edited the summary of this revision.

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

To: Fuchs, broulik, drosca
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart


D10901: Add "move to device" functionality to hamburger menu

2018-02-27 Thread Christian
Fuchs updated this revision to Diff 28219.
Fuchs added a comment.


  Move text back to if/else for at least a bit of readability, reverted the 
check to go for > 1 since that is what we are interested in. Final revision, 
hopefully.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10901?vs=28218&id=28219

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

AFFECTED FILES
  applet/contents/ui/ListItemBase.qml

To: Fuchs, broulik, drosca
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart


D10901: Add "move to device" functionality to hamburger menu

2018-02-27 Thread Christian
Fuchs added a comment.


  In D10901#215263 , @ngraham wrote:
  
  > At this point, let me also mention that screenshots are not only much 
appreciated, but vastly increase the chance of your patch (and name!) being 
featured in the next week's installment of 
https://pointieststick.wordpress.com/category/usability-productivity/, 
especially for a much-requested feature like this one! :)
  
  
  F5732869: hamburger.png 
  
  I'm not sure whether it is worth a mention and I think I'm the only one 
requesting it so far (might be wrong), but if you want to add me: sure. 
Screenshot above (assuming this worked, I am new to phab), the name is Fuchs. 
Thanks. And sorry for the misunderstanding.

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

To: Fuchs, broulik, drosca
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart


D10901: Add "move to device" functionality to hamburger menu

2018-02-27 Thread Christian
Fuchs updated this revision to Diff 28218.
Fuchs marked an inline comment as done.
Fuchs added a comment.


  According to discussion on IRC, sacrifice some more readability for brevity.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10901?vs=28214&id=28218

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

AFFECTED FILES
  applet/contents/ui/ListItemBase.qml

To: Fuchs, broulik, drosca
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart


D10901: Add "move to device" functionality to hamburger menu

2018-02-27 Thread Christian
Fuchs updated this revision to Diff 28214.
Fuchs added a comment.


  Updated the text, tried to merge the code blocks. Due to most of it happening 
in a for loop depending on the type, this was not possible in a sane way 
without having a helper method created.
  
  Personally I think legibility goes a tad bit down. If made easier to read, 
performance would go suffer (e.g. executing parts of it despite it not going to 
be shown anyway). 
  I also think the .count variant is a bit easier to read, but take whichever 
you prefer.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10901?vs=28212&id=28214

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

AFFECTED FILES
  applet/contents/ui/ListItemBase.qml

To: Fuchs, broulik, drosca
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart


D10901: Add "move to device" functionality to hamburger menu

2018-02-27 Thread Christian
Fuchs added a comment.


  In D10901#215244 , @drosca wrote:
  
  >
  
  
  
  
  > Can you merge the code into one block?
  
  Technically yes, but due to some edge cases it will make it hacky and 
difficult to read.
  
  Example: you can have a second device connected which is only an output 
(bluetooth speakers), but no input. Therefore before adding the menu entries 
you have to check whether there are currently available output or input types, 
depending on the situation. 
  So there will be a lot of conditionals, not just for setting labels, but for 
actual logic.
  
  I'll see which is the least bad attempt at that and upload a second diff, but 
I am not conviced it will be nicer.

REPOSITORY
  R115 Plasma Audio Volume Applet

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

To: Fuchs, broulik, drosca
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart


D10901: Add "move to device" functionality to hamburger menu

2018-02-27 Thread Christian
Fuchs created this revision.
Fuchs added reviewers: broulik, drosca.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
Fuchs requested review of this revision.

REVISION SUMMARY
  This patch adds the possibility to choose a device for a playback / recording 
stream in the hamburger menu. 
  As per the discussion with the developers, the drag & drop functionality 
stays untouched and is still available.
  
  This is added to be a bit more consistent with the kcm and to make the 
functionality easier to discover.
  
  The menu is only shown when there are more than one possibilities to choose 
from in order to not confuse users.

TEST PLAN
  Apply patch.
  Have multiple output and input devices. 
  Move streams between devices and see if it works.

REPOSITORY
  R115 Plasma Audio Volume Applet

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

AFFECTED FILES
  applet/contents/ui/ListItemBase.qml

To: Fuchs, broulik, drosca
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart


D10223: Improve preview thumbnail quality

2018-02-08 Thread Christian López
christianlopez added a comment.


  Hi, i was playing a bit with the code and i'm noticing you can get good 
looking images without activating the smooth and without making the thumbnails 
look blurry, also i think i know the reason why the thumbnails look distorted. 
At the line 239 in  FolderItemDelegate.qml there's the object 
PlasmaCore.IconItem which has the properties width and height. At the momen:  
the properties are calculated the following way:
  
width: root.useListViewMode ? main.GridView.view.iconSize : (parent.width - 
2 * units.smallSpacing)
height: main.GridView.view.iconSize
  
  I notices this produces numbers like: width: 81.5714 height: 48 or with: 
97.8333 height, 64 or width: 64.35 height: 32
  In all this cases both numbers are very different and i noticed the more 
different this numbers are between them the more distorted and blocky the 
thumbnail looks, i managed to produce perfectly looking thumbnails by putting 
the same number in both fields, for example: width: 80 height: 80, 
interestingly this doesn't affects the proportions of the thumbnails.
  
  The problem is that if the icons are configured, for example to have an icon 
size of 48 they'll be much smaller if we use: width: 48 height 48, and if we 
use the calculated value of 81.57 in both: width: 81.57 height: 81.57 the 
thumbnails will be very big so there must be a way set the same number on both 
properties while making the thumbnails to be shown at the desired size.
  
  Here's how it looks normally with the calculated values in the code (width: 
97.8333 height: 64):
  F5698834: Screenshot_20180208_115655.png 

  
  This is how it looks if i set with: 64 height: 64 :
  F5698842: Screenshot_20180208_115930.png 

  
  This is how it looks if i set with: 98 height: 98 :
  F5698844: Screenshot_20180208_120034.png 

  
  I don't know if this information may help, it's the first time i try to 
modify the code of plasma.

REPOSITORY
  R119 Plasma Desktop

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

To: hein, #plasma, broulik, ngraham
Cc: christianlopez, markg, broulik, ngraham, kossebau, plasma-devel, ZrenBot, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart


[Plasma Workspace Wallpapers] [Bug 379003] Wallpaper "Picture of the Day" from National Geographics only changing after reboot or not at all.

2017-07-10 Thread Christian
https://bugs.kde.org/show_bug.cgi?id=379003

--- Comment #14 from Christian  ---
Has this patch been reviewed and been made available yet in Neon?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Plasma Workspace Wallpapers] [Bug 379003] Wallpaper "Picture of the Day" from National Geographics only changing after reboot or not at all.

2017-05-10 Thread Christian
https://bugs.kde.org/show_bug.cgi?id=379003

--- Comment #13 from Christian  ---
It was called the KDE desktop back when I started using Linux so the whole
Plasma concept hasn't stuck yet 😊 Good thing out may get into Plasma so I can
use this wallpaper option again. Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Plasma Workspace Wallpapers] [Bug 379003] Wallpaper "Picture of the Day" from National Geographics only changing after reboot or not at all.

2017-05-09 Thread Christian
https://bugs.kde.org/show_bug.cgi?id=379003

--- Comment #11 from Christian  ---
As a non-developer I guess I have to wait until this makes it into KDE before I
will be able to use the NatGeo wallpaper again?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Plasma Workspace Wallpapers] [Bug 379003] Wallpaper "Picture of the Day" from National Geographics only changing after reboot or not at all.

2017-04-21 Thread Christian
https://bugs.kde.org/show_bug.cgi?id=379003

--- Comment #6 from Christian  ---
(In reply to Kai Uwe Broulik from comment #4)
> We run QXmlStreamReader over the page to find the og:image of the picture.
> 
> However, HTML isn't strictly XML and so it chokes on the lines which come
> before the "og:image" meta tag:
> 
>  href="//fonts.ngeo.com/haas/1-0-0/NHaasGroteskDSPro-55Rg.woff2" as="font"
> type="font/woff2" crossorigin>
> 
> (note the "crossorigin" without a value which isn't valid XML)

Does that mean that Nat Geo POtD won't be available anymore or could it be
fixed?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Plasma Workspace Wallpapers] [Bug 379003] Wallpaper "Picture of the Day" from National Geographics only changing after reboot or not at all.

2017-04-21 Thread Christian
https://bugs.kde.org/show_bug.cgi?id=379003

--- Comment #5 from Christian  ---
(In reply to Clemens from comment #3)
> In my case, it does not work at all.
> Even after I reboot, the picture is not available.
> 
> Plasma Version 5.9.4

I guess I wasn't being clear. Even before it started not working at all it
didn't change to the new picture every 24 hours. I either had to reboot or wait
for days for it to change. On the lock screen it changed, but not on the
desktop without a reboot or after several days. Now it doesn't work at all but
I was wondering if the delay or having to reboot could be @a different issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Plasma Workspace Wallpapers] [Bug 379003] Wallpaper "Picture of the Day" from National Geographics only changing after reboot or not at all.

2017-04-20 Thread Christian
https://bugs.kde.org/show_bug.cgi?id=379003

--- Comment #2 from Christian  ---
Good to know it's not only me, thanks. I still have the problem that the
picture isn't changing until I reboot or after more than 24 hours. But that may
be a second unrelated bug. We'll see if/when the issue with URL is fixed c

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Plasma Workspace Wallpapers] [Bug 379003] New: Wallpaper "Picture of the Day" from National Geographics only changing after reboot or not at all.

2017-04-20 Thread Christian
https://bugs.kde.org/show_bug.cgi?id=379003

Bug ID: 379003
   Summary: Wallpaper "Picture of the Day" from National
Geographics only changing after reboot or not at all.
   Product: Plasma Workspace Wallpapers
   Version: 5.9.4
  Platform: Neon Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-devel@kde.org
  Reporter: christ...@vivaldi.net
  Target Milestone: ---

I have had Picture of the Day from National Geographics set since I installed
Neon User Edition a couple of months ago. It worked for a while but mostly
changed after logout/in or after reboot. Sometimes after 48 hours or more,
never after 24 hours, but now not at all. The same wallpaper has been set for
10 days or so. Reboot doesn't trigger and update. I have checked the National
Geographics site and the picture of the day has change several times since the
one I've got was issued.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Differential] [Commented On] D4838: [Notifications] Add context menu for thumbnail

2017-03-01 Thread Christian
Fuchs added a comment.


  In https://phabricator.kde.org/D4838#91385, @colomar wrote:
  
  > > Okay, personal opinion on why split buttons are among the most horrible 
things related to UX:
  > >  (And whilst some of these points might not apply to this very specific 
use case here: they will elsewhere, and once one component users this button, 
others will too, see e.g. spectacle)
  > > 
  > > - They are very prone to accidental clicks. If you  want to click the 
(little) arrow but hit the button instead, worst case you get an undoable, 
destructive action. This gets a lot worse with touch.
  >
  >
  >
  > 1. You should not use a split button with the main button performing a 
destructive action, of course.
  
  
  What would you use then? Also I think it's rather odd if you have to limit a 
certain UI element to the kind of actions it might contain.
  
  > 2. Plasma Desktop is not optimized for touch input, Plasma Mobile certainly 
would not not use them. And as you say yourself below, a context menu does not 
work for touch, either.
  
  *sigh*  then we'd even have another different behaviour depending on device 
type. That can be good, but in this case it would not be needed, as there are 
options that would work for both.
  
  A context menu would work if plasma would have the proper touch support to 
bring it up on long touch  (interestingly enough, plasma does long touch in 
other areas where one doesn't expect it, but that would get off-topic)
  
  >> - They are horrible for handicapped people. Screen readers usually don't 
handle them properly, so these people are only aware of one action, and might 
not be able to see the others
  > 
  > How do context menus work with screen readers?
  
  They are properly read, either item by item or on hover, depending a bit on 
the context and software here.
  
  >> - They are horrible for keyboard based navigation (see above on not 
applying for this very specific use case): which button presses them? Which one 
opens then?
  > 
  > Split buttons are usually used in toolbars, which are never good for 
keyboard navigation. That's what menu bars are for.
  
  Yaeah, no. See spectacle. Also:
  
  >> **(And whilst some of these points might not apply to this very specific 
use case here: they will elsewhere, and once one component users this button, 
others will too, see e.g. spectacle)**
  
  (emphasis added)
  
  Which also goes for your answer to notmart, as them being properly designed. 
Look at spectacle, there you have both a drop down and a split button. 
Differences are minimal (a small splitter) and as expected, keyboard navigation 
does not work. So I am highly against introducing even more split buttons, as 
it might encourage people to use them, despite them being bad in so many 
aspects.
  
  >> - Space. These buttons have text on them, text that is translatable and 
might be a lot bigger in e.g. German.  The buttons in notifications already 
suffer from this (e.g. bluetooth received files, in German) and it only gets 
worse if you add multiple options and an additional arrow
  > 
  > Is that arrow really taking up that much space?
  
  No, the action is. You end up with translatable text which you always have to 
show, a problem you neither have with a hamburger menu  (which is always the 
same size, language independent, if used with an icon) or with a pop up menu, 
because in both variants you only have to show the text on an overlay, not all 
the time. All the time already is tricky  (see e.g. the text on buttons when 
you receive a file via bluetooth, with de_DE) and it only gets worse if you add 
more elements like a splitter and arrow.
  
  >> - They would obviously not work well with multiple items as per the 
example above, if you e.g. wanted item specific actions
  > 
  > As I said: Neither does the simple button. The split button wouldn't be the 
one crrating the problem. And it would not _replace_ the context menu, either.
  
  Yes, the simple button doesn't work either, but the split button does not 
only not solve many problems, it even adds some.
  
  >> What would work are either context menus as proposed  (touch is going to 
be meh though, as I just learned that we can't properply do long press anywere) 
or a button that only has the purpose of opening a menu, e.g.: hamburger button.
  > 
  > Nobody said anything against the context menus, the split button would just 
be an additional, more discoverable means to access the functions.
  
  As far as I was informed on IRC, as far as I can see in the very discussion 
here: context menus were discouraged. 
  And no, as the split button would only be able to show a limited set of 
possible actions (e.g. not item specific actions) it would imo even do a worse 
job, because some actions would be discoverable, others not, so the user would 
even more so think they don't exist.
  
  Short: context menu or hamburger menu are imo the most sensible options both 
UX wise and also with regards to

[Differential] [Commented On] D4838: [Notifications] Add context menu for thumbnail

2017-03-01 Thread Christian
Fuchs added a comment.


  In https://phabricator.kde.org/D4838#91010, @colomar wrote:
  
  > In https://phabricator.kde.org/D4838#91009, @subdiff wrote:
  >
  > > I thought of something like this: F2668672: 
Screenshot_20170228_114914.png 
  > >  Is this in line with the HIG?
  >
  >
  > That's the idea we've discussed above and yes, it is in line with the HIG.
  
  
  Okay, personal opinion on why split buttons are among the most horrible 
things related to UX:
  (And whilst some of these points might not apply to this very specific use 
case here: they will elsewhere, and once one component users this button, 
others will too, see e.g. spectacle)
  
  - They are very prone to accidental clicks. If you  want to click the 
(little) arrow but hit the button instead, worst case you get an undoable, 
destructive action. This gets a lot worse with touch.
  - They are horrible for handicapped people. Screen readers usually don't 
handle them properly, so these people are only aware of one action, and might 
not be able to see the others
  - They are horrible for keyboard based navigation (see above on not applying 
for this very specific use case): which button presses them? Which one opens 
then?
  - Space. These buttons have text on them, text that is translatable and might 
be a lot bigger in e.g. German.  The buttons in notifications already suffer 
from this (e.g. bluetooth received files, in German) and it only gets worse if 
you add multiple options and an additional arrow
  - They would obviously not work well with multiple items as per the example 
above, if you e.g. wanted item specific actions
  
  What would work are either context menus as proposed  (touch is going to be 
meh though, as I just learned that we can't properply do long press anywere) or 
a button that only has the purpose of opening a menu, e.g.: hamburger button.

REPOSITORY
  R120 Plasma Workspace

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

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

To: broulik, #plasma, #vdg
Cc: Fuchs, subdiff, colomar, plasma-devel, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol


[Breeze] [Bug 374311] it is too easy to activate context menu item if mouse moves during right-click

2016-12-30 Thread S . Christian Collins
https://bugs.kde.org/show_bug.cgi?id=374311

S. Christian Collins  changed:

   What|Removed |Added

 Resolution|--- |UPSTREAM
 Status|UNCONFIRMED |RESOLVED

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Breeze] [Bug 374311] it is too easy to activate context menu item if mouse moves during right-click

2016-12-30 Thread S . Christian Collins
https://bugs.kde.org/show_bug.cgi?id=374311

--- Comment #3 from S. Christian Collins  ---
I have reported this bug for Qt here:
https://bugreports.qt.io/browse/QTBUG-57849

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Breeze] [Bug 374311] New: it is too easy to activate context menu item if mouse moves during right-click

2016-12-29 Thread S . Christian Collins
https://bugs.kde.org/show_bug.cgi?id=374311

Bug ID: 374311
   Summary: it is too easy to activate context menu item if mouse
moves during right-click
   Product: Breeze
   Version: 5.8.5
  Platform: Neon Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-devel@kde.org
  Reporter: s_chriscoll...@hotmail.com
  Target Milestone: ---

Please see the following video:
https://youtu.be/5U9XQgf3NXI

When using applications in KDE, it is very easy to accidentally activate a
context menu item if the mouse cursor is not perfectly steady during the right
mouse click that brings up the menu. As you can see in the video, in some cases
the cursor only needs to travel 2 pixels between mouse press and release to
activate the menu item.

Steps to reproduce:
1. Open Dolphin and move it to the bottom right-hand corner of the screen.
2. Right-click (and keep the mouse button down) in the white space near the
bottom right-hand corner of Dolphin. The context menu should open just above
the mouse cursor.
3. Move the mouse up 2 pixels and release the mouse button.

Result: The bottom entry of the context menu is activated. The problem is that
this all too often happens very quickly if my mouse is not steady, or my
trackpad's accuracy sucks (which it does). For example, I can't tell you how
many times I've accidentally disabled a clip in this manner when editing videos
in Kdenlive.

Some possible solutions include:
1. If a right mouse click is very short (very little time between mouse press
and release), a context menu item shouldn't be activated on mouse button
release.
2. Set a minimum number of pixels the mouse cursor must move between launching
the menu (mouse right button press) and activating the menu item (mouse right
button release).
3. Add a few pixels of padding region around the context menu where the cursor
can exist without a menu item being selected. This solution already exists in
the Oxygen widget style, as seen at the end of the video.
4. Have the context menu appear a few pixels away from the mouse cursor instead
of right at the tip of the pointer. This solution would function similar to
solution #3, but without causing potential changes to the appearance of the
widget style.

I didn't know exactly which component to report this bug against, since as far
as I know it could be a KDE, Qt, or Breeze issue. Please reassign as necessary.

** My System **
OS: KDE Neon 5.8.90 64-bit (Plasma Desktop 5.8.5+git20161227.1802-0, KDE
Frameworks 5.30.0, Qt 5.7.0)
Linux Kernel: 4.4.0.57-generic

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Breeze] [Bug 358224] breeze dark plasma look and feel: KDE4 applications are using mixed (light and dark) colors, rendering text unreadable

2016-01-20 Thread Christian Stadelmann via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=358224

Christian Stadelmann  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Christian Stadelmann  ---
I don't know how themes did mess up so much, but this issue is now gone after
deleting and reconfiguring themes several times. I hope it'll stay that way.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[Breeze] [Bug 350682] Double-click on GTK widgets initiates window movement, breaks control of the widget

2016-01-19 Thread Christian Stadelmann via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=350682

Christian Stadelmann  changed:

   What|Removed |Added

 CC||dah5a...@genodeftest.de

--- Comment #10 from Christian Stadelmann  ---
This issue is still present with inkscape on plasma 5.5.3.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[Breeze] [Bug 358224] New: breeze dark plasma look and feel: KDE4 applications are using mixed (light and dark) colors, rendering text unreadable

2016-01-19 Thread Christian Stadelmann via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=358224

Bug ID: 358224
   Summary: breeze dark plasma look and feel: KDE4 applications
are using mixed (light and dark) colors, rendering
text unreadable
   Product: Breeze
   Version: 5.5.3
  Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-devel@kde.org
  Reporter: dah5a...@genodeftest.de

I am running plasma 5.5.3 with breeze dark look and feel. No matter what I set
as desktop theme (Oxygen or Breeze) and no matter which widget style I choose
(Oxygen, Breeze, Fusion), some applications behave weird. They are partially
rendered with a dark breeze theme, partially rendered with a white theme that
looks like it were a Gtk 2.x theme. They are rendering fonts in lists in light
gray on very light gray. Icons are breeze symbolic icons, mostly using white
and very light colors, thus are not visible either.

I think (but I am not sure) that only KDE4/Qt4 applications are affected, but
KDE5/Qt5 applications are not. This theory is based on the following lists:

List of affected applications:
* Kleopatra
* KGpg
* KMail
* KSnapshot
* KDebugDialog
* Ark
* KOrganizer
* Okular
* Dragon Player
* KTouch
* showFoto
* digiKam
* Konqueror

List of not affected applications:
* dolphin (including preferences dialog)
* konsole (including preferences dialog)
* plasma itself including most of its widgets and widget preferences dialogs
* kwrite (including preferences dialog)
* KCalc
* KCharselect
* KAlgebra
* KSysguard
* Marble

Additional info:
This issue is somewhat similiar to bug #343369, but it affects all kinds of UI
elements, not just ComboBoxes in KCM.

I don't have any other dark desktop look and feel to test, so I can't make sure
this isn't a bug somewhere else, e.g. in Qt4's theming engine or KDE4's
widgets. Please reassign if you know better (you probably do).

Reproducible: Always

Steps to Reproduce:
1. start any of the applications listed above

Actual Results:  
Applications are partially rendered in a light, partially rendered in a black
theme. Some widgets have mixed themes, e.g. light fonts (from dark theme) and
light/white background (from light theme).

Expected Results:  
Applications should look consistent, having only one single theme.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[Breeze] [Bug 351099] krunner unusable with dark breeze theme

2016-01-19 Thread Christian Stadelmann via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=351099

Christian Stadelmann  changed:

   What|Removed |Added

 CC||dah5a...@genodeftest.de

--- Comment #2 from Christian Stadelmann  ---
I am using krunner without issues. Is this issue still present for you with
plasma 5.5.3 and krunner 5.18.0?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 125618: Fixes to KameraConfigDialog

2015-10-29 Thread Christian Butcher

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

(Updated Oct. 29, 2015, 7:09 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Graphics, Plasma and Marcus Meissner.


Repository: kamera


Description
---

Fixes to the KameraConfigDialog dialogue problems, as seen in the screenshots 
attached to [this previous review](https://git.reviewboard.kde.org/r/125433/). 

Adds a QScrollArea (with no frame) to allow resizing more easily.

Labels are on the left side of the GridLayouts now, with their controls to the 
right (LineEdit, CheckBox, Slider).
The labels are almost the same in each of the three cases, but unsure that 
making just one Label, then changing based on an if() is an improvement.


Diffs
-

  kcontrol/kameraconfigdialog.cpp f8cdd43b9623ab26b868399ecf3e184c03b41d57 

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


Testing
---

Tested with Nikon 1 V2, which seems to have a significant number of available 
fields, and of varied types. Expect that not all `GP_WIDGET_{x,y,z}` are 
covered.
Tried to test with phone but uses MTP - Plasma and Dolphin allow me to open it 
nicely, and Kamera KCM shows the phone, but won't allow any actions on it. 
Unsure if this means that the KCM should discard MTP phones with which it can't 
interface.


Thanks,

Christian Butcher

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


Re: Review Request 125618: Fixes to KameraConfigDialog

2015-10-29 Thread Christian Butcher

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


Submitted with commit 891536d11f1779ee21a23b18fc2d3558f77bbc89 by Christian 
Butcher.

Manual commit message because I messed up the commit message (forgot the 
REVIEW: tag)

- Christian Butcher


On Oct. 27, 2015, 8:45 a.m., Christian Butcher wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125618/
> ---
> 
> (Updated Oct. 27, 2015, 8:45 a.m.)
> 
> 
> Review request for KDE Graphics, Plasma and Marcus Meissner.
> 
> 
> Repository: kamera
> 
> 
> Description
> ---
> 
> Fixes to the KameraConfigDialog dialogue problems, as seen in the screenshots 
> attached to [this previous 
> review](https://git.reviewboard.kde.org/r/125433/). 
> 
> Adds a QScrollArea (with no frame) to allow resizing more easily.
> 
> Labels are on the left side of the GridLayouts now, with their controls to 
> the right (LineEdit, CheckBox, Slider).
> The labels are almost the same in each of the three cases, but unsure that 
> making just one Label, then changing based on an if() is an improvement.
> 
> 
> Diffs
> -
> 
>   kcontrol/kameraconfigdialog.cpp f8cdd43b9623ab26b868399ecf3e184c03b41d57 
> 
> Diff: https://git.reviewboard.kde.org/r/125618/diff/
> 
> 
> Testing
> ---
> 
> Tested with Nikon 1 V2, which seems to have a significant number of available 
> fields, and of varied types. Expect that not all `GP_WIDGET_{x,y,z}` are 
> covered.
> Tried to test with phone but uses MTP - Plasma and Dolphin allow me to open 
> it nicely, and Kamera KCM shows the phone, but won't allow any actions on it. 
> Unsure if this means that the KCM should discard MTP phones with which it 
> can't interface.
> 
> 
> Thanks,
> 
> Christian Butcher
> 
>

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


Re: Review Request 125618: Fixes to KameraConfigDialog

2015-10-27 Thread Christian Butcher

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

(Updated Oct. 27, 2015, 8:45 a.m.)


Review request for KDE Graphics, Plasma and Marcus Meissner.


Changes
---

Check dynamic_cast pointers before using them


Repository: kamera


Description
---

Fixes to the KameraConfigDialog dialogue problems, as seen in the screenshots 
attached to [this previous review](https://git.reviewboard.kde.org/r/125433/). 

Adds a QScrollArea (with no frame) to allow resizing more easily.

Labels are on the left side of the GridLayouts now, with their controls to the 
right (LineEdit, CheckBox, Slider).
The labels are almost the same in each of the three cases, but unsure that 
making just one Label, then changing based on an if() is an improvement.


Diffs (updated)
-

  kcontrol/kameraconfigdialog.cpp f8cdd43b9623ab26b868399ecf3e184c03b41d57 

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


Testing
---

Tested with Nikon 1 V2, which seems to have a significant number of available 
fields, and of varied types. Expect that not all `GP_WIDGET_{x,y,z}` are 
covered.
Tried to test with phone but uses MTP - Plasma and Dolphin allow me to open it 
nicely, and Kamera KCM shows the phone, but won't allow any actions on it. 
Unsure if this means that the KCM should discard MTP phones with which it can't 
interface.


Thanks,

Christian Butcher

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


Re: Review Request 125618: Fixes to KameraConfigDialog

2015-10-26 Thread Christian Butcher

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


Are any changes needed?

- Christian Butcher


On Oct. 13, 2015, 2:20 a.m., Christian Butcher wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125618/
> ---
> 
> (Updated Oct. 13, 2015, 2:20 a.m.)
> 
> 
> Review request for KDE Graphics, Plasma and Marcus Meissner.
> 
> 
> Repository: kamera
> 
> 
> Description
> ---
> 
> Fixes to the KameraConfigDialog dialogue problems, as seen in the screenshots 
> attached to [this previous 
> review](https://git.reviewboard.kde.org/r/125433/). 
> 
> Adds a QScrollArea (with no frame) to allow resizing more easily.
> 
> Labels are on the left side of the GridLayouts now, with their controls to 
> the right (LineEdit, CheckBox, Slider).
> The labels are almost the same in each of the three cases, but unsure that 
> making just one Label, then changing based on an if() is an improvement.
> 
> 
> Diffs
> -
> 
>   kcontrol/kameraconfigdialog.cpp f8cdd43b9623ab26b868399ecf3e184c03b41d57 
> 
> Diff: https://git.reviewboard.kde.org/r/125618/diff/
> 
> 
> Testing
> ---
> 
> Tested with Nikon 1 V2, which seems to have a significant number of available 
> fields, and of varied types. Expect that not all `GP_WIDGET_{x,y,z}` are 
> covered.
> Tried to test with phone but uses MTP - Plasma and Dolphin allow me to open 
> it nicely, and Kamera KCM shows the phone, but won't allow any actions on it. 
> Unsure if this means that the KCM should discard MTP phones with which it 
> can't interface.
> 
> 
> Thanks,
> 
> Christian Butcher
> 
>

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


Review Request 125618: Fixes to KameraConfigDialog

2015-10-12 Thread Christian Butcher

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

Review request for KDE Graphics, Plasma and Marcus Meissner.


Repository: kamera


Description
---

Fixes to the KameraConfigDialog dialogue problems, as seen in the screenshots 
attached to [this previous review](https://git.reviewboard.kde.org/r/125433/). 

Adds a QScrollArea (with no frame) to allow resizing more easily.

Labels are on the left side of the GridLayouts now, with their controls to the 
right (LineEdit, CheckBox, Slider).
The labels are almost the same in each of the three cases, but unsure that 
making just one Label, then changing based on an if() is an improvement.


Diffs
-

  kcontrol/kameraconfigdialog.cpp f8cdd43b9623ab26b868399ecf3e184c03b41d57 

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


Testing
---

Tested with Nikon 1 V2, which seems to have a significant number of available 
fields, and of varied types. Expect that not all `GP_WIDGET_{x,y,z}` are 
covered.
Tried to test with phone but uses MTP - Plasma and Dolphin allow me to open it 
nicely, and Kamera KCM shows the phone, but won't allow any actions on it. 
Unsure if this means that the KCM should discard MTP phones with which it can't 
interface.


Thanks,

Christian Butcher

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


Re: Review Request 125433: kcm_kamera: Double calls to load() lead to strange scrollbars after saving a change

2015-10-08 Thread Christian Butcher

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

(Updated Oct. 8, 2015, 8:04 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Graphics, Plasma and Marcus Meissner.


Changes
---

Submitted with commit 67f21dab67409261879268c6372b69ad95eb9e74 by Christian 
Butcher to branch master.


Repository: kamera


Description
---

The displayGPSuccessDialogue(void) function calls load() as its last statement 
currently.

Documentation for the KCModule api (both 
[kde4](http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKCModule.html)
 and 
[frameworks](http://api.kde.org/frameworks-api/frameworks5-apidocs/kconfigwidgets/html/classKCModule.html))
 informs the reader that load() is called at the end of construction - 
consequently it seems that the additional load() call leads to the function 
(which is implemented as KKameraConfig::load() ) being called twice.

[Bug 236844](https://bugs.kde.org/show_bug.cgi?id=236844) may be related but at 
least on my KF5 based system, this does not cause or prevent a crash, which is 
referenced in the bug.

Separately, COPYING-CMAKE-SCRIPTS is referenced by the FindGphoto2.cmake file, 
and seems to have missed the commit in 
[RR-125230](https://git.reviewboard.kde.org/r/125230/). If this was 
intentional, then my apologies for readding here, but if so, the 
FindGphoto2.cmake file will need changing in some way.


Diffs
-

  COPYING-CMAKE-SCRIPTS PRE-CREATION 
  kcontrol/kamera.cpp 2d8f61449a5a6f2650d864c864652ebea780a422 
  kcontrol/kameradevice.h b0ecb974f8fcb765228afe1965aeebab8e7656ed 

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


Testing
---

When the call is present, opening the Kamera KCM within systemsettings after 
saving changes and going back to the main systemsettings view leads to a 
strange set of scrollbars.

With the additional call removed, the KCM-Kamera opens properly on the second 
attempt, after saving changes.

As a camera to test, the first (in the scroll list) serial port camera is 
'Achiever Digital Adc65'. 'Barbie' may be easier to find as the first entry for 
'B', and is also more memorable... I used a serial camera, since then the kcm 
will load images even without a camera connected


File Attachments


scrollbars
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/09/28/74e8bd93-4c4a-4103-9fb1-7bd106258058__kcm1.png
Settings panel
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/10/08/1cc9a8bc-b8a9-40d4-986d-3ae91d040d17__Screenshot_20151008_164010.png
Information panel
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/10/08/13129de5-a4f3-4bd8-958b-205505a9d973__info.png
Test panel
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/10/08/176fcc11-c56a-4782-a827-88c0b0b75347__test.png
Config panel
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/10/08/afae96ce-7281-42b6-aaac-dc8b8299eb30__configure.png


Thanks,

Christian Butcher

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


  1   2   3   >