D7424: Very slightly increase text contrast for the default Breeze color scheme

[Nathaniel Graham]

ngraham added a reviewer: VDG.

REPOSITORY
  R31 Breeze

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

To: ngraham, hpereiradacosta, jensreuterberg, jriddell, kvermette, #vdg
Cc: sebas, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, apol, mart, lukas

[Breeze] [Bug 381288] Breeze could use higher-contrast text by default (tweaked color scheme attached)

[Nate Graham]

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

Nate Graham  changed:

   What|Removed |Added

  Flags||Usability+

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

Re: Plasma Mobile on the Librem 5

[Eike Hein]

On 08/30/2017 10:31 PM, Matthias Klumpp wrote:
> I was made aware of that effort already a few weeks ago, and it is
> looking great! I guess the default Matrix app in the Librem phone
> would have to be something focused on person-to-person communication
> and tight integration with the user's contact list, instead of being
> more group-chat centric like Konversation is. But having more choice
> in Matrix clients is a good thing, and maybe we can have different UIs
> for the same backend.

Indeed!

Having worked on chat and related stuff for some time, we're no
stranger to trying to provide rich integration in that space.

Once upon a time in KDE 3, we had a technology called "KIMProxy" -
KMail was able to tell you when the sender of an email was online
in Konversation on IRC while you were reading their mail, as both
drew upon the same address book, with Konversation allowing to
associate IRC nicks with address book contacts and contributing
presence state to a global pool. Our instant messenger application
at the time, Kopete, was likewise integrated with the system.

In Plasma 5 we currently have a successor technology called KPeople,
which is used in concert with KDE Telepathy, the KActivities(-Stats)
framework and the launcher menu backend. The launcher menus bundled
with Plasma Desktop have an optional "Recent Contacts" category
which will list recent conversations by contact, with realtime
presence status (i.e. a little online status badge on the contact
avatar used as icon for the menu entry).

This works by KDE Telepathy providing a KPeople plugin that contri-
butes data (contact info, state) to the pool and entering KPeople
URIs to the KActivities-Stats db when opening a conversation. The
launcher menu backend queries the db, and then uses KPeople API to
get contact info and state - without knowing anything about KDE
Telepathy specifically.

The plan would be for Konversation's Matrix backend to likewise
integrate with KPeople, getting that info into the launchers.

This is relevant for Plasma Mobile as we have plans to reimple-
ment the homescreen UI on top of the Plasma Desktop launcher
menu backend - it provides all the apps/docs/contacts/widgets
data it needs along with a rich favoriting mechanism (i.e.
pinning things). The Application Dashboard fullscreen launcher
bundled with Plasma Desktop probably drives this possibility
home the best right now.

Retaining KPeople, PM's Contacts application would then likewise
be written against its APIs.

This is all stuff we have in some sense done before, know how to
do, and know we want ... :)


Cheers,
Eike
-
Plasma, apps developer
KDE e.V. vice president, treasurer

D5093: Add ~/.local/share/icons to icons search paths

[Andrey Bondrov]

abondrov added a comment.


  In https://phabricator.kde.org/D5093#142799, @rkflx wrote:
  
  > Pushing or landing might not work if you use the wrong prefix as the push 
target. It should be `g...@git.kde.org:`. You can check with `git remote -v`.
  
  
  Thanx for your help!  After adding these lines to my git config pushing is 
working again:
  
  [url "g...@git.kde.org:"]
  
pushInsteadOf = git://anongit.kde.org/

REPOSITORY
  R135 Integration for Qt applications in Plasma

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

To: abondrov, jriddell, broulik, davidedmundson
Cc: rkflx, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D5093: Add ~/.local/share/icons to icons search paths

[Andrey Bondrov]

This revision was automatically updated to reflect the committed changes.
Closed by commit R135:f9e5b852faa7: Add ~/.local/share/icons to icons search 
paths (authored by abondrov).

REPOSITORY
  R135 Integration for Qt applications in Plasma

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D5093?vs=19048=19151

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

AFFECTED FILES
  src/platformtheme/khintssettings.cpp

To: abondrov, jriddell, broulik, davidedmundson
Cc: rkflx, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

Re: Plasma Mobile on the Librem 5

[Matthias Klumpp]

2017-09-03 23:17 GMT+02:00 Sebastian Kügler :
> Hey Zlatan,
> [...]
>> so I had discussion with our CEO and he is of course absolutely in.
>> To make clear our standpoint - both GNOME and KDE *will* be first
>> class citizen on Librem5. So there is no favorite between two, but
>> both are equal in this challenge.
>>
>> That said, looking in general code readiness between two, it would
>> appear that plasma mobile would be default in first wave of librems
>> (we are not releasing until one DE is ready for it and we will also
>> not wait for other DE to be ready but gradually add it). There is
>> some discussion in terms of offer - do we want to offer Librem5 with
>> choice of having Plasma or GNOME or do we have both right away inside
>> (maybe to heavy for such device)  so users can pick during boot-up?
>
> I'm not familiar with GNOME's strategy for a mobile UI (would love to
> know more however!), so for me it's hard to judge whether Plasma is
> technologically closer. From the Plasma side, I know that we're
> *currently* not good enough for anything end-user, so it will need a
> dedicated development push, and we need to rally the resources
> necessary for that.

Plasma is much further developed than GNOME though on the mobile front
- GNOME at the moment would require a vendor to commit to making GNOME
Mobile, which is a rather large task involving changes in all parts of
the GNOME platform. Plasma Mobile on the other hand has the groundwork
done already.

> I do know that there is a good amount of interest
> in the community, but my impression is also that many people are
> playing a waiting game for others to move before they're getting their
> hands dirty. This is something we need to resolve to get the ball really
> rolling. A decent plan and coordination of these effort is definitely
> needed, and this is something we should come up with first. Build and
> they will come.

Indeed!

> [...]
>> Also, while currently we are offering PureOS with GNOME as default on
>> Librem13/15, I think there is future for KDE as desktop offering by
>> default as well (also as an option PureOS GNOME and PureOS Plasma/KDE)
>> because the convergence might be very interesting choice for many
>> users and your desktop is very modular for fine tweaking.
>
> I haven't looked into the packaging for the device, so it's hard to
> comment on that. I can imagine that Plasma is something people would
> want to run on the device, and it makes a story of complementary
> devices both running Plasma more compelling, so I think we should at
> least have an answer to that.
>
> That said, I'm not familiar with packaging for PureOS, and KDE is just
> getting ready to flatpak things.

Don't worry about that - PureOS is basically a combination of Debian
with things the FSF doesn't like stripped out, combined with some good
ideas from the Tanglu debian derivative. Anything that runs on Debian
runs on PureOS as well.

> I'm not sure in how far flatpacking
> the DE is an option, but I guess Matthias can weigh in here as well.

Flatpacking a DE is a bad idea. Flatpak is strictly for applications,
and does not work well (or at all, depending on the specifics) for
anything that's more than an app. For example, the desktop needs to
provide the portals implementation, fire up the user/session DBus on
startup, communicate with the display manager, and in general
integrate well with the rest of the OS. It also doesn't benefit much
from being sandboxed, since it launches applications that would
inherit the sandboxing policies of their parent, which can cause all
kind of problems.

For the phone base system, I envision a system similar to what
EndlessOS[1] currently is. This will require quite a bit of
redesigning of PureOS to work well with OSTree[2] and build OSTree
images automatically from packages, but will work much better on a
phone. Apps should be in Flatpaks, but that is also something I can
help with (although last time I looked at it, all work was done in KDE
already).
In any case, don't worry about the base OS and plumbing layer for now
:-) That will work well no matter which UX sits on top.

> We
> do have some expertise in the Plasma team as well, but so far the DE
> itself hasn't been the primary target of our flatpak efforts, we've
> more concentrated on apps.

Don't try flatpacking the DE, it won't be a good investment of time
(Ubuntu's Snappy system works differently here in that it allows
making snaps of pretty much anything, even system components - last
time I heard though that even Ubuntu would stick with .deb package for
longer though).
Flatpak is strictly for apps, and at the moment even more strictly for
apps that have a graphical user interface.

> [...]

Cheers,
Matthias

Re: Plasma Mobile on the Librem 5

[Sebastian Kügler]

Hey Zlatan,

On Sat, 2 Sep 2017 17:23:09 +0200
Zlatan Todoric  wrote:

> (Cleared all previous mails to make this one more visible, feel free
> to respond on this one while quoting previous replies in this thread)
> 
> Hi all,
> 
> so I had discussion with our CEO and he is of course absolutely in.
> To make clear our standpoint - both GNOME and KDE *will* be first
> class citizen on Librem5. So there is no favorite between two, but
> both are equal in this challenge.
> 
> That said, looking in general code readiness between two, it would
> appear that plasma mobile would be default in first wave of librems
> (we are not releasing until one DE is ready for it and we will also
> not wait for other DE to be ready but gradually add it). There is
> some discussion in terms of offer - do we want to offer Librem5 with
> choice of having Plasma or GNOME or do we have both right away inside
> (maybe to heavy for such device)  so users can pick during boot-up?

I'm not familiar with GNOME's strategy for a mobile UI (would love to
know more however!), so for me it's hard to judge whether Plasma is
technologically closer. From the Plasma side, I know that we're
*currently* not good enough for anything end-user, so it will need a
dedicated development push, and we need to rally the resources
necessary for that. I do know that there is a good amount of interest
in the community, but my impression is also that many people are
playing a waiting game for others to move before they're getting their
hands dirty. This is something we need to resolve to get the ball really
rolling. A decent plan and coordination of these effort is definitely
needed, and this is something we should come up with first. Build and
they will come.

On the other hand, the offering of non-Android Free software mobile
workspaces and apps have, with the demise of Firefox OS and Ubuntu
become pretty thin, and the best we can hope from that rather
disappointing development is that a consolidation will bundle
resources and get the community together with more focus. 

> Also, while currently we are offering PureOS with GNOME as default on
> Librem13/15, I think there is future for KDE as desktop offering by
> default as well (also as an option PureOS GNOME and PureOS Plasma/KDE)
> because the convergence might be very interesting choice for many
> users and your desktop is very modular for fine tweaking.

I haven't looked into the packaging for the device, so it's hard to
comment on that. I can imagine that Plasma is something people would
want to run on the device, and it makes a story of complementary
devices both running Plasma more compelling, so I think we should at
least have an answer to that.

That said, I'm not familiar with packaging for PureOS, and KDE is just
getting ready to flatpak things. I'm not sure in how far flatpacking
the DE is an option, but I guess Matthias can weigh in here as well. We
do have some expertise in the Plasma team as well, but so far the DE
itself hasn't been the primary target of our flatpak efforts, we've
more concentrated on apps. I'd be interesting to know, perhaps we can
use the Librem notebooks as potential targets when we think about how we
want to make deployment of Plasma possible. I suppose it's a good way
to get Plasma ready for deployment on the handheld devices as well.
These kind of deployment scenarios are actually at the heart of
Plasma's cross device strategy, so I'd love to find out more.

> Now that is said - what suggestion do you have for a meeting around
> promoting collaboration between Purism and KDE regarding Librem5?
> Videoconferencing or async via mail? Other tools? I would add to the
> discussion our CEO, CMO and Director of Creative.

Video would probably work best, a phone conference is also an option.
Plasma and KDE promo people are mostly in Europe, but I'm sure we can
make something work, even if it's outside of office hours (I don't
mind). 

Cheers,
-- 
sebas

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

D6047: Support XDG v6

[David Edmundson]

davidedmundson updated this revision to Diff 19148.
davidedmundson marked an inline comment as done.
davidedmundson added a comment.
Restricted Application edited projects, added Plasma on Wayland; removed Plasma.


  Rename grab signal

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D6047?vs=18807=19148

BRANCH
  temp

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

AFFECTED FILES
  autotests/client/CMakeLists.txt
  autotests/client/test_xdg_shell.cpp
  autotests/client/test_xdg_shell.h
  autotests/client/test_xdg_shell_v5.cpp
  autotests/client/test_xdg_shell_v6.cpp
  src/client/CMakeLists.txt
  src/client/protocols/xdg-shell-unstable-v6.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/xdgshell.cpp
  src/client/xdgshell.h
  src/client/xdgshell_p.h
  src/client/xdgshell_v5.cpp
  src/client/xdgshell_v6.cpp
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/xdgshell_interface.cpp
  src/server/xdgshell_interface.h
  src/server/xdgshell_interface_p.h
  src/server/xdgshell_v5_interface.cpp
  src/server/xdgshell_v5_interface_p.h
  src/server/xdgshell_v6_interface.cpp
  src/server/xdgshell_v6_interface_p.h
  src/tools/mapping.txt
  tests/CMakeLists.txt
  tests/xdgtest.cpp

To: davidedmundson, #plasma, graesslin
Cc: graesslin, mart, plasma-devel, #frameworks, leezu, ZrenBot, alexeymin, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, eliasp, sebas, 
apol, hein, lukas

D7681: Update human-readable tier designation in API dox

[David Faure]

dfaure accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R169 Kirigami

BRANCH
  master

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

To: adridg, dfaure, mart
Cc: plasma-devel, apol, mart, hein

D7681: Update human-readable tier designation in API dox

[Luigi Toscano]

ltoscano added a reviewer: mart.

REPOSITORY
  R169 Kirigami

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

To: adridg, dfaure, mart
Cc: plasma-devel, apol, mart, hein

D7681: Update human-readable tier designation in API dox

[Adriaan de Groot]

adridg created this revision.
Restricted Application added a project: Kirigami.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  text is wrong

TEST PLAN
  re-generate APIdox and read text

REPOSITORY
  R169 Kirigami

BRANCH
  master

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

AFFECTED FILES
  Mainpage.dox

To: adridg, dfaure
Cc: plasma-devel, apol, mart, hein

D5093: Add ~/.local/share/icons to icons search paths

[Henrik Fehlauer]

rkflx added a comment.


  Are you sure? In 
https://phabricator.kde.org/R119:8eaf1e15ad8662b0ef72d83a242893b27f8058df it 
seemed to work fine. You can check in https://identity.kde.org whether you are 
in the "developers" group and you have the correct ssh key set up. `ssh 
g...@git.kde.org info` should work then. (I can't find your name in Identity 
although you are on Phabricator, which is strange. Consider opening a ticket 
.)
  
  Pushing or landing might not work if you use the wrong prefix as the push 
target. It should be `g...@git.kde.org:`. You can check with `git remote -v`.
  
  Following [3] was enough to make ssh and git push work for me. If you still 
have trouble, you can get help on IRC or just ask David to land the patch on 
your behalf. I'm sure you'll figure it out (assuming you'll eventually want to 
contribute more patches ☺).
  
  [3] https://techbase.kde.org/Development/Tutorials/Git/GitQuickStart

REPOSITORY
  R135 Integration for Qt applications in Plasma

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

To: abondrov, jriddell, broulik, davidedmundson
Cc: rkflx, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D7648: Fix ksysguard not starting on plasmoid click

[Mladen Milinkovic]

maxrd2 added a comment.


  I don't have full developer account so i can't land this one. It also needs 
https://phabricator.kde.org/D7676 for this to work.

REPOSITORY
  R114 Plasma Addons

BRANCH
  launch-change

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

To: maxrd2, #plasma, davidedmundson
Cc: #frameworks, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D7648: Fix ksysguard not starting on plasmoid click

[Mladen Milinkovic]

maxrd2 added a dependency: D7676: Added openService() method to KRunProxy.

REPOSITORY
  R114 Plasma Addons

BRANCH
  launch-change

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

To: maxrd2, #plasma, davidedmundson
Cc: #frameworks, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D7648: Fix ksysguard not starting on plasmoid click

[David Edmundson]

davidedmundson accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R114 Plasma Addons

BRANCH
  launch-change

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

To: maxrd2, #plasma, davidedmundson
Cc: #frameworks, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D7648: Fix ksysguard not starting on plasmoid click

[Mladen Milinkovic]

maxrd2 added a comment.


  There it goes... updated the qml and added KRunProxy changes here: 
https://phabricator.kde.org/D7676

REPOSITORY
  R114 Plasma Addons

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

To: maxrd2, #plasma
Cc: #frameworks, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D7648: Fix ksysguard not starting on plasmoid click

[Mladen Milinkovic]

maxrd2 updated this revision to Diff 19136.
maxrd2 added a comment.


  Plasmoid uses KRun::openService() to launch ksysguard

REPOSITORY
  R114 Plasma Addons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7648?vs=19134=19136

BRANCH
  launch-change

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

AFFECTED FILES
  applets/systemloadviewer/package/contents/ui/SystemLoadViewer.qml

To: maxrd2, #plasma
Cc: #frameworks, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D7648: Fix ksysguard not starting on plasmoid click

[Mladen Milinkovic]

maxrd2 updated this revision to Diff 19134.
maxrd2 edited the summary of this revision.
maxrd2 added a comment.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.


  Added KRun::openService() method

REPOSITORY
  R296 KDeclarative

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7648?vs=19076=19134

BRANCH
  runproxy_openservice

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

AFFECTED FILES
  src/qmlcontrols/kioplugin/krunproxy.cpp
  src/qmlcontrols/kioplugin/krunproxy.h

To: maxrd2, #plasma
Cc: #frameworks, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D7648: Fix ksysguard not starting on plasmoid click

[David Edmundson]

davidedmundson added a comment.


  sorry  ::serviceByDesktopName() isn't deprecated and does what we want.

REPOSITORY
  R114 Plasma Addons

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

To: maxrd2, #plasma
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7648: Fix ksysguard not starting on plasmoid click

[Mladen Milinkovic]

maxrd2 added a comment.


  Also seems KService::serviceByName() was removed from KF5.. so it's ok just 
to re-add it?
  https://github.com/KDE/kservice/blob/master/src/services/kservice.h

REPOSITORY
  R114 Plasma Addons

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

To: maxrd2, #plasma
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7648: Fix ksysguard not starting on plasmoid click

[Mladen Milinkovic]

maxrd2 added a comment.


  Great will make those changes/additions then.
  Do you know why was KService::serviceByName() deprecated in KDE 4? 
(https://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKService.html#a2c5b00fd381b9843b6ba99da692c90ae)

REPOSITORY
  R114 Plasma Addons

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

To: maxrd2, #plasma
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D6047: Support XDG v6

[David Edmundson]

davidedmundson marked an inline comment as done.
davidedmundson added inline comments.

INLINE COMMENTS

> graesslin wrote in xdgshell_interface.cpp:40
> what's the idea behind a mutable lambda?

the captured "attempt" variable is modified inside the lambda

REPOSITORY
  R127 KWayland

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

To: davidedmundson, #plasma, graesslin
Cc: graesslin, mart, plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, lukas

D7648: Fix ksysguard not starting on plasmoid click

[David Edmundson]

davidedmundson added a comment.


  The problem I have is that if we see a bug, and then work round it instead of 
understanding it, we still have a bug - and that will just come up again in a 
different place again and again.
  
  > I have also noticed with this change that there is no (few second) delay 
after clicking the applet and ksysguard starting to launch.
  
  That comes back to the exact same question; why is there a few second delay 
when getting a (supposedly) pre-cached entry from the DataEngine.
  
  -
  
  The other viable option, which IMHO would make this code far far neater is 
adding a
  
  KRunProxy::openService(const QString name); in kdeclarative
   which uses KService::serviceByName() instead of serviceByDesktopPath
  
  then we can kill the apps dataengine completely and not have to worry about 
it.

REPOSITORY
  R114 Plasma Addons

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

To: maxrd2, #plasma
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7648: Fix ksysguard not starting on plasmoid click

[Mladen Milinkovic]

maxrd2 removed a reviewer: sars.

REPOSITORY
  R114 Plasma Addons

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

To: maxrd2, #plasma
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7648: Fix ksysguard not starting on plasmoid click

[Mladen Milinkovic]

maxrd2 added a comment.


  Am not sure why apps.data["org.kde.ksysguard.desktop"] becomes undefined.
  Think it might be a bug in PlasmaCore.DataSource? I haven't noticed any log 
messages apart that TypeError.
  
  Will try to see if sourceDisconnected/Removed is signaled at some point.
  It will probably take some time before i manage to get more info this, issue 
starts happening after applet's been running long time.
  
  I have also noticed with this changed that there is no (few second) delay 
after clicking the applet and ksysguard starting to launch.
  IMO that is welcome improvement especially when some process starts using 
100% cpu or eating ram.

REPOSITORY
  R114 Plasma Addons

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

To: maxrd2, #plasma, sars
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7648: Fix ksysguard not starting on plasmoid click

[David Edmundson]

davidedmundson added a comment.


  Thanks, but do you know why the apps datasource doesn't have that entry after 
a while?

REPOSITORY
  R114 Plasma Addons

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

To: maxrd2, #plasma, sars
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7648: Fix ksysguard not starting on plasmoid click

[Mladen Milinkovic]

maxrd2 added a reviewer: sars.

REPOSITORY
  R114 Plasma Addons

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

To: maxrd2, #plasma, sars
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart, lukas

Re: start menu icon

[Franklin Weng]

Hi all,


I solved my problem by adding my own template-layout in
.local/share/plasma/layout-templates/.

Thank you for your help.  About the syntax of
org.kde.plasma.desktop-layout.js if you can explain or give me some
documents I'll very appreciate.

I'm going to write a blog about this and hope to help further migrators
who wants to customize Plasma 5.

BTW, there are still some problems like plasmashell ignores
XDG_MENU_PREFIX and some XDG environment variables.  I'll start another
topic for this.


Thanks,
Franklin


Franklin Weng 於 2017年09月02日 20:16 寫道:
>
> Hi Marco & Eike,
>
>
> Marco Martin 於 2017年08月31日 03:51 寫道:
>> On mercoledì 30 agosto 2017 15:07:26 CEST Franklin Weng wrote:
>>> *looking at Eike with shining eyes*
>>> Could you please tell me in more detail about "ship an applet config
>>> initialization script in look-n-feel package"?  In the package
>> documentation-wise i fear all there is is:
>> https://userbase.kde.org/KDE_System_Administration/
>> PlasmaDesktopScripting#Look_and_Feel_dependent_default_setup_for_applets
>>
>> but says oretty much all there is to know
>> you would have in your look and feel a file called
>> contents/plasmoidsetupscripts/org.kde.plasma.kickoff.js
>>
>> in that script you can access to a global variable called "applet"
>> to which you can access and write its configuration like the normal 
>> layout.js 
>> script
>> , you would have something like:
>>
>> applet.currentConfigGroup = ["General"]
>> applet.writeConfig("icon", "file:///usr/share/whatever/my/icon/path")
>> applet.reloadConfig();
>
> Thanks for your help, I've successfully customized kicker, kickoff and
> kickerdash with look-n-feel packages.  Also customized the desktop
> successfully.
>
> Now I'm stuck at a few more questions, which I've googled but couldn't
> find the answers:
>  1. In the
> look-and-feel/org.kde.ezgo.desktop/contents/layouts/org.kde.plasma.desktop-layout.js
> the contents include:
>
> var plasma = getApiVersion(1);
> var layout = {
>  "desktops": [
>  { "applets" : [ ], "config" : [ ... ] }
>  ]
>  "panels": [
>  {  "applets" : [...], "config": { ... } ... }
>  ]
> }
>
> where do "desktops" and "panels" define?  or are they just
> keywords for org.kde.plasma.desktop?  I searched
> shells/org.kde.plasma.desktop but got nothing.  By customizing this
> file I've successfully done what I want.  I just don't quite
> understand the syntax in this file, and in the "layout".
>
>  2. Now I want to modify the contents of the defaultPanel (without
> changing the
> layout-templates/org.kde.plasma.desktop.defaultPanel/contents/layout.js),
> adding some widgets before the task manager.  I tried several ways:
>-
> look-and-feel/org.kde.ezgo.desktop/contents/layouts/org.kde.plasma.desktop.defaultPanel-layout.js
>- plasmoidsetupscripts/org.kde.panel.js
>
>without success.  In the org.kde.panel.js I just added something like
>
> applet.addWidget("org.kde.plasma.showActivityManager")
> applet.reloadConfig()
>
>When I tried to add a default panel it still showed "default" --
> without activity manager widget on it.  It seems like not to create a
> org.kde.panel plasmoid (which should run the setup scripts).
>
>And in the defaultPanel-layout.js I used the same way as above but
> no luck too.  I wonder if the syntax in defaultPanel-layout.js should
> be like desktop-layout.js, but I don't know if there is any keywords
> or syntax for defaultPanel.
>
>Any help is very appreciated.
>
> Thanks,
> Franklin



signature.asc
Description: OpenPGP digital signature

D7669: Make AbstractEglBackend a QObject

[Martin Flöser]

graesslin created this revision.
Restricted Application added a project: KWin.
Restricted Application added subscribers: kwin, plasma-devel.

REVISION SUMMARY
  Several of the subclasses are already derived from QObject.
  
  The main reason is that the class should be moved out of KWin core in
  order to move the OpenGL scene into a plugin. As Compositor calls into
  the AbstractEglBackend to unbind the wayland display this creates a
  problem which is easily solved by turning the AbstractEglBackend into a
  QObject and connect to the signal emitted by the Compositor.

TEST PLAN
  Compiles

REPOSITORY
  R108 KWin

BRANCH
  abstract-egl-backend-qobject

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

AFFECTED FILES
  abstract_egl_backend.cpp
  abstract_egl_backend.h
  composite.cpp
  plugins/platforms/drm/egl_gbm_backend.cpp
  plugins/platforms/drm/egl_gbm_backend.h
  plugins/platforms/virtual/egl_gbm_backend.cpp
  plugins/platforms/virtual/egl_gbm_backend.h
  plugins/platforms/wayland/egl_wayland_backend.cpp
  plugins/platforms/wayland/egl_wayland_backend.h

To: graesslin, #kwin, #plasma
Cc: plasma-devel, kwin, bwowk, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
hardening, jensreuterberg, abetts, sebas, apol, mart, lukas

D6047: Support XDG v6

[Martin Flöser]

graesslin added inline comments.

INLINE COMMENTS

> xdgshell_interface.cpp:40
> +int attempt = 0;
> +connect(pingTimer, ::timeout, q, [this, serial, attempt]() 
> mutable {
> +++attempt;

what's the idea behind a mutable lambda?

> xdgshell_interface.h:458
> + */
> +void grabbed(KWayland::Server::SeatInterface *seat, quint32 serial);
> +

If it's something the client request, I would suggest a rename to grabRequested.

Could you please explain what "grab" is supposed to be?

REPOSITORY
  R127 KWayland

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

To: davidedmundson, #plasma, graesslin
Cc: graesslin, mart, plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, lukas