D7695: Fix message when the image was shared using a plugin that doesn't reply with a URL

[Aleix Pol Gonzalez]

apol created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  BUG: 383276

REPOSITORY
  R166 Spectacle

BRANCH
  master

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

AFFECTED FILES
  src/Gui/KSMainWindow.cpp

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

D1075: Display mouse image in mouse kcm properly on highdpi screen

[Xuetian Weng]

xuetianweng abandoned this revision.

REPOSITORY
  R119 Plasma Desktop

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

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

D7694: Update app icons to match icon design guidelines

[Andrew Lake]

alake created this revision.
alake added a project: MyCroft Integration.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Simple update of the main app icons to follow icon design guidelines for 
margins. Also simplified svg file.F3898953: mycroft-plasma-appicon.svg 

  
  It's been a while since I used Phabricator so I hope I'm doing this right.

REPOSITORY
  R846 Mycroft Plasma integration

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

AFFECTED FILES
  image/breeze-dark/apps/16/mycroft-plasma-appicon.svg
  image/breeze-dark/apps/32/mycroft-plasma-appicon.svg
  image/breeze/apps/16/mycroft-plasma-appicon.svg
  image/breeze/apps/32/mycroft-plasma-appicon.svg
  plasmoid/contents/images/mycroft-plasma-appicon.svg

To: alake, #mycroft_integration
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Matthias Klumpp]

2017-09-04 22:29 GMT+02:00 Martin Flöser :
> Am 2017-09-04 19:51, schrieb Zlatan Todoric:
>>
>> I had pretty unstable experience with KDE in Debian, so I assume that
>> KDE community will improve that in future (we need more Debian KDE
>> maintainers!) ;)
>
> Personal opinion as a long time Debian testing user (~10 years) and KDE
> contributor following:
>
> The packaging of Debian is really not great and questionable. As an example:
> currently testing ships Qt 5.9 in combination with KWin 5.8. KWin 5.8 does
> not compile against Qt 5.9, patches exist in master and I refused to
> backport them to the 5.8 branch as that is untested. Debian shipped that
> without even consulting with upstream developers. I think that is extremely
> bad practice from a distribution. They know me, they know they could ask for
> my opinion.

That is definitely a problem. It could be that the team is overworked
though (I don't know enough here). In any case, a good relation with
upstream is key for any package maintainer, it looks like there is
definitely something lacking here.

> The task-kde does a really bad default package selection. As an example: it
> installs Konqueror as the default browser in the favorites section of the
> launcher while at the same time warning against QtWebKit based browsers in
> the release announcement.

Agreed! The KDE task interestingly isn't maintained by the KDE team
though, and last time I asked that there was no influence on it. I
doubt that. Sending a patch would definitely be accepted by the task
maintainers.
When we made Tanglu, people were amazed how well the distro was
working, and how quickly. When I looked into that, it turned out that
the more lightweight package selection was the biggest cause for that
perception.

> [...]
> And honestly I don't think it's something the Debian team cares about: it's
> much more important to have the "perfect" package.

Yes, that is required for getting things into the distribution. The
copyright analysis must be done and be good to even get into Debian,
which is something Neon was lacking last time I checked. The Kubuntu
packaging oftentimes was mediocre too (bumping epochs without reason
comes to my mind, even for new packages) - *but* that is no reason to
take the Neon packaging, fix the problems and submit the changes back
to Neon and the package to Debian. That workflow would actually help
both projects and reduce work for Debian.
But I think this is getting into a highly political area, and I don't
feel qualified to comment about why things are the way they are or
what has been tried in the past.

> After all they constantly
> re-invent the wheel instead of using the already packaged software by
> Kubuntu or KDE Neon (hopefully that improved, but looking at the recent
> commits it doesn't look like it:
> https://anonscm.debian.org/git/pkg-kde/plasma/kwin.git/commit/?id=1cf72f55228a59fb37649c8f8a29cc509a8881b1
> ).

That got me curious, and I diff'ed the Neon vs. Debian packaging.
Surprisingly, the packaging is completely disjoint. Sometimes, Debian
is better, sometimes Neon is. And it looks like Neon does take care of
the copyright file afterall, in some packages it is even *better* than
in Debian.
Also, fun bits happen, for example Debian updated your copyright in
the kwin package, Neon forgot to do that, but instead added other
copyright holders Debian missed. Also, Neon adds
"KF5IdleTimeKWinWaylandPrivatePlugin.so" to the kwin-common package,
while in Debian it's in kwin-wayland (where it belongs, I guess?).
Debian also builds proper debugsymbols using the dbgsym support in
Debian, while Neon is using legacy stuff.

> Just my 2 cents as someone who has been annoyed by the lack of collaboration
> between Kubuntu and Debian for years

>From briefly looking over it, I have to agree - this is not only slightly 
>mad...
I know at some point, Kubuntu packaging was in Debian Git, but then it
was abandoned (I think someone in Debian complained, but I am not
certain).

Anyway, this is something PureOS and Purism could actually resolve or
help resolving (in the ideal case directly on Debian, in the worst
case only for PureOS).

Cheers,
Matthias

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Martin Flöser]

Am 2017-09-04 19:51, schrieb Zlatan Todoric:

I had pretty unstable experience with KDE in Debian, so I assume that
KDE community will improve that in future (we need more Debian KDE
maintainers!) ;)


Personal opinion as a long time Debian testing user (~10 years) and KDE 
contributor following:


The packaging of Debian is really not great and questionable. As an 
example: currently testing ships Qt 5.9 in combination with KWin 5.8. 
KWin 5.8 does not compile against Qt 5.9, patches exist in master and I 
refused to backport them to the 5.8 branch as that is untested. Debian 
shipped that without even consulting with upstream developers. I think 
that is extremely bad practice from a distribution. They know me, they 
know they could ask for my opinion.


The task-kde does a really bad default package selection. As an example: 
it installs Konqueror as the default browser in the favorites section of 
the launcher while at the same time warning against QtWebKit based 
browsers in the release announcement.


When I install Debian it looks to me like a try to package everything 
and provide everything. But not like trying to get a decent desktop 
experience. If you compare that to openSUSE or KDE Neon - that are huge 
differences.


And honestly I don't think it's something the Debian team cares about: 
it's much more important to have the "perfect" package. After all they 
constantly re-invent the wheel instead of using the already packaged 
software by Kubuntu or KDE Neon (hopefully that improved, but looking at 
the recent commits it doesn't look like it: 
https://anonscm.debian.org/git/pkg-kde/plasma/kwin.git/commit/?id=1cf72f55228a59fb37649c8f8a29cc509a8881b1 
).
If you literally waste time like that, it's no surprise the quality 
suffers :-(


Just my 2 cents as someone who has been annoyed by the lack of 
collaboration between Kubuntu and Debian for years


Cheers
Martin

D7155: Implement sorting of the device tree items

[Isaac True]

isaact edited the summary of this revision.

REPOSITORY
  R102 KInfoCenter

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

To: isaact, #plasma, cfeck
Cc: cfeck, broulik, anthonyfieroni, plasma-devel, ZrenBot, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D7155: Implement sorting of the device tree items

[Isaac True]

isaact edited the summary of this revision.

REPOSITORY
  R102 KInfoCenter

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

To: isaact, #plasma, cfeck
Cc: cfeck, broulik, anthonyfieroni, plasma-devel, ZrenBot, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D7155: Implement sorting of the device tree items

[Isaac True]

isaact updated this revision to Diff 19184.
isaact marked 4 inline comments as done.
isaact added a comment.


  Updated code as per feedback

REPOSITORY
  R102 KInfoCenter

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7155?vs=17758=19184

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

AFFECTED FILES
  Modules/devinfo/devicelisting.cpp
  Modules/devinfo/soldevice.cpp
  Modules/devinfo/soldevice.h

To: isaact, #plasma, cfeck
Cc: cfeck, broulik, anthonyfieroni, plasma-devel, ZrenBot, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D7155: Implement sorting of the device tree items

[Isaac True]

isaact marked 6 inline comments as done.
isaact added a comment.


  Thanks for the feedback - diff has been updated

INLINE COMMENTS

> broulik wrote in devicelisting.cpp:49
> Why disable again?

I've removed the disable as it's pointless

> anthonyfieroni wrote in soldevice.cpp:165
> left->number() < right->number() ?

This is reversed as it's sorted in the opposite order (ascending) to the other 
entries (descending)

> anthonyfieroni wrote in soldevice.cpp:169
> Reverse again ?

These are also sorted in ascending order, so that it goes from sda1, sda2, etc.

> anthonyfieroni wrote in soldevice.h:108
> Why virtual ?

Habit - removed

REPOSITORY
  R102 KInfoCenter

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

To: isaact, #plasma, cfeck
Cc: cfeck, broulik, anthonyfieroni, plasma-devel, ZrenBot, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

Re: Plasma Mobile on the Librem 5

[Zlatan Todoric]

Hi Martin,


On 09/04/2017 06:00 PM, Martin Flöser wrote:
> Am 2017-09-03 23:17, schrieb Sebastian Kügler:
>> 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.
>
> *nod* - I absolutely think this is a chicken-egg problem. Due to not
> having hardware nobody is interested in doing work and due to not
> having software we don't get the hardware. Librem 5 might be just the
> push to get out of this loop. What might be needed is getting
> development boards early to KDE devs and we need to get the initial
> setup story good, so that it's easy to hack on without having to fight
> the system (I remember the horror of Nokia's maemo cross compiler)
>
>>> 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).
>
> If you need any input from the Wayland stack (e.g. rendering, input)
> I'm happy to participate, though that would mean outside of office
> hours ;-) (earliest 16 CEST).

You should participate for sure as I plan to have Wayland as the only
display server we will run (if we can avoid X and all its dependencies,
that would be a good thing for all). I will now create a separate thread
for the proposal of meeting date.

>
> Cheers
> Martin
Z

Re: Plasma Mobile on the Librem 5

[Zlatan Todoric]

On 09/03/2017 11:17 PM, Sebastian Kügler wrote:
> 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.

GNOME is basically not ready at all. The GTK3 is not for mobile use and
it will not get any updates regarding that (it is considered stable, in
frozen state and they don't want to break ABI). GTK4 has potential to be
mobile ready toolkit but that can be a year or two away and someone
would still need to write entire UI for it.

I heard about the issue of plasma mobile community not having energy to
push things forward as they didn't have the device for it but now we
have a chance to finally have device and not play at all in Android
world and all the hassle those devices bring with for developing Free OS.

>
> 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. 

Yep, I hope we will get campaign out, so we can revive entire community
around it and create collaboration and growth that will connect all dots
for entire community (I consider Purism just as part of larger
community) so we can create something unique and break status quo.

>
>> 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.

PureOS is basically Debian - and I as Purism CTO and as Debian Developer
invite entire community to help make KDE as best as possible for user
experience.

>
> 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.

Flatpak'ing DE is not something you should do. Flatpaks are meant for
graphical apps. I think the best possible combination for wider
community is to have base OS and base DE components as .deb's and have
upstream make flatpak of their end-user apps. For OS/DE security we plan
to enable AppArmor as default because in my 

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Matthias Klumpp]

2017-09-04 19:51 GMT+02:00 Zlatan Todoric :
> [...]
> Well, for having both as separate offer (if GNOME hits the pace), is not
> an issue. I am wondering if having both at the same time on phone will
> end up being to much (how many libraries are there that one uses and
> other DE doesn't), also depending on disk space, you don't want to eat
> like 20% of all space for base OS.

Just commenting on that point: I think having two DEs on a phone with
some kind of "desktop switcher" is a terrible idea. I think it would
be much more maintainable if we spin two separate base images, and in
case someone wants something different they can just swap those (we
will offer those images on our website anyway).

Giving users the choice to switch between desktops randomly when using
the phone is a bad thing usability wise (it's not a simple thing, and
radically changes the appearance of the UI), requires additional
engineering effort and is generally harder to maintain and support
(because we will have multiple configurations and mix of technology on
one image).
Shipping the phone with one default image and offering others on our
site that people can put on their phone seems to be a much better idea
to me.

> I had pretty unstable experience with KDE in Debian, so I assume that
> KDE community will improve that in future (we need more Debian KDE
> maintainers!) ;)

When exactly was that? ;-) But yeah, the Debian KDE team would be
happy for any additional help.

> [...]

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Zlatan Todoric]

Hey Thomas,


On 09/03/2017 02:16 AM, Thomas Pfeiffer wrote:
> Hi Zlatan,
> please ignore my previous two mails mail to you which were both sent
> from the wrong address (sorry for that, new computer with no proper
> email client yet and GMail is terrible when it comes to multiple email
> addresses).

heh, no worries.

> On Sat, Sep 2, 2017 at 5:23 PM, 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.
> Great to hear!
>
>> 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).
> Makes sense.
>
>> 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?
> Sounds like quite a challenge, but if you can make it work, why not?

Well, for having both as separate offer (if GNOME hits the pace), is not
an issue. I am wondering if having both at the same time on phone will
end up being to much (how many libraries are there that one uses and
other DE doesn't), also depending on disk space, you don't want to eat
like 20% of all space for base OS.

>
>> 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.
> Great to hear that as well, and of course we agree that Plasma Desktop
> and Plasma Mobile work great in tandem!

I had pretty unstable experience with KDE in Debian, so I assume that
KDE community will improve that in future (we need more Debian KDE
maintainers!) ;)

>
>> 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.
> Yes, that's certainly useful!
> Video conference sounds good since it's always nice to see people when
> getting to know them. Which system do you usually use for video calls?
> We've been using Jitsi Meet or OpenTokRTC so far.
>
> From our side apart from Sebastian it would be Bhushan (Plasma
> Mobile's maintainer), Paul from the KDE promo team, me (Thomas, member
> of the board of directors of KDE e.V. and member of KDE's design
> team), and potentially others who might want to join.

Everyone is welcome!

>
> What times would work best for you?

I will write separate mail to propose time after I answer few more mails
in this thread.

>
> Looking forward to the meeting,
> Thomas
Z (excited as well)

D7648: Fix ksysguard not starting on plasmoid click

[David Edmundson]

davidedmundson added a comment.


  We have a slight problem (and I'm sorry as this is my fault)
  
  Plasma 5.10 will depend on frameworks 5.38. 
  This was just tagged and doesn't include your krun change.
  
  If this was a feature I would be really strict and make us wait till Plasma 
5.11.
  
  As this is a bug fix, and frameworks 5.39 will be out just before Plasma 
5.10, I think we can grant an exception. If a user does use 5.37, it'll just 
give a warning and continue.
  
  I'm going to wait until after the beta is released to merge this change.

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

Re: ksmserver consuming memory

[David Edmundson]

Lets keep bug reports on the bug tracker, it makes it easier for everyone
to track.

It sounds like: https://bugs.kde.org/show_bug.cgi?id=373274
Please check your version number, and if you still have the issue, comment
there.

David

D6047: Support XDG v6

[David Edmundson]

This revision was automatically updated to reflect the committed changes.
davidedmundson marked an inline comment as done.
Closed by commit R127:d4c82b60cf16: Support XDG v6 (authored by davidedmundson).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D6047?vs=19148=19169#toc

REPOSITORY
  R127 KWayland

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

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

Re: Plasma Mobile on the Librem 5

[Martin Flöser]

Am 2017-09-03 23:17, schrieb Sebastian Kügler:

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.


*nod* - I absolutely think this is a chicken-egg problem. Due to not 
having hardware nobody is interested in doing work and due to not having 
software we don't get the hardware. Librem 5 might be just the push to 
get out of this loop. What might be needed is getting development boards 
early to KDE devs and we need to get the initial setup story good, so 
that it's easy to hack on without having to fight the system (I remember 
the horror of Nokia's maemo cross compiler)



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).


If you need any input from the Wayland stack (e.g. rendering, input) I'm 
happy to participate, though that would mean outside of office hours ;-) 
(earliest 16 CEST).


Cheers
Martin

D6047: Support XDG v6

[Martin Flöser]

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

REPOSITORY
  R127 KWayland

BRANCH
  temp

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

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

D3805: Per-activity favorites (Final, again?)

[Ivan Čukić]

ivan updated this revision to Diff 19163.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3805?vs=19108=19163

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

AFFECTED FILES
  applets/kicker/CMakeLists.txt
  applets/kicker/package/contents/code/tools.js
  applets/kicker/package/contents/config/main.xml
  applets/kicker/package/contents/ui/ActionMenu.qml
  applets/kicker/package/contents/ui/main.qml
  applets/kicker/plugin/abstractentry.cpp
  applets/kicker/plugin/appentry.cpp
  applets/kicker/plugin/appentry.h
  applets/kicker/plugin/computermodel.cpp
  applets/kicker/plugin/computermodel.h
  applets/kicker/plugin/computermodel.h.orig
  applets/kicker/plugin/favoritesmodel.cpp
  applets/kicker/plugin/favoritesmodel.h
  applets/kicker/plugin/kastatsfavoritesmodel.cpp
  applets/kicker/plugin/kastatsfavoritesmodel.h
  applets/kicker/plugin/kickerplugin.cpp
  applets/kicker/plugin/placeholdermodel.cpp
  applets/kicker/plugin/placeholdermodel.h
  applets/kicker/plugin/recentusagemodel.cpp
  applets/kicker/plugin/rootmodel.cpp
  applets/kicker/plugin/rootmodel.h
  applets/kicker/plugin/simplefavoritesmodel.cpp
  applets/kicker/plugin/simplefavoritesmodel.h
  applets/kicker/plugin/systemmodel.cpp
  applets/kickoff/package/contents/code/tools.js
  applets/kickoff/package/contents/config/main.xml
  applets/kickoff/package/contents/ui/ActionMenu.qml
  applets/kickoff/package/contents/ui/FullRepresentation.qml

To: ivan, mart, hein
Cc: Zren, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

Minutes Monday Plasma Hangout (also Plasma Mobile!)

[Sebastian Kügler]

We've met, and we talked about Plasma, then talked about Plasma Mobile and 
came up with plans, minutes for both attached!

Plasma Mobile, live pad: https://notes.kde.org/p/plasmamobileplan

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org
-- 
http://vizZzion.orgPlasma Team meeting, 4-9-2017

Present: kbroulik, notmart, Sho, jensreu, bshah, sebas

kbroulik:
* Did various improvements to Folder View
** improved startup performance with lazy loading in panel like plasmoids do it
** pressing Esc in showing desktop mode will cancel a rename op first instead 
of always blatantly throwing you out of showing desktop
* Some minor performance improvements, e.g. creating margins/fixedMargins 
objects on demand, avoiding needless clearing of SVGs
* ConfigModel can now be used with an Instantiator, used in digital clock to 
show holiday plugin config only for enabled ones
* Dolphin now prefers Place name in title bar (so you get "Home" instead of 
lowercase user name or "Trash" (or "Papierkorb") instead of trash:/)
!! I started an Etherpad for 5.11 release announcement !! Please fill in your 
features and noteworthy improvements !! https://notes.kde.org/p/plasma_5_11

notmart:
* wayland foreign: this has all the comments adressed, please review: 
https://phabricator.kde.org/D7521 and https://phabricator.kde.org/D7369
Diff 7521 "[WIP] make use of foreign protocol" [Needs Review] 
https://phabricator.kde.org/D7521
Diff 7369 "[WIP] Wayland foreign protocol" [Needs Review] 
https://phabricator.kde.org/D7369
* some triaging on plasmashell bugs
* work on kirigami papercut bugs, related to looks, scrolling and formfactor 
switching
* work
* theme ScrollView, along with workarounds for rendering correctly on desktop 
and correct scrolling
* plasma-mobile
** better working activity switching by slide
** new top panel with just a simple quick settings thing in it, quick target is 
just to have a simple prototype that doesn't "look broken" (more on that on pm 
meeting)
* QtQuickControls2 style: a ScrollView that has a better management of mouse 
wheels/touchpad
* QtQuickControls2 style: asked lists to make it a frameworks, apps want to 
depend from it to not look awful on desktop

Sho:
* [Launchers] Worked a few more rounds with Ivan on KAStats-based favorites
** Still buggy ... getting concerned re 5.11 considering we need VDG help 
post-merge to fix the context menu design, and message freeze is approaching 
fast :/
* [Kirigami] Worked on resizing drawers with a drag handle - works in Konvi, 
will likely submit a code example
* [Kirigami] Chatted with Marco about scrolling, color stuff, framework-ness, 
...
* [QtWS] More coordination stuff, poking, prodding, emailing
** Still missing some replies with registration confirmation and questionnaire 
answers, if you spoke up about attending please check your inbox and reply
* [Other] Spent some time on the text view code for the Konversation Qt Quick 
rewrite

bshah:
- [Neon] Upto applications are done in neon CI
- [Mobile CI] Code changed to use the packages from neon CI
- [Mobile CI] Some work to make use of Multijob in Mobile CI, so there is just 
one meta job instead of _src, _bin and _pub jobs
- [Packaging] Found most elegant solution to QCOM_BSP problem, working with JBB 
on telegram to implement it
- I hope to have initial images with neon packages and qt5.9 ready by wednesday

sebas:
* trying to get Fairphone interested, mild but not much succes so far
* bit of coordination with Purism, see librem thread on plasma ML
* my laptop's giving problems again and its Plasma install is borked, needs 
fixing
* not much Plasma things otherwise
* pending is still the touchscreen rotation code and of course the OSD patches 
which I still don't know how to properly position

We also talked about Plasma mobile, notes of that are here: 
https://notes.kde.org/p/plasmamobileplan


snapshot for posterity:

Strategy / Goals:

Attract more developers from the outside
Increase awareness for Plasma Mobile in Free software ecosystem
Get Plasma Mobile to a basic 1.0 state, functional as daily driver for limited 
use cases
to me is mostly being a decent dumb phone, 1998-grade functionality

Split PM work into different areas with their coordinator:
Technical / low-level / stack: bshah
Technical UI: notmart  (plasma-shell homescreen, kirigami framework base for 
apps.. apps need someone adopting them)
Design: jensreu
PR / communication: sebas

The idea is that these "coordinators" / "topic owners" keep track and 
coordinate among each others and work as a team to advance PM towards the goals 
above - Project management for the distinctive areas to happen on phab
Create a design vision, taking current state-of-the-art in PM into account, and 
flesh it out with designers
Jens to sit down with Sho and Notmart and AlexL to define what can and can't be 
done, then take it into design team to work on mockups
Create a clear list of functional objectives: what's needed for a 1.0 version? 

Re: ddcutil .deb

[Jonathan Riddell]

Thanks for your comments Sanford.  The code isn't mine it's done by
Dorian for KDE Plasma's Powerdevil which gets a beta release next week
(I'm the release dude).

Dorian please review ddcutil Sanford's comments below for changes that could be 
made.

Sanford given the API/ABI stability should we be recommending distros
package up libddcutil and use this code or would that cause more
problems and we should mark it as in-development for this release?

Jonathan


- Forwarded message from Sanford Rockowitz  -

Date: Fri, 1 Sep 2017 10:52:29 -0400
From: Sanford Rockowitz 
To: Jonathan Riddell 
Subject: Re: ddcutil .deb

Jonathan,

I've taken a look at your powerdevil code at 
https://cgit.kde.org/powerdevil.git/tree/daemon/backends/upower/ddcutilbrightness.cpp.
It can be simplified to improve performance and reliability.

1)  The DDCA_Display_Identifier -> DDCA_Display_Ref lookup exists to
allow for choosing a monitor by its characteristics, when you don't
already have a list of monitors to select from, e.g. on the ddcutil
command line.   Struct DDCA_Display_Info, returned (as an array) by
ddca_display_info_list(), contains field dref, which is a valid
DDCA_Display_Ref you can use.   See function
display_selection_using_ddca_get_displays() in sample file
demo_display_selection.c.

The documentation could be clearer here.

2) There's no need to look up the VCP value for the Brightness field.
Per the MCCS spec, it's always x10.

3) Rather than reading and parsing the capabilities string to
determine if a monitor supports VCP feature code x10, it's both faster
and more reliable just to try reading the value of code x10.

Reading the capabilities string is a very expensive operation,
entailing multiple I2C write/read exchanges, as a single read can
return at most 32 bytes.  Every write/read exchange contains sleeps
mandated by the DDC/CI protocol.  (In fact, ddcutil spends 90% of it's
elapsed time sleeping.)Since the I2C protocol is unreliable, a
write/read exchange may have to be retried, and even worse a whole
sequence of write/read exchanges may have be to restarted.   Most
monitors are relatively clean, but some, such Dell P2412h monitors
that I have tested, have so many I2C failures that read capabilities
sometimes fails even after retries.

Moreover, the capabilities string is not necessarily accurate. See,
for example, the description of the HP LP2480zx monitor. on page
http://www.ddcutil.com/monitor_notes/.  The string does not include
VCP feature code x10, even though the monitor supports it.

BTW, while monitors vary enormously in the VCP feature codes they
support, I've yet to see a monitor that doesn't support feature x10.

4) You may want to control/capture messages issued from the library.
See functions ddca_set_fout(), ddca_set_ferr(),
ddca_set_output_level(), etc.

5) In certain very exceptional situations (i.e. things that should
never happen, but hey, it's conceivable) the library may abort.
Instead of aborting, the library can return to a location in the
caller registered using function ddca_register_jmp_buf().  See
function handle_library_abort() in sample file demo_global_settings.c.
I have to admit that I'm not entirely comfortable with making a
longjmp visible to the library client, but I'm trying to avoid forcing
the library user to check for truly exceptional failures on each API
call, while still avoiding library aborts that cause the client to
fail.   Let me know if you find this design useful/usable.

Regards,
Sanford

D7686: Don't show a region selector when selecting avatars from a gallery

[David Edmundson]

davidedmundson created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Prompting the user for a region makes sense when loading from a file,
  but not from the gallery.
  
  CreateAvatarJob does two things:
  
  - copies from KIO
  - goes via a KPixmapRegionSelector and saves to a local file
  
  We know the gallery files are locally mounted, and we don't want the
  region selector so we can just skip the job completely.

TEST PLAN
  Set avatar from file. Got prompt, saved properly
  Set avatar from gallery. Skipped prompt, saved properly

REPOSITORY
  R128 User Manager

BRANCH
  master

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

AFFECTED FILES
  src/accountinfo.cpp

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

D7663: Correct text style

[patrick j pereira]

patrickelectric closed this revision.
patrickelectric added a comment.


  Merged.

REPOSITORY
  R169 Kirigami

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

To: patrickelectric, tcanabrava, mart, #kirigami
Cc: plasma-devel, apol, mart, hein

D3805: Per-activity favorites (Final, again?)

[Eike Hein]

hein added a comment.


  With the updated kactivitymanagerd the missing favorite no longer happens, 
although the "also add it on the second activity by checking item" step inserts 
it in a strange position of last-2 instead of appending it on the same applet 
on the other activity - considering all the other faves in the test are shared, 
I'd expect it to appear the end (where it also was on the first activity). 
Still, progress!

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

To: ivan, mart, hein
Cc: Zren, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D3805: Per-activity favorites (Final, again?)

[Eike Hein]

hein added a comment.


  > After the port, all launchers have the same items on the top, with the new 
items added to the end. Do you have any speial URL formats in your original 
favorites (preferred: needed special treatment, that is why I'm asking)? Can 
you check whether the plasma configuration file has the correct order?
  
  Of course I have a preferred:// favorite: The default favorites have one for 
the browser ...
  
  plasma rc:
  
  
favoriteApps=preferred://browser,org.kde.dolphin.desktop,org.kde.kate.desktop,fontforge.desktop,systemsettings.desktop,gimp.desktop
  
favorites=systemsettings.desktop,org.kde.dolphin.desktop,org.kde.kate.desktop,org.kde.discover.desktop,blender.desktop,preferred://browser,org.kde.krita.desktop
  
  stats rc:
  
  
[Favorites-org.kde.plasma.kicker.favorites.instance-19-00c64f45-3049-42e5-b3c4-568afabb2b3d]
  
ordering=preferred://browser,applications:org.kde.dolphin.desktop,applications:org.kde.kate.desktop,applications:fontforge.desktop,applications:systemsettings.desktop,applications:gimp.desktop,applications:org.kde.discover.desktop,applications:blender.desktop,applications:org.kde.krita.desktop,applications:chocolate-setup.desktop
  
  
[Favorites-org.kde.plasma.kicker.favorites.instance-19-2126853d-731e-4ccb-bdd6-8e00bf5a3ec0]
  
ordering=preferred://browser,applications:org.kde.dolphin.desktop,applications:org.kde.kate.desktop,applications:fontforge.desktop,applications:systemsettings.desktop,applications:gimp.desktop,applications:blender.desktop,applications:org.kde.discover.desktop,applications:org.kde.krita.desktop,applications:org.kde.okular.desktop
  
  [Favorites-org.kde.plasma.kicker.favorites.instance-19-global]
  
ordering=preferred://browser,org.kde.dolphin.desktop,org.kde.kate.desktop,fontforge.desktop,systemsettings.desktop,gimp.desktop
  
  
[Favorites-org.kde.plasma.kickoff.favorites.instance-3-00c64f45-3049-42e5-b3c4-568afabb2b3d]
  
ordering=applications:fontforge.desktop,applications:gimp.desktop,applications:org.kde.dolphin.desktop,applications:org.kde.kate.desktop,applications:systemsettings.desktop,preferred://browser,applications:org.kde.discover.desktop,applications:blender.desktop,applications:org.kde.krita.desktop,applications:chocolate-setup.desktop
  
  
[Favorites-org.kde.plasma.kickoff.favorites.instance-3-2126853d-731e-4ccb-bdd6-8e00bf5a3ec0]
  
ordering=applications:systemsettings.desktop,applications:org.kde.dolphin.desktop,applications:org.kde.kate.desktop,applications:org.kde.discover.desktop,applications:blender.desktop,preferred://browser,applications:org.kde.krita.desktop,applications:fontforge.desktop,applications:gimp.desktop,applications:org.kde.okular.desktop
  
  [Favorites-org.kde.plasma.kickoff.favorites.instance-3-global]
  
ordering=systemsettings.desktop,org.kde.dolphin.desktop,org.kde.kate.desktop,org.kde.discover.desktop,blender.desktop,preferred://browser,org.kde.krita.desktop
  
  > You haven't updated kactivitymanagerd as I said?
  
  I updated all of frameworks, including kactivities and kactivities-stats, I 
assumed kactivitymanagerd is in there? :)

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

To: ivan, mart, hein
Cc: Zren, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D3805: Per-activity favorites (Final, again?)

[Ivan Čukić]

ivan added a comment.


  > Post-migration sorting still feels completely random - not sure how solid 
that feeling is though.
  
  Hmh. My test is - have three launchers with some favs shared, some not.
  
  After the port, all launchers have the same items on the top, with the new 
items added to the end. Do you have any speial URL formats in your original 
favorites (preferred: needed special treatment, that is why I'm asking)? Can 
you check whether the plasma configuration file has the correct order?
  
  > Definitive bug:
  
  You haven't updated kactivitymanagerd as I said?

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

To: ivan, mart, hein
Cc: Zren, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

Re: Adding existing project to KDE incubator

[Aleix Pol]

On Sun, Sep 3, 2017 at 1:28 AM, Mladen Milinkovic  wrote:
> Hi everyone,
>
> am looking into adding a project i develop/maintain 
> (https://github.com/maxrd2/subtitlecomposer) into KDE incubator.
> Have read through wiki on incubator and whole process and it says this:
>
>> Candidate
>>  - provide description of the project to be incubated
>>  - must include the people committing to the project
>>  - must have a plan to be in compliance with the manifesto
>>  - must be supported by a sponsor which will help during the incubation phase
>
> So how does one get a sponsor?

Hi Mladen,
Asking is a great first step! :)

This is the Plasma mailing list, maybe try a wider mailing list like
the community's: kde-commun...@kde.org.

Good luck!
Aleix

D7273: Use the new ECMQMLModules to specify all of KWin's runtime dependencies

[Aleix Pol Gonzalez]

apol added a comment.


  In https://phabricator.kde.org/D7273#138099, @graesslin wrote:
  
  > ping, anything speaking against pushing it?
  
  
  Push? :)

REPOSITORY
  R108 KWin

BRANCH
  ecmqmlmodules

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

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

D3805: Per-activity favorites (Final, again?)

[Eike Hein]

hein added a comment.


  And another round of testing:
  
  1. Post-migration sorting still feels completely random - not sure how solid 
that feeling is though. Note my test script is still the same - start with a 
Kickoff and a Kicker instance, append two different new favorites to each, drag 
the first and second default faves (respectively, i.e. #1 on the first applet, 
#2 on the second) between the two new ones, patch, restart Plasma. After that I 
would expect the list of favorites that was identical at the top of both 
favorite lists to remain there, and then for the sorting of the remainder to be 
somewhat jumbly ... but here I get something seemingly random at the top of the 
post-migration result.
  
  2. Definitive bug:
  3. Have two activities
  4. Add a favorite to the current activity
  5. Right-click it, check the other activity in the submenu
  6. Right-click it again, uncheck the current activity
  7. Expected: Favorite is now on the other activity (and only there); Actual 
result: Favorite has disappeared
  
  3. Warning that may be related:
  
  
/home/eike/devel/src/kde/workspace/plasma-desktop/applets/kicker/plugin/kastatsfavoritesmodel.cpp:415:39:
 warning: unused parameter ‘currentActivity’ [-Wunused-parameter]
  
this, [&] (const QString ) {

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

To: ivan, mart, hein
Cc: Zren, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

Adding existing project to KDE incubator

[Mladen Milinkovic]

Hi everyone,

am looking into adding a project i develop/maintain 
(https://github.com/maxrd2/subtitlecomposer) into KDE incubator.
Have read through wiki on incubator and whole process and it says this:

> Candidate
>  - provide description of the project to be incubated
>  - must include the people committing to the project
>  - must have a plan to be in compliance with the manifesto
>  - must be supported by a sponsor which will help during the incubation phase

So how does one get a sponsor?

thanks,
 Max

Re: Problem building Kirigami example.

[patrick JP]

Hi Tomaz,



2017-08-31 5:58 GMT-03:00 Tomaz Canabrava :

> Pats,
>
>
> On Mon, Aug 28, 2017 at 6:27 PM, patrick JP 
> wrote:
>
>> I am trying to compile kirigami apk. This is my command line to use
>> cmake:
>>
>> cmake .. 
>> -DCMAKE_TOOLCHAIN_FILE=/usr/share/cmake-3.9/Modules/Platform/Android.cmake
>> \
>> -DQTANDROID_EXPORTED_TARGET=kirigami2gallery
>> -DANDROID_APK_DIR=../examples/galleryapp/ \
>> -DCMAKE_PREFIX_PATH=/opt/android-qt5/5.9.1/armeabi-v7a \
>> -DCMAKE_INSTALL_PREFIX=potato \
>> -DECM_DIR=/usr/share/ECM/cmake \
>> -DBUILD_EXAMPLES=ON
>>
>> When running make, an error message appears saying that the binaries are
>> incompatible.
>>
>> make
>>
>> [  4%] Automatic MOC for target kirigamiplugin
>>
>> Generating MOC predefs moc_predefs.h
>>
>> [  4%] Built target kirigamiplugin_autogen
>>
>> [  9%] Linking CXX shared library libkirigamiplugin.so
>>
>> /opt/android-qt5/5.9.1/armeabi-v7a/lib/libQt5Quick.so: error adding symbols: 
>> File in wrong format
>>
>> collect2: error: ld returned 1 exit status
>>
>> make[2]: *** [src/CMakeFiles/kirigamiplugin.dir/build.make:225: 
>> src/libkirigamiplugin.so] Error 1
>>
>> make[1]: *** [CMakeFiles/Makefile2:361: 
>> src/CMakeFiles/kirigamiplugin.dir/all] Error 2
>>
>> make: *** [Makefile:163: all] Error 2
>>
>> The .obj that is generated from kirigami is x86-64 and not arm v7:
>>
>> ./src/CMakeFiles/kirigamiplugin.dir/ECMQmLoader-libkirigami2plugin_qt.cpp.obj:
>> ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
>>
>>
>> I don't know what is the problem, I was just following the README.md.
>>
>> My best regards,
>> --
>> Patrick José Pereira
>> Electronics Engineer
>> Skype: patrickelectric434
>> IRC: patrickelectric
>> +55 (048) 99917-4777 <(48)%2099917-4777>
>>
>
> I have a working script to build for android on subsurface
> sources/packaging/android
>
> take a look there and see if it helps, it's fully documented.
>
> Tys, I'll take a look asap.

Now about my journey trying to compile the kirigami apk.
Talking with Marco I changed my cmake command line to use the same path to
ECM and Android.cmake.

make .. -DCMAKE_TOOLCHAIN_FILE=/usr/share/ECM/toolchain/Android.cmake
-DQTANDROID_EXPORTED_TARGET=kirigami2gallery
-DANDROID_APK_DIR=../examples/galleryapp/ \
-DCMAKE_PREFIX_PATH=/opt/android-qt5/5.9.1/armeabi-v7a \
-DCMAKE_INSTALL_PREFIX=/mnt/hd/kirigami-install \
-DECM_DIR=/usr/share/ECM/cmake \
-DBUILD_EXAMPLES=ON -DCMAKE_SYSTEM_NAME="Android"
-DCMAKE_ANDROID_NDK=/opt/android-ndk -DQTANDROID_EXPORTED_TARGET=galleryapp


Than cmake was not happy, and was not possible to find Qt5CoreConfig.cmake
https://paste.kde.org/ppkru7p0j

Than I added a new line,
-DQt5Core_DIR=/opt/android-qt5/5.9.1/armeabi-v7a/lib/cmake/Qt5Core/
cmake was not so much happy but no errors this time.
cmake + make result https://paste.kde.org/ppkhbkmwx:

Ok, now make create-apk-galleryapp appears !!
And a new error too..
https://paste.kde.org/pi7szfhj9

I'll try Tomaz approach, but I'll be very happy to solve than and help
Kirigami documentation.

My best regards,

-- 
Patrick José Pereira
Electronics Engineer
Skype: patrickelectric434
IRC: patrickelectric
+55 (048) 99917-4777

Re: kscreenlocker: loginctl/systemd

[Hartmut Goebel]

Hi Martin,

thanks for you answer and sorry for not coming back on this earlier – I
was busy building other plasma components, too.

Am 10.08.2017 um 20:10 schrieb Martin Flöser:
> As it says this is needed for emergency unlocking in case the lock
> screen breaks. If you neither have loginctl nor consolekit2 the
> emergency unlocking feature is not available. 

IC. It would be great, if this would be described a a README, as it
would help packages a lot.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: start menu icon

[Marco Martin]

On sabato 2 settembre 2017 14:16:04 CEST you wrote:
> 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-l
> ayout.js the contents include:
> 
> var plasma = getApiVersion(1);
> var layout = {
>  "desktops": [
>  { "applets" : [ ], "config" : [ ... ] }
>  ]
>  "panels": [
>  {  "applets" : [...], "config": { ... } ... }
>  ]
> }

it's the config serialized in json, instead of having it all explicitly  in 
imperative javascript of applet = containment.addaApplet() etc
it's a more compact version that's fine in most cases and can still be mixed 
with imperative code if needed


-- 
Marco Martin

D6047: Support XDG v6

[Marco Martin]

mart added inline comments.

INLINE COMMENTS

> davidedmundson wrote in xdgshell_interface.cpp:40
> the captured "attempt" variable is modified inside the lambda

needs to tack the state as needs to track that only a couple of attempts are 
made

REPOSITORY
  R127 KWayland

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

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

D7663: Correct text style

[Marco Martin]

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

REPOSITORY
  R169 Kirigami

BRANCH
  doc

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

To: patrickelectric, tcanabrava, mart, #kirigami
Cc: plasma-devel, apol, mart, hein

ksmserver consuming memory

[Stéphane Ancelot]

Hi,

I have a system which autologins , the ksmserver process after 2 days 
usage is consuming 57% of my 4G ram.


Is there a way watching/isolating what is happening ?

Regards,

S.Ancelot