Respin request for KIO

2021-06-11 Thread Aleix Pol
Hi David,
It would be good that
https://invent.kde.org/frameworks/kio/-/commit/3bc92c23dd3456bb18efd44968fabf32dd9c3402
was included since 9c9c8df545ab5bd2362e7c01467d3875d79f30ce is also
inside and it fixes a regression.

Sorry for the inconvenience and thank you very much!

Aleix


Re: KGlobalAccel on non-Plasma systems

2021-04-06 Thread Aleix Pol
On Tue, Apr 6, 2021 at 5:30 PM Nicolas Fella  wrote:
>
> Hi,
>
> we received a few reports [1] [2] from people using non-Plasma systems
> that the kglobalaccel5 process was started, leading to clashes with the
> native global shortcut system.
>
> This seems to happen when apps call some API of KGlobalAccel which
> results in the kglobalaccel5 process to be DBus-activated.
>
> This brings me to the question of whether there is a use case for using
> KGlobalAccel on non-Plasma systems at all. While technically
> KGlobalAccel should work on all X11 systems most (all?) desktop
> environments have their own way of global shortcut handling that we
> should not interfere with. On Wayland it is only working in combination
> with KWin. On systems that do not use X11 (Windows, macOS, Android) it
> is most likely not useful at all. api.kde.org lists only Linux and
> FreeBSD as supported, but the code contains special casing for non-Unix
> platforms and for macOS.
>
> At the recent Frameworks sprint we talked about better communicating
> whether a given Framework is truly a cross-platform/cross-desktop
> library or an implementation detail of Plasma/used for integrating with
> Plasma [3]. It seems to me that KGlobalAccel falls into the latter
> category.
>
> If we agree that KGlobalAccel is only relevant when running Plasma we
> should take the necessary steps to ensure it does not get activated in a
> non-Plasma environment to avoid nasty side effects. Clearly defining the
> scope would also help frameworks and app developers make technical
> decisions and would allow to clean up some unneeded code.
>
> Thoughts?
>
> Cheers
>
> Nico
>
> [1] https://bugs.kde.org/show_bug.cgi?id=435420
>
> [2] https://bugs.kde.org/show_bug.cgi?id=430691
>
> [3] https://phabricator.kde.org/T14294
>

Hi Nico,
It makes a lot of sense.

And TBH, my first thought was "h n". But then it kind of does
make sense. KGlobalAccel has a lot of logic to centralise these
shortcuts settings and in practice it's nothing that would be
realistically mappable to a non-Plasma system.

So in general, yes. +1

Aleix


Plasma Wayland Protocols 1.2.0

2021-03-27 Thread Aleix Pol
Hello everyone,
We have just released a new 1.2 version that includes some extra
interfaces that will be necessary in the next KF5 release as well as
Plasma 5.22.

You can find it here:
https://download.kde.org/stable/plasma-wayland-protocols/plasma-wayland-protocols-1.2.0.tar.xz.mirrorlist

Thanks!
Aleix


Re: KDE Frameworks 6 - Virtual Sprint setup

2021-01-31 Thread Aleix Pol
On Fri, Jan 29, 2021 at 5:24 PM Adam Szopa  wrote:
>
> Hello,
>
> I've been talking with David Faure about setting up a Sprint focused on KF6  
> work. Some of the topics would include:
>
> - Reviewing the KF6 board (https://phabricator.kde.org/project/board/310/[1]):
>
> -- Clean up
>
> -- Tagging Junior Jobs
>
> - Working out a structure/process for handling:
>
> -- "Stuck" tasks
>
> -- Unit test regressions
>
> - Decide the 5.15 minimum requirement bump timeline
>
> - Decide on a 6 branching strategy and timeline
>
> - Decide if/how ECM should support multiple Qt versions
>
>
> That's just an example list - the wiki should include the up to date and 
> detailed topics.
>
>
> The Sprint will use the KDE BBB instance - same tech that powered last years  
> Akademy; I'll coordinate that with our sysadmins to have it available.
>
>
> As for the date and length, usually Virtual Sprints are a weekend thing. I'd
>
> love to hear from you if that sounds OK, and which weekend would be workable
>
> for you (how soon can we get this started) and your preferred availability
>
> hours. I'll set up a poll later to pinpoint the final timing.
>
>
> Thanks,
>
> - Adam

+1! :)


Re: KACL from KIO isn't really POSIX-compliant

2020-12-11 Thread Aleix Pol
On Wed, Dec 2, 2020 at 10:47 AM Gleb Popov <6year...@gmail.com> wrote:
>
> Hello everyone.
>
> I tried compiling kio/src/core/kacl.cpp on FreeBSD, which does support POSIX 
> ACLs, and failed. This is because KACL's code uses non-standard 
> Linux-specific acl_* functions. I tried implementing them using standard ones 
> and it turned out to be impossible, mainly because types like acl_t are 
> opaque to the user of the library.
>
> For instance, there is no standard acl_get_perm() function and it is 
> impossible to implement it without getting into acl_permset_t.
>
> Now I'm a bit unsure how to solve this. I can implement non-standard 
> functions in FreeBSD's libc without touching KACL code, or I can rewrite the 
> KACL class to be truly POSIX-compliant. The latter seems to be a better idea 
> on the first look, but it'd require keeping track of all the permission flags 
> set (again, because there is no acl_get_perm()) inside. This will turn KACL 
> class from being a tiny acl_* wrapper into a beefy chunk of code, but at 
> least we won't lie that it is POSIX-compliant.
>
> Any thoughts?
>
> P.S. Please CC me, as I'm not subscribed.

Adding Adriaan who has been working on KDE+FreeBSD things.

Aleix


Re: Would distributions have an issue if KF 5.77+ would require Qt >= 5.14 (instead of >= 5.13 as of now)?

2020-12-02 Thread Aleix Pol
On Tue, Dec 1, 2020 at 1:30 PM Jonathan Riddell  wrote:
>
> Not from KDE neon of course, we're on 5.15.  And not from the KDE snaps build 
> either.  But I suppose there's more than just Linux distros to consider as we 
> ship apps using KDE frameworks on Flatpak, Android, Windows, even Mac to 
> ponder too.
>
> Jonathan
>
>
> On Tue, 1 Dec 2020 at 12:14, Friedrich W. H. Kossebau  
> wrote:
>>
>> Hi,
>>
>> last week KDE Frameworks master saw a bump in the required/expected minimal 
>> Qt
>> version to Qt 5.13, following rules once agreed and noted here:
>> https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements
>>
>> I would like to challenge that former decision though and propose to instead
>> go straight to Qt 5.14 as minimum requirement now.
>>
>>
>> QUESTION:
>> Would any of the distributions have an issue with requiring Qt 5.14 instead 
>> of
>> Qt 5.13?
>>
>>
>> From some quick checks using https://repology.org/ it seems that any
>> distribution versions which currently use Qt 5.13 have also settled on some
>> older KF version, so will not update to just KF 5.77 and thus be screwed.
>>
>> Motivation:
>> * KDE CI not setup ATM to cover builds with Qt 5.13 (no build, no unit tests)
>> * Qt 5.14 added some new API, chance to miss out when using that in new code
>> * C++: no need to write #if QT_VERSION < QT_VERSION_CHECK(5, 14, 0) variants
>> * QML: no need to do hard-to-read generation tricks to support < Qt 5.14
>> * Qt 5.13 went out-of-support in June
>> * App bundle builders would rather use some recent Qt 5.14/5.15
>>
>> So by restraining to Qt 5.13 as minimum version IMHO we would make/keep life
>> complicated for KF contributors without adding any value for anyone.
>>
>> With most of KDE Frameworks in my local checkout:
>> grep "QT_VERSION_CHECK(5, 14, 0)"  frameworks/*/src -r 2>/dev/null | \
>> grep "QT_VERSION " | wc -l
>> gives me "92", so there are quite some code variants which need support in
>> current code.
>>
>> From the emails at least in 
>> https://mail.kde.org/pipermail/kde-frameworks-devel/2020-July/112712.html I 
>> could not see a discussion whether Qt 5.13 makes
>> sense at all now, seems mainly the algorithm was applied. I propose to match
>> the result to known real world needs now. Or teach me what I have missed here
>> :)
>>
>> Cheers
>> Friedrich

For Flatpak it's not a problem either, We've had 5.15 for a while.

Any distro shipping 5.13 right now (and 5.14 in 9 days) is doing a
disservice to its users anyway, since upstream isn't supporting it
either.
https://en.wikipedia.org/wiki/Qt_version_history#Qt_5

Aleix


Re: Stepping down as KRunner maintainer

2020-10-09 Thread Aleix Pol
Thanks to the both of you for the work done! :)

Updated the metainfo file of the krunner framework:
https://invent.kde.org/frameworks/krunner/commit/621ca6e3b2e518a546c1ac8651cfb2cfd4c25122

Aleix

On Thu, Oct 8, 2020 at 10:32 PM Nicolas Fella  wrote:
>
> Thanks for all your work Kai and congratulations Alexander, this is well
> deserved!
>
> Cheers
>
> Nico
>
> On 08.10.20 19:17, Kai Uwe Broulik wrote:
> > Hi everyone,
> >
> > you might not even have known this but officially I have been KRunner's 
> > maintainer for several years at this point :-)
> >
> > However, I have decided to step down as its maintainer as I believe won't 
> > be able to really move KRunner forward for KF6 despite a grand vision [1] 
> > for a lack of time and, frankly, motivation.
> >
> > Therefore, I'd like to pass the torch to Alexander Lohnau. He's bringing 
> > many fresh ideas to the table and is very enthusiastic about making KRunner 
> > shine again. He's also surely done more in the past months than I did in 
> > the past years and so it's only fair to not have his ambitions hindered by 
> > my unresponsiveness on code reviews.
> >
> > Alexander, thank you again for hosting that KRunner BoF at your first ever 
> > Akademy - the stage is yours ;-)
> >
> > Cheers
> > Kai Uwe
> >
> > [1] https://phabricator.kde.org/T12031


D29872: Provide methods to register SecretAgent to NetworkManager with capabilities, specifically with NM_SECRET_AGENT_CAPABILITY_VPN_HINTS

2020-08-02 Thread Aleix Pol Gonzalez
apol abandoned this revision.
apol added a comment.


  https://invent.kde.org/frameworks/networkmanager-qt/-/merge_requests/2

REPOSITORY
  R282 NetworkManagerQt

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

To: apol, jgrulich, enriquem
Cc: ngraham, apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns


D29872: Provide methods to register SecretAgent to NetworkManager with capabilities, specifically with NM_SECRET_AGENT_CAPABILITY_VPN_HINTS

2020-08-02 Thread Aleix Pol Gonzalez
apol commandeered this revision.
apol added a reviewer: enriquem.

REPOSITORY
  R282 NetworkManagerQt

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

To: apol, jgrulich, enriquem
Cc: ngraham, apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns


D29872: Provide methods to register SecretAgent to NetworkManager with capabilities, specifically with NM_SECRET_AGENT_CAPABILITY_VPN_HINTS

2020-08-01 Thread Aleix Pol Gonzalez
apol added a comment.


  We have moved to gitlab, now patches should be uploaded here: 
https://invent.kde.org/frameworks/networkmanager-qt
  
  Sorry for the change (@jgrulich can still review it, but it's better to have 
everything in the new infrastructure).
  
  The patch itself looks okay to me.

REPOSITORY
  R282 NetworkManagerQt

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

To: enriquem, jgrulich
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


Re: Dropping the moderation by default flag

2020-07-21 Thread Aleix Pol
El dt., 21 de jul. 2020, 21:16, Albert Astals Cid  va
escriure:

> Hi, this list has an unusual setting [for kde mailing lists] inherited
> from kde-core-devel that is that even subscribed people get moderated, and
> then the list moderator can decide to clear the moderate flag for each
> person one by one.
>
> I'm proposing to change that because:
>  * it's non consistent with the rest of kde mailing lists
>  * as moderator of this list i don't think i've seen ever any spam coming
> from a subscribed member.
>
> Opinions?
>
> Cheers,
>   Albert
>


+1

I've been moderating this mailing list too, nothing fishy ever happened
that was prevented by this setting.

Aleix

>


Re: Frameworks support for Qt 5.12

2020-07-15 Thread Aleix Pol
On Wed, Jul 15, 2020 at 6:13 PM Nicolas Fella  wrote:
>
> Hi,
>
> I received a question on how long KF5 will continue to support Qt 5.12.
>
> Given that 5.12 is an LTS release according to our policy it would be
> supported "until the next Qt release after the next Qt release", which
> would be 5.16, which will never exist.
>
> Our policy states "With Qt6 this changes a little bit again. To avoid
> supporting 5.12 LTS and 5.15 LTS for ever, 5.15 LTS will be the minimum
> required version 18 months after its release.". This however does not
> answer what will happen with 5.12.
>
> If I remember correctly our intention when formalizing this was to
> extrapolate the hypothetical releases and apply the existing rules to
> it. This would mean that by the time Qt 5.16 would be released (6 months
> after Qt 5.15) KF5 would drop support for Qt 5.12 and require 5.13.
>
> Is my interpretation of this correct? If so the wiki page should be
> updated with this information.

It means that 5.12 support will be discontinued, much like it is right
now for any older Qt release.

FWIW I am not sure it makes a lot of sense to stay with 5.12 for much
more though, I think supporting at least 5.14 soon would allow us to
remove several workarounds and warnings at least on QML code which we
will need solved anyway looking into the Qt 6.

Aleix


Re: Deprecate KRandomSequence ?

2020-06-29 Thread Aleix Pol
On Mon, Jun 29, 2020 at 10:27 PM Albert Astals Cid  wrote:
>
> QRandomGenerator is very similar in which you can give it a seed and get 
> randomness out of it.
>
> Things that QRandomGenerator doesn't have:
>  * getBool(); -> should be easy enough to port to bounded(2) == 1
>  * randomize(QList) -> We could add namespace function in KRandom
>  * modulate() -> Couldn't find any user, so no worries if we drop it
>
> Benefits of deprecation:
>  * Less manintaince
>
> Problems of deprecation:
>  * Moving from KRadomSequence(FIXED_SEED) to QRandomGenerator(FIXED_SEED) 
> will probably generate a different sequence, so if you need to 100% generate 
> the same sequence for all your app versions (e.g. for a game or something) 
> moving may not be "possible"
>
> Ideas? Comments?

+1 makes sense to me.

If an application was relying on the random application sequence, it
probably has bigger problems. It can always be hardcoded into the
application too.

Aleix


D27338: Provide an initial implementation for input-method-unstable-v1

2020-06-26 Thread Aleix Pol Gonzalez
apol abandoned this revision.
apol added a comment.


  https://invent.kde.org/plasma/kwayland-server/-/merge_requests/31

REPOSITORY
  R127 KWayland

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

To: apol, #kwin, #frameworks
Cc: davidedmundson, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


D22362: Port keystates to use QtWayland's generator

2020-06-26 Thread Aleix Pol Gonzalez
apol abandoned this revision.
apol added a comment.


  Moved to invent for kwayland-server

REPOSITORY
  R127 KWayland

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

To: apol, #kwin
Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


Re: KEmoticons, emoticons kcm

2020-05-24 Thread Aleix Pol
On Sun, May 24, 2020 at 3:09 AM Sandro Knauß  wrote:

> Hi,
>
> > Now while I know why this exists, it feels like it's more of a thing
> > of the past from when people wrote :) instead of .
>
> Okay now I feeling old :-) -  I don't even know how to create a unicode
> smiley, that's why I always create these :-) smileys.
>
> hefee
>

If you use any stable Plasma you'll get the emoji selector by pressing
meta+.(dot).

Aleix


Re: New Framework Review: KDAV

2020-05-24 Thread Aleix Pol
On Sun, May 24, 2020 at 8:52 AM Volker Krause  wrote:
>
> The remaining issues that didn't change ABI anymore (movable value types, hide
> private methods/slots inside the private classes, etc) have long since been
> addressed.
>
> I think there's two possible time slots to actually execute the move to
> frameworks now:
> * ASAP, for the June release.
> * For the July release, just in time for the 20.08 dependency freeze.
>
> Opinions?
>
> Thanks,
> Volker
>
> On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote:
> > Thanks for the review! We are cutting it close again with the 20.04
> > deadline, but fortunately most of these findings aren't ABI-breaking :)
> >
> > The result was discussed in more detail at the (virtual) PIM sprint, summary
> > below for the record.
> >
> > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote:
> > > Hello,
> > >
> > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote:
> > > > during Akademy there was a request to promote KDAV from KDE PIM to
> > > > Frameworks for use by Plasma Mobile. KDAV is a framework that implements
> > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It
> > > > would be classified as a functional tier 3 framework.
> > > >
> > > > So far we have fixed a number of obvious ABI-compatibility issues,
> > > > removed
> > > > QtXml[Patterns] usage from the public interface and relicensed GPL parts
> > > > (apart from a bit of test code) to LGPL. The next step would be a more
> > > > thorough review to identify changes necessary before becoming a
> > > > Framework.
> > > >
> > > > To avoid the last minute invasive changes we ended up doing for
> > > > KCalendarCore, I'd propose the following timeline:
> > > >
> > > > - identify and implement all necessary changes to the API and ABI until
> > > > the
> > > > 20.04 Application release (that includes the still necessary move to the
> > > > KF5 library namespace).
> > >
> > > I'm likely late to the party, but here is what I found by looking at KDAV
> > >
> > > master today (first day of the KDE PIM sprint):
> > >  * There's a few private methods or Q_SLOTS that I'd hide completely by
> > >
> > > moving them to the d-pointer, for the slots we're using type safe connects
> > > so they don't even need to be marked as slots at all;
> >
> > Cosmetic with no ABI impact, we can do that post 20.04 still.
> >
> > >  * Is it worth making DavCollection moveable? It's only copyable right
> > >  now;
> >
> > Probably yes, that's new API with no ABI break, so we can do that post 20.04
> > as well.
> >
> > >  * We might want to do something about "ctag" in DavCollection it's a bit
> > >
> > > obscure as a name (and the API doc doesn't help), also it seems to not be
> > > an official standard (while being widely supported) and there's the
> > > sync-token mechanism which has a RFC (RFC6578);
> >
> > I have no idea what ctag is (I am only doing the technical work needed to
> > turn this into a framework, I didn't write this library).
> >
> > >  * Why isn't DavCollectionModifyJob using DavCollection somehow? (might
> > >  just
> > >
> > > be my ignorance but I find it surprising that it is solely based on a
> > > property mechanism);
> >
> > I think this is to be able to control which properties get changed, rather
> > than sending the full set of them.
> >
> > >  * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter on
> > >
> > > its collectionDiscovered signal, is it really necessary? if it has to
> > > stay,
> > > shouldn't be at least documented? or at least a safer type than int?
> >
> > Fixed in https://phabricator.kde.org/D28564 and https://phabricator.kde.org/
> > D28566
> >
> > > * DavCollectionsMultiFetchJob is inconsistent as it's not using
> > > Q_DECLARE_PRIVATE;
> >
> > That's due to using KJob as a base directly.
> >
> > Subsequent discussion suggested this should be a KCompositeJob, David is
> > taking care of this.
> >
> > >  * KDAV::Error would benefit from more apidox;
> >
> > Yes, not blocked by the 20.04 freeze though.
> >
> > >  * Is it worth making DavItem moveable? It's only copyable right now;
> >
> > See above, same as DavCollection.
> >
> > >  * Same comment about etag for DavItem than the ctag one for DavCollection
> >
> > See above, same as ctag.
> >
> > >  * I'd be tempted to move all the protected methods of DavJobBase on its
> > >  d-
> > >
> > > pointer, the job subclasses would have access to them anyway, it'd make
> > > sense to put them protected in the header only if we expect subclasses
> > > outside of the lib (and I doubt this is actually supported);
> >
> > ABI impact mitigated by https://phabricator.kde.org/D28562 so we can clean
> > this up after 20.04.
> >
> > >  * It needs to decide between Qt smart pointers or STL ones I think, found
> > >  a
> > >
> > > bit of both so far (I'd lean toward STL ones but maybe that's just me);
> >
> > Also fixed by https://phabricator.kde.org/D28562.
> >
> > > * Make DavUrl moveable?

KEmoticons, emoticons kcm

2020-05-22 Thread Aleix Pol
Hi,
I was looking through some Plasma code and I saw that we have some
fairly old emoticons KCM using KF5Emoticons.

Now while I know why this exists, it feels like it's more of a thing
of the past from when people wrote :) instead of . While keeping it
around for the few apps that might still use it (ktp? kopete?) could
make sense, I'm afraid it's probably making it confusing for the users
who expect this to actually allow them to customise their  but
won't.

Do you think it would make sense to deprecate the framework and remove the KCM?

If some application still uses it, they can integrate the kcm
temporarily until their users come to terms that  is the new :).

Aleix


D28235: Add a simpler example

2020-05-22 Thread Aleix Pol Gonzalez
apol closed this revision.

REPOSITORY
  R216 Syntax Highlighting

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

To: apol, vkrause, cullmann
Cc: cullmann, kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, 
domson, michaelh, ngraham, bruns, demsking, sars, dhaumann


D26524: configmodule: Make sure the kcm information is loaded when the qml is created

2020-05-22 Thread Aleix Pol Gonzalez
apol added a comment.


  hmmm. Ping @mart. :) what do you suggest we do?

REPOSITORY
  R296 KDeclarative

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

To: apol, #plasma, #frameworks
Cc: mart, davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


D28235: Add a simpler example

2020-05-22 Thread Aleix Pol Gonzalez
apol added a comment.


  Should I understand this is not desired and that I should abandon it?
  
  I know it's not going to make a big difference to the project but it was hard 
for me to adopt it in the first place.

REPOSITORY
  R216 Syntax Highlighting

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

To: apol, vkrause
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann


D29540: plasmawindowmodel: Expose the internal id to the model

2020-05-19 Thread Aleix Pol Gonzalez
apol abandoned this revision.
apol added a comment.


  Will move to gitlab

REPOSITORY
  R127 KWayland

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

To: apol
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29810: Don't use setenv after fork

2020-05-17 Thread Aleix Pol Gonzalez
apol added inline comments.

INLINE COMMENTS

> kcrash.cpp:823
> +char** environ_end;
> +for(environ_end = environ; *environ_end; ++environ_end);
> +

Use {} instead of ; for readability.

REPOSITORY
  R285 KCrash

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

To: jpalecek, #frameworks
Cc: apol, anthonyfieroni, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


D29802: Require out-of-source builds

2020-05-17 Thread Aleix Pol Gonzalez
apol accepted this revision.

REPOSITORY
  R266 Breeze Icons

BRANCH
  require-in-source-build (branched from master)

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

To: ngraham, #frameworks, #vdg, ognarb, davidre, apol
Cc: ltoscano, davidre, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


D29745: look for kded as runtime dep

2020-05-14 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R241 KIO

BRANCH
  kded

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

To: sitter, dfaure, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29631: [android] Allow specifying APK install location

2020-05-11 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  androinstall

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

To: nicolasfella, #frameworks, #android, apol, vkrause
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns


D29600: Fix build with KF set to EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT

2020-05-11 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  fixbuildwithoutdeprecated

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

To: kossebau, #plasma, mart, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29631: [android] Allow specifying APK install location

2020-05-11 Thread Aleix Pol Gonzalez
apol added a comment.


  +1 overall, good idea.

REPOSITORY
  R240 Extra CMake Modules

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

To: nicolasfella, #frameworks, #android, apol, vkrause
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns


D29631: [android] Allow specifying APK install location

2020-05-11 Thread Aleix Pol Gonzalez
apol added inline comments.

INLINE COMMENTS

> Android.cmake:93
>  #
> -# The APK would then be found in ``myapp_build_apk/bin`` in the build 
> directory.
> +# You can specify the APK output directory by setting 
> ANDROID_APK_INSTALL_DIR.
> +# Otherwise the APK can be found in ``myapp_build_apk/`` in the build 
> directory.

ANDROID_APK_INSTALL_DIR should be between quotes like other variables.
Also I'd call the variable ANDROID_APK_OUTPUT_DIR. We have an install concept 
already.

> ECMAndroidDeployQt.cmake:85
>  add_custom_target(install-apk-${QTANDROID_EXPORTED_TARGET}
>  COMMAND adb install -r 
> "${EXPORT_DIR}/${QTANDROID_EXPORTED_TARGET}-${CMAKE_ANDROID_ARCH_ABI}.apk"
>  )

Needs adapting.

REPOSITORY
  R240 Extra CMake Modules

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

To: nicolasfella, #frameworks, #android, apol, vkrause
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns


D29511: Label: Add ping-pong logic

2020-05-10 Thread Aleix Pol Gonzalez
apol added a comment.


  I feel like this could break Labels unknowingly. Maybe it would make sense to 
have an extra scrollToFit (?) property or even another separate component to do 
that.
  
  Seeing things bouncing without the author intending could be worse than 
having the text cut off.

REPOSITORY
  R242 Plasma Framework (Library)

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

To: patrickelectric, #plasma, #vdg, ognarb, davidedmundson
Cc: apol, davidedmundson, ognarb, cblack, kde-frameworks-devel, LeGast00n, 
michaelh, ngraham, bruns


Re: RFC: relative executables in desktop files

2020-05-10 Thread Aleix Pol
On Sun, Apr 26, 2020 at 1:36 PM David Faure  wrote:
>
> During the review of https://phabricator.kde.org/D29170 the following 
> question surfaced again: should it be possible for a desktop file to refer to 
> an executable that is in the "current directory", for some definition of that 
> term. At least, outside of $PATH.
>
> In my opinion, in a GUI program started graphically, the notion of "current 
> dir" (QDir::currentPath()) has no meaning. The user can't see it and can't 
> change it. When starting the program from the command line it does serve a 
> purpose for command line arguments, but IMHO not after that (e.g. if you 
> navigate to another dir in dolphin, QDir::currentPath() still points to the 
> directory you started dolphin from).
>
> There is however another "current directory" that might make more sense when 
> starting a desktop file: the directory of the desktop file itself.
>
> There are actual use cases for that, see this very old request on the XDG 
> mailing-list:
> https://lists.freedesktop.org/archives/xdg/2011-April/011883.html
>
> AFAICS this discussion has 3 possible outcomes:
>
> * We do not support starting executables that are not in $PATH, end of story.
> That was actually what I had in mind when writing the code initially, any use 
> of API that also looked in the current directory (like QFileInfo::exists) was 
> accidental. Unless I'm mistaken, this is how it's been until now. It's also 
> what the XDG spec [1] says.
>
> * We support launching executables relative to the desktop file, 
> transparently. In the same directory, put a copy of dolphin called dolphin2, 
> and a copy of org.kde.dolphin.desktop modified to say Exec=dolphin2, and 
> clicking on the desktop file starts dolphin2. That's what my current revision 
> of D29170 does.
> I'm wondering if this is the right thing to do though.
> After all, on the command line "foo" doesn't start a local executable called 
> foo, only ./foo does that. Except for people who add "." to $PATH, but that's 
> generally not recommended (security, accidental use of wrong binary).
>
> * We could also adopt the above proposal from the xdg list, which is that 
> Exec=foo only looks in $PATH, while Exec=./foo only looks in the directory of 
> the desktop file.
>
> (I'm purposefully excluding the 4th option, resolving relative to 
> QDir::currentPath() which as explained at the top, would be nonsense IMHO)
>
> Thoughts?

One thing to note, which is probably easy to support: at the moment in
kwin we're relying on certain apps to be defined in absolute paths for
some security measures.

Just supporting $PATH makes most sense to me, there's increasingly
other ways to distribute software that abstract XDG out (e.g. snap,
appimage and flatpak). Weird custom uses should become increasingly
more rare over time.

Aleix


D28882: Create protocol to manage video feeds

2020-05-08 Thread Aleix Pol Gonzalez
apol added a comment.


  Moving to kwayland-server

REPOSITORY
  R127 KWayland

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

To: apol, #kwin, jgrulich, davidedmundson, zzag
Cc: meven, davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, 
cblack, michaelh, ngraham, bruns


D28882: Create protocol to manage video feeds

2020-05-08 Thread Aleix Pol Gonzalez
apol abandoned this revision.

REPOSITORY
  R127 KWayland

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

To: apol, #kwin, jgrulich, davidedmundson, zzag
Cc: meven, davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, 
cblack, michaelh, ngraham, bruns


D29540: plasmawindowmodel: Expose the internal id to the model

2020-05-08 Thread Aleix Pol Gonzalez
apol created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
apol requested review of this revision.

REVISION SUMMARY
  It allows to use this class together with the screencast protocol.
  It's public API on the window anyway so it should probably be exposed.

TEST PLAN
  Used it with the other screencast patches for convenience.

REPOSITORY
  R127 KWayland

BRANCH
  master

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

AFFECTED FILES
  src/client/plasmawindowmodel.cpp
  src/client/plasmawindowmodel.h

To: apol
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29445: [KOpenWithDialog] When pointing at a non-executable file print more meaningful error

2020-05-05 Thread Aleix Pol Gonzalez
apol added inline comments.

INLINE COMMENTS

> kopenwithdialog.cpp:1006
>  // Ensure that the typed binary name actually exists (#81190)
>  if (QStandardPaths::findExecutable(binaryName).isEmpty()) {
> +// Maybe it exists but isn't executable

This patch D29170  suggests that 
findExecutable won't find non-executables.

Something's wrong.

REPOSITORY
  R241 KIO

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

To: broulik, #frameworks, #vdg
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29406: Add X-KDE-Original-Executable to Applications properties

2020-05-04 Thread Aleix Pol Gonzalez
apol added a comment.


  > If I understand correctly, it is necessary to use dbus spectacle in this 
case, so that dbus can manage the application instance and make sure we end up 
with only one, whether we launch the app, use a shortcut or launch from command 
line.
  
  I don't think that's a good reason. We have lots of applications that do that 
without having to be launched by dbus: plasmashell, krunner, yakuake, etc. It's 
done by using KDBusService.

REPOSITORY
  R309 KService

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

To: meven, #frameworks, davidedmundson, apol, bport
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29405: [PoC] Make notifications work without a notifyrc file

2020-05-04 Thread Aleix Pol Gonzalez
apol added a comment.


  What's the advantage?
  Won't this make it harder to put together the notifications kcm?

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik, vkrause
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29406: Add X-KDE-Original-Executable to Applications properties

2020-05-04 Thread Aleix Pol Gonzalez
apol added a comment.


  This should be documented somewhere, as is it's really confusing.
  
  I'm not sure it wouldn't be better to have spectacle launched again there 
instead of going through dbus (which is a change I admittedly don't understand 
very well).

REPOSITORY
  R309 KService

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

To: meven, #frameworks, davidedmundson, apol, bport
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29396: Suppress find_package_handle_standard_args package name mismatch warning.

2020-05-03 Thread Aleix Pol Gonzalez
apol accepted this revision.
apol added a comment.
This revision is now accepted and ready to land.


  This will make our configure steps readable again. Thanks!

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

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

To: xuetianweng, #frameworks, #build_system, apol
Cc: apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns


D29201: KCMUtils: Add option to append service file to list of arguments

2020-05-03 Thread Aleix Pol Gonzalez
apol added a comment.


  I have the feeling there's a missing piece here.
  
  Would it make sense to always pass it? Would it regress in any way?
  
  At the very least, on the API documentation, explain why one would want that.

REPOSITORY
  R295 KCMUtils

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

To: alex, #plasma, ngraham, meven, broulik
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29361: KCrash: remove debug output which breaks unittests from using ~/.qttest/config for categorized logging

2020-05-03 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R285 KCrash

BRANCH
  master

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

To: dfaure, kossebau, davidedmundson, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


Re: Information regarding upcoming Gitlab Migration: clarifications

2020-05-01 Thread Aleix Pol
On Fri, May 1, 2020 at 7:18 AM Ben Cooksley  wrote:
>
> On Fri, May 1, 2020 at 4:38 PM Nate Graham  wrote:
> >
> >
> >
> > On 4/30/20 5:59 PM, Aleix Pol wrote:
> > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
> > >> Am I the only person that just has all the repos on the same folder? I 
> > >> thought it was the common thing to do :?
> > >
> > > I do too
> >
> > Same here. kdesrc-build's default settings do this, and download all
> > repos into ~/kde/src without any of the levels of hierarchy. This would
> > seem to require unique repo names, no?
>
> Not necessarily.
>
> Git allows you to override the name that the local folder is called
> when cloning, so there is no reason why we can't specify something in
> the metadata to override the local name that the folder gets called in
> your local checkout folder.
> This would allow for example:
>
> - frameworks/kcoreaddons on Gitlab continues to be called
> 'kcoreaddons' in your local checkout folder
> - maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout 
> folder
>
> This allows for the URLs on Gitlab to make sense, while simultaneously
> allowing your local source checkout folders to continue to work in the
> manner in which they do currently.
> Note that we do not expect people to hit this in many cases - this is
> about giving us the flexibility for the long term without imposing
> unnecessary bureaucracy and limits on projects within the KDE
> umbrella.
>
> Automated tooling such as kdesrc-build and the proposed clone script
> (that searches in namespaces) should be able to handle this without
> much issue.
> In the case of manually done clones, it is reasonable to expect people
> to know what they're doing with their clones, and name them
> appropriately in the event they have a collision.
>
> Does this sound acceptable?

Okay, if that's necessary, we'll have to do it.

We'll appreciate simpler bureaucracy.

Aleix


Re: Information regarding upcoming Gitlab Migration: clarifications

2020-04-30 Thread Aleix Pol
On Fri, May 1, 2020 at 1:08 AM Nicolás Alvarez
 wrote:
>
> El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
> (aa...@kde.org) escribió:
> >
> > El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va 
> > escriure:
> > > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
> > > >
> > > > > We have made a big fuss in the past about having different projects
> > > > > that do the same thing and now we'll have that but also we'll have
> > > > > several projects with the same name?
> > > > > It really feels off to me and I wonder if this is related to the move 
> > > > > to
> > > > > gitlab.
> > > >
> > > > +1 to both sentiments - that projects should have different names and 
> > > > that
> > > > this is a bit off topic for the gitlab migration.
> > >
> > > The projects *DO* have very different names. That *HAS NOT* changed.
> > > To use the example Bhushan gave above, one is called Plasma Mobile
> > > Dialer and the other one is called Maui Dialer.
> > >
> > > With the current git.kde.org setup, we have a flat namespace, so all
> > > repositories if the name appears to be generic (as dialer is) have to
> > > be namespaced by prefixing of the repository name.
> > >
> > > With Gitlab however we will now namespaces that group repositories,
> > > making the prefixing unnecessary and as some projects have complained
> > > about, duplicative.
> > >
> > > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
> > > path, which just looks silly.
> >
> > Am I the only person that just has all the repos on the same folder? I 
> > thought it was the common thing to do :?

I do too

> Oh, your local path could be anywhere. It doesn't even need the same
> name, you can put it in the same folder as the rest and call it
> dial-thingy :)

And then you'll have to have a modified build script to account for
thingy because KDE can't stay consistent at naming.

I suggest not to use the gitlab transition to make such an important change.

Aleix


2 new repositories: plasma-wayland-protocols and kwayland-server

2020-04-30 Thread Aleix Pol
Hi everyone,
After long discussions, we have broken kwayland into 3 pieces so we
can work and improve kwin_wayland without having to extend our stable
framework constantly. This of course comes together with an updated
policy with regards to where things should be developed with the goal
of only adding Wayland protocol implementation public interfaces in
the cases that will be shared among several users.

This then includes 2 new repositories:
kdesupport/plasma-wayland-protocols
kde/workspace/kwayland-server

The first should be released independently whenever we have a new
protocol, the latter only together with the rest of Plasma.

Over the next months we'll adapt KWayland as well to depend on
plasma-wayland-protocols and deprecate some of its parts that are now
duplicated.

Anything compiling against kwayland for now is fine and will continue
to work. It still needs to be installed.
All 3 are co-installable.

Sorry for the extra work of caring for the extra repositories. We are
convinced it will be worth it in the long run.

Best regards,
Aleix


Re: Information regarding upcoming Gitlab Migration: clarifications

2020-04-30 Thread Aleix Pol
On Wed, Apr 29, 2020 at 12:25 PM Bhushan Shah  wrote:
>
> Good afternoon,
>
> [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> replies]
>
> I want to clarify some bits for which we have gotten a questions about,
>
> - Non unique naming: There's some teams which prefer if we dropped the
>   namespace- part from their name which we have added. While currently
>   this does not result in the naming conflict right away, we realize
>   this will cause it at one point, for example,
>
>   maui-dialer -> maui/dialer
>   plasma-dialer -> plasma-mobile/dialer
>
>   To minimize the impact of the Gitlab move we won't be doing such
>   renames which introduce non-unique names right away. But we would
>   prefer if the existing tooling or infrastructure is ready for this
>   kind of cases at later point. Only way to enforce non-unique naming is
>   one big KDE/ subgroup which we want to avoid.
>
>   Current naming in the repo-metadata branch[1] I've pointed does not
>   reflect those renames, as we are not planning to do those renames
>   right away during gitlab move, but at a later stage.

We have made a big fuss in the past about having different projects
that do the same thing and now we'll have that but also we'll have
several projects with the same name?
It really feels off to me and I wonder if this is related to the move to gitlab.

> - Existing configurations: we want to reduce impact on existing release
>   schedule, and existing developer workflow,  therefore we will continue
>   to privide the existing anongit.kde.org and git.kde.org (although this
>   will be read-only) with current flat structuring for 3 weeks after
>   actual migration, which will keep the existing scripts/clones working
>   enough to give developers time to change to the new structure.
>
>   We will also try to provide a script which allows you to migrate your
>   existing clones to new repo paths and as mentioned by Ben in other
>   message, potentially a git-kde script which would allow you to clone
>   individual repository without knowing it's namespace (provided that
>   there is no conflict of it's name). like "git kde karchive"

IMHO needing tools ad-hoc to KDE development can be a barrier of entrance.
I feel like these things make us look distant, it's important that
people's skills translate automatically when they want to get started.

> - Translations: we will co-ordinate with the translations team to let
>   them adapt their tooling to updated structure as this requires changes
>   on their side how translations are stored in svn repository

Thanks! :)


D29278: Port KWin to KWaylandServer

2020-04-30 Thread Aleix Pol Gonzalez
This revision was automatically updated to reflect the committed changes.
Closed by commit R108:3a9d7a6e9d75: Port KWin to KWaylandServer (authored by 
apol).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D29278?vs=81574=81575#toc

REPOSITORY
  R108 KWin

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29278?vs=81574=81575

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

AFFECTED FILES
  CMakeLists.txt
  abstract_client.cpp
  abstract_client.h
  abstract_output.cpp
  abstract_output.h
  abstract_wayland_output.cpp
  abstract_wayland_output.h
  autotests/CMakeLists.txt
  autotests/integration/dont_crash_cursor_physical_size_empty.cpp
  autotests/integration/globalshortcuts_test.cpp
  autotests/integration/idle_inhibition_test.cpp
  autotests/integration/input_stacking_order.cpp
  autotests/integration/internal_window.cpp
  autotests/integration/lockscreen.cpp
  autotests/integration/maximize_test.cpp
  autotests/integration/plasmawindow_test.cpp
  autotests/integration/pointer_constraints_test.cpp
  autotests/integration/pointer_input.cpp
  autotests/integration/scene_opengl_shadow_test.cpp
  autotests/integration/scene_qpainter_shadow_test.cpp
  autotests/integration/scene_qpainter_test.cpp
  autotests/integration/test_helpers.cpp
  autotests/integration/transient_placement.cpp
  autotests/integration/xdgshellclient_test.cpp
  autotests/integration/xwayland_input_test.cpp
  autotests/integration/xwayland_selections_test.cpp
  autotests/mock_effectshandler.h
  autotests/test_window_paint_data.cpp
  composite.cpp
  debug_console.cpp
  decorations/decorationbridge.cpp
  effects.cpp
  effects.h
  effects/backgroundcontrast/contrast.cpp
  effects/backgroundcontrast/contrast.h
  effects/blur/blur.cpp
  effects/blur/blur.h
  effects/desktopgrid/desktopgrid.cpp
  effects/slidingpopups/slidingpopups.cpp
  events.cpp
  idle_inhibition.cpp
  idle_inhibition.h
  input.cpp
  keyboard_input.cpp
  keyboard_repeat.cpp
  libkwineffects/CMakeLists.txt
  libkwineffects/kwineffects.cpp
  libkwineffects/kwineffects.h
  linux_dmabuf.cpp
  linux_dmabuf.h
  main.cpp
  main_wayland.cpp
  platform.cpp
  platform.h
  platformsupport/scenes/opengl/CMakeLists.txt
  platformsupport/scenes/opengl/abstract_egl_backend.cpp
  platformsupport/scenes/opengl/abstract_egl_backend.h
  platformsupport/scenes/opengl/egl_dmabuf.cpp
  platformsupport/scenes/opengl/egl_dmabuf.h
  plugins/platforms/drm/drm_backend.cpp
  plugins/platforms/drm/drm_inputeventfilter.cpp
  plugins/platforms/drm/drm_output.cpp
  plugins/platforms/drm/drm_output.h
  plugins/platforms/drm/egl_stream_backend.cpp
  plugins/platforms/drm/egl_stream_backend.h
  plugins/platforms/drm/remoteaccess_manager.cpp
  plugins/platforms/drm/remoteaccess_manager.h
  plugins/platforms/fbdev/fb_backend.cpp
  plugins/platforms/hwcomposer/hwcomposer_backend.cpp
  plugins/platforms/hwcomposer/hwcomposer_backend.h
  plugins/platforms/virtual/virtual_backend.cpp
  plugins/platforms/virtual/virtual_output.cpp
  plugins/platforms/wayland/egl_wayland_backend.cpp
  plugins/platforms/wayland/wayland_backend.cpp
  plugins/platforms/wayland/wayland_output.cpp
  plugins/platforms/x11/windowed/x11windowed_backend.cpp
  plugins/platforms/x11/windowed/x11windowed_output.cpp
  plugins/scenes/opengl/scene_opengl.cpp
  plugins/scenes/opengl/scene_opengl.h
  plugins/scenes/qpainter/scene_qpainter.cpp
  plugins/scenes/qpainter/scene_qpainter.h
  pointer_input.cpp
  pointer_input.h
  scene.cpp
  scene.h
  shadow.cpp
  shadow.h
  tablet_input.cpp
  toplevel.cpp
  toplevel.h
  touch_input.cpp
  virtualdesktops.cpp
  virtualdesktops.h
  virtualkeyboard.cpp
  wayland_cursor_theme.cpp
  wayland_server.cpp
  wayland_server.h
  xdgshellclient.cpp
  xdgshellclient.h
  xkb.cpp
  xkb.h
  xwl/clipboard.cpp
  xwl/clipboard.h
  xwl/databridge.cpp
  xwl/databridge.h
  xwl/dnd.cpp
  xwl/dnd.h
  xwl/drag_wl.cpp
  xwl/drag_wl.h
  xwl/drag_x.cpp
  xwl/drag_x.h
  xwl/selection_source.cpp
  xwl/selection_source.h
  xwl/transfer.cpp
  xwl/transfer.h

To: apol, #kwin, #plasma, #frameworks, davidedmundson, zzag
Cc: zzag, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, 
ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, 
romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D29278: Port KWin to KWaylandServer

2020-04-30 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 81574.
apol added a comment.


  Address @zzag's comments

REPOSITORY
  R108 KWin

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29278?vs=81521=81574

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  abstract_client.cpp
  abstract_client.h
  abstract_output.cpp
  abstract_output.h
  abstract_wayland_output.cpp
  abstract_wayland_output.h
  autotests/CMakeLists.txt
  autotests/integration/dont_crash_cursor_physical_size_empty.cpp
  autotests/integration/globalshortcuts_test.cpp
  autotests/integration/idle_inhibition_test.cpp
  autotests/integration/input_stacking_order.cpp
  autotests/integration/internal_window.cpp
  autotests/integration/lockscreen.cpp
  autotests/integration/maximize_test.cpp
  autotests/integration/plasmawindow_test.cpp
  autotests/integration/pointer_constraints_test.cpp
  autotests/integration/pointer_input.cpp
  autotests/integration/scene_opengl_shadow_test.cpp
  autotests/integration/scene_qpainter_shadow_test.cpp
  autotests/integration/scene_qpainter_test.cpp
  autotests/integration/test_helpers.cpp
  autotests/integration/transient_placement.cpp
  autotests/integration/xdgshellclient_test.cpp
  autotests/integration/xwayland_input_test.cpp
  autotests/integration/xwayland_selections_test.cpp
  autotests/mock_effectshandler.h
  autotests/test_window_paint_data.cpp
  composite.cpp
  debug_console.cpp
  decorations/decorationbridge.cpp
  effects.cpp
  effects.h
  effects/backgroundcontrast/contrast.cpp
  effects/backgroundcontrast/contrast.h
  effects/blur/blur.cpp
  effects/blur/blur.h
  effects/desktopgrid/desktopgrid.cpp
  effects/slidingpopups/slidingpopups.cpp
  events.cpp
  idle_inhibition.cpp
  idle_inhibition.h
  input.cpp
  keyboard_input.cpp
  keyboard_repeat.cpp
  libkwineffects/CMakeLists.txt
  libkwineffects/kwineffects.cpp
  libkwineffects/kwineffects.h
  linux_dmabuf.cpp
  linux_dmabuf.h
  main.cpp
  main_wayland.cpp
  platform.cpp
  platform.h
  platformsupport/scenes/opengl/CMakeLists.txt
  platformsupport/scenes/opengl/abstract_egl_backend.cpp
  platformsupport/scenes/opengl/abstract_egl_backend.h
  platformsupport/scenes/opengl/egl_dmabuf.cpp
  platformsupport/scenes/opengl/egl_dmabuf.h
  plugins/platforms/drm/drm_backend.cpp
  plugins/platforms/drm/drm_inputeventfilter.cpp
  plugins/platforms/drm/drm_output.cpp
  plugins/platforms/drm/drm_output.h
  plugins/platforms/drm/egl_stream_backend.cpp
  plugins/platforms/drm/egl_stream_backend.h
  plugins/platforms/drm/remoteaccess_manager.cpp
  plugins/platforms/drm/remoteaccess_manager.h
  plugins/platforms/fbdev/fb_backend.cpp
  plugins/platforms/hwcomposer/hwcomposer_backend.cpp
  plugins/platforms/hwcomposer/hwcomposer_backend.h
  plugins/platforms/virtual/virtual_backend.cpp
  plugins/platforms/virtual/virtual_output.cpp
  plugins/platforms/wayland/egl_wayland_backend.cpp
  plugins/platforms/wayland/wayland_backend.cpp
  plugins/platforms/wayland/wayland_output.cpp
  plugins/platforms/x11/windowed/x11windowed_backend.cpp
  plugins/platforms/x11/windowed/x11windowed_output.cpp
  plugins/scenes/opengl/scene_opengl.cpp
  plugins/scenes/opengl/scene_opengl.h
  plugins/scenes/qpainter/scene_qpainter.cpp
  plugins/scenes/qpainter/scene_qpainter.h
  pointer_input.cpp
  pointer_input.h
  scene.cpp
  scene.h
  shadow.cpp
  shadow.h
  tablet_input.cpp
  toplevel.cpp
  toplevel.h
  touch_input.cpp
  virtualdesktops.cpp
  virtualdesktops.h
  virtualkeyboard.cpp
  wayland_cursor_theme.cpp
  wayland_server.cpp
  wayland_server.h
  xdgshellclient.cpp
  xdgshellclient.h
  xkb.cpp
  xkb.h
  xwl/clipboard.cpp
  xwl/clipboard.h
  xwl/databridge.cpp
  xwl/databridge.h
  xwl/dnd.cpp
  xwl/dnd.h
  xwl/drag_wl.cpp
  xwl/drag_wl.h
  xwl/drag_x.cpp
  xwl/drag_x.h
  xwl/selection_source.cpp
  xwl/selection_source.h
  xwl/transfer.cpp
  xwl/transfer.h

To: apol, #kwin, #plasma, #frameworks, davidedmundson
Cc: zzag, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, 
ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, 
romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D29278: Port KWin to KWaylandServer

2020-04-30 Thread Aleix Pol Gonzalez
apol marked an inline comment as done.

REPOSITORY
  R108 KWin

BRANCH
  master

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

To: apol, #kwin, #plasma, #frameworks, davidedmundson
Cc: zzag, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, 
ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, 
romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D29278: Port KWin to KWaylandServer

2020-04-29 Thread Aleix Pol Gonzalez
apol created this revision.
apol added reviewers: KWin, Plasma, Frameworks.
Herald added a project: KWin.
Herald added a subscriber: kwin.
apol requested review of this revision.

REVISION SUMMARY
  Away from KWayland::Server and KF5WaylandServer.

TEST PLAN
  Builds, ran nested session

REPOSITORY
  R108 KWin

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  abstract_client.cpp
  abstract_client.h
  abstract_output.cpp
  abstract_output.h
  abstract_wayland_output.cpp
  abstract_wayland_output.h
  autotests/CMakeLists.txt
  autotests/integration/dont_crash_cursor_physical_size_empty.cpp
  autotests/integration/globalshortcuts_test.cpp
  autotests/integration/idle_inhibition_test.cpp
  autotests/integration/input_stacking_order.cpp
  autotests/integration/internal_window.cpp
  autotests/integration/lockscreen.cpp
  autotests/integration/maximize_test.cpp
  autotests/integration/plasmawindow_test.cpp
  autotests/integration/pointer_constraints_test.cpp
  autotests/integration/pointer_input.cpp
  autotests/integration/scene_opengl_shadow_test.cpp
  autotests/integration/scene_qpainter_shadow_test.cpp
  autotests/integration/scene_qpainter_test.cpp
  autotests/integration/test_helpers.cpp
  autotests/integration/transient_placement.cpp
  autotests/integration/xdgshellclient_test.cpp
  autotests/integration/xwayland_input_test.cpp
  autotests/integration/xwayland_selections_test.cpp
  autotests/mock_effectshandler.h
  autotests/test_window_paint_data.cpp
  composite.cpp
  debug_console.cpp
  decorations/decorationbridge.cpp
  effects.cpp
  effects.h
  effects/backgroundcontrast/contrast.cpp
  effects/backgroundcontrast/contrast.h
  effects/blur/blur.cpp
  effects/blur/blur.h
  effects/desktopgrid/desktopgrid.cpp
  effects/slidingpopups/slidingpopups.cpp
  events.cpp
  idle_inhibition.cpp
  idle_inhibition.h
  input.cpp
  keyboard_input.cpp
  keyboard_repeat.cpp
  libkwineffects/CMakeLists.txt
  libkwineffects/kwineffects.cpp
  libkwineffects/kwineffects.h
  linux_dmabuf.cpp
  linux_dmabuf.h
  main.cpp
  main_wayland.cpp
  platform.cpp
  platform.h
  platformsupport/scenes/opengl/CMakeLists.txt
  platformsupport/scenes/opengl/abstract_egl_backend.cpp
  platformsupport/scenes/opengl/abstract_egl_backend.h
  platformsupport/scenes/opengl/egl_dmabuf.cpp
  platformsupport/scenes/opengl/egl_dmabuf.h
  plugins/platforms/drm/drm_backend.cpp
  plugins/platforms/drm/drm_inputeventfilter.cpp
  plugins/platforms/drm/drm_output.cpp
  plugins/platforms/drm/drm_output.h
  plugins/platforms/drm/egl_stream_backend.cpp
  plugins/platforms/drm/egl_stream_backend.h
  plugins/platforms/drm/remoteaccess_manager.cpp
  plugins/platforms/drm/remoteaccess_manager.h
  plugins/platforms/fbdev/fb_backend.cpp
  plugins/platforms/hwcomposer/hwcomposer_backend.cpp
  plugins/platforms/hwcomposer/hwcomposer_backend.h
  plugins/platforms/virtual/virtual_backend.cpp
  plugins/platforms/virtual/virtual_output.cpp
  plugins/platforms/wayland/egl_wayland_backend.cpp
  plugins/platforms/wayland/wayland_backend.cpp
  plugins/platforms/wayland/wayland_output.cpp
  plugins/platforms/x11/windowed/x11windowed_backend.cpp
  plugins/platforms/x11/windowed/x11windowed_output.cpp
  plugins/scenes/opengl/scene_opengl.cpp
  plugins/scenes/opengl/scene_opengl.h
  plugins/scenes/qpainter/scene_qpainter.cpp
  plugins/scenes/qpainter/scene_qpainter.h
  pointer_input.cpp
  pointer_input.h
  scene.cpp
  scene.h
  shadow.cpp
  shadow.h
  tablet_input.cpp
  toplevel.cpp
  toplevel.h
  touch_input.cpp
  virtualdesktops.cpp
  virtualdesktops.h
  virtualkeyboard.cpp
  wayland_cursor_theme.cpp
  wayland_server.cpp
  wayland_server.h
  xdgshellclient.cpp
  xdgshellclient.h
  xkb.cpp
  xkb.h
  xwl/clipboard.cpp
  xwl/clipboard.h
  xwl/databridge.cpp
  xwl/databridge.h
  xwl/dnd.cpp
  xwl/dnd.h
  xwl/drag_wl.cpp
  xwl/drag_wl.h
  xwl/drag_x.cpp
  xwl/drag_x.h
  xwl/selection_source.cpp
  xwl/selection_source.h
  xwl/transfer.cpp
  xwl/transfer.h

To: apol, #kwin, #plasma, #frameworks
Cc: kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, 
ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, 
romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart


D29256: [server] Introduce mapped() signal

2020-04-29 Thread Aleix Pol Gonzalez
apol accepted this revision.

REPOSITORY
  R127 KWayland

BRANCH
  introduce-mapped-signal

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

To: zzag, #kwin, davidedmundson, apol
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29079: android: include the architecture on the apk name

2020-04-28 Thread Aleix Pol Gonzalez
This revision was automatically updated to reflect the committed changes.
Closed by commit R240:fca97c036c8d: android: include the architecture on the 
apk name (authored by apol).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29079?vs=80829=81480

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

AFFECTED FILES
  toolchain/ECMAndroidDeployQt.cmake

To: apol, #android, #frameworks, nicolasfella
Cc: vkrause, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, 
bencreasy, michaelh, ngraham, bruns


D29256: [server] Introduce mapped() signal

2020-04-28 Thread Aleix Pol Gonzalez
apol added inline comments.

INLINE COMMENTS

> zzag wrote in surface_interface.cpp:333
> We can't use != because mapped() will be emitted each time a new buffer is 
> attached to the surface.

I don't understand, ^ and != are logically equivalent, ^ is the bitwise 
counterpart.

Am I missing something?

REPOSITORY
  R127 KWayland

BRANCH
  introduce-mapped-signal

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

To: zzag, #kwin, davidedmundson
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29256: [server] Introduce mapped() signal

2020-04-28 Thread Aleix Pol Gonzalez
apol added a comment.


  +1

INLINE COMMENTS

> surface_interface.cpp:333
>  const bool childrenChanged = source->childrenChanged;
> +const bool visibilityChanged = bool(source->buffer) ^ 
> bool(target->buffer);
>  bool sizeChanged = false;

Using != would probably be more readable and accurate (we're don't need it to 
be bitwise, we're assuming bool changes it to 1 or 0).

REPOSITORY
  R127 KWayland

BRANCH
  introduce-mapped-signal

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

To: zzag, #kwin, davidedmundson
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


Re: Splitting KWayland

2020-04-28 Thread Aleix Pol
On Mon, Apr 27, 2020 at 2:57 PM Aleix Pol  wrote:
>
> Hi,
> As discussed in the meeting last week, I've been looking into the split.
>
> Here's what I was thinking of, please tell me if there's something
> massively important I'm missing.
>
> The idea would be to start working on it after kwayland and other kf5
> have been tagged next week (?).
>
> Something I was wondering too is that I guess the new repos should end
> up in invent? Although neither plasma or kf5 are there.
> So maybe not?
>
> There's a couple of questions below as well, thoughts would be welcome
>
> Aleix
>
> git clone kde:kwayland
> mv kwayland plasma-wayland-protocols
> cd plasma-wayland-protocols
> git rm -r autotests/ docs/ tests/ src/
> # fix build
> # close https://phabricator.kde.org/T13024
>
> git clone kde:kwayland
> mv kwayland/ kwayland-server
> git rm -r src/client/
> # namespace KWayland::Server -> namespace KWaylandServer
> # fix build
> # remove server tests?
> # see to move things to KWin?
> # close https://phabricator.kde.org/T13025
>
> git clone kde:kwayland
> # deprecate all KWayland::Server
> # remove server tests?

Here's an implementation of above:
https://invent.kde.org/apol/plasma-wayland-protocols
https://invent.kde.org/apol/kwayland-server

My suggestion as next steps is to turn these into proper KDE
repositories in its own right soon and develop master kwin and plasma
overall against these.

When 5.19 needs releasing, then the wayland protocol would be included in KF5.

Can someone take a look and tell me if it's what they expected? If so
I'll proceed to request the repositories and start talking to the
different stakeholders.

Aleix


D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

2020-04-27 Thread Aleix Pol Gonzalez
apol added inline comments.

INLINE COMMENTS

> keyboard_shortcuts_inhibit_interface.cpp:144
> +QPair key(surface, seat);
> +if (m_inhibitors.contains(key)) {
> +return m_inhibitors[key];

Just `return m_inhibitors.value({ surface, seat })` to save a look-up and a few 
lines of code.

REPOSITORY
  R127 KWayland

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

To: bport, zzag, davidedmundson, apol
Cc: romangg, crossi, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


D28882: Create protocol to manage video feeds

2020-04-27 Thread Aleix Pol Gonzalez
apol added a comment.


  > In future, it might be faster to put up just the interface xml for review 
first.
  
  @davidedmundson  @zzag I don't really see how it would have made a 
difference, you only decided to review it 7 to 10 days after I first submitted 
it. 路
  
  > What about using existing wl_output objects? The add_source event can be 
simplified quite a lot (even maybe dropped). For windows, we could use string 
handles.
  
  So your proposal would be to pass a random resource id or string and see what 
the compositor spits back?
  My intention was to keep the protocol auto-contained to some extent so every 
client doesn't need to track windows and screens to be able to request a stream.

REPOSITORY
  R127 KWayland

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

To: apol, #kwin, jgrulich, davidedmundson, zzag
Cc: meven, davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, 
cblack, michaelh, ngraham, bruns


D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

2020-04-27 Thread Aleix Pol Gonzalez
apol added a comment.


  Code looks good overall, I'd say you'll get to polish the weird bits when 
developing the kwin side.
  
  In fact, this probably could be implemented within kwin considering what we 
discussed last week. We could remove the weirdness we have to keep its ABI.

INLINE COMMENTS

> keyboard_shortcuts_inhibit_interface.cpp:25
> +Private(Display *display, SurfaceInterface *surface, SeatInterface 
> *seat, KeyboardShortcutsInhibitorInterface* q)
> +: zwp_keyboard_shortcuts_inhibitor_v1(*display, s_version) // TODO 
> check we want to use display
> +, q(q)

You'll want to connect it to the respective client here, it's not a global 
anymore.

REPOSITORY
  R127 KWayland

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

To: bport, zzag, davidedmundson, apol
Cc: crossi, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D28882: Create protocol to manage video feeds

2020-04-27 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 81341.
apol added a comment.


  Address review comments

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28882?vs=81113=81341

BRANCH
  master

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_screencasting.cpp
  src/client/CMakeLists.txt
  src/client/protocols/screencast.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/screencasting.cpp
  src/client/screencasting.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/screencasting_interface.cpp
  src/server/screencasting_interface.h

To: apol, #kwin, jgrulich, davidedmundson
Cc: meven, davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, 
cblack, michaelh, ngraham, bruns


D28882: Create protocol to manage video feeds

2020-04-27 Thread Aleix Pol Gonzalez
apol marked 2 inline comments as done.

REPOSITORY
  R127 KWayland

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

To: apol, #kwin, jgrulich, davidedmundson
Cc: meven, davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, 
cblack, michaelh, ngraham, bruns


Splitting KWayland

2020-04-27 Thread Aleix Pol
Hi,
As discussed in the meeting last week, I've been looking into the split.

Here's what I was thinking of, please tell me if there's something
massively important I'm missing.

The idea would be to start working on it after kwayland and other kf5
have been tagged next week (?).

Something I was wondering too is that I guess the new repos should end
up in invent? Although neither plasma or kf5 are there.
So maybe not?

There's a couple of questions below as well, thoughts would be welcome

Aleix

git clone kde:kwayland
mv kwayland plasma-wayland-protocols
cd plasma-wayland-protocols
git rm -r autotests/ docs/ tests/ src/
# fix build
# close https://phabricator.kde.org/T13024

git clone kde:kwayland
mv kwayland/ kwayland-server
git rm -r src/client/
# namespace KWayland::Server -> namespace KWaylandServer
# fix build
# remove server tests?
# see to move things to KWin?
# close https://phabricator.kde.org/T13025

git clone kde:kwayland
# deprecate all KWayland::Server
# remove server tests?


Re: Information regarding upcoming Gitlab Migration

2020-04-27 Thread Aleix Pol
On Mon, Apr 27, 2020 at 12:55 PM Ben Cooksley  wrote:
>
> On Mon, Apr 27, 2020 at 10:39 PM Aleix Pol  wrote:
> >
> > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> > >
> > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > > replies]
> > >
> > > Hello Community members,
> > >
> > > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > > the recommended structuring for the repositories on Gitlab.
> > >
> > > We had multiple options,
> > >
> > > - Flat structure: In this option we would have everything under one
> > >   single namespace/group: https://invent.kde.org/kde/knetwalk
> > > - Subgroups under top-level group: In this option we would have a groups
> > >   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > > - Groups at top level: In this option we would establish a series of
> > >   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> > >
> > > We have discussed this with small but representative group of
> > > contributors or maintainers, and based on their suggestions, we
> > > recommend that we go with option 3. Having sub-groups at top level will
> > > allow us to,
> > >
> > > - Provides good visibility on all reviews, tasks and other items within
> > >   the groups/modules we define
> > > - Provides improvements to discoverability of projects
> > > - Makes it possible for groups of projects to establish a group level
> > >   task board should it fit their needs (for tracking a release for
> > >   instance)
> > > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> > >   in option 2 is duplicative considering the Gitlab instance is under
> > >   kde.org.
> > > - The discoverability of projects is maximised, as there is no need to
> > >   open the top level ‘KDE’ group before going into the subgroup.
> > >
> > > I've worked on draft "move" of the current set of the repositories in
> > > their respective subgroups at the repo-metadata project's branch [1].
> > > You can browse the directory structure to get idea of how final
> > > structure on Gitlab would look like.
> > >
> > > If we don't have any objections we would like to implement this next
> > > week and move projects to https://invent.kde.org.
> > >
> > > Thanks!
> > > Bhushan for sysadmin team
> > >
> > > [1] 
> > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> >
> > Does this mean that to clone it we'll have to go "git clone
> > kde:games/knetwalk" or something along the lines?
>
> Yes.
>
> >
> > If that's the case I'd much prefer if we didn't do this, at the moment
> > it's already uncomfortable for me to remember the URL for some of the
> > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > problem and I personally don't see the advantage.
>
> So you'd rather that we have no way to easily see a list of just
> Plasma / Frameworks / PIM / etc reviews?
> (See https://invent.kde.org/groups/kde/-/merge_requests for an example
> of the problem)
>
> Not to mention the fact that there will be several hundred
> repositories all in one group, so they will be completely
> undiscoverable to anyone outside of our community.
>
> >
> > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > krita graphics or its own thing?
> >
> > I really prefer when I don't have to guess this kind of things when
> > fetching a repository.
>
> There is always the search on Gitlab, and you can keep a checkout of
> sysadmin/repo-metadata for grepping on.

I don't know, I've always felt that the nesting we have nowadays
stemmed from svn's tree structure more than convenience.

I don't have the feeling I'd use that feature and I'm happy to
convinced otherwise.

While discoverability would be an incentive, I don't know if it will
make a difference since it would be especially useful to see how
repositories relate one to another, but it's something we generally
split explicitly through frameworks so I don't see that will help
much, other than for the very big suites (kdepim, plasma, etc).

I know you don't like it when I do this, but:
https://gitlab.gnome.org/explore/groups < gnome kept all the programs
under the same group
https://gitlab.freedesktop.org/explore/groups < didn't, but they have
projects that have very little overlap of contributors

Aleix


Re: Information regarding upcoming Gitlab Migration

2020-04-27 Thread Aleix Pol
On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
>
> [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> replies]
>
> Hello Community members,
>
> In view of upcoming Gitlab migration, we sysadmin team wants to share
> the recommended structuring for the repositories on Gitlab.
>
> We had multiple options,
>
> - Flat structure: In this option we would have everything under one
>   single namespace/group: https://invent.kde.org/kde/knetwalk
> - Subgroups under top-level group: In this option we would have a groups
>   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> - Groups at top level: In this option we would establish a series of
>   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
>
> We have discussed this with small but representative group of
> contributors or maintainers, and based on their suggestions, we
> recommend that we go with option 3. Having sub-groups at top level will
> allow us to,
>
> - Provides good visibility on all reviews, tasks and other items within
>   the groups/modules we define
> - Provides improvements to discoverability of projects
> - Makes it possible for groups of projects to establish a group level
>   task board should it fit their needs (for tracking a release for
>   instance)
> - Makes the most semantic sense, as the ‘KDE’ top level group suggested
>   in option 2 is duplicative considering the Gitlab instance is under
>   kde.org.
> - The discoverability of projects is maximised, as there is no need to
>   open the top level ‘KDE’ group before going into the subgroup.
>
> I've worked on draft "move" of the current set of the repositories in
> their respective subgroups at the repo-metadata project's branch [1].
> You can browse the directory structure to get idea of how final
> structure on Gitlab would look like.
>
> If we don't have any objections we would like to implement this next
> week and move projects to https://invent.kde.org.
>
> Thanks!
> Bhushan for sysadmin team
>
> [1] 
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent

Does this mean that to clone it we'll have to go "git clone
kde:games/knetwalk" or something along the lines?

If that's the case I'd much prefer if we didn't do this, at the moment
it's already uncomfortable for me to remember the URL for some of the
repos (e.g. is it sysadmin/ or not?), this will only increase the
problem and I personally don't see the advantage.

e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
krita graphics or its own thing?

I really prefer when I don't have to guess this kind of things when
fetching a repository.

Aleix


D29216: Remove dead code since KF5.0: mount/umount devices in their contextmenu

2020-04-26 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R241 KIO

BRANCH
  2020_04_remove_dead_solid_code

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

To: dfaure, apol, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29181: Use KFileMetaData for XAttr support instead of private reimplementation

2020-04-25 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R293 Baloo

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

To: bruns, #baloo, ngraham, apol
Cc: kde-frameworks-devel, hurikhan77, lots0logs, LeGast00n, cblack, 
fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams


D28882: Create protocol to manage video feeds

2020-04-24 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 81113.
apol added a comment.


  Refactor the protocol as suggested by David and Vlad

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28882?vs=80984=81113

BRANCH
  master

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_screencasting.cpp
  src/client/CMakeLists.txt
  src/client/protocols/screencast.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/screencasting.cpp
  src/client/screencasting.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/screencasting_interface.cpp
  src/server/screencasting_interface.h

To: apol, #kwin, jgrulich, davidedmundson
Cc: davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns


D28882: Create protocol to manage video feeds

2020-04-24 Thread Aleix Pol Gonzalez
apol marked an inline comment as done.
apol added inline comments.

INLINE COMMENTS

> davidedmundson wrote in screencast.xml:31
> this is racey with create.

Any suggestion on how to do it better?

REPOSITORY
  R127 KWayland

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

To: apol, #kwin, jgrulich, davidedmundson
Cc: davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns


D28882: Create protocol to manage video feeds

2020-04-23 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 80984.
apol added a comment.


  Also propagate the buffer size, it's important for the client to know what 
buffer size it will have.

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28882?vs=80801=80984

BRANCH
  master

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_screencasting.cpp
  src/client/CMakeLists.txt
  src/client/protocols/screencast.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/screencasting.cpp
  src/client/screencasting.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/screencasting_interface.cpp
  src/server/screencasting_interface.h

To: apol, #kwin, jgrulich
Cc: romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29102: Prefer QIcon::pixmap(QWindow*, ...) overload

2020-04-22 Thread Aleix Pol Gonzalez
This revision was automatically updated to reflect the committed changes.
Closed by commit R242:25ce2b90dab1: Prefer QIcon::pixmap(QWindow*, ...) 
overload (authored by apol).

REPOSITORY
  R242 Plasma Framework (Library)

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29102?vs=80908=80945

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

AFFECTED FILES
  src/declarativeimports/core/iconitem.cpp
  src/declarativeimports/core/windowthumbnail.cpp

To: apol, #plasma, #frameworks, davidedmundson
Cc: davidedmundson, ngraham, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
bruns


D29102: Prefer QIcon::pixmap(QWindow*, ...) overload

2020-04-22 Thread Aleix Pol Gonzalez
apol created this revision.
apol added reviewers: Plasma, Frameworks.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
apol requested review of this revision.

REVISION SUMMARY
  It takes into account the dpi of the screen we're rendering to.
  Other overloads assume the window is nullptr and will use the primary 
screen's dpi which can change almost randomly.

TEST PLAN
  Icons still look fine even if I drag windows from a screen to another.

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

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

AFFECTED FILES
  src/declarativeimports/core/iconitem.cpp
  src/declarativeimports/core/windowthumbnail.cpp

To: apol, #plasma, #frameworks
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29097: Adapt FindKF5 to stricter checks in newer find_package_handle_standard_args

2020-04-22 Thread Aleix Pol Gonzalez
apol added a comment.


  +1 makes sense

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  avoidnewwarningsinfindkf5

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

To: kossebau, #frameworks, #build_system, cgiboudeaux
Cc: apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns


D29063: Fix testpackage-appstream: XDG_DATA_DIRS needs to be explicitly extended

2020-04-21 Thread Aleix Pol Gonzalez
apol accepted this revision.
apol added a comment.
This revision is now accepted and ready to land.


  Looks like an improvement

REPOSITORY
  R290 KPackage

BRANCH
  fixXDG_DATA_DIRSextending

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

To: kossebau, #frameworks, mart, apol, sitter, bcooksley
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29079: android: include the architecture on the apk name

2020-04-21 Thread Aleix Pol Gonzalez
apol created this revision.
apol added reviewers: Android, Frameworks.
Herald added projects: Frameworks, Build System.
Herald added subscribers: kde-buildsystem, kde-frameworks-devel.
apol requested review of this revision.

REVISION SUMMARY
  Makes them easier to use afterwards.

TEST PLAN
  Tested locally

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

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

AFFECTED FILES
  toolchain/ECMAndroidDeployQt.cmake

To: apol, #android, #frameworks
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns


D29062: Port KToolInvocation::kdeinitExecWait to QProcess

2020-04-21 Thread Aleix Pol Gonzalez
apol accepted this revision.
apol added inline comments.
This revision is now accepted and ready to land.

INLINE COMMENTS

> kded.cpp:67
>  
>  static void runKonfUpdate()
>  {

The function has a typo, should be `runKConfUpdate`, no?

REPOSITORY
  R297 KDED

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

To: broulik, davidedmundson, #frameworks, apol
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D28882: Create protocol to manage video feeds

2020-04-21 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 80801.
apol added a comment.


  Hopefully fix the build for Jan

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28882?vs=80798=80801

BRANCH
  master

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_screencasting.cpp
  src/client/CMakeLists.txt
  src/client/protocols/screencast.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/screencasting.cpp
  src/client/screencasting.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/screencasting_interface.cpp
  src/server/screencasting_interface.h

To: apol, #kwin, jgrulich
Cc: romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D28882: Create protocol to manage video feeds

2020-04-21 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 80798.
apol added a comment.


  - Test Cleanup
  - When a resource is destroyed, emit to close all its streams

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28882?vs=80677=80798

BRANCH
  master

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_screencasting.cpp
  src/client/CMakeLists.txt
  src/client/protocols/screencast.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/screencasting.cpp
  src/client/screencasting.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/screencasting_interface.cpp
  src/server/screencasting_interface.h

To: apol, #kwin, jgrulich
Cc: romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29033: Remove duplicated code

2020-04-21 Thread Aleix Pol Gonzalez
apol abandoned this revision.
apol added a comment.


  My bad, thanks!

REPOSITORY
  R130 Frameworks integration plugin using KWayland

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

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


D29033: Remove duplicated code

2020-04-20 Thread Aleix Pol Gonzalez
apol created this revision.
apol added a reviewer: Frameworks.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
apol requested review of this revision.

REVISION SUMMARY
  Went through it while reviewing some code.

TEST PLAN
  Been running it for a while, including direct testing of the code while 
investigating something else

REPOSITORY
  R130 Frameworks integration plugin using KWayland

BRANCH
  master

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

AFFECTED FILES
  src/windowsystem/waylandintegration.cpp

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


D29018: Align description in metainfo.yaml with the one of README.md

2020-04-20 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R174 KContacts

BRANCH
  fixmetainfodescription

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

To: kossebau, mlaurent, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D28882: Create protocol to manage video feeds

2020-04-20 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 80677.
apol added a comment.


  Improve how we initialise the sourceId

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28882?vs=80662=80677

BRANCH
  master

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_screencasting.cpp
  src/client/CMakeLists.txt
  src/client/protocols/screencast.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/screencasting.cpp
  src/client/screencasting.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/screencasting_interface.cpp
  src/server/screencasting_interface.h

To: apol, #kwin, jgrulich
Cc: romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D28780: [FstabWatcher] Fix loosing of fstab watcher

2020-04-20 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R245 Solid

BRANCH
  submit

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

To: bruns, #frameworks, ngraham, apol
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D28882: Create protocol to manage video feeds

2020-04-20 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 80662.
apol added a comment.


  Iterate tests (which work now) and uses

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28882?vs=80658=80662

BRANCH
  master

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_screencasting.cpp
  src/client/CMakeLists.txt
  src/client/protocols/screencast.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/screencasting.cpp
  src/client/screencasting.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/screencasting_interface.cpp
  src/server/screencasting_interface.h

To: apol, #kwin, jgrulich
Cc: romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D28882: Create protocol to manage video feeds

2020-04-20 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 80658.
apol added a comment.


  Fix test

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28882?vs=80637=80658

BRANCH
  master

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_screencasting.cpp
  src/client/CMakeLists.txt
  src/client/protocols/screencast.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/screencasting.cpp
  src/client/screencasting.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/screencasting_interface.cpp
  src/server/screencasting_interface.h

To: apol, #kwin, jgrulich
Cc: romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D28882: Create protocol to manage video feeds

2020-04-20 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 80637.
apol added a comment.


  iterate test

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28882?vs=80605=80637

BRANCH
  master

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_screencasting.cpp
  src/client/CMakeLists.txt
  src/client/protocols/screencast.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/screencasting.cpp
  src/client/screencasting.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/screencasting_interface.cpp
  src/server/screencasting_interface.h

To: apol, #kwin, jgrulich
Cc: romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29003: Use Q_EMIT and build with QT_NO_KEYWORDS

2020-04-20 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R275 KItemModels

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

To: junghans, kossebau, dfaure, apol
Cc: ahmadsamir, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D28882: Create protocol to manage video feeds

2020-04-19 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 80605.
apol added a comment.


  oops

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28882?vs=80604=80605

BRANCH
  master

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_screencasting.cpp
  src/client/CMakeLists.txt
  src/client/protocols/screencast.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/screencasting.cpp
  src/client/screencasting.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/screencasting_interface.cpp
  src/server/screencasting_interface.h

To: apol, #kwin, jgrulich
Cc: romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D28882: Create protocol to manage video feeds

2020-04-19 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 80604.
apol added a comment.


  Include server side, a test (that doesn't pass) and some renaming

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28882?vs=80411=80604

BRANCH
  master

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_screencasting.cpp
  src/client/CMakeLists.txt
  src/client/protocols/screencast.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/screencasting.cpp
  src/client/screencasting.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/screencasting_interface.cpp
  src/server/screencasting_interface.h

To: apol, #kwin, jgrulich
Cc: romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D28978: [PluginLoader] Replace one usage of QRegExp with QString::startsWith()

2020-04-19 Thread Aleix Pol Gonzalez
apol added a comment.


  I wonder, while this will work with all our uses of DropUrlPatterns, this 
would have been able to work with something like `scheme:/*potato*` which after 
this patch won't work.
  
  In fact, it's called Patterns, not DropUrlWhenStartsWith. I'd appreciate 
feedback from someone else. Code-wise, looks better for sure.

REPOSITORY
  R242 Plasma Framework (Library)

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

To: ahmadsamir, #plasma, apol
Cc: kde-frameworks-devel, plasma-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D28956: [QML Monitor] Show remaining time as soon as possible

2020-04-19 Thread Aleix Pol Gonzalez
apol added a comment.


  You're using QDeadlineTimer weird. Why don't you use 
QDeadlineTimer::remainingTime() and ::setDeadline?

REPOSITORY
  R293 Baloo

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

To: bruns, #baloo, ngraham
Cc: apol, kde-frameworks-devel, hurikhan77, lots0logs, LeGast00n, cblack, 
fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams


D28955: [FileContentIndexer] Fix state update and signal order

2020-04-19 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R293 Baloo

BRANCH
  submit

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

To: bruns, #baloo, ngraham, apol
Cc: kde-frameworks-devel, hurikhan77, lots0logs, LeGast00n, cblack, 
fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams


D28953: [Extractor] Fix progress reporting

2020-04-19 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R293 Baloo

BRANCH
  submit

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

To: bruns, #baloo, ngraham, mlaurent, apol
Cc: kde-frameworks-devel, hurikhan77, lots0logs, LeGast00n, cblack, 
fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams


D28954: [Monitor] Fix monitor state and signal ordering

2020-04-19 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R293 Baloo

BRANCH
  submit

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

To: bruns, #baloo, ngraham, apol
Cc: kde-frameworks-devel, hurikhan77, lots0logs, LeGast00n, cblack, 
fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams


D28940: [baloo_file] Remove KAboutData from baloo_file

2020-04-18 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R293 Baloo

BRANCH
  submit

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

To: bruns, #baloo, ngraham, leszeklesner, apol
Cc: kde-frameworks-devel, hurikhan77, lots0logs, LeGast00n, cblack, 
fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams


D28900: Fix wayland scanner warnings

2020-04-17 Thread Aleix Pol Gonzalez
This revision was automatically updated to reflect the committed changes.
Closed by commit R240:3734a5368e44: Fix wayland scanner warnings (authored by 
apol).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28900?vs=80334=80436

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

AFFECTED FILES
  find-modules/FindQtWaylandScanner.cmake
  find-modules/FindWaylandScanner.cmake

To: apol, #build_system, #kwin, #frameworks, davidedmundson
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns


D28882: Create protocol to manage video feeds

2020-04-17 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 80411.
apol added a comment.


  Include the server side and some renames

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28882?vs=80284=80411

BRANCH
  master

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

AFFECTED FILES
  src/client/CMakeLists.txt
  src/client/protocols/screencast.xml
  src/client/screencasting.cpp
  src/client/screencasting.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h

To: apol, #kwin, jgrulich
Cc: romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D28882: Create protocol to manage video feeds

2020-04-17 Thread Aleix Pol Gonzalez
apol marked 2 inline comments as done.

REPOSITORY
  R127 KWayland

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

To: apol, #kwin, jgrulich
Cc: romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D28919: Drop delayed second phase

2020-04-17 Thread Aleix Pol Gonzalez
apol accepted this revision.
apol added a comment.
This revision is now accepted and ready to land.


  Makes sense, sounds like the second phase is quite arbitrary there.

REPOSITORY
  R297 KDED

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

To: broulik, #plasma, dfaure, davidedmundson, apol
Cc: apol, kde-frameworks-devel, davidedmundson, LeGast00n, cblack, michaelh, 
ngraham, bruns


D28355: Introduce function ecm_install_configured_file

2020-04-17 Thread Aleix Pol Gonzalez
apol added a comment.


  Are we stuck somewhere? The patch looks good to me.

REPOSITORY
  R240 Extra CMake Modules

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

To: davidedmundson
Cc: apol, kossebau, pino, kde-frameworks-devel, kde-buildsystem, LeGast00n, 
cblack, bencreasy, michaelh, ngraham, bruns


D19913: [plasma-framework] make it compiles without foreach

2020-04-16 Thread Aleix Pol Gonzalez
apol accepted this revision.
apol added inline comments.

INLINE COMMENTS

> dropmenu.cpp:80
>  } else if (m_menu) {
> -foreach (QAction *action, m_dropActions) {
> +for (QAction *action : qAsConst(m_dropActions)) {
>  m_menu->addAction(action);

`m_menu->addActions(m_dropActions);`

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  compile_without_foreach (branched from master)

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

To: mlaurent, dfaure, apol
Cc: ahmadsamir, nicolasfella, broulik, apol, kde-frameworks-devel, LeGast00n, 
cblack, michaelh, ngraham, bruns


D28900: Fix wayland scanner warnings

2020-04-16 Thread Aleix Pol Gonzalez
apol created this revision.
apol added reviewers: Build System, KWin, Frameworks.
Herald added projects: Frameworks, Build System.
Herald added subscribers: kde-buildsystem, kde-frameworks-devel.
apol requested review of this revision.

REVISION SUMMARY
  Tells cmake not to automoc certain files that don't need it, which would 
become a big fuss on the cmake output.

TEST PLAN
  No warnings

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

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

AFFECTED FILES
  find-modules/FindQtWaylandScanner.cmake
  find-modules/FindWaylandScanner.cmake

To: apol, #build_system, #kwin, #frameworks
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns


D28883: Add wrapper for wl_global_remove

2020-04-16 Thread Aleix Pol Gonzalez
apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R127 KWayland

BRANCH
  master

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

To: davidedmundson, #plasma, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


  1   2   3   4   5   6   7   8   9   10   >