Re: github pull requests are piling up

2020-12-29 Thread Albert Astals Cid
El dijous, 24 de desembre de 2020, a les 11:02:16 CET, Albert Astals Cid va 
escriure:
> We're at 52 at this point
> 
> https://github.com/pulls?q=is%3Aopen+is%3Apr+user%3AKDE
> 
> Sadly my bot broke and fixing it is not possible for me in the time i can 
> dedicate to it (it's written in go which I'm not very proficient at and it 
> seems that there have been github and google appengine API changes).
> 
> If someone wants to try to look at it together with me ping me and we can 
> have a look, if not i'll shut it down at some point, it's costing me like 
> 0,01€ a month that is kind of unjustifiable given that it does nothing :D
> 
> Bot code is at https://github.com/tsdgeos/nopullrequests

Ok, Shantanu seems to have fixed it :)

https://github.com/KDE/okular/pull/8

Cheers,
  Albert

P.S: I'll manually close the open ones now

> 
> Cheers,
>   Albert
> 
> 
> 






github pull requests are piling up

2020-12-24 Thread Albert Astals Cid
We're at 52 at this point

https://github.com/pulls?q=is%3Aopen+is%3Apr+user%3AKDE

Sadly my bot broke and fixing it is not possible for me in the time i can 
dedicate to it (it's written in go which I'm not very proficient at and it 
seems that there have been github and google appengine API changes).

If someone wants to try to look at it together with me ping me and we can have 
a look, if not i'll shut it down at some point, it's costing me like 0,01€ a 
month that is kind of unjustifiable given that it does nothing :D

Bot code is at https://github.com/tsdgeos/nopullrequests

Cheers,
  Albert




Re: KDE review for KWeatherCore

2020-12-21 Thread Albert Astals Cid
El dilluns, 21 de desembre de 2020, a les 7:16:09 CET, hanyoung va escriure:
> KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for 
> querying weather forecast data.
> During the development of KWeather, we found the need to have a weather 
> library.
> KWeatherCore is the result of extracting weather data fetching code from 
> KWeather.
> I think having a dedicated weather library can serve the following propose:
> - simplify the KWeather code
> - easier to develop a weather daemon
> - potentially less code duplication across KDE

There's quite some things that need improvement:
 * You don't have d-pointer in most of the public classes
 * You have quite some code inline in the .h which makes keeping BC harder
 * You return const Q* & which is not usual in Qt classes

locationquerytest is unstable https://paste.debian.net/1177864/

You have a script that extracts translations to libkweather5 but then you do 
-DTRANSLATION_DOMAIN=\"kweathercore5\"

Cheers,
  Albert

> 
> Many of you may have already seen my previous email to kde-devel mailing list.
> Thank you for your constructive suggestions. Here are something I want to 
> clarify:
> 
> > I would also propose to consider doing a demon instead, so different
> > programs/processes all interested in weather forecast data could share the
> > data
>   The end goal is a daemon indeed, but we want to build the daemon upon the 
> library. This would give us flexibility
>  in the future if we don't want a daemon. At least KWeather and other 
> projects can still benefit from the code.
> 
> > but we want to make sure we don't end up with two things.
>   I admit there are some overlapped functionalities. But KWeatherCore isn't 
> designed as a weather data provider as Weather DataEngine.
>   Instead, it's trying to be the building block of weather related 
> applications. KWeatherCore saves you the hassle of
>   dealing with APIs, getting locations and converting timezone. You can build 
> a daemon with it, or you can
>   use it in your applications. For example, KItinerary and KWeather use the 
> same weather API, but don't share code.
>   That means two code base to maintain. Regarding the dynamic nature of 
> online APIs, it's better to have one library,
>   so other applications don't need to be worried about their APIs being 
> depraved, and they aren't able to update it in time.
> 
>   Though not currently implemented, KWeatherCore does intend to have weather 
> alerts added. We hope it can be done in this Sok
>   https://community.kde.org/SoK/Ideas/2021#KWeather
>   With this bit added, then the work on weather daemon can be started.
> 
> Regards,
> Han Young
> 
> 






Re: T13975: Move hanyoung/libkweather to frameworks/kweathercore

2020-12-20 Thread Albert Astals Cid
Where has this been discussed?

This is a 1 month old library with no external review whatsoever, I don't see 
how it can be ready to be part of KDE Frameworks.

Cheers,
  Albert

El diumenge, 20 de desembre de 2020, a les 11:48:30 CET, Han Young va escriure:
> hanyoung created this task.
> hanyoung triaged this task as "Normal" priority.
> hanyoung added a project: Sysadmin.
> Herald added a subscriber: sysadmin.
> 
> TASK DESCRIPTION
>   https://invent.kde.org/hanyoung/libkweather is a library provides weather 
> forecast data. This will save a lot of duplicated work when trying to get 
> weather information, especially when developing plasmoids.
> 
> TASK DETAIL
>   https://phabricator.kde.org/T13975
> 
> To: hanyoung
> Cc: sysadmin, kde-frameworks-devel, hanyoung, duffus
> 






Re: RFC: Switching to min Qt version 5.14 for KF on December 14th

2020-12-18 Thread Albert Astals Cid
El divendres, 18 de desembre de 2020, a les 18:51:32 CET, Albert Astals Cid va 
escriure:
> El divendres, 18 de desembre de 2020, a les 6:44:41 CET, Friedrich W. H. 
> Kossebau va escriure:
> > Am Donnerstag, 17. Dezember 2020, 21:06:23 CET schrieb David Faure:
> > > In general I might have asked for a more conservative approach; but
> > > currently anything we do to help with preparing the Qt 6 migration is a
> > > good thing, and having one less Qt version to support helps with that.
> > > 
> > > So, in those exceptional circumstances, I'm in favour, go for it.
> > 
> > Okay :) And it are those exceptional circumstances also which made me push 
> > for 
> > the bump here, otherwise I would have rather tried to have us get Qt 5.13 
> > back 
> > onto KDE CI.
> > 
> > Albert, commit data tells me did the last bump. Could you go and do the 
> > bump 
> > to Qt 5.14 as well now, given you seem to have some setup for that?
> 
> Running now.
> 
> For reference:
> https://invent.kde.org/sysadmin/release-tools/-/blob/frameworks/5.0/increase_qt_version.sh

I've done ifdefs cleanups in all the repos that had version checks against < 
5.14 and one or two build fix commits.

Please check your favorite framework that i did not any mistake.

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> 
> 






Re: RFC: Switching to min Qt version 5.14 for KF on December 14th

2020-12-18 Thread Albert Astals Cid
El divendres, 18 de desembre de 2020, a les 6:44:41 CET, Friedrich W. H. 
Kossebau va escriure:
> Am Donnerstag, 17. Dezember 2020, 21:06:23 CET schrieb David Faure:
> > In general I might have asked for a more conservative approach; but
> > currently anything we do to help with preparing the Qt 6 migration is a
> > good thing, and having one less Qt version to support helps with that.
> > 
> > So, in those exceptional circumstances, I'm in favour, go for it.
> 
> Okay :) And it are those exceptional circumstances also which made me push 
> for 
> the bump here, otherwise I would have rather tried to have us get Qt 5.13 
> back 
> onto KDE CI.
> 
> Albert, commit data tells me did the last bump. Could you go and do the bump 
> to Qt 5.14 as well now, given you seem to have some setup for that?

Running now.

For reference:
https://invent.kde.org/sysadmin/release-tools/-/blob/frameworks/5.0/increase_qt_version.sh

Cheers,
  Albert




Re: RFC: Switching to min Qt version 5.14 for KF on December 14th

2020-12-17 Thread Albert Astals Cid
El dijous, 17 de desembre de 2020, a les 21:16:57 CET, Ahmad Samir va escriure:
> On 17/12/2020 22:06, David Faure wrote:
> [...]
> > 
> > Right. That's a reason to fix something indeed, but there are still two ways
> > to fix that, if it was the only reason : either raise min req to Qt 5.14, or
> > ask for a Qt 5.13 CI.
> > 
> 
> Ben said on IRC:
> "I used 5.14 as a practical matter as 5.13 is essentially unavailable"

I'm fine going to 5.14, but saying that 5.13 is unavailable is just not the 
truth.

Cheers,
  Albert

> 
> That's why team jumped to 5.14 directly, don't know the details however.
> 
> [...]
> 
> 






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

2020-12-16 Thread Albert Astals Cid
El dimecres, 2 de desembre de 2020, a les 10:36:30 CET, Gleb Popov va escriure:
> 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?

This is exactly why we need CI at the Merge Request stage and not later, we 
would have caught this and whoever was proposing the change would have to fix 
it or find someone to help fix it.

Anyhow, that's off topic :D

About how to fix it, well fixing it in FreeBSD is probably "harder" that in kio 
(amount of people needed to be convinced), so I'd vote for the second so we can 
get unblocked as soon as possible.

On how to fix it in KIO, the optimal way in my opinion is 
"abstract-like-its-kde", i.e. create a wrapper API on top of acl_* that has a 
#if LINUX and just calls the existing code and and #else POSIX and has the 
"beefy chunk of code" (but that's me not having a clue whatsoever about this 
ACL code).

Cheers,
  Albert

> 
> P.S. Please CC me, as I'm not subscribed.
> 






Re: Problem with ksycoca not being regenerated under flatpak

2020-12-13 Thread Albert Astals Cid
El dissabte, 12 de desembre de 2020, a les 22:59:58 CET, David Faure va 
escriure:
> Time flies, sorry for the delay.
> 
> On samedi 12 septembre 2020 19:44:45 CET Albert Astals Cid wrote:
> > flatpak mounts all files as if created on January 1st 1970.
> 
> Isn't that a bug in itself? Why doesn't it preserve mtimes?

I don't know, because reasons i guess, i never fully understood the answers i 
got on the flatpak mailing list

https://lists.freedesktop.org/archives/flatpak/2020-October/002049.html

https://lists.freedesktop.org/archives/flatpak/2020-November/002057.html

> 
> > This has the unfortunate effect that when we add new plugins to a flatpak
> > (i.e. we just added markdown preview support in kate), they are not seen
> > because ksycoca doesn't feel the need to regenerate itself (the sycoca file
> > for flatpak is written "outside" flatpak container and thus has a newer
> > date).
> > 
> > I remember talking about this probably a year ago at least with Aleix, but i
> > guess we did not come up with any solution since it's still broken :D
> > 
> > I don't know much about sycoca, but can we make it so the cache always get
> > regenerated on app launch when run under flatpak?
> 
> Is there no way to manually "touch" a directory after adding new files?
> 
> Otherwise, the hack you have in mind could be implemented as in the attached 
> patch. Untested, except that it compiles.

I'll test the patch at some point, thanks for caring :)

Cheers,
  Albert





Re: RFC: Switching to min Qt version 5.14 for KF on December 14th

2020-12-06 Thread Albert Astals Cid
El diumenge, 6 de desembre de 2020, a les 14:20:47 CET, Friedrich W. H. 
Kossebau va escriure:
> Hi,
> 
> you might have seen I asked* whether anyone knows a real world requirement to 
> stick with Qt 5.13 as new current minimum required Qt version for current KF 
> releases. So far no-one had to report a reason to support Qt >= 5.13 instead 
> of only Qt >= 5.14 now.
> * E.g. https://mail.kde.org/pipermail/distributions/2020-December/000894.html
> 
> So hereby I propose to switch for KF 5.78 to Qt 5.14 as minimum version, and 
> change the KF dependencies policy text* to this:
> * https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements 
> 
> "
> With Qt6 this changes a little bit again. We interpolate "as if" more Qt 5 
> versions would be released. Then adapt to actual real world usage of a given 
> Qt version:
> * Qt 5.13 will be the minimum required version 6 months after Qt 5.15, i.e. 
> on 
> 26 Nov 2020
> * Qt 5.14 would be the minimum required version 12 months after Qt 5.15, i.e. 
> on 26 May 2021. With no-one known to stick with Qt 5.13, the date is moved to 
> earlier mid-December 2020.
> * Qt 5.15 LTS will be the minimum required version 18 months after its 
> release, i.e. on 26 Nov 2021
> "
> 
> from previous
> 
> "
> With Qt6 this changes a little bit again. We interpolate "as if" more Qt 5 
> versions would be released: 
> * Qt 5.13 will be the minimum required version 6 months after Qt 5.15, i.e. 
> on 
> 26 Nov 2020
> * Qt 5.14 will be the minimum required version 12 months after Qt 5.15, i.e. 
> on 26 May 2021
> * Qt 5.15 LTS will be the minimum required version 18 months after its 
> release, i.e. on 26 Nov 2021
> "
> 
> I also propose that if no objections pop up until Monday, December 14th, CET 
> Noon, we then go that day and update the policy and have our dependency 
> bumping service people execute the bump to Qt 5.14.
> 
> Your comments, please :)

Personally what interests me more as a minimum Qt version is not what 
distributions will be shipping it, but what they have already shipped so 
existing people can become developers without having to compile all of Qt.

Looking at https://repology.org/project/qt/badges 

The distros with Qt 5.13 are:
 * Chakra
 * Fedora 31
 * MidnightBSD
 * openBSD
 * OpenMandriva 4.0

Both Fedora 31 and OpenMandriva 4.0 have releases with newer Qt so I guess 
those wanting to develop have a relatively easy path forward.

Chakra seems on the "almost dead" area (Qt 5.13 for what's supposedly a rolling 
distribution is not a good sign) so i'm going to guess it doesn't have many 
users still.

The BSDs are a bit more unfortunate.

Not a -1 nor a -1 from my side, just wanting to provide a different perspective 
that's looking to the past of distributions and not to the future.

Cheers,
  Albert



> 
> Cheers
> Friedrich
> 
> 
> 






Re: PSA: Frameworks depends on Qt 5.13 now

2020-11-26 Thread Albert Astals Cid
El divendres, 27 de novembre de 2020, a les 0:21:04 CET, Nicolas Fella va 
escriure:
> Hi,
> 
> per our Qt dependency policy [0] Frameworks depends on Qt 5.13 6 months
> after the release of Qt 5.15, which is now.
> 
> Have fun with the new stuff.

And i think i broke all the CI updating the requirement since we have a CI that 
builds against 5.12 in build.kde.org

Apologies for that ^_^

I've asked sysadmin to remove it.

Cheers,
  Albert

> 
> Nico
> 
> [0] https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements
> 
> 






Re: KCGroups in KDEreview

2020-11-20 Thread Albert Astals Cid
El divendres, 20 de novembre de 2020, a les 14:55:16 CET, Henri Chain va 
escriure:
> Hello everyone,
> 
> KCgroups has been moved to KDEReview !
> What is that, you ask ? It's a library that wraps the systemd dbus API to 
> expose a higher-level concept of desktop application and allow control of its 
> system resource usage (CPU, RAM, IO, etc).
> 
> It relies on the recent ability of plasma to launch applications in their own 
> systemd scopes, with correspond to cgroups and provides a more robust 
> definition for an application (more details at 
> https://lwn.net/Articles/834329/ 
> ) .
> 
> The main use of the library is to expose related resource control settings 
> for 
> those applications, at a user space level that other KDE applications and 
> frameworks can use, including consumption straight from QML as demonstrated 
> in 
> the test application.
> 
> KCgroups is intended to become a (Tier 1) framework. A first user of this 
> library might be the foreground window CPU booster daemon that is available 
> here: https://invent.kde.org/libraries/kcgroups/-/tree/work/foreground-booster
> 
> Packages are already available for both Neon and Arch Linux.
> 
> Looking forward to your feedback and ideas for using this,

I'm a bit scared about your optional class being there all in the main 
namespace. I'd suggest putting in some "namespace kcgroups{}" or name it 
kcgoptional or something.

you have a few properties without NOTIFY, ideally you should either add it if 
they can change or mark them as CONSTANT if they can't.

Cheers,
  Albert


> Henri
> 
> 
> 






Re: RSIBreak / KIdleTime on Wayland

2020-11-15 Thread Albert Astals Cid
El dissabte, 14 de novembre de 2020, a les 12:46:41 CET, Dominik Waurenschk va 
escriure:
> Hi, I just came across the issue that RSIBreak is unable to count down in 
> wayland, after 1 second it always resets its timer.
> 
> I investigated the code and found that it calls KIdleTime, which in turn 
> calls a platform-specific plugin. 
> 
> In particular, it calls forcePollRequest() to get the current idle time 
> (instead of waiting for a timeout event or similar)
> 
> For Wayland this function prints a warning that this plugin doesn't support 
> polling idle time, but then always returns 0, which RSIBreak later interprets 
> as activity, since it thinks 0 seconds passed, this halting the countdown.
> 
> This plugin in turn uses KWayland::Client::Idle, which does indeed seem to 
> only support timeouts and no getting the actual idle time. So if it is really 
> not possible to count idle time in wayland (I don't know enough about wayland 
> to implement it myself at this time), then I think it would be useful to, 
> instead of only printing a warning to console/log, the function would 
> actually return some type of error code to the caller. (It could return -1, 
> or throw an exception, or similar) 
> 
> 
> So then the caller can react to the fact that polling is not supported, and 
> could perhaps implement a different way of measuring time on that platform. 
> (it could perhaps use its own timer and reset when the platform plugin emits 
> resumingFromIdle, i haven't tried out how this works yet).
> 
> So do you think it makes sense to have the function return some form or error 
> instead of just returning 0, or is there a good reason it is not doing that 
> already?

I agree, if we can't make the KIdleTime framework work in Wayland there should 
be a way to query the framework if it's going to work or not.

CC'ing the frameworks devel list.

Cheers,
  Albert

> 
> Thank you,
> Dominik
> 






Re: Help using KArchive with GZIP files

2020-11-02 Thread Albert Astals Cid
El dilluns, 2 de novembre de 2020, a les 22:23:44 CET, Gabriel Domínguez 
Camarero va escriure:
> Hello I am gabridc,

Hello Gabriel, this KDE Frameworks devel is for discussion around development 
*of* KDE Frameworks not *with* KDE Frameworks, your question belongs to 
kde-de...@kde.org

> 
> 
> 
> I am a developer for Index-fm and we are trying to integrate KArchive in the 
> file explorer, I have tried to do this but there some error that block me to 
> open a file. I dont know if i am using correctly the class KCompressionDevice.

Is this question related to the code down below? or different?

> Also, I would to ask another question because I would like to write a file 
> inside my file.gz but in this case I dont have the function writeFile like 
> KTar or KZip classes.

You can't write a file *inside* a gz file, a gz is not multiple files, it's 
just one file (a .tar.gz is still just one gz file, it's the tar part that has 
multiple files).

Cheers,
  Albert

> 
> 
> 
> auto kgzip = KCompressionDevice(QUrl(where.toString() + “/” + fileName + 
> “.gz”).toLocalFile(), KCompressionDevice::GZip);
> assert(kgzip.isOpen() == true);
> 
> 
> kgzip.write(QString("hello World").toUtf8());
> kgzip.close();






Problem with ksycoca not being regenerated under flatpak

2020-09-12 Thread Albert Astals Cid
flatpak mounts all files as if created on January 1st 1970.

This has the unfortunate effect that when we add new plugins to a flatpak (i.e. 
we just added markdown preview support in kate), they are not seen because 
ksycoca doesn't feel the need to regenerate itself (the sycoca file for flatpak 
is written "outside" flatpak container and thus has a newer date).

I remember talking about this probably a year ago at least with Aleix, but i 
guess we did not come up with any solution since it's still broken :D

I don't know much about sycoca, but can we make it so the cache always get 
regenerated on app launch when run under flatpak?

Cheers,
  Albert




Re: General information for KDE Frameworks developers

2020-09-09 Thread Albert Astals Cid
El dimecres, 9 de setembre de 2020, a les 15:31:27 CEST, David Faure va 
escriure:
> Here are some notes from the KF6 BoF at Akademy, as well as general 
> information that I realized might not be known to all the relevant developers.
> 
> * There's a nice board with many tasks related to preparing KDE Frameworks 
> for 
> KF6. https://phabricator.kde.org/project/board/310/
> All the tasks in the "Backlog" column, are tasks that can be done TODAY 
> already, they don't depend on Qt6 or the possibility to break API/ABI in KDE 
> Frameworks. Help is very much needed and welcome!
> 
> * We'll have an online meeting at some point to go through the board and add 
> tags for priorities and "junior jobs".
> 
> * I strongly recommend subscribing to kde-frameworks-devel. If you got scared 
> in the past by the amount of "merge requests" emails coming in, this is no 
> longer the case with gitlab.
> 
> * Instead, I recommend subscribing in gitlab to the projects you care about.
> For instance you go to https://invent.kde.org/frameworks/kio and click on the 
> bell icon on the right of the large "KIO" header.
> 
> * If you want to keep an eye on *all* Frameworks merge requests, as used to 
> happen on k-f-d, you can visit 
> https://invent.kde.org/groups/frameworks/-/merge_requests (however I don't 
> see 
> a way to get notified by email).

As discussed on IRC you can go to https://invent.kde.org/frameworks click on 
the bell on and click Watch if you want to watch all frameworks.

Cheers,
  Albert

> 
> * We decided on a two months deadline for the unittests that have always 
> failed on FreeBSD and Windows to be whitelisted with QEXPECT_FAIL macros,
> and turned into bug reports. This way we can start from a clean state in CI, 
> react on regressions more easily, and even set up gitlab to check that MRs 
> don't introduce regressions on any platform. It'll also help reducing the 
> noise on k-f-d.
> If you use either of those platforms, please give a hand with fixing those 
> issues for real.
> Reminder: to see failing tests, go to
> https://build.kde.org/job/Frameworks/view/Everything/
> then click on the platform you're interesting in, and then click on the "S" 
> column twice. The yellow will propagate to the top.
> 
> Happy hacking!
> 
> 






Re: Dropping the moderation by default flag

2020-08-10 Thread Albert Astals Cid
El dimecres, 22 de juliol de 2020, a les 17:47:26 CEST, Volker Krause va 
escriure:
> On Tuesday, 21 July 2020 21:16:00 CEST Albert Astals Cid wrote:
> > 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?
> 
> +1. That setup on core-devel was already around in the early 2000s, so 
> probably a response to some events from 20 years ago, I doubt we still need 
> that today.

So i was going to do it, but I've just realized that I can't, I only have the 
moderator password, not the owner password.

Please owner[s], can you disable this?

I *think* it's the "By default, should new list member postings be moderated?" 
in "Privacy options..." -> "Sender filters".

Cheers,
  Albert


> 
> Regards,
> Volker
> 
> 
> 






Dropping the moderation by default flag

2020-07-21 Thread Albert Astals Cid
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




Re: xml_mimetypes5 and kcoreaddons

2020-07-19 Thread Albert Astals Cid
El diumenge, 19 de juliol de 2020, a les 13:56:14 CEST, David Faure va escriure:
> On mercredi 15 juillet 2020 12:24:34 CEST Harald Sitter wrote:
> > On Wed, Jul 15, 2020 at 12:39 AM David Faure  wrote:
> > > On mardi 14 juillet 2020 19:35:41 CEST Albert Astals Cid wrote:
> > > > El dimarts, 14 de juliol de 2020, a les 15:14:38 CEST, Jonathan Riddell
> > > > va
> > > 
> > > escriure:
> > > > > We're playing with translations in neon packages and looking at
> > > > > kcoreaddons
> > > > > the tars have
> > > > > xml_mimetypes5
> > > > > But we can't see anything in the code which uses this.  Do these
> > > > > translations get used?
> > > > 
> > > > Yes, the translations are used.
> > > > 
> > > > No, they don't need to be on the tarball.
> > > > 
> > > > The translations are used at scripty time to to fill
> > > > https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/mimetype
> > > > s/k
> > > > de5.xml
> > > > 
> > > > Luigi recently did a change so the files ending in _xml_mimetypes.po
> > > > don't
> > > > get added to the release service tarballs.
> > > > 
> > > > This didn't work here because a) KF5 is using a different branch of
> > > > release-tools b) the file doesn't follow the same naming pattern than
> > > > the
> > > > rest of xml mimetype files we have.
> > > > 
> > > > If DavidF is fine adapting his scripts to not release files ending in
> > > > _xml_mimetypes.po (i.e. him or someone else patches the scripts) i
> > > > volunteer to do the small patch for src/mimetypes/XmlMessages.sh to
> > > > rename
> > > > it.
> > > 
> > > Fine with me, but don't we have more cases of the same kind, with
> > > different
> > > names? Any case of translations being "integrated" into some file leads to
> > > this. Desktop files, mimetype XML, is there really nothing else?
> > 
> > It's a bit more "fluid" than one would hope. Looking at
> > update_translations the following patterns exist:
> > 
> > - created by XmlMessages.sh unfortunately arbitrary named files but
> > largely using the standard suffix Albert mentioned (the only other
> > violation I can find with lxr is kpat)
> > - created by StaticMessages.sh also arbitrary, only used for websites
> > I think (?)
> > - ._desktop_.po automatic - shouldn't be shipped
> > - ._json_.po automatic - shouldn't be shipped
> > - .appdata.po automatic - shouldn't be shipped
> > - .metadata.po automatic - shouldn't be shipped
> 
> OK. make_rc_tag.sh already says
> 
> find -regextype egrep -regex '.*\.(_desktop_|_json_|appdata|metainfo)\.po' 
> -delete
> 
> which matches the above, assuming you meant metainfo when writing metadata?
> 
> I just changed that regexp to add _xml_mimetypes.po, I hope this solves the 
> issue.
> https://invent.kde.org/sysadmin/release-tools/commit/ffee07853b586b80236791edd69afc9d9d5dfd8e
> 
> Ah, no, Albert still needs to "do the small patch for 
> src/mimetypes/XmlMessages.sh to rename it", IIUC.

https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/13



> 
> 






Re: xml_mimetypes5 and kcoreaddons

2020-07-15 Thread Albert Astals Cid
El dimecres, 15 de juliol de 2020, a les 12:24:34 CEST, Harald Sitter va 
escriure:
> On Wed, Jul 15, 2020 at 12:39 AM David Faure  wrote:
> >
> > On mardi 14 juillet 2020 19:35:41 CEST Albert Astals Cid wrote:
> > > El dimarts, 14 de juliol de 2020, a les 15:14:38 CEST, Jonathan Riddell va
> > escriure:
> > > > We're playing with translations in neon packages and looking at
> > > > kcoreaddons
> > > > the tars have
> > > > xml_mimetypes5
> > > > But we can't see anything in the code which uses this.  Do these
> > > > translations get used?
> > >
> > > Yes, the translations are used.
> > >
> > > No, they don't need to be on the tarball.
> > >
> > > The translations are used at scripty time to to fill
> > > https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/mimetypes/k
> > > de5.xml
> > >
> > > Luigi recently did a change so the files ending in _xml_mimetypes.po don't
> > > get added to the release service tarballs.
> > >
> > > This didn't work here because a) KF5 is using a different branch of
> > > release-tools b) the file doesn't follow the same naming pattern than the
> > > rest of xml mimetype files we have.
> > >
> > > If DavidF is fine adapting his scripts to not release files ending in
> > > _xml_mimetypes.po (i.e. him or someone else patches the scripts) i
> > > volunteer to do the small patch for src/mimetypes/XmlMessages.sh to rename
> > > it.
> >
> > Fine with me, but don't we have more cases of the same kind, with different
> > names? Any case of translations being "integrated" into some file leads to
> > this. Desktop files, mimetype XML, is there really nothing else?
> 
> It's a bit more "fluid" than one would hope. Looking at
> update_translations the following patterns exist:
> 
> - created by XmlMessages.sh unfortunately arbitrary named files but
> largely using the standard suffix Albert mentioned (the only other
> violation I can find with lxr is kpat)
> - created by StaticMessages.sh also arbitrary, only used for websites
> I think (?)

It's used for more things, e.g. kdeconnect-android

StaticMessages is a bit of a DIY import/export for files that need to be 
extracted to .po and then imported in "random" file formats.

Cheers,
  Albert

> - ._desktop_.po automatic - shouldn't be shipped
> - ._json_.po automatic - shouldn't be shipped
> - .appdata.po automatic - shouldn't be shipped
> - .metadata.po automatic - shouldn't be shipped
> 
> (of course also Messages.sh with arbitrary naming, but that's the
> regular translations so they need shipping ^^)
> 
> HS
> 






Re: xml_mimetypes5 and kcoreaddons

2020-07-14 Thread Albert Astals Cid
El dimarts, 14 de juliol de 2020, a les 15:14:38 CEST, Jonathan Riddell va 
escriure:
> We're playing with translations in neon packages and looking at kcoreaddons
> the tars have
> xml_mimetypes5
> But we can't see anything in the code which uses this.  Do these
> translations get used?

Yes, the translations are used.

No, they don't need to be on the tarball.

The translations are used at scripty time to to fill 
https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/mimetypes/kde5.xml

Luigi recently did a change so the files ending in _xml_mimetypes.po don't get 
added to the release service tarballs.

This didn't work here because a) KF5 is using a different branch of 
release-tools b) the file doesn't follow the same naming pattern than the rest 
of xml mimetype files we have.

If DavidF is fine adapting his scripts to not release files ending in 
_xml_mimetypes.po (i.e. him or someone else patches the scripts) i volunteer to 
do the small patch for src/mimetypes/XmlMessages.sh to rename it.

Cheers,
  Albert

> 
> Jonathan
> 






Re: Deprecate KRandomSequence ?

2020-07-04 Thread Albert Astals Cid
El dilluns, 29 de juny de 2020, a les 22:27:44 CEST, Albert Astals Cid va 
escriure:
> 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

https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/7

Here the first step of adding a randomize to KRandom.

Cheers,
  Albert

>  * 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?
> 
> Cheers,
>   Albert
> 
> 
> 






Re: Deprecate KRandomSequence ?

2020-06-30 Thread Albert Astals Cid
El dimarts, 30 de juny de 2020, a les 22:17:56 CEST, Johan Ouwerkerk va 
escriure:
> On Tue, Jun 30, 2020 at 7:32 PM Albert Astals Cid  wrote:
> >
> > >
> > > If an application was relying on the random application sequence, it
> > > probably has bigger problems.
> >
> > Why? It's exactly what KRandomSequence (and QRandomGenerator) promise to do.
> >
> > And at least on KPat this is really useful.
> >
> > You can directly seed the random generator from the "Create new game" UI, 
> > so if there's a bug found in say game 1232145345, you can tell me that and 
> > then everyone can reproduce that bug since starting game 1232145345 gives 
> > everyone the same random numbers.
> >
> > Cheers,
> >   Albert
> >
> 
> As I read it, the only thing that could change is that KRandomSequence
> and QRandomGenerator will produce different outputs for the same seed
> value because the underlying PRNG may be different. So that might
> introduce a backwards incompatible change if you rely on the output of
> the sequence remaining stable between two versions of KPat. However,
> seeding it with a fixed value and then consuming the sequence should
> remain fully reproducible between two instances of the *same* KPat
> version.

Correct :)

Cheers,
  Albert

> 
> Regards,
> 
> - Johan
> 






Re: Deprecate KRandomSequence ?

2020-06-30 Thread Albert Astals Cid
El dimarts, 30 de juny de 2020, a les 1:21:48 CEST, Aleix Pol va escriure:
> 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. 

Why? It's exactly what KRandomSequence (and QRandomGenerator) promise to do.

And at least on KPat this is really useful.

You can directly seed the random generator from the "Create new game" UI, so if 
there's a bug found in say game 1232145345, you can tell me that and then 
everyone can reproduce that bug since starting game 1232145345 gives everyone 
the same random numbers.

Cheers,
  Albert

> It can always be hardcoded into the
> application too.
> 
> Aleix
> 






Deprecate KRandomSequence ?

2020-06-29 Thread Albert Astals Cid
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?

Cheers,
  Albert




Re: New Framework Review: KDAV

2020-06-14 Thread Albert Astals Cid
El diumenge, 14 de juny de 2020, a les 10:17:01 CEST, Ben Cooksley va escriure:
> On Sun, Jun 14, 2020 at 8:03 PM Volker Krause  wrote:
> >
> > With both 20.04.2 and 5.71.0 out I think it's now time to do this move.
> >
> > What extra steps do we need to take now that the framework/application
> > distinction exists in Gitlab as well? I guess this is the first case of a
> > post-migration move. Also, what is the impact on the 20.04.3 release when we
> > move this in Gitlab?
> 
> You'll need to file a Sysadmin ticket requesting we relocate the
> repository from it's current home in pim/ to frameworks/
> Gitlab will provide a redirect for this automatically, so existing
> urls and clones won't be affected by this - although they will be
> given a notice that it has moved.
> 
> Systems such as scripty won't be impacted by this as they use the
> stable repository identifier.
> 
> In terms of the Release Service 20.04.3 release, Albert/Christoph will
> need to comment on this.

It shouldn't, the release service scripts don't care about the subdir repos are 
in, and given gitlab follows moves, we shouldn't not have a problem either with 
things like pushing tags, etc.

Cheers,
  Albert

> 
> >
> > Thanks,
> > Volker
> 
> Cheers,
> Ben
> 
> >
> > On Sunday, 24 May 2020 08:52:17 CEST 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 

D26342: Allow overriding to disable auto language detection

2020-06-13 Thread Albert Astals Cid
aacid added a comment.


  In D26342#675164 , @sdepiets wrote:
  
  > In D26342#675142 , @dfaure wrote:
  >
  > > This actually breaks language auto-detection for me in the KMail composer.
  > >
  > > Testcase:
  > >
  > > - New Mail
  > > - I type "Bonjour," in the body
  > >
  > >   Before: It's detected as French and not underlined as a typo
  > >
  > >   After: The language remains English, and the word is underlined as a 
typo
  > >
  > >   Workaround: Tools / Spelling / change language from English to French
  > >
  > >   Too bad I'm realizing this is the reason for the regression only today 
(day of 5.71 release) by looking at the KF-5.71 changelog :(
  >
  >
  > I don't think that's a regression, in the previous behavior you could try 
to set any language to proofread, it would always auto-detect "Bonjour" as 
French, thus the "Tools / Spelling / change language" had not effect if 
autodetect was enabled at system level (while autodetection should be an 
application or even case by case decision).
  >
  > It may not seem like an issue for simple cases, but actually for mixed 
contents (i.e. an email that is 50% French, 50% English) that would be detected 
as English, you would have no way at all to check the French text without 
disabling system-wide autodectection.
  >
  > Calling setAutoDetectLanguageDisabled(false) restores the previous behavior
  
  
  The problem here is that David probably never set any language on purpose.
  
  you could argue that this is a deficiency of the UI, should have a checkbox 
for "enable spellchecking" and another for "enable spellchecking *exactly* in 
this language"
  
  And this is were we failed, we changed the default behaviour and that's 
probably not the greatest of the ideas in retrospect. Even if we could not see 
why anyone would set a language and would still want the auto language 
detection to be enabled, well it seems that at least David wanted because it's 
been the behaviour for ages :D
  
  Not sure what's the correct path forward though :/

REPOSITORY
  R246 Sonnet

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

To: sdepiets, #frameworks, cullmann, mlaurent, mludwig, aacid
Cc: dfaure, aacid, mludwig, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


Re: Opening files by mimetype instead of by file extension

2020-06-10 Thread Albert Astals Cid
El dimecres, 10 de juny de 2020, a les 11:52:03 CEST, David Faure va escriure:
> On mercredi 10 juin 2020 00:52:16 CEST Albert Astals Cid wrote:
> > As far as I can see QFileDialog only supports listing by file extension.
> > 
> > On the other hand it seems in GTK+ land you can get an open file dialog
> > listing by mimetype, so I've got one bug about "you're worse than XXX
> > because you can't do this"
> 
> What does "list by mimetype" mean exactly?
> Is this about a mimetype column in the table/tree view? (missing)
> Is this about the filter combobox showing mimetypes? (supported)
> Or is it something else?

It's about using https://doc.qt.io/qt-5/qfiledialog.html#setMimeTypeFilters ^_^

Thanks Friedrich on IRC for reminding me that function exists

And sorry for the noise.

Cheers,
  Albert

> 
> 






Opening files by mimetype instead of by file extension

2020-06-09 Thread Albert Astals Cid
As far as I can see QFileDialog only supports listing by file extension.

On the other hand it seems in GTK+ land you can get an open file dialog listing 
by mimetype, so I've got one bug about "you're worse than XXX because you can't 
do this"

Is there something we could do at the KDE Frameworks level to support this 
feature? 

Or should this be done in Qt?

Cheers,
  Albert





Re: KRunProxy

2020-06-06 Thread Albert Astals Cid
El dissabte, 6 de juny de 2020, a les 19:00:59 CEST, David Faure va escriure:
> In order to switch kdeclarative to 
> -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x054700
> we need to port KRunProxy away from KRun, or to deprecate KRunProxy.
> 
> AFAICS it exposes an object named KRun to QML files, but searching for
> qml files with KRun in them leads to no results: 
> https://lxr.kde.org/search?_filestring=*.qml&_string=KRun
> 
> Am I doing this wrong? 

Yes, this is the correct search

https://lxr.kde.org/search?_filestring=.*%5C.qml&_advanced=1&_string=KRun&_casesensitive=1

>From what i can see it's only used in one place to launch ksysguard

Cheers,
  Albert

> Are there other file extensions to take into consideration?
> 
> If not, can I deprecate KRunProxy?
> 
> 






D29826: [KMainWindow] Invoke QIcon::setFallbackThemeName (later)

2020-06-04 Thread Albert Astals Cid
aacid added a comment.


  In D29826#674634 , @aacid wrote:
  
  > oh i think  i'm too late :D
  
  
  Let's wait for the fix to actually land and then i'll propose that change

REPOSITORY
  R263 KXmlGui

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

To: poboiko, aacid, mart, broulik
Cc: mart, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29826: [KMainWindow] Invoke QIcon::setFallbackThemeName (later)

2020-06-04 Thread Albert Astals Cid
aacid added a comment.


  oh i think  i'm too late :D

INLINE COMMENTS

> kmainwindow.cpp:253
> +// TODO: remove this once we depend on Qt 5.15.1, where this is fixed
> +#if QT_VERSION >= QT_VERSION_CHECK(5, 12, 0)
> +if (QIcon::fallbackThemeName().isEmpty()) {

should this be
#if QT_VERSION >= QT_VERSION_CHECK(5, 12, 0) && #if QT_VERSION < 
QT_VERSION_CHECK(5, 15, 1)
?

REPOSITORY
  R263 KXmlGui

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

To: poboiko, aacid, mart, broulik
Cc: mart, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29826: [KMainWindow] Invoke QIcon::setFallbackThemeName (later)

2020-06-04 Thread Albert Astals Cid
aacid added a comment.


  It didn't really land on Qt 5.15 yet, so we may need to update the comment to 
say 5.15.1 or something
  
  https://codereview.qt-project.org/c/qt/qtbase/+/302581
  
  But as said i think this is reasonable for now

REPOSITORY
  R263 KXmlGui

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

To: poboiko, aacid, mart, broulik
Cc: mart, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29826: [KMainWindow] Invoke QIcon::setFallbackThemeName (later)

2020-05-24 Thread Albert Astals Cid
aacid added a comment.


  Personally I'm happy enough with this, i guess wait a few days and if noone 
disagrees, land it

REPOSITORY
  R263 KXmlGui

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

To: poboiko, aacid, mart, broulik
Cc: mart, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29826: [KMainWindow] Invoke QIcon::setFallbackThemeName (later)

2020-05-23 Thread Albert Astals Cid
aacid added a comment.


  Do you think we should mention something like
  
  // TODO Remove once we can depend on a Qt version that has 
https://codereview.qt-project.org/c/qt/qtbase/+/301588
  
  Or maybe i'm being too optimistic in getting that landed ^_^ 

REPOSITORY
  R263 KXmlGui

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

To: poboiko, aacid, mart, broulik
Cc: mart, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D22488: invoke QIcon::setFallbackThemeName a bit later

2020-05-23 Thread Albert Astals Cid
aacid added a comment.


  In D22488#673575 , @poboiko wrote:
  
  > UPD: seems like it doesn't. I've added couple qDebug lines, to 
`QIcon::fromTheme()` method and near `QIcon::setFallbackThemeName()` with your 
patch, and then ran okular and dolphin. 
  >  By the time `setFallbackThemeName()` is called, almost all icons are 
already loaded :(
  
  
  Yes, that's exactly what i said with my comment about it being bad :D
  
  Ok, maybe we can go extra crazy and [assuming my patch makes it to Qt 5.15.1] 
have this block and your block from KMainWindow (maybe adding a if 
QIcon::fallbackThemeName().isEmpty() first, we don't want to overwrite if 
people manually chose something else)

REPOSITORY
  R302 KIconThemes

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

To: mart, #frameworks, #plasma
Cc: poboiko, aacid, mlaurent, broulik, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns


D29826: [KMainWindow] Invoke QIcon::setFallbackThemeName (later)

2020-05-23 Thread Albert Astals Cid
aacid added a comment.


  In D29826#673572 , @poboiko wrote:
  
  > Thanks for looking into it! :)
  >
  > In D29826#673543 , @aacid wrote:
  >
  > > I don't think moving this code from KIconThemes to kmainwindow makes 
sense, what about all the apps that use KIconThemes but no KMainWindow?
  >
  >
  > I'm just not aware of any. I've looked at some of the most used (by me :]), 
noted that all of them use KMainWindow and thought it might be a good option.
  
  
  What about discover for example?

REPOSITORY
  R263 KXmlGui

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

To: poboiko, aacid, mart, broulik
Cc: mart, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D22488: invoke QIcon::setFallbackThemeName a bit later

2020-05-22 Thread Albert Astals Cid
aacid added a comment.


  Now i understand this is causing relatively several issues, sorry for 
dropping the ball, so we should probably fix for users before Qt 5.15.1
  
  What about something like
  
diff --git a/src/kicontheme.cpp b/src/kicontheme.cpp
index 4f5d9d5..62fc9d7 100644
--- a/src/kicontheme.cpp
+++ b/src/kicontheme.cpp
@@ -70,6 +70,19 @@ void initRCCIconTheme()
 }
 Q_COREAPP_STARTUP_FUNCTION(initRCCIconTheme)
 
+class SetBreezeFallbackHelper : public QObject
+{
+bool event(QEvent *e) override
+{
+if (e->type() == QEvent::User) {
+QIcon::setFallbackThemeName(QStringLiteral("breeze"));
+deleteLater();
+return true;
+}
+return QObject::event(e);
+}
+};
+
 // Set the icon theme fallback to breeze
 // Most of our apps use "lots" of icons that most of the times
 // are only available with breeze, we still honour the user icon
@@ -77,7 +90,8 @@ Q_COREAPP_STARTUP_FUNCTION(initRCCIconTheme)
 // since it's almost sure it'll be there
 static void setBreezeFallback()
 {
-QIcon::setFallbackThemeName(QStringLiteral("breeze"));
+SetBreezeFallbackHelper *helper = new SetBreezeFallbackHelper();
+QCoreApplication::instance()->postEvent(helper, new 
QEvent(QEvent::User), Qt::HighEventPriority);
 }
 
 Q_COREAPP_STARTUP_FUNCTION(setBreezeFallback)
  
  It's still totally bad since it only sets the fallback after QGuiApplication 
*starts* running (which is mega late since most of the constructors will have 
already be created), but at least doesn't rely on the app creating a KIconTheme.

REPOSITORY
  R302 KIconThemes

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

To: mart, #frameworks, #plasma
Cc: aacid, mlaurent, broulik, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns


D22488: invoke QIcon::setFallbackThemeName a bit later

2020-05-22 Thread Albert Astals Cid
aacid added a comment.


  https://codereview.qt-project.org/c/qt/qtbase/+/301588

REPOSITORY
  R302 KIconThemes

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

To: mart, #frameworks, #plasma
Cc: aacid, mlaurent, broulik, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns


D22488: invoke QIcon::setFallbackThemeName a bit later

2020-05-22 Thread Albert Astals Cid
aacid added a comment.


  Wouldn't it make more sense to fix in Qt?
  
  Something like
  
diff --git a/src/gui/image/qicon.cpp b/src/gui/image/qicon.cpp
index 41fe649fc5..f86ad3c760 100644
--- a/src/gui/image/qicon.cpp
+++ b/src/gui/image/qicon.cpp
@@ -1260,7 +1260,7 @@ QString QIcon::fallbackThemeName()
 */
 void QIcon::setFallbackThemeName(const QString )
 {
-QIconLoader::instance()->setFallbackThemeName(name);
+QIconLoader::instance(NoInializeNeeded)->setFallbackThemeName(name);
 }
 
 /*!
diff --git a/src/gui/image/qiconloader.cpp b/src/gui/image/qiconloader.cpp
index 15ab1b3cd9..96dfd9163d 100644
--- a/src/gui/image/qiconloader.cpp
+++ b/src/gui/image/qiconloader.cpp
@@ -125,10 +125,12 @@ void QIconLoader::ensureInitialized()
 }
 }
 
-QIconLoader *QIconLoader::instance()
+QIconLoader *QIconLoader::instance(InstanceOptions o)
 {
-   iconLoaderInstance()->ensureInitialized();
-   return iconLoaderInstance();
+if (o == EnsureInitialized) {
+iconLoaderInstance()->ensureInitialized();
+}
+return iconLoaderInstance();
 }
 
 // Queries the system theme and invalidates existing
diff --git a/src/gui/image/qiconloader_p.h b/src/gui/image/qiconloader_p.h
index fac18b5d79..a69da4a5f7 100644
--- a/src/gui/image/qiconloader_p.h
+++ b/src/gui/image/qiconloader_p.h
@@ -185,7 +185,11 @@ public:
 void setFallbackSearchPaths(const QStringList );
 QStringList fallbackSearchPaths() const;
 QIconDirInfo dirInfo(int dirindex);
-static QIconLoader *instance();
+enum InstanceOptions {
+NoInializeNeeded = 0,
+EnsureInitialized = 1
+}
+static QIconLoader *instance(InstanceOptions o = EnsureInitialized);
 void updateSystemTheme();
 void invalidateKey() { m_themeKey++; }
 void ensureInitialized();
  
  I think this should be relatively easy to push though in Qt explaining that 
small ordering issue there is
  
  Not sure it compiles, for some reason i can't compile Qt 5.15 branch right now

REPOSITORY
  R302 KIconThemes

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

To: mart, #frameworks, #plasma
Cc: aacid, mlaurent, broulik, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns


D29826: [KMainWindow] Invoke QIcon::setFallbackThemeName (later)

2020-05-22 Thread Albert Astals Cid
aacid added a comment.


  Not sure if you're subscribed to https://phabricator.kde.org/D22488 see my 
last comment there i think it's the way to go

REPOSITORY
  R263 KXmlGui

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

To: poboiko, aacid, mart, broulik
Cc: mart, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29826: [KMainWindow] Invoke QIcon::setFallbackThemeName (later)

2020-05-22 Thread Albert Astals Cid
aacid added a comment.


  I don't think moving this code from KIconThemes to kmainwindow makes sense, 
what about all the apps that use KIconThemes but no KMainWindow?

REPOSITORY
  R263 KXmlGui

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

To: poboiko, aacid, mart, broulik
Cc: mart, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29577: Stop using deprecated methods

2020-05-09 Thread Albert Astals Cid
aacid closed this revision.

REPOSITORY
  R320 KIO Extras

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

To: aacid, dfaure
Cc: kossebau, kde-frameworks-devel, kfm-devel, dfaure, waitquietly, azyx, 
nikolaik, pberestov, iasensio, aprcela, fprice, LeGast00n, cblack, 
fbampaloukas, alexde, Codezela, feverfew, meven, michaelh, spoorun, 
navarromorales, firef, ngraham, andrebarros, bruns, emmanuelp, rdieter, 
mikesomov


D29577: Stop using deprecated methods

2020-05-09 Thread Albert Astals Cid
aacid added a subscriber: kossebau.

REPOSITORY
  R320 KIO Extras

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

To: aacid
Cc: kossebau, kde-frameworks-devel, kfm-devel, dfaure, waitquietly, azyx, 
nikolaik, pberestov, iasensio, aprcela, fprice, LeGast00n, cblack, 
fbampaloukas, alexde, Codezela, feverfew, meven, michaelh, spoorun, 
navarromorales, firef, ngraham, andrebarros, bruns, emmanuelp, rdieter, 
mikesomov


D29577: Stop using deprecated methods

2020-05-09 Thread Albert Astals Cid
aacid created this revision.
Herald added projects: Dolphin, Frameworks.
Herald added subscribers: kfm-devel, kde-frameworks-devel.
aacid requested review of this revision.

REVISION SUMMARY
  They are no-ops

REPOSITORY
  R320 KIO Extras

BRANCH
  master

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

AFFECTED FILES
  fish/fish.cpp

To: aacid
Cc: kde-frameworks-devel, kfm-devel, dfaure, waitquietly, azyx, nikolaik, 
pberestov, iasensio, aprcela, fprice, LeGast00n, cblack, fbampaloukas, alexde, 
Codezela, feverfew, meven, michaelh, spoorun, navarromorales, firef, ngraham, 
andrebarros, bruns, emmanuelp, rdieter, mikesomov


D29390: Respect QIcon::fallbackSearchpaths()

2020-05-03 Thread Albert Astals Cid
aacid added inline comments.

INLINE COMMENTS

> aacid wrote in kiconloader.cpp:1142
> Would it make sense trying to use QIconLoader::lookupFallbackIcon ? This way 
> we "upstream" Qt behaviour? For example you're supporting svgz while Qt 
> doesn't. Which would mean different QIcon::fallbackSearchPaths whether you're 
> using KIconLoader or not which doesn't seem totally great?

I just realized that function is private, not really easy to use :/

anyhow do you think we should remove svgz?

Also i think using

const QStringList extensions = { QStringLiteral(".png"), 
QStringLiteral(".svg"), QStringLiteral(".svgz"), QStringLiteral(".xpm") };

should be a bit faster

REPOSITORY
  R302 KIconThemes

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

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


D29390: Respect QIcon::fallbackSearchpaths()

2020-05-03 Thread Albert Astals Cid
aacid added inline comments.

INLINE COMMENTS

> kiconloader.cpp:1142
> +for (const QString  : fallbackPaths) {
> +const QStringList extensions = QStringList() << 
> QStringLiteral(".png") << QStringLiteral(".svg") << QStringLiteral(".svgz") 
> << QStringLiteral(".xpm");
> +

Would it make sense trying to use QIconLoader::lookupFallbackIcon ? This way we 
"upstream" Qt behaviour? For example you're supporting svgz while Qt doesn't. 
Which would mean different QIcon::fallbackSearchPaths whether you're using 
KIconLoader or not which doesn't seem totally great?

REPOSITORY
  R302 KIconThemes

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

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


D26342: Allow overriding to disable auto language detection

2020-05-03 Thread Albert Astals Cid
This revision was automatically updated to reflect the committed changes.
Closed by commit R246:422fac8a6f92: Allow overriding to disable auto language 
detection (authored by sdepiets, committed by aacid).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D26342?vs=81177=81805#toc

REPOSITORY
  R246 Sonnet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26342?vs=81177=81805

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

AFFECTED FILES
  autotests/test_highlighter.cpp
  src/core/backgroundchecker.cpp
  src/core/backgroundchecker.h
  src/core/backgroundchecker_p.h
  src/ui/highlighter.cpp
  src/ui/highlighter.h

To: sdepiets, #frameworks, cullmann, mlaurent, mludwig, aacid
Cc: aacid, mludwig, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D26342: Allow overriding to disable auto language detection

2020-05-03 Thread Albert Astals Cid
aacid accepted this revision.
aacid added a comment.
This revision is now accepted and ready to land.


  Noone seems to really disagree.
  
  Let's merge it. @sdepiets I hope this doesn't break everything ;)

REPOSITORY
  R246 Sonnet

BRANCH
  master

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

To: sdepiets, #frameworks, cullmann, mlaurent, mludwig, aacid
Cc: aacid, mludwig, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29369: Use UI marker context in more tr() calls

2020-05-03 Thread Albert Astals Cid
aacid added a comment.


  +0.5

REPOSITORY
  R294 KBookmarks

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

To: kossebau, #frameworks, #localization
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29370: Use UI marker context in more tr() calls

2020-05-03 Thread Albert Astals Cid
aacid added a comment.


  +0.5

REPOSITORY
  R289 KNotifications

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

To: kossebau, #frameworks, #localization, broulik
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29369: Use UI marker context in more tr() calls

2020-05-03 Thread Albert Astals Cid
aacid added inline comments.

INLINE COMMENTS

> kbookmarkmenu.cpp:288
>  
> -QString title = tr("Open Folder in Tabs");
> +const QString title = tr("Open Folder in Tabs", "@action:inmenu");
>  

@title:inmenu?

REPOSITORY
  R294 KBookmarks

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

To: kossebau, #frameworks, #localization
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29368: Use UI marker context in more tr() calls

2020-05-03 Thread Albert Astals Cid
aacid added a comment.


  +0.5

REPOSITORY
  R284 KCompletion

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

To: kossebau, #frameworks, #localization
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29367: Use UI marker context in more tr() calls

2020-05-03 Thread Albert Astals Cid
aacid added a comment.


  +0.5

REPOSITORY
  R276 KItemViews

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

To: kossebau, #frameworks, #localization, davidedmundson
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29347: KAuthorized: export method to reload restrictions

2020-05-03 Thread Albert Astals Cid
aacid accepted this revision.
aacid added a comment.
This revision is now accepted and ready to land.


  a, for using in a different repo, ok.

REPOSITORY
  R237 KConfig

BRANCH
  master

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

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


D29363: Use UI marker context in more tr() calls

2020-05-02 Thread Albert Astals Cid
aacid added a comment.


  The descriptions seem reasonable.
  
  The problem with this is that it makes all strings untranslated and i'm not 
sure it's worth the effort.
  
  My hope is that at this point anything that was actually ambiguous would have 
been reported by the translators and fixed. But i know that's a hope ^_^ more 
than a reality
  
  So take this as a +0.1 i guess :D

REPOSITORY
  R236 KWidgetsAddons

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

To: kossebau, #frameworks, #localization, cfeck
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29347: KAuthorized: export method to reload restrictions

2020-05-02 Thread Albert Astals Cid
aacid added a comment.


  So how you're going to use it from unittests? declaring the function there?
  
  maybe better to declare it to some of the _p.h headers ?

REPOSITORY
  R237 KConfig

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

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


Re: Information regarding upcoming Gitlab Migration: clarifications

2020-04-30 Thread Albert Astals Cid
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 :?

Cheers,
  Albert

> 
> >
> > Cheers,
> > Ivan
> >
> >
> 
> Regards,
> Ben
> 
> >
> > --
> > dr Ivan Čukić
> > i...@cukic.co, https://cukic.co/
> > gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232  07AE 01C6 CE2B FF04 1C12
> >
> >
> 






Re: Information regarding upcoming Gitlab Migration

2020-04-27 Thread Albert Astals Cid
El dilluns, 27 d’abril de 2020, a les 3:40:01 CEST, Bhushan Shah va escriure:
> [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.

Anything that breaks kde:$repo will break the release-tools used for the 
monthly releases done by the release service and the l10n scripty scripts.

If it ends up happening it would be good if such change is as far away as 
possible from a release so the scripts can be adapted timely and hopefully 
without mistakes.

Cheers,
  Albert

> 
> Thanks!
> Bhushan for sysadmin team
> 
> [1] 
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> 
> 






Re: Information regarding upcoming Gitlab Migration

2020-04-27 Thread Albert Astals Cid
El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va escriure:
> On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud  
> wrote:
> >
> > Hi,
> >
> > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> > > 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
> > > >
> >
> > Thank you for having options and talking to us before implementing it.
> >
> > > > 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.
> > >
> >
> > I 100% agree with Aleix and I think it would also be detrimental for 
> > discoverability, exactly for the examples Aleix just gave.
> >
> > We came back from this subgroups ideas some times ago : wiki pages were 
> > hard to find because hidden under layers of groups. The same was true for 
> > api documentations. Now everything is flat and I think it's easier to find.
> >
> > Another bad message could also be sent by this: instead of exposing Konsole 
> > or Ark as two applications under the KDE umbrella, it would look like Utils 
> > for KDE, bringing back the KDE Desktop idea (where every application is 
> > already store in a submenu).
> >
> > As someone wrote later, if I'm looking for a given application, there is 
> > always the search function...
> 
> That requires that you know it exists. We have 1,043 mainline
> repositories at the moment, which translates to 53 pages of projects
> under a flat structure system.
> Reality is nobody is going to page through that looking for something.

But they have gitlab search, don't they?

I mean it's the solution you told Aleix to figure out if Okular was inside 
graphics or okular.

Why is search valid for one case and not for the other?

Cheers,
  Albert

> 
> Please also see my point regarding listing merge requests at the group
> level - you can see an example of what a flat structure ends up
> looking like at https://gitlab.gnome.org/GNOME
> 
> For those projects that span multiple repositories, you have just
> denied them any chance or ability to see a listing of everything
> related to their wider project.
> 
> >
> > Best regards,
> > Olivier
> > > Aleix
> >
> >
> 
> Cheers,
> 

Re: Information regarding upcoming Gitlab Migration

2020-04-27 Thread Albert Astals Cid
El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va escriure:
> In part I am mostly re-iterating what Ben already mentioned in different
> messages.
> 
> On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote:
> > Does this mean that to clone it we'll have to go "git clone
> > kde:games/knetwalk" or something along the lines?
> 
> Yes
> 
> [Rest of message is with sysadmin hat off and as a developer]
> 
> > 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.
> 
> I do agree that it maybe small inconvience, but let's be honest, most of
> us have been using kdesrc-build or some kind of automated tooling for
> building everything, apart from very rare case we never have to manually
> clone any of KDE repository, at least it is true for me personally. I am
> not sure about others.

Please let's refrain from saying things like "most of us have been using 
kdesrc-build" when you don't have any data to back that up.

Cheers,
  Albert




D24367: Some sanity verification

2020-04-26 Thread Albert Astals Cid
aacid accepted this revision.
aacid added a comment.
This revision is now accepted and ready to land.


  Looks good to me :)

REPOSITORY
  R287 KImageFormats

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

To: sandsmark, aacid, cfeck
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D26342: Allow overriding to disable auto language detection

2020-04-25 Thread Albert Astals Cid
aacid added a comment.


  You need to update the \since markers?
  
  After that i guess you can commit unless anyone really disagrees?
  
  @mludwig @cullmann ?

REPOSITORY
  R246 Sonnet

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

To: sdepiets, #frameworks, cullmann, mlaurent, mludwig
Cc: aacid, mludwig, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D25267: Improve XCF support

2020-04-14 Thread Albert Astals Cid
aacid added a comment.


  In D25267#647547 , @sandsmark 
wrote:
  
  > In D25267#647148 , @aacid wrote:
  >
  > > Seems like the windows build is broken :/
  > >
  > > 
https://build.kde.org/job/Frameworks/job/kimageformats/job/kf5-qt5%20WindowsMSVCQt5.14/16/console
  >
  >
  > Seems like I forgot to use the custom rand_r (to avoid exactly that + get 
the same noise function as windows) a couple of places.
  >
  > Should just be to replace `rand_r` with `RandomTable::rand_r` where it is 
missing, okay if I just do that in master?
  
  
  Yeah fixing that directly in master makes sense

REPOSITORY
  R287 KImageFormats

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

To: sandsmark, aacid, cfeck, apol, vkrause
Cc: ngraham, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns


D25267: Improve XCF support

2020-04-13 Thread Albert Astals Cid
aacid added a comment.


  In D25267#647129 , @sandsmark 
wrote:
  
  > I messed up and it got linked to the wrong phabricator review... Here it is 
anyways:
  >
  > 
https://cgit.kde.org/kimageformats.git/commit/?id=c60e77c048d32ccf743cec695743b77b2b25dc87
  
  
  Seems like the windows build is broken :/
  
  
https://build.kde.org/job/Frameworks/job/kimageformats/job/kf5-qt5%20WindowsMSVCQt5.14/16/console

REPOSITORY
  R287 KImageFormats

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

To: sandsmark, aacid, cfeck, apol, vkrause
Cc: ngraham, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns


D25267: Improve XCF support

2020-04-12 Thread Albert Astals Cid
aacid added a comment.


  the files are not uploaded correctly to phabricator so i can't check they 
work.
  
  Given we just released KF 5.69 *yesterday* i'm going to go crazy and say 
commit this and we have a "whole month" to fix regressions if it has any...

REPOSITORY
  R287 KImageFormats

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

To: sandsmark, aacid, cfeck, apol, vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D27632: Implement UString operator= to make gcc happy

2020-04-12 Thread Albert Astals Cid
This revision was automatically updated to reflect the committed changes.
Closed by commit R314:e637e721e40e: Implement UString operator= to make gcc 
happy (authored by aacid).

REPOSITORY
  R314 KJs

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27632?vs=76323=79911

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

AFFECTED FILES
  src/kjs/ustring.h

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


D26342: Allow overriding to disable auto language detection

2020-03-23 Thread Albert Astals Cid
aacid added a comment.


  In D26342#632842 , @sdepiets wrote:
  
  > In D26342#623729 , @aacid wrote:
  >
  > > Would it make sense to enshrine this behaviour with an autotest?
  >
  >
  > Sorry what do you mean by that? Similar to tests/BackgroundTest.cpp ?
  
  
  No, something like the stuff autotests/
  
  one example would be something like, use a text written in french that the 
autodetect algorithm properly detects as french, but then you go and force say 
German on it and then you go and ask for which language is and it should say 
German when autodetetaLanguageDisabled = true but then if you go and say 
setAutoDetectLanguageDisabled(false) again it should say again French
  
  Am i making sense?

REPOSITORY
  R246 Sonnet

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

To: sdepiets, #frameworks, cullmann, mlaurent, mludwig
Cc: aacid, mludwig, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns


D28151: Autotest file showing wrong File path

2020-03-19 Thread Albert Astals Cid
aacid accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R237 KConfig

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

To: usta, meven, aacid
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27966: KParts: add PartLoader as replacement to KMimeTypeTrader for parts

2020-03-12 Thread Albert Astals Cid
aacid added a comment.


  Looks reasonable to me, but i'm not a huge expert here either, i guess you 
can commit given you are the expert.
  
  Or maybe wait a few days in case someone else has commits?

REPOSITORY
  R306 KParts

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

To: dfaure, aacid, nicolasfella, kossebau
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27966: KParts: add PartLoader as replacement to KMimeTypeTrader for parts

2020-03-11 Thread Albert Astals Cid
aacid added inline comments.

INLINE COMMENTS

> dfaure wrote in partloader.h:59
> This is an excellent point, thanks for this feedback.
> 
> Loading a part from a given KPluginMetadata is extremely simple, though:
> 
>   KPluginLoader loader(md.fileName());
>   m_part = loader.factory()->create(this, this);
> 
> Just like any other plugin.
> [maybe with md.keyword() as third argument in the future, once that's 
> implemented]
> 
> I can see the idea of providing everything that is needed for KParts at the 
> KParts level, so that one doesn't actually have to figure out that the above 
> is the way to do it. But then again, this is the way to do it for any plugin, 
> there's nothing specific about KParts there. So an alternative would be to 
> put this into the documentation for partsForMimeType?
> 
> What do you think? Docu or wrapper for a two-liner?
> 
> BTW I just implemented part listing (in an actionlist) and part switching in 
> partviewer (which is turning into a mini-konqueror, hehe). It shows that the 
> above works. It also shows that the duplication between new-style JSON and 
> old-style desktop files is a problem, I'll add some duplicate pruning...

I'd say documentation is fine :)

REPOSITORY
  R306 KParts

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

To: dfaure, aacid, nicolasfella, kossebau
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27997: Fix cmake warning

2020-03-11 Thread Albert Astals Cid
aacid accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R309 KService

BRANCH
  warning

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

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


D27966: KParts: add PartLoader as replacement to KMimeTypeTrader for parts

2020-03-10 Thread Albert Astals Cid
aacid added inline comments.

INLINE COMMENTS

> partloader.h:59
> + */
> +KPARTS_EXPORT QVector partsForMimeType(const QString 
> );
> +

What's the use for this? The function below doesn't let me chose which one i 
want (i guess it always uses the one with the most preference?), so why would i 
need to query which parts are available?

Maybe there should be a version of create that takes a KPluginMetadata?

REPOSITORY
  R306 KParts

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

To: dfaure, aacid, nicolasfella, kossebau
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D26342: Allow overriding to disable auto language detection

2020-03-07 Thread Albert Astals Cid
aacid added a comment.


  Would it make sense to enshrine this behaviour with an autotest?

REPOSITORY
  R246 Sonnet

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

To: sdepiets, #frameworks, cullmann, mlaurent, mludwig
Cc: aacid, mludwig, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns


D26342: Allow overriding to disable auto language detection

2020-03-07 Thread Albert Astals Cid
aacid added inline comments.

INLINE COMMENTS

> backgroundchecker.cpp:147
>  {
> +d->autoDetectLanguageDisabled = true;
>  d->currentDict = speller;

question from someone that has never really used this setSpeller API.

Is this behaviour change for sure 100% of the times wanted?

If not you should add a new API that is setSpeller(speller, bool)

> backgroundchecker.cpp:179
>  // this sets language only for current sentence
> +d->autoDetectLanguageDisabled = true;
>  d->currentDict.setLanguage(lang);

same question here

REPOSITORY
  R246 Sonnet

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

To: sdepiets, #frameworks, cullmann, mlaurent, mludwig
Cc: aacid, mludwig, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns


D26342: Allow overriding to disable auto language detection

2020-02-29 Thread Albert Astals Cid
aacid added a comment.


  without having used Sonnet much, this seems the wrong API to me.
  
  Are you saying that it can happen that you tell Sonnet "use this language" 
and it goes and say "nah i'll ignore you and do my thing".
  
  It seems to me that what would make sense is that the "use this language" is 
what sets autoDetectLanguageDisabled to false, or at least the function that 
should get a new overload saying setLanguage(¿qstring? language, bool 
disableAutoDetection) if we want to be sure not to change existing behaviour

REPOSITORY
  R246 Sonnet

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

To: sdepiets, #frameworks, cullmann, mlaurent, mludwig
Cc: aacid, mludwig, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns


D27633: Port to KPluginLoader

2020-02-28 Thread Albert Astals Cid
aacid added a comment.


  In D27633#619369 , @aacid wrote:
  
  > In D27633#619365 , @aacid wrote:
  >
  > > I think this broke 
https://build.kde.org/job/Applications/job/ktp-common-internals/job/kf5-qt5%20SUSEQt5.12/20/console
 guess ¿KAccountsDPlugin now requires parameters to the constructor and is thus 
not a valid Q_INTERFACE?
  > >
  > > @nicolasfella can you please look at it?
  >
  >
  > On top of that that's a BIC change, you can't do BIC changes on KF5 repos, 
so revert?
  
  
  kaccount-integrations is not a KF5 repo ^_^

REPOSITORY
  R155 KAccounts Integration

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

To: nicolasfella, bshah, leinir, #frameworks, apol
Cc: aacid, lbeltrame


D27633: Port to KPluginLoader

2020-02-28 Thread Albert Astals Cid
aacid added a comment.


  In D27633#619365 , @aacid wrote:
  
  > I think this broke 
https://build.kde.org/job/Applications/job/ktp-common-internals/job/kf5-qt5%20SUSEQt5.12/20/console
 guess ¿KAccountsDPlugin now requires parameters to the constructor and is thus 
not a valid Q_INTERFACE?
  >
  > @nicolasfella can you please look at it?
  
  
  On top of that that's a BIC change, you can't do BIC changes on KF5 repos, so 
revert?

REPOSITORY
  R155 KAccounts Integration

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

To: nicolasfella, bshah, leinir, #frameworks, apol
Cc: aacid, lbeltrame


D27633: Port to KPluginLoader

2020-02-28 Thread Albert Astals Cid
aacid added a comment.


  I think this broke 
https://build.kde.org/job/Applications/job/ktp-common-internals/job/kf5-qt5%20SUSEQt5.12/20/console
 guess ¿KAccountsDPlugin now requires parameters to the constructor and is thus 
not a valid Q_INTERFACE?
  
  @nicolasfella can you please look at it?

REPOSITORY
  R155 KAccounts Integration

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

To: nicolasfella, bshah, leinir, #frameworks, apol
Cc: aacid, lbeltrame


D27632: Implement UString operator= to make gcc happy

2020-02-24 Thread Albert Astals Cid
aacid added a subscriber: porten.

REPOSITORY
  R314 KJs

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

To: aacid
Cc: porten, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns


D27632: Implement UString operator= to make gcc happy

2020-02-24 Thread Albert Astals Cid
aacid created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
aacid requested review of this revision.

REVISION SUMMARY
  otherwise complains that there's a copy constructor but not an
  assignment operator

REPOSITORY
  R314 KJs

BRANCH
  master

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

AFFECTED FILES
  src/kjs/ustring.h

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


D27039: [KStyle] Set the color of KMessageWidgets to the correct one from the current color scheme

2020-02-22 Thread Albert Astals Cid
aacid added a comment.


  Any particular reason you added me?

REPOSITORY
  R252 Framework Integration

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

To: davidre, #frameworks, aacid
Cc: anthonyfieroni, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns


Re: Banning QNetworkAccessManager

2020-02-20 Thread Albert Astals Cid
El dijous, 20 de febrer de 2020, a les 14:29:47 CET, Allen Winter va escriure:
> On Wednesday, February 19, 2020 6:09:02 PM EST Albert Astals Cid wrote:
> > El dimecres, 19 de febrer de 2020, a les 9:28:22 CET, Volker Krause va 
> > escriure:
> > > Additionally, improved documentation, a possible KNAM and/or driving the 
> > > QNAM 
> > > changes upstream can still be done alongside this obviously.
> > 
> > Also for Qt5 which will probably never be changed a clazy warning and 
> > making it easy to run clazy on gitlab CI would be great.
> > 
> 
> Krazy has a checker for QNetworkAccessManager use in Qt4 code.
> I could add a checker for Qt5 code if someone tells me what to look for
> (not that many people look at krazy reports. couldn't hurt. might help.

There's other ways to do it, but i guess we could start with something that 
checks for this?

https://community.kde.org/Policies/API_to_Avoid#QNetworkAccessManager

Cheers,
  Albert





Re: Banning QNetworkAccessManager

2020-02-19 Thread Albert Astals Cid
El dimecres, 19 de febrer de 2020, a les 9:28:22 CET, Volker Krause va escriure:
> Additionally, improved documentation, a possible KNAM and/or driving the QNAM 
> changes upstream can still be done alongside this obviously.

Also for Qt5 which will probably never be changed a clazy warning and making it 
easy to run clazy on gitlab CI would be great.

Cheers,
  Albert

> 
> Regards,
> Volker






Re: Banning QNetworkAccessManager

2020-02-19 Thread Albert Astals Cid
El dimecres, 19 de febrer de 2020, a les 8:05:01 CET, Ben Cooksley va escriure:
> The easiest path forward is to simply ban QNetworkAccessManager.

Stop saying that, that's not going to happen.

Cheers,
  Albert

> 
> >
> > Regards,
> > Volker
> 
> Regards,
> Ben
> 






Re: 2 kirigami fixes for a point release

2020-02-18 Thread Albert Astals Cid
El dimarts, 18 de febrer de 2020, a les 4:03:05 CET, Nate Graham va escriure:
> On 2020-02-16 14:43, Albert Astals Cid wrote:
> > Maybe i explain myself wrongly, i'm not blaming distros at all.
> > 
> > They made a decision, we/I may agree with them or not, that's *my/our* 
> > problem, what I was disagreeing is to us having to do extra work because 
> > someone elses (the distros) decision.
> 
> We already do this: it's called the Plasma LTS product. :-) It's been 
> specifically created to cater to various distros' desires for an 
> extended-support product they can ship to users of their own LTS releases.
> 
> But yes, I can also agree with more tests, better stability, moving to 
> GitLab so tests are run before merging, etc. I think we can all agree 
> with that.
> 
> However all the autotests in the world will not resolve the fundamental 
> incompatibility between the Plasma LTS product, which is built around 
> the release model of extended, ongoing bugfix releases, and Frameworks, 
> which is built around a rolling release model with no bugfix releases at 
> all.

I still don't see why this is a problem, as said Plasma depends on a myriad of 
libraries that are building each with their own release model, most probably 
with no bugfix releases at all either.

Incidentally what happens is that those libraries are not buggy, and it seems 
the Plasma-facing parts of KF5 are, well, let's make them not be.

Cheers,
  Albert




D27459: Port QLinkedList which is deprecated in qt5.15

2020-02-17 Thread Albert Astals Cid
aacid added a comment.


  Are we sure we can lose the features of QLinkedList here?
  
  maybe makes more sense to use std::list that has the same features as 
QLinkedList?

REPOSITORY
  R263 KXmlGui

BRANCH
  port_QLinkedList (branched from master)

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

To: mlaurent, dfaure, apol
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns


Re: 2 kirigami fixes for a point release

2020-02-16 Thread Albert Astals Cid
El diumenge, 16 de febrer de 2020, a les 22:34:51 CET, David Faure va escriure:
> On dimanche 16 février 2020 22:17:17 CET Albert Astals Cid wrote:
> > This is their fault, they as a distribution have decided to support a random
> > KDE Frameworks version for longer than we do support it, so they are the
> > ones that should be the job of supporting it.
> > 
> > It's like you are trying to say we should be doing the distributions jobs,
> > what we should be doing is doing our job which is making the best software
> > we can, not spending time accomodating decisions that somebody else took
> > for us, and since distributions often only bring us pain in the shape of
> > not updating versions, etc. IMHO what we should be doing is moving away
> > from distributions model and more into the snap/flatpak model in which we
> > control what we give our users.
> > 
> > Sadly flatpak doesn't work for non applications and snap is
> > Ubuntu-only-not-really-but-yes-really so for Plasma this doesn't really
> > solver the problem so maybe we should just finally tell our users to start
> > using the good distributions if they care about their user experience. By
> > good meaning those with a rolling KDE software suite or those that actually
> > do backport fixes to the version they have randomly decided to lock onto.
> 
> At the same time, we can only successfully convince distributions to upgrade 
> to the monthly KF5 releases if they are stable and don't come with 
> regressions. I believe this is true for most of the frameworks, but I'm not 
> so 
> sure about kirigami/qqc2-desktop-style, based on what I hear (not just the 
> recent issue).
> 
> Before blaming distros, I believe we have our own backyard to take care of,
> with for sure more systematic use of code reviews and possibly more automated 
> testing, for those frameworks (for the latter I guess that QtQuick doesn't 
> make it easy, but that's part of the problem...).

Maybe i explain myself wrongly, i'm not blaming distros at all. 

They made a decision, we/I may agree with them or not, that's *my/our* problem, 
what I was disagreeing is to us having to do extra work because someone elses 
(the distros) decision.

And yes, totally, we need more autotests, and moving to gitlab so tests are 
finally run *before* merging stuff.

Cheers,
  Albert

> 
> 






Re: 2 kirigami fixes for a point release

2020-02-16 Thread Albert Astals Cid
El dissabte, 15 de febrer de 2020, a les 20:35:23 CET, Nate Graham va escriure:
> On 2020-02-15 11:55, Ben Cooksley wrote:
> > My point above was that the version you decide to freeze on should
> > only be the version you depend on during development.
> > The version you depend on when you release will be the next release of
> > Frameworks (so by freezing on 5.66 for development, it should have had
> > a release-day dependency of 5.67)
> > 
> > The release of Plasma should then take place shortly after the
> > Frameworks version you have a release-day dependency on.
> > 
> > You stagger it like this to ensure that developers are performing a
> > full burn in of the Frameworks version for several weeks on their
> > systems, and to ensure that all the problems they find end up in the
> > Frameworks that users will have on their systems.
> 
> None of this makes a difference for distros that ship LTS Plasma don't 
> ship newer Frameworks versions. No matter how much testing you do, some 
> bugs in Frameworks will slip through and need to be fixed after the 
> release. But the frameworks release cycle has no concept of the 
> post-release bugfix like Apps and Plasma do; instead the expectation is 
> that the distro will just ship a new Frameworks version in a month. This 
> expectation does not match the reality for the distros that want to ship 
> an LTS plasma version and do not ship newer Frameworks versions.

This is their fault, they as a distribution have decided to support a random 
KDE Frameworks version for longer than we do support it, so they are the ones 
that should be the job of supporting it.

It's like you are trying to say we should be doing the distributions jobs, what 
we should be doing is doing our job which is making the best software we can, 
not spending time accomodating decisions that somebody else took for us, and 
since distributions often only bring us pain in the shape of not updating 
versions, etc. IMHO what we should be doing is moving away from distributions 
model and more into the snap/flatpak model in which we control what we give our 
users. 

Sadly flatpak doesn't work for non applications and snap is 
Ubuntu-only-not-really-but-yes-really so for Plasma this doesn't really solver 
the problem so maybe we should just finally tell our users to start using the 
good distributions if they care about their user experience. By good meaning 
those with a rolling KDE software suite or those that actually do backport 
fixes to the version they have randomly decided to lock onto.

Cheers,
  Albert

> 
> 
> > As for the distributions that are refusing to update Frameworks, do
> > you have a list of those distributions?
> > If they're providing a poor experience to our users then we at the
> > very least should ensure we steer people away from them.
> 
> Oh, you know, just some weird, unimportant little ones, like Debian, 
> Ubuntu/Kubuntu, and openSUSE Leap. ;-) We should definitely make sure 
> that our users don't use *those*; it's not like they're the big heavy 
> hitters of the Linux world that are used in large numbers by 
> corporations and shipped on hardware or anything. :)
> 
> Nate
> 






D27419: Update Japanese holidays

2020-02-15 Thread Albert Astals Cid
aacid added a comment.


  No, she (i think) does not have commit access.

REPOSITORY
  R175 KHolidays

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

To: nhiga, dvratil, winterz, cgiboudeaux
Cc: aacid, #kde_pim, kde-frameworks-devel, LeGast00n, cblack, fbampaloukas, 
GB_2, dcaliste, michaelh, ngraham, bruns, dvasin, rodsevich, winterz, vkrause, 
mlaurent, knauss, dvratil


D25698: New query mechanism for applications: KApplicationTrader

2020-02-04 Thread Albert Astals Cid
aacid added a comment.


  For me it can go in, but i'm not really really netiher a Frameworks developer 
nor potentially a user of this class, so i'd feel more confortable if someone 
else also +1'ed
  
  On the other hand you're the mega-manintainer of everything, so i guess it 
can go in :)

REPOSITORY
  R309 KService

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

To: dfaure, broulik, mart, vkrause, nicolasfella, aacid, davidedmundson
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns


D26873: KStandardAction: add method for SwitchApplicationLanguage action creation

2020-01-29 Thread Albert Astals Cid
aacid accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R265 KConfigWidgets

BRANCH
  addconveniencemethodforlanguageswitchaction

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

To: kossebau, #frameworks, aacid
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns


D26990: Allow setting ItemsModel engine to either KNSCore or KNSQuick engine

2020-01-29 Thread Albert Astals Cid
aacid added a comment.


  Seems reasonable to me.

REPOSITORY
  R304 KNewStuff

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

To: leinir, #knewstuff, aacid, #frameworks
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns


D21721: Bring KNewStuffQuick to feature parity with KNewStuff(Widgets)

2020-01-28 Thread Albert Astals Cid
aacid added a comment.


  FWIW this broke artikulate since you changed the expected entry for engine: 
in KNS.ItemsModel

REPOSITORY
  R304 KNewStuff

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

To: leinir, #knewstuff, #vdg, #frameworks, ahiemstra
Cc: aacid, cfeck, davidedmundson, broulik, ahiemstra, anthonyfieroni, pino, 
ngraham, kde-frameworks-devel, LeGast00n, GB_2, michaelh, bruns


D26167: Update holidays and add flagdays and namedays for Sweden

2020-01-28 Thread Albert Astals Cid
This revision was automatically updated to reflect the committed changes.
Closed by commit R175:2d9ea97d1cdd: Update holidays and add flagdays and 
namedays for Sweden (authored by riiga, committed by aacid).

REPOSITORY
  R175 KHolidays

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26167?vs=72048=74529

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

AFFECTED FILES
  holidays/holidays.qrc
  holidays/plan2/holiday_se_sv
  holidays/plan2/holiday_se_sv_nameday

To: riiga, #kde_pim, winterz
Cc: ltoscano, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns


D25698: New query mechanism for applications: KApplicationTrader

2020-01-19 Thread Albert Astals Cid
aacid added inline comments.

INLINE COMMENTS

> kapplicationtrader.h:56
> + * true for all services, this would return the complete list of all
> + * installed applications (slow).
> + *

why is it slow? Looking at the code we have to go trhough all apps anyway since 
what we do is erase if returning false, so wouldn't returning true actually be 
faster?

REPOSITORY
  R309 KService

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

To: dfaure, broulik, mart, vkrause, nicolasfella, aacid, davidedmundson
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns


D25698: New class KApplicationTrader, to replace KMimeTypeTrader and KServiceTypeTrader

2020-01-17 Thread Albert Astals Cid
aacid added inline comments.

INLINE COMMENTS

> kapplicationtrader.h:57
> + *
> + * The @p constraint language is rather full.  The most common
> + * keywords are AND, OR, NOT, IN, and EXIST, all used in an

all this "constraint" definition needs updating

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

To: dfaure, broulik, mart, vkrause, nicolasfella
Cc: aacid, dhaumann, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, 
bruns


D26205: KWallet: Port QRegExp to QRegularExpression

2020-01-15 Thread Albert Astals Cid
aacid added a comment.


  In D26205#595080 , @ahmadsamir 
wrote:
  
  > In D26205#595034 , @blaze wrote:
  >
  > > 
https://github.com/KDE/falkon/blob/master/src/plugins/KDEFrameworksIntegration/kwalletpasswordbackend.cpp#L187
  > >
  > >   QMap entries;
  > >   if (m_wallet->readEntryList("*", entries) != 0) {
  > >   qWarning() << "KWalletPasswordBackend::initialize Cannot read 
entries!";
  > >   return;
  > >   }
  > >   
  > >
  > > This is the problematic code. As you can see it uses "*" as a wildcard. 
So may be it is possible just to use a different wildcard and it could be 
solved IDK
  >
  >
  > OK, I'll see if I can make it work and also fix the double-anchored issue; 
in a new diff, otherwise, we could just revert this patch.
  >
  > @apol, @aacid WDYT?
  
  
  I was going to be silent here, but since you asked my opinion is this, if you 
are not going to test the code you are changing, you should stop changing code. 
And by reading the comments it seems you aren't testing it, so either start 
testing it or stop doing blind changes.

REPOSITORY
  R311 KWallet

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

To: ahmadsamir, #frameworks, aacid, apol
Cc: blaze, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns


Re: KApplicationTrader API

2020-01-12 Thread Albert Astals Cid
El diumenge, 12 de gener de 2020, a les 11:50:03 CET, David Faure va escriure:
> I wrote a KApplicationTrader class in https://phabricator.kde.org/D25698
> and I need input on API.
> 
> Use case: the user types "km" in krunner.
> In order to find all applications that contain "km" (case insensitive), do we 
> want to write
> 
> auto offers = KApplicationTrader::self()->query("'km' ~~ Name");
> 
> or
> 
> auto filter = [](const KService::Ptr ) { return 
> service->name().contains("km", Qt::CaseInsensitive); }
> auto offers = KApplicationTrader::self()->query(filter);
> 
> ?

The second one fails if i type service->name() wrong, the first one doesn't if 
i write NaMe, so the second one is millions of times better in that regard in 
my opinion.

I mean i already know how to write C++ why should i learn "weird language"?

Cheers,
  Albert




D26424: [kdiroperator] Add method for accessing actions without KActionCollection

2020-01-05 Thread Albert Astals Cid
aacid added a comment.


  Why are we using a string instead of an enum?
  
  It's not like this is KXMLGui where people can define their own actions, is 
it?

REPOSITORY
  R241 KIO

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

To: nicolasfella, #frameworks, dfaure
Cc: dhaumann, aacid, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, 
bruns


  1   2   3   4   5   6   7   8   9   10   >