D2754: Touchpad KDED: fix metadata warning

[Albert Astals Cid]

aacid requested changes to this revision.
aacid added a comment.
This revision now requires changes to proceed.


  So what's the status of this? needs landing? needs help?

REPOSITORY
  R119 Plasma Desktop

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

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

D6566: Do not leak XVisualInfo (X11 EGL path)

[Albert Astals Cid]

aacid closed this revision.

REPOSITORY
  R102 KInfoCenter

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

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

Re: ddcutil .deb

[Dorian Vogel]

Hi all,
Thanks for the comments ! And sorry for the late reply.
I realize the implementation is far from optimal, and would be happy to
rework it. Unfortunately I'm quite busy with other things right now, and
for about two more weeks so I can not really swear anything until then.

Jonathan: keeping the feature "in development" for now sounds reasonable,
the fact that powerdevil's architecture does not allow ddc brightness
control for laptop might become a source of frustration for users.

Regards,
Dorian

Le 4 sept. 2017 2:07 PM, "Jonathan Riddell"  a écrit :

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

Re: ddcutil .deb

[Sanford Rockowitz]

Jonathan,

Much as I'd like to see some external pressure for ddcutil's inclusion 
in distros (it's been a slow process), I think it's premature to be 
including the library version in distros. Probably better off for now 
for PowerDevil to use its own private copy.  I'm happy to work with 
you/Dorian to improve the PowerDevil code.  It will help identify 
changes that the libddcutil API needs in order to be more usable.  One 
particular are of concern I have is support for multi-threaded clients.  
As I noted, DDC/CI operations are slow because of protocol mandated 
sleeps (typically 50 ms per operation).  GUIs may not want to wait for 
operations to complete.


Regards,
Sanford

On 09/04/2017 08:07 AM, Jonathan Riddell wrote:

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

D7698: Pass EGL information from AbstractEglBackend to Platform instead of query

[Martin Flöser]

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

REVISION SUMMARY
  So far the Platform performed a deep query into the AbstractEglBackend
  to get information such as EGLContext, EGLConfig, EGLSurface. This
  change adjusts this so that the AbstractEGLPlatform forwards it directly
  whenever it gets informed about one following the approach already used
  for EGLDisplay. This simplifies the code a lot and allows to remove the
  dependency on the actual scene backend from the Platform (in order to
  split out the SceneOpenGL into a plugin).

TEST PLAN
  Run nested kwin_wayland, triggered Outline which requires all
  those methods.

REPOSITORY
  R108 KWin

BRANCH
  egl-backend-to-platform

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

AFFECTED FILES
  abstract_egl_backend.cpp
  abstract_egl_backend.h
  platform.cpp
  platform.h

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

Re: Videoconference between KDE community and Purism regarding Librem5

[Todd Weaver]

On Tue, 2017-09-05 at 08:48 -0400, Jeff F. wrote:
> Sebastian Kügler wrote :
> 
> > let's pin down Thursday, 19:00 CEST (9.00am PDT), in any case.
> 
> 
> Works for me, added to my calendar tentatively, I'd like to hear
> confirmation of Todd's availability.

I have a tentative physical meeting with Gizmodo on Thursday, and have
not confirmed the time with him/them yet.

So, for now, let's schedule 9am PT and get a meet.jit.si room sent-out, 
and I will only update my status if a conflict arises from Gizmodo.

I look forward to discussing KDE and Purism working together.

Todd.

signature.asc
Description: This is a digitally signed message part

Re: Videoconference between KDE community and Purism regarding Librem5

[Aleix Pol]

On Mon, Sep 4, 2017 at 8:29 PM, Zlatan Todoric  wrote:
> Hello all,
>
> as Mak and me approached KDE community to discuss about potential
> collaboration between two sides we found very welcoming community that
> is not only eager about potential work on such device but also wants to
> create a joint promotion (quotes, video, campaign page update etc).
>
> So this is proposal for a Jitsi Meet videoconference on Wednesday (Sep
> 6) 18.00 CET (9.00am PDT and noon for EST folks).
>
> On our side we have: Todd (CEO), Mak (Lead PureOS/Debian Developer),
> Nicole (our lead for phone), Francois (Creative), Jeff (Marketing guru)
> and me (CTO/Debian Developer). We could add two more PureOS developers
> which both are Debian Developers and one is currently DPL (Chris and
> Jonas) but I don't want meeting to be to heavy on resources as Jitsi
> sometimes just bugs on us.
>
> Anyone from KDE is welcome, I just CC'ed those who sent (most) replies
> on our discussion.
>
> Let us know (all, even the Purism members) if date/time format is
> working for you so we can have this (maybe historical? :)) meeting about
> collaboration and promotion of both projects. If you will not be able to
> participate, please add what date/time does work for you so we can
> figure out better option (or maybe we can create doodle if there is too
> many people not being able to participate at this time).
>
> Happy hacking,
>
> Z
>

I'll be happy to join.

See you on Thursday!
Aleix

Re: Videoconference between KDE community and Purism regarding Librem5

[Paul Brown]

On Tuesday, 5 September 2017 14:48:13 CEST Jeff F. wrote:
> Sebastian Kügler wrote :
> > let's pin down Thursday, 19:00 CEST (9.00am PDT), in any case.
> 
> Works for me, added to my calendar tentatively, I'd like to hear
> confirmation of Todd's availability.

Works for me also. 

Cheers

Paul
-- 
Promotion & Communication

www: http://kde.org
Mastodon: https://mastodon.technology/@kde
Facebook: https://www.facebook.com/kde/
Twitter: https://twitter.com/kdecommunity



signature.asc
Description: This is a digitally signed message part.

Re: Videoconference between KDE community and Purism regarding Librem5

[Andy B]

If I am needed, I can join as well.

Andy


On September 5, 2017 at 7:55:52 AM, Matthias Klumpp (matth...@tenstral.net)
wrote:

> Sebastian Kügler wrote :
> let's pin down Thursday, 19:00 CEST (9.00am PDT), in any case.

For me, this would work even better :-)
(But we need Todd in the meeting, so let's wait and hope he's
available at that time as well)

Re: Videoconference between KDE community and Purism regarding Librem5

[Matthias Klumpp]

> Sebastian Kügler wrote :
> let's pin down Thursday, 19:00 CEST (9.00am PDT), in any case.

For me, this would work even better :-)
(But we need Todd in the meeting, so let's wait and hope he's
available at that time as well)

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

[Aleix Pol Gonzalez]

apol added a comment.


  > I think we first need to get https://phabricator.kde.org/D7543 in, to be 
able to depend from the ECM version.
  
  I don't see how it's related

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

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

[Martin Flöser]

graesslin added a comment.


  In https://phabricator.kde.org/D7273#142926, @apol wrote:
  
  > In https://phabricator.kde.org/D7273#138099, @graesslin wrote:
  >
  > > ping, anything speaking against pushing it?
  >
  >
  > Push? :)
  
  
  I think we first need to get https://phabricator.kde.org/D7543 in, to be able 
to depend from the ECM version.

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

D7369: Wayland foreign protocol

[Martin Flöser]

graesslin requested changes to this revision.
graesslin added a comment.
This revision now requires changes to proceed.


  Overall lots of documentation is missing.
  
  From API layout that looks much better now, but we still have a few places 
where "Unstable" is needlessly in the API. Most important in Display the create 
method is not forward compatible by not having an enum to describe which 
interface version should be created.

INLINE COMMENTS

> registry.h:527-528
> +
> +zxdg_exporter_v1 *bindXdgExporterUnstableV1(uint32_t name, uint32_t 
> version) const;
> +zxdg_importer_v1 *bindXdgImporterUnstableV1(uint32_t name, uint32_t 
> version) const;
>  ///@}

please add documentation

> registry.h:940-941
> +
> +XdgExporter *createXdgExporterUnstable(quint32 name, quint32 version, 
> QObject *parent = nullptr);
> +XdgImporter *createXdgImporterUnstable(quint32 name, quint32 version, 
> QObject *parent = nullptr);
>  ///@}

please add documentation

> registry.h:940-941
> +
> +XdgExporter *createXdgExporterUnstable(quint32 name, quint32 version, 
> QObject *parent = nullptr);
> +XdgImporter *createXdgImporterUnstable(quint32 name, quint32 version, 
> QObject *parent = nullptr);
>  ///@}

Why did you keep the suffix "Unstable"?

> registry.h:1132-1133
> +
> +void exporterUnstableV1Announced(quint32 name, quint32 version);
> +void importerUnstableV1Announced(quint32 name, quint32 version);
>  ///@}

please add documentation

> registry.h:1288-1290
> +void exporterUnstableV1Removed(quint32 name);
> +void importerUnstableV1Removed(quint32 name);
>  ///@}

please add documentation

> display.h:223
>  
> +XdgForeignInterface *createXdgForeignUnstableInterface(QObject *parent = 
> nullptr);
>  /**

please add documentation.

Also the common way would be to have an enum to describe which interface should 
be created, but therefore drop the Unstable from the API name.

> xdgforeign_interface.h:37
> +class XdgImporterUnstableV1Interface;
> +
> +class KWAYLANDSERVER_EXPORT XdgForeignInterface : public QObject

Something like an enum ForeignInterfaceVersion is missing, please compare 
TextInputInterface

> xdgforeign_v1_interface.cpp:260
> +
> +QPointer imp = new 
> XdgImportedUnstableV1Interface(s->q, surface);
> +imp->create(s->display->getConnection(client), 
> wl_resource_get_version(resource), id);

what's an imp? Could you please write full variable names?

REPOSITORY
  R127 KWayland

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

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

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

[Martin Flöser]

Am 2017-09-05 12:10, schrieb Jonathan Riddell:

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.


Thanks for your bug reports, we also accept patches or bugs on
bugs.kde.org or KDE devs can commit directly :)


Before you start changing stuff: I think your packaging is correct here. 
The plugin gets loaded by kwin-core (which is part of kwin-common). The 
behavior with the plugin missing could become undefined any time the 
code changes and nobody would notice. So only packaging together with 
main_wayland as Debian does is dangerous :-)


Cheers
Martin

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

[Eike Hein]

hein added a comment.


  It lmost looked good, but I got this bug back:
  
  1. add fav to current activity (activity 1)
  2. add to activity 2 by checking in context menu while in activity 1
  3. switch to activity 2, verify it was added
  4. switch back to activity 1, in context menu uncheck activity 1
  5. switch back to activity 2 to verify it's still there - but it's gone
  
  I tried to repeat those steps and then at step 3, the favorite that 
disappeared at step 5 actually did show up. So this might be a case where the 
model didn't refresh correctly on activity switch? However with the new 
favorite I was trying it with, it didn't disappear. Then when I tried it again 
after trying some other things, it happened again, and other favorites 
disappeared as well alongside it.
  
  Another UX note: At some point during testing I added a new favorite directly 
to all activities. Then I switched from activity 1 to activity 2, and I saw on 
activity 2 the favorite wasn't appended to the list but appeared in front of 
the activity 2-only favorites. This isn't a huge deal breaker, although I feel 
like it might be simpler and more predictable for users to always just append - 
I thought the applets now have their own ordering conceptually so I was sort of 
surprised this didn't happen. But maybe I'm misunderstanding how per-applet 
ordering and global ordering (new applets need to get ordering from somewhere I 
guess ...) interact, or should interact. So don't get too scared by this 
feedback ...

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

Re: Videoconference between KDE community and Purism regarding Librem5

[Sebastian Kügler]

On dinsdag 5 september 2017 14:55:31 CEST R.Harish Navnit wrote:
> ​
> I assume notes or at least they key takeaways from the meeting will be
> shared around, but do you think it might be worthwhile to maybe record the
> meeting itself ? I know I'd be interested.

I can send notes about the meeting to kde-promo so we keep people who are 
interested in contributing in the loop.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org
-- 
http://vizZzion.org

Re: Videoconference between KDE community and Purism regarding Librem5

[Thomas Pfeiffer]

> On 5. Sep 2017, at 12:52, Sebastian Kügler  wrote:
> 
> Hi all,
> 
> On maandag 4 september 2017 20:29:26 CEST Zlatan Todoric wrote:
>> as Mak and me approached KDE community to discuss about potential
>> collaboration between two sides we found very welcoming community that
>> is not only eager about potential work on such device but also wants
>> to create a joint promotion (quotes, video, campaign page update etc).
>> 
>> So this is proposal for a Jitsi Meet videoconference on Wednesday (Sep
>> 6) 18.00 CET (9.00am PDT and noon for EST folks).
>> 
>> On our side we have: Todd (CEO), Mak (Lead PureOS/Debian Developer),
>> Nicole (our lead for phone), Francois (Creative), Jeff (Marketing
>> guru) and me (CTO/Debian Developer). We could add two more PureOS
>> developers which both are Debian Developers and one is currently DPL
>> (Chris and Jonas) but I don't want meeting to be to heavy on
>> resources as Jitsi sometimes just bugs on us.
>> 
>> Anyone from KDE is welcome, I just CC'ed those who sent (most) replies
>> on our discussion.
>> 
>> Let us know (all, even the Purism members) if date/time format is
>> working for you so we can have this (maybe historical?  meeting about
>> collaboration and promotion of both projects. If you will not be able
>> to participate, please add what date/time does work for you so we can
>> figure out better option (or maybe we can create doodle if there is
>> too many people not being able to participate at this time).
> 
> I just checked with Marco (responsible for the Plasma UI side) and
> Bhushan (our guy working on the stack and lower levels) (the people
> we'd absolutely want in this meeting from the Plasma side, I'm
> coordinating PR and communication for Plasma Mobile) and for us,
> Thursday would work much better, same time though.
> 
> So that's Thursday, 7th Sept, 18:00 CET (19:00 CEST and presumably
> 9.00am PDT, 12.00 EST)?
> 
> Is this something you could accommodate?
> 

For me, Thursday evening unfortunately wouldn’t work, but Aleix, vice president 
of KDE e.V., could be there on Thursday.
If it’s non Wednesday, I could be there.

It would also be good if Paul from the central KDE marketing / promo group 
could be in the meeting, to coordinate the promo campaigns directly.

Re: Videoconference between KDE community and Purism regarding Librem5

[Sebastian Kügler]

Hi,

On dinsdag 5 september 2017 13:32:09 CEST Thomas Pfeiffer wrote:
> > On 5. Sep 2017, at 12:52, Sebastian Kügler  wrote:
> > On maandag 4 september 2017 20:29:26 CEST Zlatan Todoric wrote:
> >> as Mak and me approached KDE community to discuss about potential
> >> collaboration between two sides we found very welcoming community
> >> that is not only eager about potential work on such device but
> >> also wants to create a joint promotion (quotes, video, campaign
> >> page update etc).
> >> 
> >> So this is proposal for a Jitsi Meet videoconference on Wednesday
> >> (Sep 6) 18.00 CET (9.00am PDT and noon for EST folks).
> >> 
> >> On our side we have: Todd (CEO), Mak (Lead PureOS/Debian
> >> Developer), Nicole (our lead for phone), Francois (Creative), Jeff
> >> (Marketing guru) and me (CTO/Debian Developer). We could add two
> >> more PureOS developers which both are Debian Developers and one is
> >> currently DPL (Chris and Jonas) but I don't want meeting to be to
> >> heavy on resources as Jitsi sometimes just bugs on us.
> >> 
> >> Anyone from KDE is welcome, I just CC'ed those who sent (most)
> >> replies on our discussion.
> >> 
> >> Let us know (all, even the Purism members) if date/time format is
> >> working for you so we can have this (maybe historical?  meeting
> >> about collaboration and promotion of both projects. If you will
> >> not be able to participate, please add what date/time does work
> >> for you so we can figure out better option (or maybe we can create
> >> doodle if there is too many people not being able to participate
> >> at this time).
> > 
> > I just checked with Marco (responsible for the Plasma UI side) and
> > Bhushan (our guy working on the stack and lower levels) (the people
> > we'd absolutely want in this meeting from the Plasma side, I'm
> > coordinating PR and communication for Plasma Mobile) and for us,
> > Thursday would work much better, same time though.
> > 
> > So that's Thursday, 7th Sept, 18:00 CET (19:00 CEST and presumably
> > 9.00am PDT, 12.00 EST)?
> > 
> > Is this something you could accommodate?
> 
> For me, Thursday evening unfortunately wouldn’t work, but Aleix, vice
> president of KDE e.V., could be there on Thursday. If it’s non
> Wednesday, I could be there.
> 
> It would also be good if Paul from the central KDE marketing / promo
> group could be in the meeting, to coordinate the promo campaigns
> directly.

I just talked with Paul, he'll be able to make it as well, so from the
KDE side, we get a rather complete set of people together to be useful,
technical, UI, and promo people involved. I'll ask Jens, our design
lead to join in as well, but let's pin down Thursday, 19:00 CEST
(9.00am PDT), in any case.

We can and probably will take details from the meeting and work on them 
separately.

Zlatan, if meeting time suits everyone at Purism, can you send around a
link to a specific jitsii room beforehand?

Thanks,
-- 
sebas

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

Re: Videoconference between KDE community and Purism regarding Librem5

[Nicole Faerber]

Am 05.09.2017 um 12:52 schrieb Sebastian Kügler:
> Hi all,
> 
> On maandag 4 september 2017 20:29:26 CEST Zlatan Todoric wrote:
>> as Mak and me approached KDE community to discuss about potential
>> collaboration between two sides we found very welcoming community that
>> is not only eager about potential work on such device but also wants
>> to create a joint promotion (quotes, video, campaign page update etc).
>>
>> So this is proposal for a Jitsi Meet videoconference on Wednesday (Sep
>> 6) 18.00 CET (9.00am PDT and noon for EST folks).
>>
>> On our side we have: Todd (CEO), Mak (Lead PureOS/Debian Developer),
>> Nicole (our lead for phone), Francois (Creative), Jeff (Marketing
>> guru) and me (CTO/Debian Developer). We could add two more PureOS
>> developers which both are Debian Developers and one is currently DPL
>> (Chris and Jonas) but I don't want meeting to be to heavy on
>> resources as Jitsi sometimes just bugs on us.
>>
>> Anyone from KDE is welcome, I just CC'ed those who sent (most) replies
>> on our discussion.
>>
>> Let us know (all, even the Purism members) if date/time format is
>> working for you so we can have this (maybe historical?  meeting about
>> collaboration and promotion of both projects. If you will not be able
>> to participate, please add what date/time does work for you so we can
>> figure out better option (or maybe we can create doodle if there is
>> too many people not being able to participate at this time).
> 
> I just checked with Marco (responsible for the Plasma UI side) and
> Bhushan (our guy working on the stack and lower levels) (the people
> we'd absolutely want in this meeting from the Plasma side, I'm
> coordinating PR and communication for Plasma Mobile) and for us,
> Thursday would work much better, same time though.
> 
> So that's Thursday, 7th Sept, 18:00 CET (19:00 CEST and presumably
> 9.00am PDT, 12.00 EST)?
> 
> Is this something you could accommodate?

That would work for me too, thank you!

> Cheers,
Cheers
  nicole



0x2D27BC78.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Videoconference between KDE community and Purism regarding Librem5

[R.Harish Navnit]

Hey,

On Tue, Sep 5, 2017 at 5:30 PM, Sebastian Kügler  wrote:

> Hi,
>
> On dinsdag 5 september 2017 13:32:09 CEST Thomas Pfeiffer wrote:
> > > On 5. Sep 2017, at 12:52, Sebastian Kügler  wrote:
> > > On maandag 4 september 2017 20:29:26 CEST Zlatan Todoric wrote:
> > >> as Mak and me approached KDE community to discuss about potential
> > >> collaboration between two sides we found very welcoming community
> > >> that is not only eager about potential work on such device but
> > >> also wants to create a joint promotion (quotes, video, campaign
> > >> page update etc).
> > >>
> > >> So this is proposal for a Jitsi Meet videoconference on Wednesday
> > >> (Sep 6) 18.00 CET (9.00am PDT and noon for EST folks).
> > >>
> > >> On our side we have: Todd (CEO), Mak (Lead PureOS/Debian
> > >> Developer), Nicole (our lead for phone), Francois (Creative), Jeff
> > >> (Marketing guru) and me (CTO/Debian Developer). We could add two
> > >> more PureOS developers which both are Debian Developers and one is
> > >> currently DPL (Chris and Jonas) but I don't want meeting to be to
> > >> heavy on resources as Jitsi sometimes just bugs on us.
> > >>
> > >> Anyone from KDE is welcome, I just CC'ed those who sent (most)
> > >> replies on our discussion.
> > >>
> > >> Let us know (all, even the Purism members) if date/time format is
> > >> working for you so we can have this (maybe historical?  meeting
> > >> about collaboration and promotion of both projects. If you will
> > >> not be able to participate, please add what date/time does work
> > >> for you so we can figure out better option (or maybe we can create
> > >> doodle if there is too many people not being able to participate
> > >> at this time).
> > >
> > > I just checked with Marco (responsible for the Plasma UI side) and
> > > Bhushan (our guy working on the stack and lower levels) (the people
> > > we'd absolutely want in this meeting from the Plasma side, I'm
> > > coordinating PR and communication for Plasma Mobile) and for us,
> > > Thursday would work much better, same time though.
> > >
> > > So that's Thursday, 7th Sept, 18:00 CET (19:00 CEST and presumably
> > > 9.00am PDT, 12.00 EST)?
> > >
> > > Is this something you could accommodate?
> >
> > For me, Thursday evening unfortunately wouldn’t work, but Aleix, vice
> > president of KDE e.V., could be there on Thursday. If it’s non
> > Wednesday, I could be there.
> >
> > It would also be good if Paul from the central KDE marketing / promo
> > group could be in the meeting, to coordinate the promo campaigns
> > directly.
>
> I just talked with Paul, he'll be able to make it as well, so from the
> KDE side, we get a rather complete set of people together to be useful,
> technical, UI, and promo people involved. I'll ask Jens, our design
> lead to join in as well, but let's pin down Thursday, 19:00 CEST
> (9.00am PDT), in any case.
>
> We can and probably will take details from the meeting and work on them
> separately.
>
​
I assume notes or at least they key takeaways from the meeting will be
shared around, but do you think it might be worthwhile to maybe record the
meeting itself ? I know I'd be interested.

-- 
Cheers,
Harish

Videoconference between KDE community and Purism regarding Librem5

[Zlatan Todoric]

Hello all,

as Mak and me approached KDE community to discuss about potential
collaboration between two sides we found very welcoming community that
is not only eager about potential work on such device but also wants to
create a joint promotion (quotes, video, campaign page update etc).

So this is proposal for a Jitsi Meet videoconference on Wednesday (Sep
6) 18.00 CET (9.00am PDT and noon for EST folks).

On our side we have: Todd (CEO), Mak (Lead PureOS/Debian Developer),
Nicole (our lead for phone), Francois (Creative), Jeff (Marketing guru)
and me (CTO/Debian Developer). We could add two more PureOS developers
which both are Debian Developers and one is currently DPL (Chris and
Jonas) but I don't want meeting to be to heavy on resources as Jitsi
sometimes just bugs on us.

Anyone from KDE is welcome, I just CC'ed those who sent (most) replies
on our discussion.

Let us know (all, even the Purism members) if date/time format is
working for you so we can have this (maybe historical? :)) meeting about
collaboration and promotion of both projects. If you will not be able to
participate, please add what date/time does work for you so we can
figure out better option (or maybe we can create doodle if there is too
many people not being able to participate at this time).

Happy hacking,

Z

Re: Videoconference between KDE community and Purism regarding Librem5

[Jeff F.]

Sebastian Kügler wrote :

> let's pin down Thursday, 19:00 CEST (9.00am PDT), in any case.


Works for me, added to my calendar tentatively, I'd like to hear
confirmation of Todd's availability.

Re: Videoconference between KDE community and Purism regarding Librem5

[Sebastian Kügler]

Hi all,

On maandag 4 september 2017 20:29:26 CEST Zlatan Todoric wrote:
> as Mak and me approached KDE community to discuss about potential
> collaboration between two sides we found very welcoming community that
> is not only eager about potential work on such device but also wants
> to create a joint promotion (quotes, video, campaign page update etc).
> 
> So this is proposal for a Jitsi Meet videoconference on Wednesday (Sep
> 6) 18.00 CET (9.00am PDT and noon for EST folks).
> 
> On our side we have: Todd (CEO), Mak (Lead PureOS/Debian Developer),
> Nicole (our lead for phone), Francois (Creative), Jeff (Marketing
> guru) and me (CTO/Debian Developer). We could add two more PureOS
> developers which both are Debian Developers and one is currently DPL
> (Chris and Jonas) but I don't want meeting to be to heavy on
> resources as Jitsi sometimes just bugs on us.
> 
> Anyone from KDE is welcome, I just CC'ed those who sent (most) replies
> on our discussion.
> 
> Let us know (all, even the Purism members) if date/time format is
> working for you so we can have this (maybe historical?  meeting about
> collaboration and promotion of both projects. If you will not be able
> to participate, please add what date/time does work for you so we can
> figure out better option (or maybe we can create doodle if there is
> too many people not being able to participate at this time).

I just checked with Marco (responsible for the Plasma UI side) and
Bhushan (our guy working on the stack and lower levels) (the people
we'd absolutely want in this meeting from the Plasma side, I'm
coordinating PR and communication for Plasma Mobile) and for us,
Thursday would work much better, same time though.

So that's Thursday, 7th Sept, 18:00 CET (19:00 CEST and presumably
9.00am PDT, 12.00 EST)?

Is this something you could accommodate?

Cheers,
-- 
sebas

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

D7369: Wayland foreign protocol

[Marco Martin]

mart retitled this revision from "[WIP] Wayland foreign protocol" to "Wayland 
foreign protocol".

REPOSITORY
  R127 KWayland

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

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

D7521: Make use of foreign protocol

[Marco Martin]

mart retitled this revision from "[WIP] make use of foreign protocol" to "Make 
use of foreign protocol".

REPOSITORY
  R108 KWin

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

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

D7694: Update app icons to match icon design guidelines

[Aditya Mehra]

Aiix accepted this revision as: MyCroft Integration.

REPOSITORY
  R846 Mycroft Plasma integration

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

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-05 12:10 GMT+02:00 Jonathan Riddell :
> On Mon, Sep 04, 2017 at 10:56:12PM +0200, Matthias Klumpp wrote:
>> > 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.
>
> There's nobody much watching over neon's copyright analysis so I often
> don't spend much time writing long copyright files. It's more
> important to me that the code KDE releases has clear and valid
> licences and I frequently make changes in KDE directly when it doesn't,
> as well as ensuring KDE projects actually make releases so they can
> get picked up by distros and that those releases follow a licence
> policy and best release practice plus defining those policies and best
> practice.

That makes complete sense for a project like Neon, which is
KDE-centric and wants to ship new version of KDEs software as soon as
possible.
Debian has a different focus there and treats all upstreams equal, in
equally not blindly trusting their license claims. That's why
copyright reviews are made and documented in d/copyright. Of course,
that's a pointless excercise if you *are* the upstream project :D

>> 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.
>
> I'm a bit lost here. epochs are typically set to keep package sets
> consistent with each other, you can blame stephan coolo for packaging
> KDE in debian in the 1990s. I'd love to have more sharing between
> kubuntu, neon and Debian. The neon packaging automatically merges in
> debian packaging for frameworks and makes it easy for everything else
> so I merge whenever there's a benefit.

I was specifically thinking about e.g. Muon getting an epoch although
it was a completely new package, etc. It's not really an obstacle for
collaboration though.

>> 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.
>
> Why thank you, I think :)

>From just very briefly looking at the things, the Neon packaging is
often times better/more complete. I did not expect Neon to have a
better d/copyright file, so that was very surprising :-D

> We like to automate things in neon so the automated QA tools will moan
> about some thing which get fixed. It would be great if Debian and/or
> kubuntu would merge these back but I suspect it doesn't happen much.
>
> Stuff gets packaged on different schedules of course so updates happen at 
> different times.

Right - with Neon being faster, adopting changes in Debian would make
a lot of sense though, instead of duplicating effort.

>> 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.
>
> Thanks for your bug reports, we also accept patches or bugs on
> bugs.kde.org or KDE devs can commit directly :)

Hehe ^^ - I think I'll fix that one directly then :-)

>> [...]
>> 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).
>
> Doing merges between neon/kubuntu/debian would be super awesome

I would love that! I am a member of the Debian KDE team, but the
majority of packaging work is not done by me, so I don't have that
much of a say about anything. But I could probably bring that up. The
primary person of contact about Debian KDE stuff would be maxy, I
think.
I think one of the best ways for collaboration would be merging the
Neon packaging autmatically into a branch of the corresponding Debian
packaging, so Debian can pick changes from there and ideally also send
patches back. Kubuntu was using a similar approach, but that was
stopped, so figuring out what went wrong there would likely be one of
the first things to do.

In any case, I think there is something we could do about making Neon
and KDE work better together. And also, I've put a task to investigate
fixing the Debian KDE task onto my todo list, because that one is
indeed not the 

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

[Ivan Čukić]

ivan updated this revision to Diff 19206.
ivan added a comment.


  Fixing the ordering

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

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
  kcms/kfontinst/thumbnail/fontthumbnail.desktop

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

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

[Aleix Pol Gonzalez]

This revision was automatically updated to reflect the committed changes.
Closed by commit R166:6304ed1e0f4e: Fix message when the image was shared using 
a plugin that doesn't reply with a… (authored by apol).

REPOSITORY
  R166 Spectacle

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7695?vs=19194=19205

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

AFFECTED FILES
  src/Gui/KSMainWindow.cpp

To: apol, #plasma, davidedmundson
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)

[Jonathan Riddell]

On Mon, Sep 04, 2017 at 10:56:12PM +0200, Matthias Klumpp wrote:
> > 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.

There's nobody much watching over neon's copyright analysis so I often
don't spend much time writing long copyright files. It's more
important to me that the code KDE releases has clear and valid
licences and I frequently make changes in KDE directly when it doesn't,
as well as ensuring KDE projects actually make releases so they can
get picked up by distros and that those releases follow a licence
policy and best release practice plus defining those policies and best
practice.

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

I'm a bit lost here. epochs are typically set to keep package sets
consistent with each other, you can blame stephan coolo for packaging
KDE in debian in the 1990s. I'd love to have more sharing between
kubuntu, neon and Debian. The neon packaging automatically merges in
debian packaging for frameworks and makes it easy for everything else
so I merge whenever there's a benefit.

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

Why thank you, I think :)

We like to automate things in neon so the automated QA tools will moan
about some thing which get fixed. It would be great if Debian and/or
kubuntu would merge these back but I suspect it doesn't happen much.

Stuff gets packaged on different schedules of course so updates happen at 
different times.

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

Thanks for your bug reports, we also accept patches or bugs on
bugs.kde.org or KDE devs can commit directly :)

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

lo siento

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

Doing merges between neon/kubuntu/debian would be super awesome

Jonathan

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

[Eike Hein]

hein added a comment.


  ^ What's new in the latest rev?

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

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

[David Edmundson]

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

REPOSITORY
  R166 Spectacle

BRANCH
  master

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

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