Re: Flatpak/Snap/Appimage BoF at Akademy

[Aleix Pol]

On Mon, Aug 26, 2019 at 6:58 AM Jan Grulich  wrote:
>
> Hi,
>
> do we want to do another Flatpak/Snap/Appimage BoF at Akademy this year? From
> my side it definitely can be useful and we can also have new people around
> this time and help them to package their applications if anyone is interested.
>
> Which day would you prefer? There is AGM on Monday and a daytrip on Wednesday,
> while most of the Tuesday is taken by Plasma, which is where I expect most of
> the people. Does Thursday sound good to you?

Works for me, yes.

See you in Milan!
Aleix

Re: kdump all the things!

[Aleix Pol]

I tried it, it is not showing anything to me. :'(

On Sat, Sep 7, 2019 at 5:35 PM Harald Sitter  wrote:
>
> I've made a thing that makes systemd-coredump easier to use and I for
> one use it as a replacement for drkonqi because it's both more
> reliable but also less UI faffing to get to what matters most to me...
> gdb.
>
> https://invent.kde.org/sitter/kde-coredump
>
> We could probably pursue extending it further and make it extragear or
> something if there's interest.
>
> HS

Re: kdump all the things!

[Aleix Pol]

It turns out it was working after all, just not the way I expected it
to initially.

Good stuff! :)

Aleix

On Sun, Sep 8, 2019 at 10:21 AM Aleix Pol  wrote:
>
> I tried it, it is not showing anything to me. :'(
>
> On Sat, Sep 7, 2019 at 5:35 PM Harald Sitter  wrote:
> >
> > I've made a thing that makes systemd-coredump easier to use and I for
> > one use it as a replacement for drkonqi because it's both more
> > reliable but also less UI faffing to get to what matters most to me...
> > gdb.
> >
> > https://invent.kde.org/sitter/kde-coredump
> >
> > We could probably pursue extending it further and make it extragear or
> > something if there's interest.
> >
> > HS

Re: Taking over maintainership of the kaccounts-* repos

[Aleix Pol]

On Fri, Sep 13, 2019 at 10:35 AM Bhushan Shah  wrote:
>
> Hello!
>
> At akademy we talked about the KAccounts and realized that kaccounts is
> unmaintained and/or Martin is not active.
>
> So I propose to take over maintainership of the following repositories.
>
> - kaccounts-integration
> - kaccounts-providers
> - kaccounts-mobile
>
> If you have any concerns/objections with this, let me know.
>
> Thanks
>
> --
> Bhushan Shah
> http://blog.bshah.in
> IRC Nick : bshah on Freenode
> GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D

:) thanks Bhushan!

Aleix

Re: Retirement of notes.kde.org

[Aleix Pol]

On Sun, Sep 15, 2019 at 8:58 PM Ben Cooksley  wrote:
>
> Good evening all,
>
> Currently we're in the situation where the software we use to run
> notes.kde.org is both difficult to maintain, as well as support (for
> things like document confidentiality for various groups within KDE).
>
> We'd therefore like to retire the service, replacing it with the
> Realtime Text Editor within Nextcloud (share.kde.org). Internally this
> editor uses Markdown.
>
> You can find a demo of this at https://share.kde.org/s/gtFcRmwetRKqTZJ
> (no login required)
>
> It would be appreciated if everyone could please test the realtime
> text editor and let us know if they encounter any issues.
>
> In terms of feature differences, we are aware that
> highlighting/authorship information won't be retained by the new
> editor, and there can occasionally be problems when editing the same
> line with someone else simultaneously.
>
> If everyone is okay with this we'd like to go ahead with shutting down
> notes.kde.org as soon as possible.
>
> Thanks,
> Ben Cooksley
> KDE Sysadmin

Hi,
Is the new editor already usable on share.kde.org? If I create a text
file I get a different thing than your demo.

Aleix

Re: Retirement of notes.kde.org

[Aleix Pol]

On Thu, Sep 19, 2019 at 4:34 AM Ben Cooksley  wrote:
>
> On Thu, Sep 19, 2019 at 2:50 AM Aleix Pol  wrote:
> >
> > On Sun, Sep 15, 2019 at 8:58 PM Ben Cooksley  wrote:
> > >
> > > Good evening all,
> > >
> > > Currently we're in the situation where the software we use to run
> > > notes.kde.org is both difficult to maintain, as well as support (for
> > > things like document confidentiality for various groups within KDE).
> > >
> > > We'd therefore like to retire the service, replacing it with the
> > > Realtime Text Editor within Nextcloud (share.kde.org). Internally this
> > > editor uses Markdown.
> > >
> > > You can find a demo of this at https://share.kde.org/s/gtFcRmwetRKqTZJ
> > > (no login required)
> > >
> > > It would be appreciated if everyone could please test the realtime
> > > text editor and let us know if they encounter any issues.
> > >
> > > In terms of feature differences, we are aware that
> > > highlighting/authorship information won't be retained by the new
> > > editor, and there can occasionally be problems when editing the same
> > > line with someone else simultaneously.
> > >
> > > If everyone is okay with this we'd like to go ahead with shutting down
> > > notes.kde.org as soon as possible.
> > >
> > > Thanks,
> > > Ben Cooksley
> > > KDE Sysadmin
> >
> > Hi,
> > Is the new editor already usable on share.kde.org? If I create a text
> > file I get a different thing than your demo.
>
> It should be yes. Did you create a new document or a new text document?
>
> This new editor only works with text documents (slightly confusingly)
> as the document editor is a version of LibreOffice Online (for more
> fully featured documents)
>
> >
> > Aleix
>
> Cheers,
> Ben

It was a new text document, AFAIR. This is what it looks like:
https://i.imgur.com/6RhmNLK.png

Aleix

Re: Retirement of notes.kde.org

[Aleix Pol]

On Thu, Sep 19, 2019 at 1:09 PM Ben Cooksley  wrote:
>
> On Thu, Sep 19, 2019 at 12:55 PM Aleix Pol  wrote:
> >
> > On Thu, Sep 19, 2019 at 4:34 AM Ben Cooksley  wrote:
> > >
> > > On Thu, Sep 19, 2019 at 2:50 AM Aleix Pol  wrote:
> > > >
> > > > On Sun, Sep 15, 2019 at 8:58 PM Ben Cooksley  wrote:
> > > > >
> > > > > Good evening all,
> > > > >
> > > > > Currently we're in the situation where the software we use to run
> > > > > notes.kde.org is both difficult to maintain, as well as support (for
> > > > > things like document confidentiality for various groups within KDE).
> > > > >
> > > > > We'd therefore like to retire the service, replacing it with the
> > > > > Realtime Text Editor within Nextcloud (share.kde.org). Internally this
> > > > > editor uses Markdown.
> > > > >
> > > > > You can find a demo of this at https://share.kde.org/s/gtFcRmwetRKqTZJ
> > > > > (no login required)
> > > > >
> > > > > It would be appreciated if everyone could please test the realtime
> > > > > text editor and let us know if they encounter any issues.
> > > > >
> > > > > In terms of feature differences, we are aware that
> > > > > highlighting/authorship information won't be retained by the new
> > > > > editor, and there can occasionally be problems when editing the same
> > > > > line with someone else simultaneously.
> > > > >
> > > > > If everyone is okay with this we'd like to go ahead with shutting down
> > > > > notes.kde.org as soon as possible.
> > > > >
> > > > > Thanks,
> > > > > Ben Cooksley
> > > > > KDE Sysadmin
> > > >
> > > > Hi,
> > > > Is the new editor already usable on share.kde.org? If I create a text
> > > > file I get a different thing than your demo.
> > >
> > > It should be yes. Did you create a new document or a new text document?
> > >
> > > This new editor only works with text documents (slightly confusingly)
> > > as the document editor is a version of LibreOffice Online (for more
> > > fully featured documents)
> > >
> > > >
> > > > Aleix
> > >
> > > Cheers,
> > > Ben
> >
> > It was a new text document, AFAIR. This is what it looks like:
> > https://i.imgur.com/6RhmNLK.png
>
> Ah, that is the same editor, just in logged in mode.
>
> If you were to create a publicly accessible link, and use that to
> access the document then you'd get a view that looks exactly like the
> one I created.
> In the logged in version you get the ability to see things like prior
> versions (accessible through the sidebar, which you can open by
> clicking the icon in the top right)
>
> If you're missing any controls then you may need to perform a force
> refresh (Ctrl + F5).
>
> >
> > Aleix
>
> Cheers,
> Ben

Ah, okay, cool, thanks!

BTW, it will be really handy to be able to have publicly editable
texts, this had been a problem for me in the past (that people needed
to be in identity.kde.org).

Aleix

Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?

[Aleix Pol]

On Sun, Oct 13, 2019 at 10:57 PM Albert Astals Cid  wrote:
>
> I find the merge behavior to be not what we've been doing in phabricator so 
> given the idea is to maintain our workflows i'd appreciate if we can agree on 
> continue doing the same.
>
> https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html

+1

This is the enterprise version though, does this apply to the community?

Adding sysadmin as CC, since they're the ones who will have to put it
to work in the end.

Aleix

Re: New Gesture Implementation

[Aleix Pol]

Hi Leonardo,
Reaching out to the Plasma developers mailing list, since it's where I
guess this would be developed.

Providing more details into how this could be included in Plasma would
be useful to decide how your project would integrate.

Aleix

On Thu, Nov 28, 2019 at 9:24 AM Leonardo Pennino
 wrote:
>
> Hi,
> I'm a student of Computer Science at Politecnico of Turin, I am making a 
> gesture recognition (for touchpad) software that gets events through "evdev" 
> and is able to correctly recognize following gestures:
>
> 2 Fingers pinch in and out
> 3 fingers swipe and pinch
> 4 fingers swipe and pinch
>
> My custom implementation provides informations about the distance travelled, 
> the delta time and other useful information to implement gestures for an 
> amazing experience like in Mac Os or Windows. The application is supposed to 
> support every touchpad capable of handling 4 fingers thanks to its 
> customization of threshold. I would like to have this implemented in KDE 
> environment. I am the only one working at this project but I can implement 
> this by myself and show the results.
> Hope to hear from you soon, thanks for your time.

Re: I need help fixing krita's flatpak build on binary factory

[Aleix Pol]

On Wed, Dec 4, 2019 at 9:00 AM Ben Cooksley  wrote:
>
> On Wed, Dec 4, 2019 at 3:12 AM Boudewijn Rempt  wrote:
> >
> > Krita's flatpak nightly and nightly stable builds are broken, and I don't 
> > know why. It's almost as if flatpak-builder tries to parse the yaml file as 
> > json:
> >
> > [2019-12-02T22:37:51.554Z] + flatpak-builder --force-clean 
> > --delete-build-dirs --arch=x86_64 --ccache --sandbox --user 
> > --install-deps-from=flathub --repo=/home/packaging/staging-repo/ 
> > --subject=Built on Mon Dec  2 23:37:51 CET 2019 app 
> > /home/packaging/jenkins/workspace/Krita_nightly_flatpak/packaging/linux/flatpak/org.kde.krita-nightly.yaml
> > [2019-12-02T22:37:51.554Z] Can't parse 
> > '/home/packaging/jenkins/workspace/Krita_nightly_flatpak/packaging/linux/flatpak/org.kde.krita-nightly.yaml':
> >  :1:6: Parse error: unexpected identifier `app-id', expected value
> >
> > Was there a recent change that disabled support for yaml files and should 
> > those be rewritten as json files?
>
> November 16 would roughly line up with when we changed the way the
> builders work, so it's possible that the version of flatpak-builder in
> use was changed at that time.
>
> Looking in that folder, I do see a .json format version which is 3
> months out of date.
> Maybe removing it will help?

Hi Ben,
It's quite weird, I looked into it few days ago and it built properly
on my system. It feels to me like flatpak-builder would be using the
json parser to do yaml?

Anyhow, maybe it could make sense updating the flatpak-builder version
on these systems? It's even possible to run a flatpak version of
flatpak-builder. I can help with that I just am not sure where to look
at.

Aleix

Re: Does KDE need a metronome?

[Aleix Pol]

Maybe it's something that could also make sense for Plasma Mobile, not
just Android.

Is it using Kirigami right now?
Aleix

On Mon, Feb 10, 2020 at 6:27 PM Kåre Särs  wrote:
>
> Forwarding to the android list as the application seems to be on android
> already.
>
> /Kåre
> --  Forwarded Message  --
>
> Subject: Does KDE need a metronome?
> Date: fredag 7 februari 2020, kl. 12:27:58 EET
> From: Tomasz Bojczuk 
> To: kde-devel@kde.org
>
> Halo,
>
> Recently I couldn't find metronome app that "sounds" good and doesn't
> attack user with adds,
> so I can easily offer it for my pupils and students (I'm a guitar teacher)
> Then I made it my own:
>
> https://www.opencode.net/seelook/Metronomek
>
> So I would like to ask will it find a place in KDE applications portfolio?
> And if so, I would like to ask for incubating process.
>
> It is already working, but there are a few features I would like to add to
> make it unique and justify yet another metronome in the world.
> So far it depends on sole Qt/QML  (and uses QAudio for output).
> I imported code to opencode which looks more compliant with KDE Manifesto
> than sourceforge, but here are some pictures and Android apk.
> https://sourceforge.net/projects/metronomek/
>
> Also in my language (Polish) 'little metronome' can be 'Metronomek', so I
> believe it fits well to KDE apps 'namespace'.
>
> I don't have developer team, but there is not so much to do. Anyway I would
> be happy if someone will join even for a while. But my students will be
> happy to test it.
>
> A few years ago I sent a few patches to dolphin-plugins project, so I
> believe my developer account is still active.
>
> Probably I have a few more questions about KDE infra but let see what do
> You say.
>
> With respects,
> Tomasz Bojczuk
>
> -
>
>

Re: Does KDE have a Secret Service Implementation?

[Aleix Pol]

Hi Jacky,
Maybe you'd like to use KAccounts/libaccounts/signond for that? It's
what we use in several places for managing shared OAuth tokens.

Aleix

On Thu, Feb 20, 2020 at 9:34 PM Jacky Alcine  wrote:
>
> I'm working on a social media client for KDE [1] and I want to store secrets
> for this application "the right way". It deals with OAuth access tokens. I
> figure putting that into the secret service[2] was the right way but I get the
> following error[3].
>
> If Secret Service isn't the way and something else is recommended (like
> QtKeychain or signond), I'd love to know.
>
> [1]: https://invent.kde.org/jalcine/activitydesk/
> [2]: https://specifications.freedesktop.org/secret-service/latest/
> [3]: https://invent.kde.org/jalcine/activitydesk/issues/3
> --
> Bet,
> *Jacky Alcine*
>
>
>

Re: Question about discover sortByRelevancy

[Aleix Pol]

On Thu, Apr 9, 2020 at 2:49 PM S. Champailler  wrote:
>
> Hello m-l, Nate,
>
> First thanks for the answer, it gives much needed information.
>
> I investigated the code further. What Nate says seems
> to be right. Discover uses a KNewStuff backend, which
> in turn uses Attica.
>
> Now, the thing is, the sorting order is passed from KNewStuff
> to Attica. As Attica ends up (REST) calling a provider (if I
> got that well), the sort is done by that provider...
>
> So, although we're interested in the sort order which is
> visible in Discover, the sort is actually done in the
> providers, far away from Discover.
>
> Now, since Discover aggregates results from several providers,
> I'd say that the responsibility for the sort order must be in
> Discover since it has to sort and to prioritize the results
> from the various provider (that is, it's Discover which has
> to decide what package/theme/newstuff/... is most relevant
> to the user who started the search).
>
> But still the "relevancy" aspect of it stays beyond my
> understanding. How is that defined ?
>
> Does this make sense ?
>
> I ask that for two reasons :
>
> 1/ it's an indirect way to validate I understand the way
>Discover works
> 2/ I make sure I won't change things that will lead to
>architectural dead ends... (I love to give some time
>to KDE, but that time is not exactly plenty :-) )
>
> Thanks !
>
> Stéphane
>
>
>
> > Le 8 avril 2020 à 18:07, Nate Graham  a écrit :
> >
> >
> > See https://bugs.kde.org/show_bug.cgi?id=407588. This was supposed to
> > have been fixed in AppStream itself, at least for apps. And I can
> > confirm the fix with the latest version of APpStream--again, at least
> > for apps.
> >
> > However I can see that the problem is still present for non-apps, such
> > as the "Titanium" GTK2 theme, where I can reproduce the issue, as you
> > indicate. Looks like the sorting may need to be adjusted in the KNS
> > backend specifically, or elsein the KNewStuff framework itself.
> >
> > Nate
> >
> >
> >
> > On 4/8/20 3:10 AM, S. Champailler wrote:
> > > Hello Aleix, hello KDE dev's, 
> > >
> > > I wanted to modify Discover a bit. Here's the thing :
> > >
> > > In KDE Neon, I run Discover. I search for a package named "Titanium".
> > > The result list has Titanium and some other packages in it (which is
> > > fine). However, the first item in that list is not named Titanium at all
> > > (I guess it's a match based, say, on the description).
> > >
> > > I'd like to modify the sort order so that if a package has an exact name
> > > match, then it appears on top of the search results.
> > >
> > > I've already looked at the code (and built it !)) and seen that the
> > > current sort is determined by the m_sortByRelevancy boolean. It seems to
> > > me that when that boolean is True, then no specific sort happens; not
> > > 100% sure.
> > >
> > > Before going any further, I'd like to make sure my idea doesn't
> > > contradict some of the initial design of Discover. So, does it ?
> > >
> > > Best regards,
> > >
> > > Stéphane
> >

Hi,
Yes, your assessment makes sense. It could make sense to better sort
the different feeds as we receive them. We do get sorted feeds that at
the moment we're merging naively.

One thing to check first of all is to make sure that the exact
resource you're fetching is already being provided first at its own
feed. If that's not the case this would be something to address first.

If it's first but gets buried down, we should look into it, I'd
happily help you there.

Cheers!
Aleix

Re: Question about discover sortByRelevancy

[Aleix Pol]

On Fri, Apr 10, 2020 at 8:59 AM S. Champailler  wrote:
>
> Thx for your answer. But I'm afradi I don't fully understand it.
>
> > We do get sorted feeds that at
> > the moment we're merging naively.
>
> Ok, that's the I way I understand the problem as well.
>
> > One thing to check first of all is to make sure that the exact
> > resource you're fetching is already being provided first at its own
> > feed.
>
> Let's have an example. Imagine we have 3 feeds : A,B,C.
> In each of these, we have 3 resources : a1, a2, a3; b1,b2,b3; c1,c2,c3. They 
> have names and descriptions (separated by a dash; a star indicates when the 
> titanium word is present):
>
> a1* = TitaddOns - An extension to Titanium
> a2* = The titanium engine - lorem ipsum ...
> a3 = plasma - lorem ipsum ...
> b1 = konqueror - lorem ipsum ...
> b2 = mozilla - lorem ipsum ...
> b3 = dillo - lorem ipsum ...
> c1* = titanium - lorem ipsum ...
> c2* = titanium italics - not to confuse with titanium
> c3* = titanium black - lorem ipsum ...
>
> The search string in Discover is : "titanium". I assume it's a single word.
>
> I assume the content providers will return : a1, c1, c2, a2, c3 (in no 
> particular order; for example a content provider might not sort, may take 
> long to answer, etc). Basically, what happened in this step is just a 
> filtering, no sorting. I assume that filtering is based on the presence of 
> the search term in the name of the resource, or in its description. The 
> filtering is done at the provider level because if it wasn't, then we'd have 
> to ask the complete list of resources of each content providers which could 
> potentially be a lot.
>
> Now that the filtering as occurred, we can sort by relevancy. That sort is 
> done entirely in Discover because "relevancy" makes sense only in the UI of 
> discover.
>
> I define a relevancy score :
> - 1 = The search term is the only term in the name
> - 2 = The search term is present in the name
> - 3 = The search term is present in the description
>
> With that in mind, I sort by descending scores and, if scores are equal, I 
> sort alphabetically on names :
>
> c1* = titanium - lorem ipsum ...
> a2* = The titanium engine - lorem ipsum ...
> a1* = TitaddOns - An extension to Titanium
> c3* = titanium black - lorem ipsum ...
> c2* = titanium italics - not to confuse with titanium
>
> All the information needed to do that sort is available in Discover itself.
> Now, it's perfectly clear that scores don't answer all the questions. Having 
> said that, I get back at your comment :
>
> > One thing to check first of all is to make sure that the exact
> > resource you're fetching is already being provided first at its own
> > feed.
>
> I don't understand :
>
> - Do you mean that, when the relevancy ordering doesn't discriminate enough, 
> we should preserve the order of the contents provider ? c1, a2, a1, c2, c3 ?
>
> - do you mean that we should leave the search results grouped by feed and 
> just sort the feeds separately : c1,c2,c3,a2,a1 ?
>
> or even something else ?
>
> Again, my point is that discover does the sort, totally irrelevant of how the 
> content providers order their stuff...
> In that case, I'd look in the ResourcesProxyModel of Discover and order 
> things there (with something like the lessThan method).

We don't know how the servers are sorting things, but there it is
where it has the most information, so we should trust it. Which is
part of why it's not trivial to implement this.

Also you need to take into account that some feeds (e.g. KNS) are
paginated and will need to be triggered to fetch further at some
point.

So for example if we're sorting alphabetically descending, it needs to
be at least coordinated between server and client. Otherwise we'll be
getting A-D and sorting it D-A but when we fetch further we'll be
getting resources that should be moved to the top.

Aleix

Re: Update on Status of Gitlab Migration

[Aleix Pol]

On Mon, Apr 13, 2020 at 8:30 PM Ben Cooksley  wrote:
>
> On Tue, Apr 14, 2020 at 3:35 AM Nate Graham  wrote:
> >
> > On 4/13/20 4:44 AM, Albert Vaca Cintora wrote:
> > > Regarding this: is the subdomain going to stay invent.kde.org once we
> > > have officially moved? I find it's a bit confusing to use that instead
> > > of gitlab.kde.org
> >
> > I agree. gitlab.kde.org would make more sense to me, mirroring
> > phabricator.kde.org.
> >
>
> There is no intention to change the name from invent.kde.org.
>
> We have a long precedent of not using the name of the software for the
> name in DNS, and Gitlab is continuing with this, for example:
> - bugs.kde.org is run by Bugzilla
> - dot.kde.org is run by Drupal
> - techbase.kde.org is run by Mediawiki
> - conf.kde.org is run by Frab
> - reimbursements.kde.org is run by travel-support-program
> - websvn.kde.org is run by ViewVC
> - build.kde.org and binary-factory.kde.org are both run by Jenkins
> - stats.kde.org is run by Matomo (formerly Piwik)
> - survey.kde.org is run by Limesurvey
>
> For essentially all of the above, calling it after the software
> running it makes no sense, and given that in some cases we have
> multiple instances would have made things more confusing
> (jenkins1.kde.org and jenkins2.kde.org anyone?)
>
> Phabricator and Reviewboard were the only ones to not follow this
> rule, and that was an error on our part.
>
> Given that there is a popular instance at Gitlab.com, referring to
> ours as "KDE Invent" is more likely to ensure newcomers are not
> confused (as they may not be aware that you can setup an instance of
> Gitlab on your own systems)
>
> Regards,
> Ben

We also use git.kde.org and svn.kde.org.

It would too mimic what others are doing at gitlab.gnome.org and
gitlab.freedesktop.org. So at the very least we'll want a redirect.

Aleix

Re: Information regarding upcoming Gitlab Migration

[Aleix Pol]

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

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

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

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

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

Aleix

Re: Information regarding upcoming Gitlab Migration

[Aleix Pol]

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

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

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

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

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

Aleix

Re: Information regarding upcoming Gitlab Migration: clarifications

[Aleix Pol]

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

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

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

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

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

Thanks! :)

Re: Information regarding upcoming Gitlab Migration: clarifications

[Aleix Pol]

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

I do too

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

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

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

Aleix

Re: Information regarding upcoming Gitlab Migration: clarifications

[Aleix Pol]

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

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

We'll appreciate simpler bureaucracy.

Aleix

Re: Getting involved in SoK

[Aleix Pol]

On Thu, Nov 5, 2020 at 9:36 PM Mariam Fahmy  wrote:
>
> Hello,
> I am Mariam, I am studying computer engineering, I am beginner and I want to 
> get involved in the open source community, I have good knowledge in c++, OOP, 
> data structure and algorithms.
> I have read all projects provided by SoK, I am interested in Plasma discover 
> rpm-ostree backend, what contributions shall I start related to this project 
> to fully understand it and get familiar with it?
> Any advice will be very helpful.
> Thanks in advance

Hi Mariam,
Glad you are interested in this project, I'm one of the people who put
the idea forward.

I'd say a good first step would be to install the project locally and
tinker with it a bit:
https://invent.kde.org/plasma/discover/

You can also read up on how discover backends work within the codebase.
This would be a good starting point:
https://invent.kde.org/plasma/discover/-/blob/master/libdiscover/resources/AbstractResourcesBackend.h

For any further questions don't hesitate to ask directly.
Aleix

Re: Getting involved in SoK

[Aleix Pol]

On Fri, Nov 6, 2020 at 7:37 PM Mariam Fahmy  wrote:
>
> Hello,
> Thanks alot for your advice.
> I have installed the project locally and I start discovering how backends 
> work with codebase.
> I have understood but I am missing things.
> After doing some research and gathering information, here's what I can't 
> clearly understand: (Sorry if questions are little bit silly)

Hi Mariam,
No need to worry, feel free to ask away.

> 1- what does it mean by resource?
> When I searched about it, I found that resources may be data required by user 
> or requests from clients, is it right ?

You can see here the class that defines a resource, should help you
see what it represents:
https://invent.kde.org/plasma/discover/-/blob/master/libdiscover/resources/AbstractResource.h

In general, it's an asset: be it an application, a wallpaper or
anything that can be listed and installed.

> 2- to create a new resources backend we need to implement two classes,
> The first class is the basic class which saves all created resources and 
> install & remove application or cancel transactions.
> The second class, I didn't understand it's functionality, I found that it is 
> related to plugins but didn't understand it.

The second important one is the resource I just mentioned above.
Please explain a bit more what you don't understand.

> 3-Filters in the base class: its target to filter the new requested resources?

filters we just use when searching, to see what's being searched.
In the case of this project it shouldn't be very important, since we
will just be listing a system image.

> 4- for each new resource backend, it should include all the methods of base 
> class, right?
> As these methods acts as properties for each new resource.

You need to implement all the abstract (i.e. virtual = 0) methods. The
rest of virtuals you can override if you want to give it a different
functionality.

> 5- I have searched about plugins, but I didn't fully understand it,  plugins 
> enable programmers to update host program while keeping the user within the 
> program's environment, but I can't understand what is the role of plugins 
> here if we receive new requests and make new resources?
> It is meant that while creating a new resource, we need plugin in order to 
> keep the user with the program's environment without altering it or affecting 
> it while creating new resources?

It's just a way to build the applications so the whole project doesn't
depend on a specific technology. You can see the ones we implement
right now here:
https://invent.kde.org/plasma/discover/-/tree/master/libdiscover/backends

This project should be adding a new OSTreeRPMBackend folder in here
that will only take care of this one implementation.

I hope this helps,
Aleix

Re: Getting involved in SoK

[Aleix Pol]

On Sun, Nov 15, 2020 at 10:42 AM Mariam Fahmy  wrote:
>
> Hello,
> Thanks alot for helping me.
> I have basically understand what you have provided me, what next step shall I 
> do to start in this project?
> Thanks in advance.
>
> On Mon, 9 Nov 2020, 3:40 pm Aleix Pol,  wrote:
>>
>> On Fri, Nov 6, 2020 at 7:37 PM Mariam Fahmy  wrote:
>> >
>> > Hello,
>> > Thanks alot for your advice.
>> > I have installed the project locally and I start discovering how backends 
>> > work with codebase.
>> > I have understood but I am missing things.
>> > After doing some research and gathering information, here's what I can't 
>> > clearly understand: (Sorry if questions are little bit silly)
>>
>> Hi Mariam,
>> No need to worry, feel free to ask away.
>>
>> > 1- what does it mean by resource?
>> > When I searched about it, I found that resources may be data required by 
>> > user or requests from clients, is it right ?
>>
>> You can see here the class that defines a resource, should help you
>> see what it represents:
>> https://invent.kde.org/plasma/discover/-/blob/master/libdiscover/resources/AbstractResource.h
>>
>> In general, it's an asset: be it an application, a wallpaper or
>> anything that can be listed and installed.
>>
>> > 2- to create a new resources backend we need to implement two classes,
>> > The first class is the basic class which saves all created resources and 
>> > install & remove application or cancel transactions.
>> > The second class, I didn't understand it's functionality, I found that it 
>> > is related to plugins but didn't understand it.
>>
>> The second important one is the resource I just mentioned above.
>> Please explain a bit more what you don't understand.
>>
>> > 3-Filters in the base class: its target to filter the new requested 
>> > resources?
>>
>> filters we just use when searching, to see what's being searched.
>> In the case of this project it shouldn't be very important, since we
>> will just be listing a system image.
>>
>> > 4- for each new resource backend, it should include all the methods of 
>> > base class, right?
>> > As these methods acts as properties for each new resource.
>>
>> You need to implement all the abstract (i.e. virtual = 0) methods. The
>> rest of virtuals you can override if you want to give it a different
>> functionality.
>>
>> > 5- I have searched about plugins, but I didn't fully understand it,  
>> > plugins enable programmers to update host program while keeping the user 
>> > within the program's environment, but I can't understand what is the role 
>> > of plugins here if we receive new requests and make new resources?
>> > It is meant that while creating a new resource, we need plugin in order to 
>> > keep the user with the program's environment without altering it or 
>> > affecting it while creating new resources?
>>
>> It's just a way to build the applications so the whole project doesn't
>> depend on a specific technology. You can see the ones we implement
>> right now here:
>> https://invent.kde.org/plasma/discover/-/tree/master/libdiscover/backends
>>
>> This project should be adding a new OSTreeRPMBackend folder in here
>> that will only take care of this one implementation.
>>
>> I hope this helps,
>> Aleix

Adding the mentors list to know what the exact process for students is.

Mariam, in the meantime, if you want to start working on it or want to
have some kind of call to get started, tell me and I'll see to it.

Aleix

Re: Getting involved in SoK

[Aleix Pol]

Including Timothée who will be co-mentoring the project. :)

Aleix

On Wed, Nov 18, 2020 at 5:03 AM Aleix Pol  wrote:
>
> On Sun, Nov 15, 2020 at 10:42 AM Mariam Fahmy  wrote:
> >
> > Hello,
> > Thanks alot for helping me.
> > I have basically understand what you have provided me, what next step shall 
> > I do to start in this project?
> > Thanks in advance.
> >
> > On Mon, 9 Nov 2020, 3:40 pm Aleix Pol,  wrote:
> >>
> >> On Fri, Nov 6, 2020 at 7:37 PM Mariam Fahmy  
> >> wrote:
> >> >
> >> > Hello,
> >> > Thanks alot for your advice.
> >> > I have installed the project locally and I start discovering how 
> >> > backends work with codebase.
> >> > I have understood but I am missing things.
> >> > After doing some research and gathering information, here's what I can't 
> >> > clearly understand: (Sorry if questions are little bit silly)
> >>
> >> Hi Mariam,
> >> No need to worry, feel free to ask away.
> >>
> >> > 1- what does it mean by resource?
> >> > When I searched about it, I found that resources may be data required by 
> >> > user or requests from clients, is it right ?
> >>
> >> You can see here the class that defines a resource, should help you
> >> see what it represents:
> >> https://invent.kde.org/plasma/discover/-/blob/master/libdiscover/resources/AbstractResource.h
> >>
> >> In general, it's an asset: be it an application, a wallpaper or
> >> anything that can be listed and installed.
> >>
> >> > 2- to create a new resources backend we need to implement two classes,
> >> > The first class is the basic class which saves all created resources and 
> >> > install & remove application or cancel transactions.
> >> > The second class, I didn't understand it's functionality, I found that 
> >> > it is related to plugins but didn't understand it.
> >>
> >> The second important one is the resource I just mentioned above.
> >> Please explain a bit more what you don't understand.
> >>
> >> > 3-Filters in the base class: its target to filter the new requested 
> >> > resources?
> >>
> >> filters we just use when searching, to see what's being searched.
> >> In the case of this project it shouldn't be very important, since we
> >> will just be listing a system image.
> >>
> >> > 4- for each new resource backend, it should include all the methods of 
> >> > base class, right?
> >> > As these methods acts as properties for each new resource.
> >>
> >> You need to implement all the abstract (i.e. virtual = 0) methods. The
> >> rest of virtuals you can override if you want to give it a different
> >> functionality.
> >>
> >> > 5- I have searched about plugins, but I didn't fully understand it,  
> >> > plugins enable programmers to update host program while keeping the user 
> >> > within the program's environment, but I can't understand what is the 
> >> > role of plugins here if we receive new requests and make new resources?
> >> > It is meant that while creating a new resource, we need plugin in order 
> >> > to keep the user with the program's environment without altering it or 
> >> > affecting it while creating new resources?
> >>
> >> It's just a way to build the applications so the whole project doesn't
> >> depend on a specific technology. You can see the ones we implement
> >> right now here:
> >> https://invent.kde.org/plasma/discover/-/tree/master/libdiscover/backends
> >>
> >> This project should be adding a new OSTreeRPMBackend folder in here
> >> that will only take care of this one implementation.
> >>
> >> I hope this helps,
> >> Aleix
>
> Adding the mentors list to know what the exact process for students is.
>
> Mariam, in the meantime, if you want to start working on it or want to
> have some kind of call to get started, tell me and I'll see to it.
>
> Aleix

Re: Synchronized release schedule for Plasma

[Aleix Pol]

On Tue, Nov 24, 2020 at 5:10 PM David Edmundson 
wrote:

> As distribution package maintainers, we would like Plasma developers to
>> slightly alter the release schedule to align releases with a more
>> distribution friendly cycle. You could consider shortening one release
>> cycle (and then keep the 6 month schedule) to align releases.
>>
>
> We have in the past shuffled things slightly to line up things up with
> distros on request, particularly LTS releases. We can certainly explore
> that on a one-off basis.
>
> >With this schedule in place, we would also benefit from more beta
> releases over a slightly longer period. They would be packaged into the
> beta and RC releases of those distributions thus enabling more pre-release
> testing.
>
> We did have 6 month release cycles in the past.
>
> The rationale for moving at the time was twofold:
>  - people rushed in changes towards the feature freeze as otherwise it
> would be aages till their changes reached users
>  - the more changes we have in a release, the more testing and inevitable
> regression fixes we need to do, spreading that out should result in things
> being more stable
>
> Initially we did every 3 months (which arguably still aligns) then it
> slowly slipped to 4.
>
> My personal impression is that releases have gotten better as a result of
> those changes, so I'm hesitant about reverting that decision.
>
>

Makes sense. With Qt being less of a moving target though, it could make
sense to reevaluate our cadence though, both because we might start looking
into the future and because the system we support should not be changing as
much.

Aleix

Re: Synchronized release schedule for Plasma

[Aleix Pol]

On Thu, Nov 26, 2020 at 10:38 PM Neal Gompa  wrote:
>
> On Thu, Nov 26, 2020 at 10:25 AM Aleix Pol  wrote:
> >
> > On Tue, Nov 24, 2020 at 5:10 PM David Edmundson 
> >  wrote:
> >>>
> >>> As distribution package maintainers, we would like Plasma developers to 
> >>> slightly alter the release schedule to align releases with a more 
> >>> distribution friendly cycle. You could consider shortening one release 
> >>> cycle (and then keep the 6 month schedule) to align releases.
> >>
> >>
> >> We have in the past shuffled things slightly to line up things up with 
> >> distros on request, particularly LTS releases. We can certainly explore 
> >> that on a one-off basis.
> >>
> >> >With this schedule in place, we would also benefit from more beta 
> >> >releases over a slightly longer period. They would be packaged into the 
> >> >beta and RC releases of those distributions thus enabling more 
> >> >pre-release testing.
> >>
> >> We did have 6 month release cycles in the past.
> >>
> >> The rationale for moving at the time was twofold:
> >>  - people rushed in changes towards the feature freeze as otherwise it 
> >> would be aages till their changes reached users
> >>  - the more changes we have in a release, the more testing and inevitable 
> >> regression fixes we need to do, spreading that out should result in things 
> >> being more stable
> >>
> >> Initially we did every 3 months (which arguably still aligns) then it 
> >> slowly slipped to 4.
> >>
> >> My personal impression is that releases have gotten better as a result of 
> >> those changes, so I'm hesitant about reverting that decision.
> >>
> >
> >
> > Makes sense. With Qt being less of a moving target though, it could make 
> > sense to reevaluate our cadence though, both because we might start looking 
> > into the future and because the system we support should not be changing as 
> > much.
> >
>
> If we don't want to move to 6 months, pulling back from 4 months to 3
> months would make it easier for us to not miss Plasma releases.
>
> That being said, with Qt6 now being a thing, wouldn't that mean Qt is
> more of a moving target again?

It will take some time to be able to put together a release that's
fully tested against Qt 6.

Aleix

Re:

[Aleix Pol]

On Sat, Dec 26, 2020 at 11:21 AM Bhumit Attarde
 wrote:
>
> Hey guys,
>
> I'm a second year engineering student interested in GSOC '21.
>
> I've gone through https://community.kde.org/GSoC/2021/Ideas and have zeroed 
> in on an app I like and know a little about (Okular). I plan to get myself 
> familiarized with it more over next few days and then try to get my hands 
> dirty after I'm comfortable.
>
> Do you guys have any suggestions over how I should proceed?

Including Okular as CC.

That said, have you tried contacting the mentor on the idea you're after?

Aleix

Re: Any Developer available for Sok

[Aleix Pol]

On Sun, Jan 3, 2021 at 2:35 PM VIVEK Yadav  wrote:
>
> Hello, I am Vivek yadav a contributor in kdenlive . I would like to be a Sok 
> participant of kdenlive but current kdenlive devs are really busy with their 
> own work and can not give time to mentoring a participant. I have contributed 
> to kdenlive in past on multiple occassion. But as Sok requires a mentor and i 
> don't have one it becomes difficult for me to participate. Can anyone of the 
> kde developer mentor me for Sok. You can checkout my gitlab profile 
> https://invent.kde.org/vivekkde to see my work.
>
> Thank you

Including the kdenlive mailing list.

Aleix

Re: Plasma LeakGuard 💧

[Aleix Pol]

On Tue, Mar 16, 2021 at 3:40 PM Konstantin Kharlamov  wrote:
>
> I think the most interesting thing here is to know what plasmashell developers
> think about it. Is it perhaps possible they don't have a reproducer for memory
> leak, and you have it? In which case it seems more productive to fix the bug.
>
> Please, get in touch with plasmashell devs, I'm sure they will be glad to get
> any help in addressing that sort of issues.
>
> On Tue, 2021-03-16 at 15:34 +0100, Alberto Salvia Novella wrote:
> > The thing is that plasmashell isn't always started via its service, at least
> > this is the case on my system. I shall look into that.
> >
> > On Tue, 16 Mar 2021 at 07:41, Konstantin Kharlamov  
> > wrote:
> > > On Tue, 2021-03-16 at 01:29 +0100, Alberto Salvia Novella wrote:
> > > > I have created this tool for the Plasma desktop:
> > > > https://gitlab.com/es20490446e/plasma-leakguard
> > > >
> > > > Shall I announce it somewhere?
> > > >
> > > > (When replying please include my email address on the "to" field, as I
> > > > have
> > > > mail delivery disabled for this list)
> > >
> > > (note: I'm just a random passer-by contributor)
> > >
> > > I think you better discuss this with plasmashell developers. Clearly, 
> > > memory
> > > leaks need to be fixed instead of working them around. Although if they 
> > > deem
> > > such tool as you suggest necessary, to me it seems easier to implement by
> > > creating a plasmashell user-level service with `MemoryMax=` variable set 
> > > and
> > > being restartable (or, in case they wouldn't want to depend on systemd, I
> > > imagine it should be available with bare cgroups too).
> > >

I don't think this will ever be part of the solution. I've never seen
this problem myself, but in the end we just need to remove leaks
rather than just restarting plasma. I guess this is probably useful
for the original developer, so good for him.

Note this app will make you lose whatever you're doing with the shell
at the time of the restart.

The fact that there's this file in the project, makes me question the
intent of the project altogether:
https://gitlab.com/es20490446e/plasma-leakguard/-/blob/master/info/jokes.md

Aleix

Re: KGlobalAccel on non-Plasma systems

[Aleix Pol]

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

Hi Nico,
It makes a lot of sense.

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

So in general, yes. +1

Aleix

Re: Introducing Haruna

[Aleix Pol]

On Thu, May 6, 2021 at 1:29 PM Jonathan Riddell  wrote:
>
> Just passed the Incubator process is Haruna, a video player.  It uses a bunch 
> of KDE libraries so is a natural fit to move into KDE.
>
> https://invent.kde.org/multimedia/haruna
>
> The project is run by George Florea Bănuș.

Cool! :) welcome George!

Aleix

Re: KDiff Bug 436958

[Aleix Pol]

On Thu, May 13, 2021 at 1:00 AM Michael Reeves  wrote:
>
> Could someone other than myself please have a look at this.
>
> https://bugs.kde.org/show_bug.cgi?id=436958
>
> None of these issues affect my system. I strongly suspect a distro
> specific issue. https://bugs.gentoo.org/show_bug.cgi?id=789330. The
> offending commit makes no sense as a true root cause. I would like an
> answer as to what is going on.

Hi,
I just tried opening it and I get this crash:

#5 0x7f088cf54ef5 in raise () from /usr/lib/libc.so.6
#6 0x7f088cf3e862 in abort () from /usr/lib/libc.so.6
#7 0x7f088d4dfc51 in qt_message_fatal (message=..., context=...) at
/home/apol/devel/frameworks/qt5/qtbase/src/corelib/global/qlogging.cpp:1914
#8 QMessageLogger::fatal (this=this@entry=0x7ffef2f4b378,
msg=msg@entry=0x7f088d7ddea0 "ASSERT: \"%s\" in file %s, line %d") at
/home/apol/devel/frameworks/qt5/qtbase/src/corelib/global/qlogging.cpp:893
#9 0x7f088d4df04a in qt_assert (assertion=,
file=, line=) at
/home/apol/devel/frameworks/qt5/qtbase/src/corelib/global/qglobal.cpp:3358
#10 0x55590227c7bb in SourceData::readAndPreprocess
(this=0x555903298590, pEncoding=0x555903144ab0,
bAutoDetectUnicode=true) at
/home/apol/devel/frameworks/kdiff3/src/SourceData.cpp:351
#11 0x5559021a6d5d in KDiff3App::mainInit (this=0x555903379bf0,
pTotalDiffStatus=0x55590334ae70, inFlags=...) at
/home/apol/devel/frameworks/kdiff3/src/pdiff.cpp:144
#12 0x5559021afecb in KDiff3App::slotFileOpen
(this=0x555903379bf0) at
/home/apol/devel/frameworks/kdiff3/src/pdiff.cpp:938
#13 0x55590215b154 in KDiff3App::completeInit
(this=0x555903379bf0, fn1=..., fn2=..., fn3=...) at
/home/apol/devel/frameworks/kdiff3/src/kdiff3.cpp:519
#14 0x55590214c2db in KDiff3Shell::KDiff3Shell
(this=0x5559031d7400, bCompleteInit=true) at
/home/apol/devel/frameworks/kdiff3/src/kdiff3_shell.cpp:60
#15 0x555902148223 in main (argc=1, argv=0x7ffef2f4d108) at
/home/apol/devel/frameworks/kdiff3/src/main.cpp:188

KDE is all about the apps goal

[Aleix Pol]

Hi everyone,
As you might have seen in Adam's blog post [1], I'm planning on going
through a set of topics. Before diving into it all, I feel it could be
useful to have a call together before Akademy and see what this
process will look like and which ways we can make it so the creators
in our community get the most of it.
https://szopa.org.pl/kde/2021/05/23/KDE-Goals-May-2021.html

If you'd like to be part of it, please add yourself into this poll so
we can find the correct time to meet.
https://framadate.org/DcTRSqyekJGUQ1pZ

If you feel like you prefer discussing the actual topics rather than
the coordination, make sure to join our matrix channel
https://matrix.to/#/!yvNlQHUtUfWrfcFTUU:kde.org?via=kde.org&via=matrix.org

Aleix

Re: KDE is all about the apps goal

[Aleix Pol]

On Tue, Jun 1, 2021 at 2:39 AM Aleix Pol  wrote:
>
> Hi everyone,
> As you might have seen in Adam's blog post [1], I'm planning on going
> through a set of topics. Before diving into it all, I feel it could be
> useful to have a call together before Akademy and see what this
> process will look like and which ways we can make it so the creators
> in our community get the most of it.
> https://szopa.org.pl/kde/2021/05/23/KDE-Goals-May-2021.html
>
> If you'd like to be part of it, please add yourself into this poll so
> we can find the correct time to meet.
> https://framadate.org/DcTRSqyekJGUQ1pZ
>
> If you feel like you prefer discussing the actual topics rather than
> the coordination, make sure to join our matrix channel
> https://matrix.to/#/!yvNlQHUtUfWrfcFTUU:kde.org?via=kde.org&via=matrix.org

Hi everyone,
Let's meet then next Monday at 18h UTC, here.
https://meet.kde.org/b/ale-cgt-bbb

Looking forward to it!
Aleix

Re: Project Submission

[Aleix Pol]

Hi Farkas,
Looking good! Including the Plasma mailing list as it seems mostly
related to the shell.
Also I'd suggest you talk to the KDE Visual Design Group, they may be
interested in working with you on it.

Cheers!
Aleix

On Fri, Sep 17, 2021 at 11:18 AM Farkas Máté  wrote:
>
> Dear KDE Team,
>
> hereby I would like to submit a project I have been working on in the last 
> months with the aim of incubating it within the KDE project, as I believe it 
> could contribute to the user experience on touch-capable devices (such as 
> Microsoft Surface-like hybrid laptops, tablet users, Wacom-tablet users, 
> etc.).
>
> It is an application launcher aiming for ease of use on the above mentioned 
> devices. I believe Kicker is a simple and powerful launcher, but it still 
> uses a classical old-style approach (i.e. 
> menu-submenu-sub-submenu-navigation) to help the user to find the app he/she 
> wants to launch. Using a pen or an equivalent device, this procedure (with 
> misclicks and spending time looking for the right category, subcategory, 
> etc.) could unnecessarily worsen the user experience, which motivated me to 
> implement a launcher similar to those seen on smart devices and other modern 
> desktop operating systems.
>
> The launcher (which I have named Rocket) places the user's applications in a 
> grid and allows him/her to categorize them by making folders. It supports 
> searching, so opening the launcher with a shortcut and typing the desired 
> program's name into the already focused search field already yields results 
> to keep a fluent workflow for keyboard-oriented power-users too. It aims to 
> be customizable and uses the KF5 framework to communicate with the 
> environment.
>
> Having reached an inflection point in the project (where all the features I 
> need have already been implemented with some bugs and inconsistencies still 
> being present), I am asking you whether you have any interest in 
> incorporating it in Plasma. If you have, I would be more than happy to 
> continue the development while focusing on the needs of other users and 
> improving on the codebase; if not, I would continue only improving things for 
> myself only. In case of interest, I am also ready to comply with the 
> standards required by the community.
>
> Things which need care include improving the customizability options, fixing 
> some graphical glitches, improving support for multi-touch input (including 
> double-finger trackpad scrolling which I – due to my hardware restrictions – 
> did not manage to implement as flawlessly as desired) and some "complex usage 
> cases" (i.e. cases where the user does a lot of things while dragging and 
> dropping an application icon). I would like to emphasize that none of these 
> things are of the kind which heavily restrict everyday use, but they still 
> force the user to make some compromises (and thus make Rocket less 
> "market-ready"); it is thus beyond the prototype/designing phase. I am also 
> sending you a video regarding the current state of development attached. 
> Regarding the future of the project, I have been thinking about adding 
> support for plasmoids (such that the user is allowed to add widgets to the 
> menu) and to allow the user to use KRunner as a backend search tool.
>
> Some months ago I posted a small video on a more primitive version of Rocket 
> in the official KDE Reddit-channel [1], which was also well-received (despite 
> not having as many customization options and not being able to create folders 
> yet). Also, the KDE store provides some less-powerful alternatives with a 
> non-negligible user base [2]. I also believe you have to know that I am not a 
> professional developer, which can be easily seen by looking into the code 
> [3]. With some help from fellow developers however, I think I can quickly 
> improve on my programming skills (which I am also happy to do).
>
> If you have any further questions, please do not hesitate to ask me. You can 
> reach me in English, German, French or in Hungarian, if the people in charge 
> or the community prefer it differently.
>
> Thank you for your consideration,
> Yours faithfully,
> Mate Farkas
>
> -
> [1]: 
> https://www.reddit.com/r/kde/comments/mq408q/i_have_developed_an_application_launcher_for_kde/
> [2]: https://store.kde.org/p/1364064/
> [3]: https://github.com/friciwolf/Rocket
> Please make sure to create the folder ~/.config/rocket if you compile the 
> code yourself (using qmake and make or Qt Designer), as this folder is 
> necessary for Rocket to launch – another small thing to be fixed for the 
> general audience. Also, please turn on the blurring effect in the system 
> settings for it to take effect (an option using the system wallpaper as 
> background is also possible, albeit yet only by recompiling the code 
> manually).

Re: Tiny news project

[Aleix Pol]

Hola Aleix!
Thanks for reaching out.

Have you looked at Alligator?
https://invent.kde.org/plasma-mobile/alligator

It seems they're fairly similar and maybe there's things they can
share and benefit from each other?
In any case you can submit the repository into invent.kde.org under
your username, if you want to commit into releasing it and keeping it
alive we can consider incubating it, but like I said, I'm sure we'd
all prefer to have a great RSS Kirigami app than 2 almost great ones.
;)

Salut!
Aleix

On Sat, Sep 18, 2021 at 1:55 PM Aleix Quintana Alsius
 wrote:
>
> Hello,
>
> My name is Aleix Quintana, I am from Terrassa(Barcelona), I work in
> communia.org (a little floss tech coop ) and i have created the app tiny
> news,  well i converted the idea from a previous(crappy) plasmoid
> (started  in 2014) which is a tiny tiny rss and pocket client made with
> kirigami.
>
> It's described in
> https://planet.communia.org/content/launching-tiny-news-ttrss-aggregator-client
> . and code can be found in https://gitlab.com/communia/tinynews/
>
> As it may be useful for others I think it can be in invent.kde.org , but
> I have doubts about how to do it. Do I need to follow the steps
> described in : https://community.kde.org/Incubator ? Or simply I can
> import the project from gitlab.com to invent.kde.org ?
>
> Thank's a lot!
>
> --
> Aleix Q. | https://planet.communia.org/blogs/kinta
> https://communia.org
>

Re: Tiny news project

[Aleix Pol]

On Tue, Sep 21, 2021 at 10:31 AM Aleix Quintana Alsius
 wrote:
>
> Gràcies per contestar Aleix!
>
> Some days ago FHEK789 ask me to contribute to Alligator too. I saw the 
> project when was coding Tiny News getting  some inspiration from it. But 
> technically they are different. Alligator is a local aggregator, with a good 
> logic when storing and obtaining the content via local storage database. Tiny 
> news is a client of a remote aggregator, it doesn't deal with any feed 
> protocol itself and delegates the backend work to others (Tiny Tiny Rss, 
> Pocket, and i hope Nextcloud News soon). In some point i thought that some a 
> connection to pim akregator would be done for those who want local aggregator 
> but i ended up discarding it, as i didn't need it, and the only use case to 
> satisfy until now was the case of myself.
>
> I also doubt if integrating it, mainly because the ones that use local 
> aggregators doesn't use remote and viceversa. So maybe keeping them separate 
> will make sense. On the other side the required frontend views are nearly 
> identical so wrapping all use cases is something that is possible without 
> traumatic changes...
>
> So contributions are welcome in tiny news project to integrate local 
> aggregator but i think that is more work than adding some minor Tiny News 
> features to excellent alligator : e.g. if it can easily integrate 
> webengineview, feeds organized in tree categories, or flagging entries 
> and keeping them as separate projects rather than make an app with features 
> that rarely will be used at same time.
>
> Anyway, maybe the decision can be postponed depending on the demand, I am 
> sure that some other cases happened when planning merge of features in other 
> kde apps. So opinions are welcome...
>
>
> Finally about the repository, as you see the project is in gitlab.com, do you 
> think that is it worth it to migrate the repo from gitlab.com to 
> invent.kde.org?
>
> Thank's i Salut!
>
>
>
>
> On 21/9/21 1:01, Aleix Pol wrote:
>
> Hola Aleix!
> Thanks for reaching out.
>
> Have you looked at Alligator?
> https://invent.kde.org/plasma-mobile/alligator
>
> It seems they're fairly similar and maybe there's things they can
> share and benefit from each other?
> In any case you can submit the repository into invent.kde.org under
> your username, if you want to commit into releasing it and keeping it
> alive we can consider incubating it, but like I said, I'm sure we'd
> all prefer to have a great RSS Kirigami app than 2 almost great ones.
> ;)
>
> Salut!
> Aleix
>
> On Sat, Sep 18, 2021 at 1:55 PM Aleix Quintana Alsius
>  wrote:
>
> Hello,
>
> My name is Aleix Quintana, I am from Terrassa(Barcelona), I work in
> communia.org (a little floss tech coop ) and i have created the app tiny
> news,  well i converted the idea from a previous(crappy) plasmoid
> (started  in 2014) which is a tiny tiny rss and pocket client made with
> kirigami.
>
> It's described in
> https://planet.communia.org/content/launching-tiny-news-ttrss-aggregator-client
> . and code can be found in https://gitlab.com/communia/tinynews/
>
> As it may be useful for others I think it can be in invent.kde.org , but
> I have doubts about how to do it. Do I need to follow the steps
> described in : https://community.kde.org/Incubator ? Or simply I can
> import the project from gitlab.com to invent.kde.org ?

Fair enough, I wasn't aware of the difference between both. I guess
being aware of it makes sense. I'm not entirely sure that it doesn't
make sense for Alligator to also support remote feed aggregation but I
personally do not know. Having them both on KDE Gear would be more
confusing than anything.

I wouldn't really push you to getting the project in invent.kde.org
right now just because. Maybe if you ever consider going through the
lifecycle, it's something we can look into?
https://community.kde.org/Policies/Application_Lifecycle

Salut! :)

Aleix

Re: Project Submission

[Aleix Pol]

Hi Farkas,
Integration is never a problem. QML is also written in C++. In fact, if
something is not possible to do with QML we generally just add it. On the
other hand it's harder to get C++ components to integrate visually without
QML/QtQuick as we use the components transparently.

Most of what you see in Plasma is QML, so if you aspire to integrate with
it, I also would recommend using the same technology. I'm not entirely sure
about what you mean with the different cases you see could be contentious
but I'm sure we'd find a way to integrate them.

You can for example look at the application dashboard plasmoid
(kickerdash), I'm sure it will help you understand how it works and
probably open the possibility to sharing code.
https://invent.kde.org/plasma/plasma-desktop/-/tree/master/applets/kicker/package/contents/ui

Aleix

On Tue, Sep 21, 2021 at 8:46 PM Farkas Máté  wrote:

> Hi Nate,
>
> Thank you for your interest. Following our brief exchange on Reddit where
> I initially announced the project, I have indeed considered rewriting
> things in QML. There are three reasons I stuck with C++ however, but I
> might have been naîve. First, in the long run I would like to allow the
> user to add plasmoids to the dashboard, eliminating the overall need for
> classical menus (as they are the only way to access the power buttons).
> With other words, I think it might be an interesting feature if the user
> could create a menu similar to those on iOS and Android devices containing
> both icons and widgets.
>
> Second, I have heard (from an unreliable source) that touchpad gestures
> are coming to Plasma. From the user's perspective, I believe it would be a
> nice touch to Rocket, if it had an appearance/disappearance animation
> synced to a pre-defined gesture (similar to what Launchpad in MacOS has). I
> am not an expert, but I thought the implementation of these features above
> would be easier in C++. Third, I also played with the idea of using KRunner
> as a backend, which is purely written in C++ as far as I know.
>
> Lastly (this does not really count as a reason), I wanted to accomplish
> something usable in a reasonable timeframe in order to play around with the
> idea a bit, and to see whether there would be any interest at all. Since
> QML still looks weird and annoyingly nonlinear to me (I initially took a
> look at Kickoff's code, and I could barely follow what was going on), I
> stayed with C++, which I am more familiar with; apart from that, I had the
> impression, that some functions in the Plasma libraries are C++-exclusive.
>
> Would you still propose going for QML given in this situation?
>
> Regards,
> Mate
>
> Le mar. 21 sept. 2021 à 18:01, Nate Graham  a écrit :
>
>> Hello Farkas,
>>
>> Have you considered making this a Plasma widget using QML? Plasma has an
>> existing infrastructure for installing, deleting, adding, and removing
>> widgets, and allowing users to see alternatives. Since this is basically
>> an alternative launcher, it would make sense for it to appear in the
>> "Alternatives" popup that shows existing installed alternative widgets.
>> We already have a full screen launcher widget ("Application Dastboard"),
>> so it's conceptually possible to do something like what you've done in
>> QML. However that widget is fairly old and un-loved, and would be a good
>> candidate for being overhauled or replaced with your launcher, if it
>> used the common technical infrastructure for widgets.
>>
>> Nate
>>
>>
>> On 9/16/21 16:09, Farkas Máté wrote:
>> > Dear KDE Team,
>> >
>> > hereby I would like to submit a project I have been working on in the
>> > last months with the aim of incubating it within the KDE project, as I
>> > believe it could contribute to the user experience on touch-capable
>> > devices (such as Microsoft Surface-like hybrid laptops, tablet users,
>> > Wacom-tablet users, etc.).
>> >
>> > It is an application launcher aiming for ease of use on the above
>> > mentioned devices. I believe Kicker is a simple and powerful launcher,
>> > but it still uses a classical old-style approach (i.e.
>> > menu-submenu-sub-submenu-navigation) to help the user to find the app
>> > he/she wants to launch. Using a pen or an equivalent device, this
>> > procedure (with misclicks and spending time looking for the right
>> > category, subcategory, etc.) could unnecessarily worsen the user
>> > experience, which motivated me to implement a launcher similar to those
>> > seen on smart devices and other modern desktop operating systems.
>> >
>> > The launcher (which I have named Rocket) places the user's applications
>> > in a grid and allows him/her to categorize them by making folders. It
>> > supports searching, so opening the launcher with a shortcut and typing
>> > the desired program's name into the already focused search field
>> already
>> > yields results to keep a fluent workflow for keyboard-oriented
>> > power-users too. It aims to be customizable and uses the KF5 framework
>> > 

Re: OCS Providers File - High Numbers of Requests

[Aleix Pol]

On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
>
> Hi all,
>
> It has recently come to our attention that the number of queries being 
> handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on a 
> day to day basis has gotten to the point where it is causing issues with 
> server responsiveness to other traffic. This is perhaps best summarised by 
> the following:
>
> root@nicoda /var/log/apache2 # ls -lah ...
> -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
>
> root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> 4,222,343
>
> Based on those numbers we're looking at 48-49 requests per second (on average 
> - peaks are much higher by many magnitudes), which seems extremely excessive 
> given that this file is only supposed to be retrieved by KDE software when 
> GHNS functionality is triggered. That is supported by the substantial size 
> difference it has over networkcheck.kde.org - which is used by plasma-nm and 
> NetworkManager (on Neon) to check for whether they have a working internet 
> connection - which i'd expect to be the site receiving the most traffic.
>
> As such, I therefore suspect we have bug(s) in software that makes use of 
> GHNS functionality.
>
> It would therefore be appreciated if we could please review the software in 
> question to determine whether it is operating correctly. Given that it 
> usually runs in the background on user systems, i'd especially appreciate it 
> if a detailed review could be conducted on Discover and other software that 
> conducts package management operations or assists in managing updates.
>
> Unfortunately all these applications submit a fairly useless user agent 
> (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further 
> information. If we could get information on the software that is originating 
> the request added to the user agent to assist in investigating these issues 
> in the future that would be extremely helpful.
>
> Thanks,
> Ben

That's correct. Discover fetches them at startup. It's necessary to be
able to check if there are updates on KNS-provided resources.

Incidentally,  I was looking into this yesterday incidentally. We
could see if caching is broken somehow. A request will still be needed
though to check if the cache is out of date.

Or we can prefer the cached version of the file for a few days and
assume they don't change that much.

I've seen some of them point at
"https://download.kde.org/ocs/providers.xml";, I don't know if this is
any better.

Aleix

Re: OCS Providers File - High Numbers of Requests

[Aleix Pol]

On Thu, Sep 23, 2021 at 1:54 PM Aleix Pol  wrote:
>
> On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
> >
> > Hi all,
> >
> > It has recently come to our attention that the number of queries being 
> > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on a 
> > day to day basis has gotten to the point where it is causing issues with 
> > server responsiveness to other traffic. This is perhaps best summarised by 
> > the following:
> >
> > root@nicoda /var/log/apache2 # ls -lah ...
> > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
> >
> > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> > 4,222,343
> >
> > Based on those numbers we're looking at 48-49 requests per second (on 
> > average - peaks are much higher by many magnitudes), which seems extremely 
> > excessive given that this file is only supposed to be retrieved by KDE 
> > software when GHNS functionality is triggered. That is supported by the 
> > substantial size difference it has over networkcheck.kde.org - which is 
> > used by plasma-nm and NetworkManager (on Neon) to check for whether they 
> > have a working internet connection - which i'd expect to be the site 
> > receiving the most traffic.
> >
> > As such, I therefore suspect we have bug(s) in software that makes use of 
> > GHNS functionality.
> >
> > It would therefore be appreciated if we could please review the software in 
> > question to determine whether it is operating correctly. Given that it 
> > usually runs in the background on user systems, i'd especially appreciate 
> > it if a detailed review could be conducted on Discover and other software 
> > that conducts package management operations or assists in managing updates.
> >
> > Unfortunately all these applications submit a fairly useless user agent 
> > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further 
> > information. If we could get information on the software that is 
> > originating the request added to the user agent to assist in investigating 
> > these issues in the future that would be extremely helpful.
> >
> > Thanks,
> > Ben
>
> That's correct. Discover fetches them at startup. It's necessary to be
> able to check if there are updates on KNS-provided resources.
>
> Incidentally,  I was looking into this yesterday incidentally. We
> could see if caching is broken somehow. A request will still be needed
> though to check if the cache is out of date.
>
> Or we can prefer the cached version of the file for a few days and
> assume they don't change that much.
>
> I've seen some of them point at
> "https://download.kde.org/ocs/providers.xml";, I don't know if this is
> any better.
>
> Aleix

https://invent.kde.org/frameworks/attica/-/merge_requests/15/
https://invent.kde.org/frameworks/knewstuff/-/merge_requests/141
https://invent.kde.org/plasma/discover/-/merge_requests/165

This should lessen the problem from Discover's side. Still that one
providers.xml request at startup remains.

Aleix

Re: OCS Providers File - High Numbers of Requests

[Aleix Pol]

On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez
 wrote:
>
> El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) 
> escribió:
> >
> > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
> > >
> > > Hi all,
> > >
> > > It has recently come to our attention that the number of queries being 
> > > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on 
> > > a day to day basis has gotten to the point where it is causing issues 
> > > with server responsiveness to other traffic. This is perhaps best 
> > > summarised by the following:
> > >
> > > root@nicoda /var/log/apache2 # ls -lah ...
> > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
> > >
> > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> > > 4,222,343
> > >
> > > Based on those numbers we're looking at 48-49 requests per second (on 
> > > average - peaks are much higher by many magnitudes), which seems 
> > > extremely excessive given that this file is only supposed to be retrieved 
> > > by KDE software when GHNS functionality is triggered. That is supported 
> > > by the substantial size difference it has over networkcheck.kde.org - 
> > > which is used by plasma-nm and NetworkManager (on Neon) to check for 
> > > whether they have a working internet connection - which i'd expect to be 
> > > the site receiving the most traffic.
> > >
> > > As such, I therefore suspect we have bug(s) in software that makes use of 
> > > GHNS functionality.
> > >
> > > It would therefore be appreciated if we could please review the software 
> > > in question to determine whether it is operating correctly. Given that it 
> > > usually runs in the background on user systems, i'd especially appreciate 
> > > it if a detailed review could be conducted on Discover and other software 
> > > that conducts package management operations or assists in managing 
> > > updates.
> > >
> > > Unfortunately all these applications submit a fairly useless user agent 
> > > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further 
> > > information. If we could get information on the software that is 
> > > originating the request added to the user agent to assist in 
> > > investigating these issues in the future that would be extremely helpful.
> > >
> > > Thanks,
> > > Ben
> >
> > That's correct. Discover fetches them at startup. It's necessary to be
> > able to check if there are updates on KNS-provided resources.
> >
> > Incidentally,  I was looking into this yesterday incidentally. We
> > could see if caching is broken somehow. A request will still be needed
> > though to check if the cache is out of date.
>
> Caching seems to be working, since the vast majority of the requests
> are returning 304 Not Modified.
>
> However in *many* cases I see a single IP making multiple requests in
> the same second, and doing it again the next minute. Here's one IP
> address picked randomly:
>
> [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200
> [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 

Re: OCS Providers File - High Numbers of Requests

[Aleix Pol]

On Fri, Sep 24, 2021 at 1:32 AM Nicolás Alvarez
 wrote:
>
> El jue, 23 de sep. de 2021 a la(s) 19:31, Aleix Pol (aleix...@kde.org) 
> escribió:
> >
> > On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez
> >  wrote:
> > >
> > > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) 
> > > escribió:
> > > >
> > > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > It has recently come to our attention that the number of queries 
> > > > > being handled for the endpoint 
> > > > > https://autoconfig.kde.org/ocs/providers.xml on a day to day basis 
> > > > > has gotten to the point where it is causing issues with server 
> > > > > responsiveness to other traffic. This is perhaps best summarised by 
> > > > > the following:
> > > > >
> > > > > root@nicoda /var/log/apache2 # ls -lah ...
> > > > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> > > > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> > > > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
> > > > >
> > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> > > > > 4,222,343
> > > > >
> > > > > Based on those numbers we're looking at 48-49 requests per second (on 
> > > > > average - peaks are much higher by many magnitudes), which seems 
> > > > > extremely excessive given that this file is only supposed to be 
> > > > > retrieved by KDE software when GHNS functionality is triggered. That 
> > > > > is supported by the substantial size difference it has over 
> > > > > networkcheck.kde.org - which is used by plasma-nm and NetworkManager 
> > > > > (on Neon) to check for whether they have a working internet 
> > > > > connection - which i'd expect to be the site receiving the most 
> > > > > traffic.
> > > > >
> > > > > As such, I therefore suspect we have bug(s) in software that makes 
> > > > > use of GHNS functionality.
> > > > >
> > > > > It would therefore be appreciated if we could please review the 
> > > > > software in question to determine whether it is operating correctly. 
> > > > > Given that it usually runs in the background on user systems, i'd 
> > > > > especially appreciate it if a detailed review could be conducted on 
> > > > > Discover and other software that conducts package management 
> > > > > operations or assists in managing updates.
> > > > >
> > > > > Unfortunately all these applications submit a fairly useless user 
> > > > > agent (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any 
> > > > > further information. If we could get information on the software that 
> > > > > is originating the request added to the user agent to assist in 
> > > > > investigating these issues in the future that would be extremely 
> > > > > helpful.
> > > > >
> > > > > Thanks,
> > > > > Ben
> > > >
> > > > That's correct. Discover fetches them at startup. It's necessary to be
> > > > able to check if there are updates on KNS-provided resources.
> > > >
> > > > Incidentally,  I was looking into this yesterday incidentally. We
> > > > could see if caching is broken somehow. A request will still be needed
> > > > though to check if the cache is out of date.
> > >
> > > Caching seems to be working, since the vast majority of the requests
> > > are returning 304 Not Modified.
> > >
> > > However in *many* cases I see a single IP making multiple requests in
> > > the same second, and doing it again the next minute. Here's one IP
> > > address picked randomly:
> > >
> > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > > [22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > > [22/Sep/2021:06

Re: OCS Providers File - High Numbers of Requests

[Aleix Pol]

On Fri, Sep 24, 2021 at 8:26 PM Ben Cooksley  wrote:
>
> On Sat, Sep 25, 2021 at 12:34 AM Aleix Pol  wrote:
>>
>> On Fri, Sep 24, 2021 at 1:32 AM Nicolás Alvarez
>>  wrote:
>> >
>> > El jue, 23 de sep. de 2021 a la(s) 19:31, Aleix Pol (aleix...@kde.org) 
>> > escribió:
>> > >
>> > > On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez
>> > >  wrote:
>> > > >
>> > > > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) 
>> > > > escribió:
>> > > > >
>> > > > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  
>> > > > > wrote:
>> > > > > >
>> > > > > > Hi all,
>> > > > > >
>> > > > > > It has recently come to our attention that the number of queries 
>> > > > > > being handled for the endpoint 
>> > > > > > https://autoconfig.kde.org/ocs/providers.xml on a day to day basis 
>> > > > > > has gotten to the point where it is causing issues with server 
>> > > > > > responsiveness to other traffic. This is perhaps best summarised 
>> > > > > > by the following:
>> > > > > >
>> > > > > > root@nicoda /var/log/apache2 # ls -lah ...
>> > > > > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
>> > > > > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
>> > > > > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
>> > > > > >
>> > > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
>> > > > > > 4,222,343
>> > > > > >
>> > > > > > Based on those numbers we're looking at 48-49 requests per second 
>> > > > > > (on average - peaks are much higher by many magnitudes), which 
>> > > > > > seems extremely excessive given that this file is only supposed to 
>> > > > > > be retrieved by KDE software when GHNS functionality is triggered. 
>> > > > > > That is supported by the substantial size difference it has over 
>> > > > > > networkcheck.kde.org - which is used by plasma-nm and 
>> > > > > > NetworkManager (on Neon) to check for whether they have a working 
>> > > > > > internet connection - which i'd expect to be the site receiving 
>> > > > > > the most traffic.
>> > > > > >
>> > > > > > As such, I therefore suspect we have bug(s) in software that makes 
>> > > > > > use of GHNS functionality.
>> > > > > >
>> > > > > > It would therefore be appreciated if we could please review the 
>> > > > > > software in question to determine whether it is operating 
>> > > > > > correctly. Given that it usually runs in the background on user 
>> > > > > > systems, i'd especially appreciate it if a detailed review could 
>> > > > > > be conducted on Discover and other software that conducts package 
>> > > > > > management operations or assists in managing updates.
>> > > > > >
>> > > > > > Unfortunately all these applications submit a fairly useless user 
>> > > > > > agent (Mozilla/5.0) so it is impossible for Sysadmin to ascertain 
>> > > > > > any further information. If we could get information on the 
>> > > > > > software that is originating the request added to the user agent 
>> > > > > > to assist in investigating these issues in the future that would 
>> > > > > > be extremely helpful.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Ben
>> > > > >
>> > > > > That's correct. Discover fetches them at startup. It's necessary to 
>> > > > > be
>> > > > > able to check if there are updates on KNS-provided resources.
>> > > > >
>> > > > > Incidentally,  I was looking into this yesterday incidentally. We
>> > > > > could see if caching is broken somehow. A request will still be 
>> > > > > needed
>> > > > > though to check if the cache is out of date.
>> > > >
>> > > > Caching seems t

Re: Sub: getting started with KDE community

[Aleix Pol]

Dear Sy Sagar,
Here you can find some information on different things you could look into.
https://community.kde.org/Get_Involved

I'd recommend you look into our products and see something you'd like
to work on improving. It will help you find the answers you are
looking for.

Good luck!
Aleix

On Sun, Nov 7, 2021 at 6:48 AM Sy Sagar  wrote:
>
> Hi, I am a first year college student and new to the open source community ; 
> I am interested in the KDE community projects and want to genuinely 
> contribute to it. I have an intermediate knowledge of C++ and have recently 
> been into DSA ( link list , stacks, queues,  arrays, trees , some parts of 
> graph). Please guide me to the right path as per my skills so that I can 
> begin working efficiently in any project development and learn more in my 
> journey of contribution in the open source community. Thank you!
>

Re: sub: new to KDE community

[Aleix Pol]

On Wed, Nov 10, 2021 at 6:14 AM Sy Sagar  wrote:
>
> Hello! I am SySagar . I am new to the open source community. I want your 
> help. Can you please help me know the community and its work? It will be a 
> great help. Thank you!

Dear Sy Sagar,
Here you can find some information on different things you could look into.
https://community.kde.org/Get_Involved

I'd recommend you look into our products and see something you'd like
to work on improving. It will help you find the answers you are
looking for.

Good luck!
Aleix

Re: sub: new to KDE community

[Aleix Pol]

On Wed, Nov 10, 2021 at 5:51 PM Sy Sagar  wrote:
>
> Thank you for your help! I will definitely look into it. However I have few 
> questions:
>
> 1- Do i have to learn qt framework for working into the project?

That's recommended, yes.

> 2- Can i contact with mentor(I don't know abt them)... because I am new to 
> this and would require help.

We are seeing to setting up next edition Season of KDE, stay tuned.
In the meantime, feel free to join our channels and ask questions.

> 3- I am already working on another open source project...so will the 
> configaration listed in the install brochure of the projects do any effect on 
> that project?

I'm not sure which install brochure you're referring to. You should be
able to work in different projects anyway, as long as you're careful
enough to not delete one with the other or similars.

Aleix

Re: Season of KDE Proposal: Rust wrapper for KConfig

[Aleix Pol]

On Thu, Jan 6, 2022 at 8:27 PM Ayush Singh  wrote:
>
> I am a University student and the author of the rust crate ki18n. This crate 
> allows using the KI18n Framework from Rust and can be used in conjunction 
> with the qmetaobject crate to allow writing QML applications for KDE using 
> Rust.
>
> The Proposal for my project is to create a rust wrapper for the KConfig KDE 
> Framework. With this crate present, it will be possible to create a 
> QML/Kirigami + Rust application without C++. I already have some other Rust 
> crates ready to help make the wrapper.
>
> Currently, the primary GUI solution for creating Rust applications is GTK-rs. 
> If Rust wrappers of at least the essential parts of KDE are present, it can 
> become a viable toolkit for GUI development in Rust. If this project is done 
> as part of the Season of KDE, it might also help to inform people about 
> crates like qmetaobject, which works almost flawlessly to create QML + Rust 
> applications.
>
> I am looking for someone to mentor my project. The mentor does not need to 
> have Rust skills but should be familiar with KConfig. I haven't used KConfig 
> much and might miss important parts of the Framework. I would also like to 
> make the Bindings ergonomic and would need someone who has a better 
> understanding of the Framework.
>
> My goal with this project is to increase the use of Rust in KDE as a whole. 
> But for that to happen, we first need a base to allow people to start seeing 
> KDE Frameworks as viable for Rust-based GUI.
>
> Here is my alternate email to contact me directly: ayushsingh1...@gmail.com
>
> Thank You

Rust sure looks interesting but I wonder whether having bindings for a
framework will make applications suddenly pop.

Is there any KDE project that would be furthered by having (and
maintaining) these bindings?

Aleix

Re: KDE Incubator: Telly Skout Sponsor

[Aleix Pol]

Hi Plata,
Would you be able to explain a bit what a "Convergent EPG" is?

Aleix

On Wed, Apr 27, 2022 at 11:53 PM Albert Astals Cid  wrote:
>
> El dilluns, 25 d’abril de 2022, a les 18:09:42 (CEST), Plata va escriure:
> > Hello,
>
> Hi.
>
> >
> > I'm developing Telly Skout, a convergent Kirigami based EPG 
> > (https://invent.kde.org/plata/telly-skout).
> >
> > I started developing this because I was missing an EPG to daily drive 
> > Plasma Mobile (coming from Android).
> >
> > Currently, I'm the only committer but I hope that this might change now 
> > after moving to KDE Invent from GitHub.
> >
> > I would love to see Telly Skout becoming part of Plasma (Mobile) Gear. 
> > Therefore, I'm looking for a sponsor.
>
> That's great :) We can always use more developers in KDE. Welcome!
>
> I'm not super experienced myself on Plasma Mobile, so I'd suggest you to drop 
> in their Matrix channel (or mailing list) and ask there 
> https://plasma-mobile.org/join/
>
> If you don't have any luck I will help you, after all the incubating part is 
> relatively generic for most of the KDE parts.
>
> Cheers,
>   Albert
>
> >
> > Best regards
> > Plata
> >
> >
>
>
>
>

Re: Asking for a new project

[Aleix Pol]

There's a big "Fork" button on top here: https://invent.kde.org/graphics/krita/

That said, please coordinate with krita devs to make sure your work is
ever going to reach users.

Best,
Aleix


On Tue, May 31, 2022 at 9:10 AM Bourumir Wyngs  wrote:
>
> Hello, KDE team,
>
> I would like to create the independent fork of Krita that would allow to use 
> all modern features of C++, up till that is supported by the latest GCC 
> release, 12.1 at the time of writing.
>
> The current Krita development rules are capped by C++11 that is now the ten 
> years old standard. Even that is limited by the lengthy list of restrictions. 
> The rules also require using deprecated features of the Qt framework like 
> Q_FOREACH. I understand the care of the community not to spoil anything and 
> to preserve the beauty of the existing code. This means, radical changes 
> should be done in a form.
>
> I tried to setup the project on KDE myself 
> (https://invent.kde.org/bourumir/kreed) but for some reason was not able to 
> push Krita code (about 1 Gb) into repository - hangs at the end of the push. 
> It may have something to do with quotas or things the like. It may be that I 
> need more assistance from your side to setup the project. I decided to 
> contact you first before starting the work on GitHub or independent server 
> instead.
>
> I, the project initiator, am currently 54 year old. I am robotic engineer 
> with very long programming experience, including significant industrial 
> experience with C++. In the past I made notable contribution to GNU Classpath 
> project, providing them a fully functional and interoperable implementation 
> of CORBA. It is obviously sad there are no other contributors so far but I 
> expect some people to come. I also made several contributions for Krita so 
> have some understanding about code base and architecture of this project. My 
> real name is Audrius Meskauskas.
>
>
>

Re: Incubation of pico-wizard

[Aleix Pol]

Hi Anupam,
I'll be happy to sponsor you, will send you an e-mail in private with
the next steps.

Aleix

On Fri, Aug 26, 2022 at 8:35 PM Anupam Basak  wrote:
>
> Hello KDE developers,
>
> I develop pico-wizard, an OEM install wizard used in Plasma Mobile and Plasma 
> Bigscreen. We would like to incubate it to work more closely with KDE, and 
> perhaps eventually use it for OEM installs on Plasma Desktop too.
>
> Currently it is hosted on Github at 
> https://github.com/pico-wizard/pico-wizard but moving it to KDE Gitlab is not 
> a problem. Current contributors are me(Anupam Basak), Probal Basak, Aditya 
> Mehra, Erik D, and Bart Ribbers. We are willing to comply with the KDE 
> manifesto.
>
> Would anyone like to sponsor?
>
> Thanks and regards,
> Anupam Basak
>

Re: List Flatpak runtime dependencies in a page

[Aleix Pol]

On Sat, Sep 10, 2022 at 11:14 AM TheEvilSkeleton
 wrote:
>
> Hi,
>
> At the moment, as an outsider, it's quite difficult to check what 
> dependencies the KDE runtime provides. We have to check through the manifest, 
> which in my opinion is quite unintuitive.
>
> To address that, I suggest a centralized page that lists these dependencies. 
> My current idea is to list these dependencies along with freedesktop.org, 
> elementary and GNOME runtime dependencies.
>
> The idea is, well, an idea at best. I haven't thought of the implementation 
> details or the interface of the page yet. I want to know if KDE is on board 
> with this (as well as fd.o, elementary and GNOME).
>
> I opened issue #1476 in the freedesktop-sdk repository to discuss it in one 
> place. If KDE and other organizations are on board with this idea, then it 
> would be fantastic! This will certainly help developers a lot.
>
> Thank you for the consideration,
> TheEvilSkeleton

I am not sure what you want us to be on board with.

Can you create a tool that extracts the dependencies in apps and
runtimes and presents them to users? Of course.

I guess the question is, what do you really want from us? :D

I don't think it's a matter of rallying communities around but rather
to care enough to sit down and put it together.

Aleix

Re: Product organization in Bugzilla

[Aleix Pol]

On Wed, Sep 14, 2022 at 10:13 PM Nate Graham  wrote:
>
> Hello folks,
>
> We often get feedback from bug reporters that it's hard to find the
> right product in https://bugs.kde.org/enter_bug.cgi because it contains
> just a giant intimidating list.
>
> Yes, people can use their browser's search function, and yes, if a bug
> is files in the wrong place, it will be moved to the right place. Still,
> I can't help but admit that this page is quite intimidating, and that
> intimidation may be a barrier to even trying. See
> https://bugs.kde.org/show_bug.cgi?id=340420.
>
> With this in mind, I'd like to propose that we add some grouping on this
> page. Bugzilla provides this feature natively and other FOSS projects'
> Bugzilla instances make use it; see for example:
> - https://bugs.documentfoundation.org/enter_bug.cgi
> - https://bugzilla.redhat.com/enter_bug.cgi
>
> We could do the same, providing a few user-friendly groups for common
> software people use:
>
> - KDE apps
> - KDE Plasma Desktop
> - KDE Plasma Mobile
> - KDE Frameworks
> - KDE Neon
> - Something else (which would contain everything not in any of those groups)
> - Unknown (which would lead to the generic "kde" component
>
> (note: this suggestion is not a formal proposal set in stone, it's just
> an example of a system of grouping we could use)
>
> Thoughts?
>
> Nate

+1 in general

I think that having each product separate should generally be enough.
It should be easy to identify Kate from Krita. KWin from plasmashell
less so.

Something that I think would be good to convey is that it really is
fine if you use the wrong product. I've received problems that were
from tangential components before and it's been fine. It needs
triaging either way.

Thanks for looking into this!
Aleix

Re: How long with the kde-qt5.15 repo be kept updated?

[Aleix Pol]

On Mon, Sep 26, 2022 at 7:29 PM Halla Rempt  wrote:
>
> Hi,
>
> So we, the Krita team, are once again discussing our upgrade options. Porting 
> to Qt 5.15 with the KDE patch set is one option. How long are we going to 
> maintain that, as KDE? Until needed, or until one of the official ends of the 
> LTS 
> (https://www.qt.io/blog/qt-5.15-extended-support-for-subscription-license-holders)

The reason why we made the Qt 5.15 Patch Collection is because we need
Qt 5 still and we needed to have a place to backport the work done
upstream.

I don't see why we would stop doing the work while we still needed.

I guess the official end of the LTS should just mean less and less
changes being produced for Qt 5 which should only simplify the task.

I imagine you have already seen it, but it's covered in here:
https://community.kde.org/Qt5PatchCollection

Aleix

Re: KUbuntu folks please update the "How to create useful crash reports" wiki page

[Aleix Pol]

Including the Kubuntu list, just in case.

Aleix

On Mon, Nov 7, 2022 at 8:57 PM Albert Astals Cid  wrote:
>
> In https://bugs.kde.org/show_bug.cgi?id=461258 I asked the reported to 
> provide a backtrace and he realized that
> https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Ubuntu-based_distros_.28Ubuntu.2C_Kubuntu.2C_KDE_Neon.2C_Linux_Mint.29
> links to https://wiki.kubuntu.org/DebuggingProgramCrash that does not exist.
>
> Please someone that knows how to install debug symbols in Kubuntu update that 
> page accordingly.
>
> Cheers,
>   Albert
>
>

KDE e.V. is looking for a software engineer

[Aleix Pol]

Dear KDE community,

KDE e.V., the non-profit organisation supporting the KDE community, is
looking to hire a software engineer to help improve the software stack
that KDE software relies on.
Please see the call for proposals for more details about this contract
opportunity.
https://ev.kde.org/resources/callforproposals-platform2022

We are looking forward to your application!

Best regards,

Aleix Pol, KDE e.V. President and fellow KDE software developer

Re: Bringing Cantata under the KDE umbrella?

[Aleix Pol]

On Mon, Feb 20, 2023 at 12:28 AM Heiko Becker  wrote:
>
> On Sunday, 19 February 2023 23:36:22 CET, Albert Astals Cid wrote:
> > El diumenge, 19 de febrer de 2023, a les 16:29:24 (CET), Heiko Becker va
> > escriure:
> >> Cantata is a Qt based MPD client, which was archived by its
> >> original author
> >> [1]. I started some porting to Qt6 but I wondered (and was asked in
> >> #kde-devel today) if it would make sense to move it to KDE's
> >> infrastructure? Despite being archived, it still works quite
> >> nicely. And ...
> >
> > My only 2 concerns are:
> >
> >  * Is anyone going to work on it? I guess you?
>
> Yes.

Part of the incubation process is to gather what's the team working on it.
https://community.kde.org/Incubator/Projects/DescriptionTemplate

It feels wrong to incubate a project that is already out of
development. Especially when we already have a number of music
players...

Aleix

Re: Bringing Cantata under the KDE umbrella?

[Aleix Pol]

Correct, so does KDE have what was missing in Cantata's github that
drove its contributors away?

On Mon, Feb 20, 2023 at 2:17 PM Neal Gompa  wrote:
>
> On Mon, Feb 20, 2023 at 7:18 AM Aleix Pol  wrote:
> >
> > On Mon, Feb 20, 2023 at 12:28 AM Heiko Becker  wrote:
> > >
> > > On Sunday, 19 February 2023 23:36:22 CET, Albert Astals Cid wrote:
> > > > El diumenge, 19 de febrer de 2023, a les 16:29:24 (CET), Heiko Becker va
> > > > escriure:
> > > >> Cantata is a Qt based MPD client, which was archived by its
> > > >> original author
> > > >> [1]. I started some porting to Qt6 but I wondered (and was asked in
> > > >> #kde-devel today) if it would make sense to move it to KDE's
> > > >> infrastructure? Despite being archived, it still works quite
> > > >> nicely. And ...
> > > >
> > > > My only 2 concerns are:
> > > >
> > > >  * Is anyone going to work on it? I guess you?
> > >
> > > Yes.
> >
> > Part of the incubation process is to gather what's the team working on it.
> > https://community.kde.org/Incubator/Projects/DescriptionTemplate
> >
> > It feels wrong to incubate a project that is already out of
> > development. Especially when we already have a number of music
> > players...
> >
>
> It's not without precedent though, didn't it happen with NeoChat,
> which forked from Spectral?
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!

Re: Bringing Cantata under the KDE umbrella?

[Aleix Pol]

>From a product description perspective it definitely is a music
player. MPD is an implementation detail.

On Mon, Feb 20, 2023 at 1:21 PM Reindl Harald  wrote:
>
>
>
> Am 20.02.23 um 13:18 schrieb Aleix Pol:
> > On Mon, Feb 20, 2023 at 12:28 AM Heiko Becker  wrote:
> >>
> >> On Sunday, 19 February 2023 23:36:22 CET, Albert Astals Cid wrote:
> >>> El diumenge, 19 de febrer de 2023, a les 16:29:24 (CET), Heiko Becker va
> >>> escriure:
> >>>> Cantata is a Qt based MPD client, which was archived by its
> >>>> original author
> >>>> [1]. I started some porting to Qt6 but I wondered (and was asked in
> >>>> #kde-devel today) if it would make sense to move it to KDE's
> >>>> infrastructure? Despite being archived, it still works quite
> >>>> nicely. And ...
> >>>
> >>> My only 2 concerns are:
> >>>
> >>>   * Is anyone going to work on it? I guess you?
> >>
> >> Yes.
> >
> > Part of the incubation process is to gather what's the team working on it.
> > https://community.kde.org/Incubator/Projects/DescriptionTemplate
> >
> > It feels wrong to incubate a project that is already out of
> > development. Especially when we already have a number of music
> > players...
>
> Cantata isn't a "music player"
> it's the by far best MPD client

Re: xwaylandvideobridge as a KDE app, when?

[Aleix Pol]

On Mon, Apr 3, 2023 at 7:55 PM Neal Gompa  wrote:
>
> Hey all,
>
> Two weeks ago, David Edmundson posted on his blog about
> xwaylandvideobridge[1], which is a super-cool and exciting app to make
> Plasma Wayland an even better experience when dealing with legacy X11
> apps. In that timeframe, I've gotten a lot of inquiries about when
> we'll ship it in Fedora KDE. I personally am super-excited about this
> too, as it resolves a huge pain point around the Plasma Wayland
> session for us.
>
> When will we see it released as a KDE app that I can ship?
>
> Thanks in advance and best regards,
> Neal
>
> [1]: http://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!

I've just requested the repo to sysadmin. Then it will need to go
through kdereview at least.

In the meantime, please make sure all the feedback and issues that
might need addressing are in the discuss thread:
https://discuss.kde.org/t/fixing-wayland-xwayland-screen-casting/217

Aleix

Re: Developing KWin, starting nested KWin

[Aleix Pol]

No, it will be the same settings as any other, as it's picked up using
the standard directories. You can probably override XDG_CONFIG_DIRS
for it or something like that.

I recommend using a nested kwin until you're somewhat confident that
the feature works. It makes for an  easier experience.

Aleix

On Thu, May 9, 2024 at 11:58 PM Gerion Entrup  wrote:
>
> Thanks for the link, it was an interesting read!
> It, however, focuses a little bit on the libinput and DRM hacking inside KWin,
> which requires starting in a TTY, and does not so much explain a more
> complete workflow for nested KWin. A few additional questions that came
> to my mind:
> - Do virtual screens exist in a nested KWin? And how can I switch them?
> - Can I give a nested KWin other settings than the outer one? Where can I 
> configure them?
>
> Best,
> Gerion
>
> Am Donnerstag, 9. Mai 2024, 01:11:59 MESZ schrieb Gabriel Klavans:
> > I found this post nice for some inspiration
> >
> >
> > Developing KWin Wayland – TheBlindCow
> > proli.net
> >
> >
> >
> >
> >
> > On May 8, 2024, at 6:31 PM, Gerion Entrup  wrote:
> >
> >
> > Hi,
> >
> > I'm interested in playing around with KWin's source code (especially with 
> > the
> > built-in tiling feature). However, I find it kind of complicated to find a 
> > good
> > workflow for development (I'm on a desktop with Plasma/KWin on Wayland).
> >
> > I tried to research what is possible and see this possibilities:
> > - Replace the current running KWin. I'm pretty sure that this is not a good
> > idea, especially, when I include buggy code that segfaults, etc.
> > - Start a nested KWin. I saw this here [1] and it seems to work quite well.
> > However, I need some kind of launcher. I tried krunner but it disappears and
> > pressing the keybinding just opens the "real" krunner. A terminal emulator
> > also works but opening new windows there is not quite comfortable.
> > - Start KWin on another TTY. I did not try this but it seems quite 
> > complicated
> > to change the whole context every time to test something.
> >
> > So, what is your workflow? Is it possible to start a whole Plasma session
> > inside a nested KWin and how are keybindings captured there?
> >
> > Best,
> > Gerion
> >
> > [1] https://community.kde.org/KWin/Wayland#Starting_a_nested_KWin
>

Re: [Incubation Request] Translator App

[Aleix Pol]

Hi!
It sure looks like an interesting app, looking forward to seeing what
you come up with!

Aleix

On Sun, Jun 9, 2024 at 10:02 PM Гена Черныщук  wrote:
>
> Hi KDE Development Team!
>
> We would like to request an incubation for Crow Translate 
> (https://github.com/crow-translate/crow-translate). It's a translation app 
> written in Qt.
>
> Some of its features:
>
> Supports multiple translation backends (Google, Yandex, Bing, LibreTranslate 
> and Lingva).
> Built-in OCR support via Tesseract
> Text to speech for both source and translation text.
> Adaptive interface, can be used on Plasma Mobile.
>
>
> We discussed it in https://invent.kde.org/carlschwan/apps/-/issues/2 and 
> think that both projects will benefit from it.
>
> We moved the repository to KDE Invent and created an issue with the 
> incubation checklist: 
> https://invent.kde.org/shatur/crow-translate/-/issues/692

Re: [Incubation Request] Translator App

[Aleix Pol]

Hi,
I could be a sponsor but I see many people already involved in your
idea who also could be, have you asked them? It always is useful to be
familiar with the problem when doing this kind of task.

Best,
Aleix

On Thu, Jun 13, 2024 at 11:43 PM Hennadii Chernyshchyk
 wrote:
>
> Would you like to be my incubation sponsor?
>
> ср, 12 июн. 2024 г. в 02:13, Aleix Pol :
>>
>> Hi!
>> It sure looks like an interesting app, looking forward to seeing what
>> you come up with!
>>
>> Aleix
>>
>> On Sun, Jun 9, 2024 at 10:02 PM Гена Черныщук  wrote:
>> >
>> > Hi KDE Development Team!
>> >
>> > We would like to request an incubation for Crow Translate 
>> > (https://github.com/crow-translate/crow-translate). It's a translation app 
>> > written in Qt.
>> >
>> > Some of its features:
>> >
>> > Supports multiple translation backends (Google, Yandex, Bing, 
>> > LibreTranslate and Lingva).
>> > Built-in OCR support via Tesseract
>> > Text to speech for both source and translation text.
>> > Adaptive interface, can be used on Plasma Mobile.
>> >
>> >
>> > We discussed it in https://invent.kde.org/carlschwan/apps/-/issues/2 and 
>> > think that both projects will benefit from it.
>> >
>> > We moved the repository to KDE Invent and created an issue with the 
>> > incubation checklist: 
>> > https://invent.kde.org/shatur/crow-translate/-/issues/692

Re: GSoC Proposal Feedback?

[Aleix Pol]

On Wed, Mar 12, 2014 at 7:23 AM, Zaman, Nafis  wrote:

>  Hi KDE developers!
>
>  My name is Nafis Zaman. I'm an undergrad at the University of Oklahoma
> pursuing a B.S. in Computer Science. I'm interested in working on KDevelop
> as part of GSoC 2014. Specifically, I'm interested in continuing the
> kdev-clang plugin for better clang integration.
>
>  Is it possible to get feedback on a proposal draft? I know that Milian
> Wolff is listed as the mentor for this project. Perhaps I should contact
> him directly?
>
>  Thanks,
> Nafis Zaman
>
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>
>
Hi Nafis!
Feel free to send an e-mail to kdevelop-de...@kde.org with your ideas and
we can discuss it over there. You can also contact Milian, but I think he's
on vacations this week.

Good luck!
Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: KDevelop on Apple OS X

[Aleix Pol]

On Sun, Mar 16, 2014 at 10:02 PM,  wrote:

> Hi devs,
>
> after having installed kdesdk4 successfully MacPorts needed only about 30s
> to install the residual handful of ports required by KDevelop.
>
> Now there is KDevelop 1.6.0 up and running. :)
>
> Well, before going further with questions I wonder whether I should
> address them to KDevelop’s mailing list (which seems to be quite dead) or
> rather stay here on KDE-DEVEL for the moment, since I am not sure whether
> it is a Mac specific issue or not.
>
> What I did was that I set up a project via “Project/New From
> Template…/Project Type/Graphical”.
> After running into a little issue with the temlate [1] I was able build
> the generated code with some warnings, but without a real error. :-)
>
> When I now start the application from the built app package I
> unfortunately get an error:
> —
> $ ./testgraphical
> file:///Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/:
> File not found
> Killed: 9
> —
>
> I am surprised to see a message like this on the console. What does this
> mean? Which file does the app try to load and why does it fail to do so?
>
> KDevelop doesn’t allow me to step through the code in debug mode, so that
> I cannot say where exactly the issue occurred.
>
> I could imagine that the app tries to access its configuration which is
> stored on MacOSX in ~/Library/Preferences/KDE :
> —
> $ pwd
> /Users/marko/Library/Preferences/KDE/share/apps
> $ ls -1
> RecentDocuments
> desktoptheme
> dolphin
> Kate
> kdenlive
> kdevappwizard
> kdevelop
> kfileplaces
> khelpcenter
> kssl
> plasma
> remoteview
> —
> As one can see, kdevelop itself already stores its stuff in there.
>
> I am clueless right now about how to further proceed. Hope you can push me
> into the right direction.
>
> Greets,
> Marko
>
>
>
> [1] https://bugs.kde.org/show_bug.cgi?id=329392
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>

Hi Marko,
First of all, KDevelop mailing lists are not dead, we did change our
mailing list to kde.org infrastructure, you might have looked at the wrong
place [1].

We have some people already using KDevelop through homebrew on Mac OS X
[2], maybe using the same tools Alexander used will help, at least with the
first bug.

Regarding the second one, it clearly seems like it's a bug in the cmake
integration. It hasn't been tested on Mac before so it can be just as well
that you're the first person trying that. Some further investigation will
be very much welcome. I would suggest following up in the kdevelop-devel
mailing list would be the best.

Cheers!
Aleix

[1] http://kdevelop.org/mailinglists
[2] https://github.com/adymo/homebrew-kde

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Idea for GSoC (kde base / cloud)

[Aleix Pol]

On Mon, Mar 17, 2014 at 12:52 AM, Jinesh K J  wrote:

>
> Hi all,
>
> I have an idea about a new feature for KDE base that I would like to work
> on as part of GSoC. I understand from my discussion with Valorie in IRC
> that I need to be hasten all discussions since the deadline is fast
> approaching.
>
> My idea basically deals with how any KDE App could make use of a cloud
> infrastructure to provide a transparent and harmonious usability experience
> for a user across all his KDE based devices. That was my idea in short but
> I would like to discuss about it more if others are also interested.
>
> Thanks
> Jinesh
>
>
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>
>
I'm sure the KDE Connect team will be interested [1].

Aleix

[1] https://mail.kde.org/mailman/listinfo/kdeconnect

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Plasmoids: X-KDE-PluginInfo-Website=http://plasma.kde.org/ invalid?

[Aleix Pol]

On Fri, Apr 25, 2014 at 9:27 AM, Sebastian Kügler  wrote:

> On Saturday, April 19, 2014 11:29:50 scl wrote:
> > I lately reworked a plasmoid. As desired in
> > the [Plasma/QML Getting started document]
> > the file metadata.desktop contains the line
> > X-KDE-PluginInfo-Website=http://plasma.kde.org/.
> >
> > However, when I enter this URL in my browser
> > I can't access it. I tried yesterday and today
> > and with various computers and browsers but
> > always get the same result. Ping immediately
> > results in timeout.
> >
> > Is this URL still valid and if not, which
> > URL do developers need to include now?
>
> This key is meant to be the user-visible website, so perhaps
> http://userbase.kde.org/Plasma is a better starting point to point to?
>
> Plasma team: Any objections against changing it throughout? We haven't
> bothered to update plasma.kde.org in years and now it's dead (and that's
> probably a good thing), maybe it's time to admit that and run a perl script
> over our metadata.desktop files? (I can do that.)
>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>

+1

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Plasmoids: X-KDE-PluginInfo-Website=http://plasma.kde.org/ invalid?

[Aleix Pol]

On Fri, Apr 25, 2014 at 10:22 AM, Aleix Pol  wrote:

> On Fri, Apr 25, 2014 at 9:27 AM, Sebastian Kügler  wrote:
>
>> On Saturday, April 19, 2014 11:29:50 scl wrote:
>> > I lately reworked a plasmoid. As desired in
>> > the [Plasma/QML Getting started document]
>> > the file metadata.desktop contains the line
>> > X-KDE-PluginInfo-Website=http://plasma.kde.org/.
>> >
>> > However, when I enter this URL in my browser
>> > I can't access it. I tried yesterday and today
>> > and with various computers and browsers but
>> > always get the same result. Ping immediately
>> > results in timeout.
>> >
>> > Is this URL still valid and if not, which
>> > URL do developers need to include now?
>>
>> This key is meant to be the user-visible website, so perhaps
>> http://userbase.kde.org/Plasma is a better starting point to point to?
>>
>> Plasma team: Any objections against changing it throughout? We haven't
>> bothered to update plasma.kde.org in years and now it's dead (and that's
>> probably a good thing), maybe it's time to admit that and run a perl
>> script
>> over our metadata.desktop files? (I can do that.)
>>
>> Cheers,
>> --
>> sebas
>>
>> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>>
>> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> unsubscribe <<
>>
>
> +1
>

FWIW, we could also make kde sysadmin point plasma.kde.org to that url,
otherwise we'll have lost links all over the place, which is a huge loss
either way.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: KDE applications 4.14 LTS or 4.15?

[Aleix Pol]

On Fri, Apr 25, 2014 at 9:09 PM, Mario Fux  wrote:

> Morning gals and guys
>
> First: there are several mailing lists in the "TO:" above but please just
> write to the kde-devel mailing list for this discussion.
>
> As the release schedule for our KDE applications in the version 4.14 [1]
> were
> finalized at the beginning of this week it's time to discuss if 4.14 should
> become a LTS release (e.g. until August 2015 like KDE Workspaces 4.11) or
> if
> we need (at least) another features release and thus 4.15?
>
> So what do you think? And most important, what do you, the KDE apps
> developers, think? Do you plan to develop new features with Qt4 and the KDE
> Platform 4 or do you plan to port your application to the KDE Frameworks 5
> as
> soon as they have a stable release (like this June ;-).
>
> Best regards
> Mario
>

I would like to see applications starting to use KF5 more and more. I agree
it can be a special case, but the 3 oldest projects I maintain (KDevelop
which is not in SC, KAlgebra and Kamoso) are mostly ready for action.

On the other hand, I don't see a reason for waiting more to adopt Qt5 on
our projects.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: KDE apps in the Qt Showroom

[Aleix Pol]

On Fri, Jun 6, 2014 at 11:13 AM, Mario Fux  wrote:

> Good morning dear contributors
>
> There is today this blog post from Qt:
>
> http://blog.qt.digia.com/blog/2014/06/06/qt-showroom-calling-all-application-
> developers/
>
> And I definitely think some KDE apps should be in this showroom!
>
> So please forward this message to other mailing lists if you think it makes
> sense.
>
> Thx
> Mario
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>

Can KDE Promo take care of this? I don't think any project would prefer not
to be there.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Touch interface development

[Aleix Pol]

On Mon, Jun 9, 2014 at 12:15 PM, Benedict Yappy 
wrote:

> Everyone, I am interested in how touch interface support is being
> developed in KDE.
>
> I just recently installed Sabayon 14.16 which (should) have recent KDE
> build. I find the touch interface rather bland.
> The main weakness:
> 1. Dragging across the screen moves the mouse cursor and/or select items.
> 2. High accuracy needed to perform double-click (double tapping)
> 3. Two finger zoom not working
>
> I figure that the behavior is not expected on people accustomed to touch
> in Android or other touch OSs. Meanwhile, Android OS support additional
> mouse and keyboard quite natively.
>
> I'd like to know where touch interface is being developed. I am aware of
> plasma active, but I am using regular desktop KDE in my touch-enabled
> notebook and I don't hope to fully use mobile. Some improvements can be
> made that KDE can be more touch friendly than Windows 8 desktop version.
>
> Please share me what you think, and/or point me to the right place where
> touch developed.
>
> Regards,
>
>
> Benedict.
>
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>
>
Hi,
I would suggest you to take a look at Plasma Next where most of the
development is happening and see what's the state there, I'll be happy to
see new improvements in that area. In Qt5 you'll probably have better API's
anyway.

Cheers!
Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: How to run Frameworks5

[Aleix Pol]

On Mon, Jun 9, 2014 at 8:37 PM, Arjun AK  wrote:

> I have successfully built frameworks from source using 'kdesrc-build' with
> the
> help of instructions given here (
> http://community.kde.org/Frameworks/Building)
> But i cant figure out how to run it. Installation path('kdedir') was set
>  to
> ~/kde/. Since KDM doesn't allow executing anything from home directory i
> copied all the files to /usr/local. Now when i log in all i get is the
> mouse
> pointer (no wallpaper) and the apps that are set to auto run using scripts
> in
> ~/.kde/Autostart. So what is the right way to install and run it?
>
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>

That's my service file:
apol@thinktatil:~$ cat /usr/share/xsessions/p2master.desktop
[Desktop Entry]
Encoding=UTF-8
Name=Plasma 2 Master
Exec=/home/kde-devel/kde5/bin/startkde
Type=Application

You need to set your environment variables in a /etc/profile.d/something
file.

Good luck!
Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: KDE apps in the Qt Showroom

[Aleix Pol]

On Tue, Jun 10, 2014 at 11:44 PM, Mario Fux  wrote:

> Am Freitag, 06. Juni 2014, 18.43:04 schrieb Aleix Pol:
>
> Morning Aleix
>
> > On Fri, Jun 6, 2014 at 11:13 AM, Mario Fux  wrote:
> > > Good morning dear contributors
> > >
> > > There is today this blog post from Qt:
> > >
> > >
> http://blog.qt.digia.com/blog/2014/06/06/qt-showroom-calling-all-applicat
> > > ion- developers/
> > >
> > > And I definitely think some KDE apps should be in this showroom!
> > >
> > > So please forward this message to other mailing lists if you think it
> > > makes sense.
>
> > Can KDE Promo take care of this? I don't think any project would prefer
> not
> > to be there.
>
> Generally a good idea but as the KDE promo team is not very active atm (too
> many people of the team are quite busy atm) there won't be much progress on
> this from the KDE promo side I think.
>
> On the other hand. The KDE promo team searches for new people. Interested?
> Here is your first task ;-).
>
> Best regards
> Mario
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>

Yes, it can be a nice way to get people introduced. If they want to use any
of my projects, I'll be happy to help with any needed information.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: libkdeedu icons

[Aleix Pol]

On Tue, Jun 24, 2014 at 8:46 PM, Jeremy Whiting  wrote:

> Aleix, All,
>
> In looking at what needs to be done to prepare libkdeedu for porting
> to kf5 and qt5 and what needs doing to split (or maybe just repurpose
> it as libkeduvocdocument + data ?) as per
> http://community.kde.org/KDEEdu/RouteToKF5 I took a look at the icons
> folder.
>
> The users of the icons there are mostly kmplot, but also analitza.  My
> question is where should these icons go? Can/should we move them into
> some general purpose icons repository (kde-artwork or something?) or
> should they move into analitza git repo (only if kmplot depends on
> analitza already I think). Or somewhere else entirely?
>
> Thanks,
> Jeremy
>

Hi,
kmplot doesn't use analitza and never will, what we are proposing is khipu,
a new project, as a replacement.

That said, I'd say the best could be to get a kde-math-icons repository or
similar? Is there another case of a repository with only icons? Maybe
oxygen? (even though the icons are not oxygen per se...)
Anybody has an opinion?

Aleix

PS: Adding kde-devel because I can see this happening on other modules as
well and I think we want a way do decide these things.

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: libkdeedu icons

[Aleix Pol]

On Wed, Jun 25, 2014 at 4:17 AM, Percy Camilo Triveño Aucahuasi <
percy.camilo...@gmail.com> wrote:

> On Tue, Jun 24, 2014 at 2:17 PM, Aleix Pol  wrote:
>
>> On Tue, Jun 24, 2014 at 8:46 PM, Jeremy Whiting 
>> wrote:
>>
>>> Aleix, All,
>>>
>>> In looking at what needs to be done to prepare libkdeedu for porting
>>> to kf5 and qt5 and what needs doing to split (or maybe just repurpose
>>> it as libkeduvocdocument + data ?) as per
>>> http://community.kde.org/KDEEdu/RouteToKF5 I took a look at the icons
>>> folder.
>>>
>>> The users of the icons there are mostly kmplot, but also analitza.  My
>>> question is where should these icons go? Can/should we move them into
>>> some general purpose icons repository (kde-artwork or something?) or
>>> should they move into analitza git repo (only if kmplot depends on
>>> analitza already I think). Or somewhere else entirely?
>>>
>>> Thanks,
>>> Jeremy
>>>
>>
>> Hi,
>> kmplot doesn't use analitza and never will, what we are proposing is
>> khipu, a new project, as a replacement.
>>
>>  That said, I'd say the best could be to get a kde-math-icons repository
>> or similar? Is there another case of a repository with only icons? Maybe
>> oxygen? (even though the icons are not oxygen per se...)
>> Anybody has an opinion?
>>
>> Aleix
>>
>> PS: Adding kde-devel because I can see this happening on other modules as
>> well and I think we want a way do decide these things.
>>
>>
> We could move those artifacts into something like libkdeedu-math-data or
> as Aleix said: kde-math-icons. In any case, I think a dedicated repository
> for this kind of content (related with kde math applications) is a good
> idea.
>
> Percy
>
> It still sounds quite weird that we have a repo for all artwork in KDE
except for some and then one with the mathematical icons as if they were
something that special.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Should KDED4 run all the time?

[Aleix Pol]

On Tue, Jul 1, 2014 at 4:45 AM, Ian Wadham  wrote:

> Hi Sune,
>
> Thanks for replying, Sune.
>
> On 30/06/2014, at 11:37 PM, Sune Vuorela wrote:
> > On 2014-06-28, Ian Wadham  wrote:
> >> When fixing some bugs in the KCrash-DrKonqi sequence on Apple OS X,
> >> I have come to a point where Dr Konqi attempts to call kded4, using
> DBus,
> >> and issues a message "Failed to communicate with kded. Make sure it is
> running."
> >
> > In the kdelibs4.x-age, yes. kded should be running all the time no
> matter what.
>
> In Linux and a KDE desktop manager, that is fine: kded4 is part of the
> structure
> of a KDE desktop manager.  But in Apple OS X (or other desktop managers),
> that
> should not be a requirement, if KDE is to be truly portable.
>
> Other desktop managers have their own ways of handling directory and file
> changes,
> battery level updates, device mounts, software update registration or
> whatever.  So
> maybe kded4 is not really needed at all on such platforms.
>
> In particular, the absence of kded4 should not prevent a user from
> reporting
> a crash in a KDE application on Apple OS X or any other desktop manager,
> should it?  I don't think *anything* should prevent that… :-)
>
> I do not think it is reasonable to ask the MacPorts developers to include
> kded4 in startup procedures for every user, on the off chance that he or
> she will use a KDE app sometime and that app will crash.
>
> So I will proceed to patch around the requirement for kded4 in Dr Konqi in
> Apple OS X, unless someone has a better idea or can point out some more
> frequent and vital need for kded4 in a non-KDE desktop manager.
>
> > Unfortunately, it isn't refcounting its users so it is running like
> forever.
>
> Cheers, Ian W.
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>

Yes, I agree that with portability in mind, requiring a kded running with
some services kills the mood quite a bit.

Patches are welcome indeed, although I wonder whether it wouldn't be
interesting to look into this on KF5 already, but maybe it just doesn't
make a difference.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Should KDED4 run all the time?

[Aleix Pol]

On Tue, Jul 1, 2014 at 7:46 PM, "Marko Käning"  wrote:

> Hi Aleix,
>
> > although I wonder whether it wouldn't be interesting to look into this
> on KF5 already, but maybe it just doesn't make a difference.
>
> what do you mean exactly with this comment?
>
> Greets,
> Marko
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>

That I agree with your initiative, I suggest you to look at it for future
versions based on Qt5 and KF5 (or kdelibs5), but that if it's a problem
just do it for kde4 and we can forward-port your changes to the newer
versions of kdelibs.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Overlay Icons in KDE using Qt/C++

[Aleix Pol]

On Wed, Jul 2, 2014 at 11:18 AM, Rahul  wrote:

> Hi,
>
> I'm working on a project which requires the icons of the filesystem to be
> overlaid with some symbols. This is similar to how the icons are overlaid
> by Tortoise SVN on any modification to the watch directory/file.
>
> The application is being developed in Qt/C++. So in addition to the
> application, the icon overlay feature is to be implemented. To achieve this
> how do I access KDE APIs ? How do I include the required library ? Kindly
> help me with this.
>
> Thank you.
>
> Regards,
> Rahul
>
>
You can look at the KIconThemes framework, there's a KIconEngine class you
can use that provides this overlay support.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: kwin_x11 decoration plugin Oxygen not found

[Aleix Pol]

On Fri, Jul 4, 2014 at 3:27 PM, Leslie Zhai  wrote:

> Hi martin and KDE developers,
>
> I built the KF5 and KWin from git repos hosting on
> https://projects.kde.org but when I run kwin_x11 --replace
>
> it failed to work so I simply pasted some of the output shown as below:
>
> QXcbConnection: XCB error: 3 (BadWindow), sequence: 168, resource id:
> 31457305, major code: 20 (GetProperty), minor code: 0
>
> Trying to load decoration plugin "Oxygen"
> Decoration plugin not found
> Trying to load decoration plugin "Oxygen"
> Decoration plugin not found
> KWin: The default decoration plugin is corrupt and could not be loaded.
> QObject::connect: invalid null parameter
>
> and my .xinitrc like this
> kwin_x11 &
> qtpanel
>
> then I am able to use KDE4`s kwin --replace &
> when kwin_x11 failed to work.
>
> Please someone give me some advice, thanks a lot!
>
> --
> a KDE developer
>
>  Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>>> unsubscribe <<
>>>
>>
Hi, I had this problem yesterday, I solved it by looking at the cmake
configuration output. I happened to miss xcb-util-cursor (in arch, it will
be called differently in other distros).

Good luck!
Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Jungle and Plasma Media Center

[Aleix Pol]

On Fri, Jul 4, 2014 at 1:05 PM, Shantanu Tushar Jha 
wrote:

>
>
> On Fri, Jul 4, 2014 at 12:00 AM, Vishesh Handa  wrote:
>
>> Hey Shaantanu
>>
>> Jungle is more of a personal itch that we (Alex Fiestas and I) wanted to
>> scratch. It's currently in its very very early phases, and is not ready for
>> consumption by anyone. Also, the code is not up to my quality standards.
>>
>
> Yep, that is why I wanted this discussed at the early stages. If we really
> end up having a separate app for watching movies, it quite kills all of our
> motivation of having a unified media experience on KDE.
>
>
>>
>> You're more than welcome to utilize any code from Jungle and help create
>> it into a library that we can share. We would still like to experiment with
>> some different UIs and not tie ourselves down to PMC.
>>
>
> Yep, I plan to expose a PMC backend from Jungle over this weekend, lets
> see how it goes.
>
>
>> On Thu, Jul 3, 2014 at 7:19 PM, Shantanu Tushar Jha 
>> wrote:
>>
>>> Given that Randa sprint is upcoming and lot of KDE developers will be
>>> present, it'll be nice if this can be discussed along with the usual
>>> discussions around Jungle. Though none of the PMC contributors will be
>>> physically present due to cost constraints, we'll be more than happy to do
>>> it over some kind of video call.
>>>
>>>
>> Sure.
>>
>
I was under the impression Plasma Media Center targeted Media Centers...

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Help request with Cantor port to KF5

[Aleix Pol]

On Sun, Sep 28, 2014 at 11:59 PM, Filipe Saraiva  wrote:

>  Hello gearheads,
>
> I am working in Cantor port to KF5 in last month. My milestone is to
> compile and run Cantor without backends and panel plugins. For now I can
> compile, but the binary generated have a seg fault.
>
> Then I need a help of some KF5 port guru, please. =)
>
> The code is in reviewboard https://git.reviewboard.kde.org/r/120300/. My
> main doubts are:
>
> * Is kdemacros.h (in src/lib/cantor_macros.h and src/lib/cantor_export.h)
> available in KF5?
>
No, you use generate_export_header macro().


> * What do I do with setComponentData in src/cantor_part.cpp:73? Is it
> deprecated?
>
I didn't look at the code, but I'm pretty sure you have to do
setComponentName.


> * Could someone show me the new way to use KPluginFactory
> (src/cantor_part.cpp)?
>
Well, there's many different ways to do plugins in KF5 (sigh) I'm unsure to
be honest if KParts changed, but I would suggest you to look at a ported
KPart and see how they did it. ;)


>
> All help will be appreciated. =)
>
> Thank you;
>
> --
> Filipe Saraivahttp://filipesaraiva.info/
>
>
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>
>
Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: regarding contributing to KDE-Education project "Pairs" |Mentoring

[Aleix Pol]

On Tue, Oct 21, 2014 at 9:42 AM, Harsh Thakkar  wrote:

> Dear KDE & KDE-SOC Community,
>
> It is a pleasure to learn that KDE-SOK 2014 has been announced a few days
> ago with a vast variety of projects. I am a keen user of open-source
> software, but haven't been able to contribute since a long time. I would
> like to take the KDE-SOK opportunity to repay the wonderful community.
>
> I am interested in contributing to the KDE-EDU project "Pairs". I find it
> really interesting and crucial as children are the most valuable resources
> to the society. Pairs focuses on brain stimulating games and is useful not
> only to children but to almost any age group of people. I use it almost
> daily for my daily brain exercise.
>
> I would like to propose a project as a mentor to the pairs project. I have
> a few things in mind:
>
> 1. Porting the Pairs project to QT 5. [It has been ported to QT 4x version
> link- http://quickgit.kde.org/?p=pairs.git]
> - Transiting to Qt 5 from Qt 4.x is not expected to be significant, but
>   the “modularization” of the Qt code base requires some amount of changes
> to project configuration, such as use of “headers”, and configuration of
> project build settings (such as changes to the *.pro files).
>
I'm actually amazed that you managed to write such a long e-mail and not
realize we don't use .pro files, anywhere in KDE.


>
> -This would require knowledge of qml, qt5 and basic C++.
>
> 2. In the latest version pushed by Aleix Pol and Marco Calignano, there
> are a few TODO's they proposed, i would like to include them into this idea
> and solve the remainders. These include:
> a) Adding scroll bar in-case of more than one player is involved to
> eliminate the over-lapping on the display
> b) Getting rid of window border
> c) In the game Logic and SoundLogic there is a need to highlight the first
> selected card of each turn
>
> Looking forward to hear from you people!
> Some handy resources -
> http://qt-project.org/wiki/Transition_from_Qt_4.x_to_Qt5 and
>
?? why do you tell us about the Qt 4 to 5 port?

Anyway, best thing will be that you send an e-mail to Marco and I.
Currently the port to Qt 5 is underway and it's not trivial as we're
transitioning over mixed used between QtDeclarative and QGraphicsView to
QGraphicsScene.

Cheers!
Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: regarding contributing to KDE-Education project "Pairs" |Mentoring

[Aleix Pol]

On Tue, Oct 21, 2014 at 9:42 AM, Harsh Thakkar  wrote:

> Dear KDE & KDE-SOC Community,
>
> It is a pleasure to learn that KDE-SOK 2014 has been announced a few days
> ago with a vast variety of projects. I am a keen user of open-source
> software, but haven't been able to contribute since a long time. I would
> like to take the KDE-SOK opportunity to repay the wonderful community.
>
> I am interested in contributing to the KDE-EDU project "Pairs". I find it
> really interesting and crucial as children are the most valuable resources
> to the society. Pairs focuses on brain stimulating games and is useful not
> only to children but to almost any age group of people. I use it almost
> daily for my daily brain exercise.
>
> I would like to propose a project as a mentor to the pairs project. I have
> a few things in mind:
>
> 1. Porting the Pairs project to QT 5. [It has been ported to QT 4x version
> link- http://quickgit.kde.org/?p=pairs.git]
> - Transiting to Qt 5 from Qt 4.x is not expected to be significant, but
>   the “modularization” of the Qt code base requires some amount of changes
> to project configuration, such as use of “headers”, and configuration of
> project build settings (such as changes to the *.pro files).
>
> -This would require knowledge of qml, qt5 and basic C++.
>
> 2. In the latest version pushed by Aleix Pol and Marco Calignano, there
> are a few TODO's they proposed, i would like to include them into this idea
> and solve the remainders. These include:
> a) Adding scroll bar in-case of more than one player is involved to
> eliminate the over-lapping on the display
> b) Getting rid of window border
> c) In the game Logic and SoundLogic there is a need to highlight the first
> selected card of each turn
>
> Looking forward to hear from you people!
> Some handy resources -
> http://qt-project.org/wiki/Transition_from_Qt_4.x_to_Qt5 and
>
> Affectionate regards,
> Harsh Vrajesh Thakkar
> Research Scholar |BioNLP, Information Retrieval
> Dhirubhai Ambani Institute of Information Communication Technology,
> Gandhinagar
> Facebook <http://www.facebook.com/harsh9t> |LinkedIn
> <http://in.linkedin.com/in/thakkarharsh> |Twitter
> <https://twitter.com/Harsh9t> |Web <http://harshthakkar.in/>
>
> "People cannot go wrong, if you don't let them.  They cannot go right,
> unless you let them."
>
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>
>
Hi Harsh,
I didn't notice you wanted to mentor. I don't think it's acceptable to have
somebody who hasn't contributed beforehand as a mentor. I think it breaks
the mentorship promise that the mentor will be an experienced KDE developer.

On the other hand, if are interested, you can contribute to Pairs too.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Contribute to kalzium

[Aleix Pol]

On Wed, Oct 29, 2014 at 5:57 PM, anu mittal  wrote:

> Hi,
>
> This is Anu, i am very much interested in contributing to the application
> kalzium,I have gone through the current project and would like to know if
> anybody can help me for the same by mentoring me.
>
> Regards,
> Anu.
>

Hi Anu,
I'd be happy to mentor you, if you're willing to work on the full Kalzium
port and stabilization on top of Qt5 and KF5.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Contribution to kalzium.

[Aleix Pol]

On Sat, Nov 1, 2014 at 2:03 PM, anu mittal  wrote:

> Thank you Aleix.
>
> Since i am a beginner in these languages can you please suggest some
> sources to get acquainted with the project work before the actual work
> starts.
>
> Regards,
> Anu.
>

Hi Anu,
You can start looking at my blog post about porting if you wish [1]. In
your case, you can disregard the QML/QtQuick parts.

Aleix

[1] http://www.proli.net/2014/06/21/porting-your-project-to-qt5kf5/

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: new-age kde : which c++?

[Aleix Pol]

On Tue, Nov 18, 2014 at 3:59 PM, Mayuresh Kathe  wrote:

> hello,
>
> returning to c++ and kde after a really long (16 years) time.
> has kde moved to modern (2011/2014) c++ yet?
> a google search for "kde c++ version" wasn't very helpful.
>
> ~mayuresh
>

Hi Mayuresh!
Really good to see you back!

In general for applications you get to decide what compilers you want to
target. In general, in applications, c++11 is embraced, I haven't seen much
c++14 usage yet.

For KF5, only some parts of c++11 can be used, due to the supported
compilers.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Announcing heaptrack - a Heap Memory Profiler for Linux

[Aleix Pol]

On Tue, Dec 2, 2014 at 6:59 PM, Milian Wolff  wrote:

> Hey all,
>
> I have just finished writing a lengthy introduction to heaptrack, an
> alternative to Massif, see:
>
> http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux
>
> I'd like to see more people starting to use it. Any feedback, or even
> patches,
> is welcome!
>
> Especially, I'd love to see more people use it on their pet project in KDE.
> Quite often, you'll find useless temporary allocations, overly large memory
> consumption or even significant memory leaks. C++/Qt/KDE code can be
> extremely
> efficient, but you have to code accordingly. If you have any questions to
> the
> results you obtain from heaptrack, or how to improve the situation, don't
> hesitate to ask me. Please ask on a public mailing list, such that others
> can
> benefit from the discussion as well.
>
> Furthermore, I hereby request an official code review. Heaptrack currently
> lives in a scratch repository:
>
> http://quickgit.kde.org/?p=scratch%2Fmwolff%2Fheaptrack.git
>
> I want to move this to extragear, skipping playground altogether, if
> possible.


Cool stuff! I'll definitely give it a try!

Regarding the move to extragear, you can start requesting the repository to
get it in playground and then request the move to kdereview, if you're
confident it's pristine. ;)

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: building extra-cmake-modules

[Aleix Pol]

On Tue, Dec 16, 2014 at 7:12 AM, anu mittal  wrote:
> Hi Chritian,
> $KF5 must contain the relative path to its frameworks directory?
> How can know where is it.!
> I am working on Kubuntu Plasme 5 and i suppose kf5 is preinstalled?
>
> On Tue, Dec 16, 2014 at 2:26 AM, Christian Dávid 
> wrote:
>>
>> Am Dienstag, 16. Dezember 2014, 02:11:27 schrieb anu mittal:
>> > I have been trying to build ecm
>> > after executing the command cmake -DCMAKE_INSTALL_PREFIX=$KF5
>> > error is thrown-mentioned in the attachment.
>> > Can anybody help in resolving it?
>>
>> Hi Anu,
>>
>> probably you variable $KF5 contains a relative path. Replace it by an
>> absolute
>> path and the error message should disappear.
>>
>> Greetings
>> Christian
>>
>> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >> unsubscribe <<
>
>
>
> --
> Regards,
> Anu.
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

You can also install extra-cmake-modules from apt, no need to compile it.
https://launchpad.net/ubuntu/+source/extra-cmake-modules

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: kubuntu plasma 5 login error

[Aleix Pol]

On Wed, Dec 17, 2014 at 7:35 PM, anu mittal  wrote:
> Hi everyone,
> I have been using kubuntu plasma 5 via VMware Workstation 9.0 for porting an
> application to kf5,everything was working perfectly but when i tried logging
> in kubuntu today via same vmware, after accepting the login password and
> loading the system the screen faded and turned blank.
> The error message which i got from .xsession-error was:
>
> kded5 : org.kde.powerdevil.backlighthelper.brightnessvaluemax failed
> list is empty
> lock called
>
> I would like to know if there any solution for it or should i dual boot my
> laptops's main memory and try working on kubuntu from there.?
> --
> Regards,
> Anu.
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

Something I've seen doing a plasma 5 kubuntu user today is:
- getting the blank screen.
- opening a konsole
- killall plasmashell
- plasmashell

It worked for him, still it seems to be a downstream problem.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: KF5Avogadro

[Aleix Pol]

On Fri, Dec 26, 2014 at 11:32 AM, anu mittal  wrote:
> Hi ,
>
> while building cmake i got the following error and
>
> i have already installed the binary package for Avogadro by
>
> apt-get install libavogadro-dev
>
> CMake Warning at /usr/share/ECM/find-modules/FindKF5.cmake:75
> (find_package):
>   Could not find a package configuration file provided by "KF5Avogadro" with
>   any of the following names:
>
> KF5AvogadroConfig.cmake
> kf5avogadro-config.cmake
>
>   Add the installation prefix of "KF5Avogadro" to CMAKE_PREFIX_PATH or set
>   "KF5Avogadro_DIR" to a directory containing one of the above files.  If
>   "KF5Avogadro" provides a separate development package or SDK, be sure it
>   has been installed.
> Call Stack (most recent call first):
>   CMakeLists.txt:8 (find_package)
>
> -- Could NOT find KF5Avogadro: found neither KF5AvogadroConfig.cmake nor
> kf5avogadro-config.cmake
> CMake Error at
> /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108
> (message):
>   Could NOT find KF5 (missing: Avogadro) (found version "5.3.0")
> Call Stack (most recent call first):
>   /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315
> (_FPHSA_FAILURE_MESSAGE)
>   /usr/share/ECM/find-modules/FindKF5.cmake:111
> (find_package_handle_standard_args)
>   CMakeLists.txt:8 (find_package)
>
> -- Configuring incomplete, errors occurred!
>
> It says "Could NOT find KF5Avogadro" even after having the binary package
> installed,How can i resolve it?
>
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

Like I said before, KF5 prefix is only for KDE Frameworks.

Aleix

[1] https://projects.kde.org/projects/frameworks

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Unable to upload patch file to review board.

[Aleix Pol]

On Sun, Dec 28, 2014 at 1:36 PM, anu mittal  wrote:
> Hi everyone,
> I created a patch file (git format-patch -n --full-index HEAD^) but unable
> to upload at Review board.
> Error shown "The uploaded diff uses short revisions, but Review Board
> requires full revisions.
> Please generate a new diff using the --full-index parameter."
> I also tired creating diff file, but it showed the same error.
> Somebody help me with a solution
> diff file link: http://pastebin.com/50XxGWJx
>
> --
> Regards,
> Anu.
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

Just do "git diff origin/master". It should be enough.

Cheers!
Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Last and third CI IRC meeting

[Aleix Pol]

On Mon, Jan 5, 2015 at 10:04 PM, Mario Fux  wrote:
> Morning
>
> A bit late be here is a link to that last IRC meeting about KDE's CI stuff:
> https://notes.kde.org/public/CI_IRC_Meeting_02
>
> https://notes.kde.org/p/CI_IRC_Meeting_02 <= is the link where you can edit
> ;-)
>
> For the next meeting we are doing another Doodle:
> http://doodle.com/pb6a7xaur5wduds5
> to get as many participants from as many timezones as possible.
>
> Cu
> Mario

It could be interesting to have a kanban board for CI, so we all know
what's going on?
Feel free to add things in the SDK one [1]

Aleix

[1] https://todo.kde.org/?controller=board&action=show&project_id=13

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: kgeography master is now KF5 based

[Aleix Pol]

On Sun, Jan 18, 2015 at 11:29 PM, Albert Astals Cid  wrote:
> Just a heads up.
>
> Cheers,
>   Albert

Hurray! \o/

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Documentation for KF5

[Aleix Pol]

On Mon, Jan 19, 2015 at 4:40 PM, Olivier CHURLAUD  wrote:
> Dear all,
>
> I'm looking for documentation about KF5 projects. I found a lot of things on
> techbase.kde.org but it often seems to be old and deprecated (often the
> newest chapter is about kde4 and no TODO or whatever about the future
> appears concerning kf5).
>
> Is there another resource website? Where should I look to?

You can also look in here in the API documentation:
http://api.kde.org/frameworks-api/frameworks5-apidocs/

Hope this helps,
Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Porting Kalzium

[Aleix Pol]

n Sun, Jan 25, 2015 at 6:48 PM, anu mittal  wrote:

> Hi,
> Where do i need to make these changes?
> KDE_IMPORT OpenBabel2Wrapper is no where defined  in .h file or in any
> cmake.
> I can also not find any kdemacro.h.cmake file in my project Kalzium.
>
> On Sun, Jan 25, 2015 at 4:30 PM, Tomas Mecir  wrote:
>
>> Replacing KDE_IMPORT with Q_DECL_IMPORT should fix that.
>>
>> 2015-01-24 17:56 GMT+01:00 anu mittal :
>>
>>> Can anybody please give me hint, how to solve the issue shown?
>>> openbabel2wrapper.h contains the code:-
>>>
>>> class COMPOUNDVIEWER_EXPORT OpenBabel2Wrapper
>>> {
>>> public:
>>> /**
>>>  * This class reads the molecule in the file @p filename. It returns
>>> 0 if
>>>  * the file couldn't be read.
>>>  */
>>> static Avogadro::Molecule *readMolecule(const QString& filename);
>>>
>>> bool writeMolecule(const QString& filename, Avogadro::Molecule *);
>>>
>>> QString getFormula(Avogadro::Molecule *molecule);
>>>
>>> QString getPrettyFormula(Avogadro::Molecule *molecule);
>>> };
>>>
>>> and the issues shown are:
>>> http://pastebin.com/cZyYtyPU
>>>
>>> Please find the attachment which shows the snippet.
>>>
>>> --
>>> Regards,
>>> Anu.
>>>
>>
You can either do as Tomas says or epend on KF5::KDELibs4Support.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: KDE backward compatibility issue

[Aleix Pol]

On Fri, Jan 30, 2015 at 11:41 AM, Vasily Khoruzhick  wrote:
> Hi,
>
> I'd like to rise KDE backward compatibility issue once again.
>
> I've read [1] and [2] and as far as I understand, dropping xembed
> support was more political decision than technical difficulty. Please
> kindly understand that breaking applications for users is a no-go.
> I'd like to remind a situation when KDE was broken by a change in
> kernel API (IIRC it happened several times). But since kernel policy
> is "we never break userspace", these changes were reverted.
>
> As a software developer and a KDE user I'd like to see similar
> approach in KDE. Nowadays KDE is a software platform, not only a DE,
> it provides some APIs to other applications. So KDE's situation is
> somewhat similar to kernel's - you should not break backward
> compatibility for older applications.
>
> There're some proprietary applications using xembed tray and Qt5 <
> 5.4, for example - dropbox and viber. There's no way to fix them. As
> for GTK apps - it's required to add libappindicator support to the
> application, and it's not what app devs are willing to do (correct me
> if I'm wrong). So proposed workaround requires some work for app devs.
> And I suspect that they don't understand why THEY need to fix the
> thing YOU broke.
>
> Looking at all changes happened to KDE for several past years I've an
> impression that some KDE devs suffer from NIH syndrom. Broken system
> tray (and using instead specification which wasn't adopted by all
> other DEs), nepomuk -> baloo transition, no KDE PIM (once again... I
> remember times when I lost all local mail archive during transition
> from kmail 1 to kmail 2), missing support for autostarting scripts,
> one more rework of solid (it isn't dropped yet?) - battery indicator
> always shows that battery is charging... Etc, etc.
>
> I understand that some of these issues we'll be addressed within
> several KDE releases, but it is somewhat like 1 year. Guys, do you
> undestand that you propose to users non-complete and somewhat broken
> software for at least one year?
>
> We (KDE users) have already seen issues like that back in KDE 4.0-4.1 times.
>
> Guys, could anyone tell me what prevents you from making transition to
> KDE 5 smoother? What's the reason of dropping legacy support? What's
> the reason of breaking non-KDE applications?
>
> [1] http://blog.martin-graesslin.com/blog/2014/03/system-tray-in-plasma-next/
> [2] http://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Do you have sni-qt installed?

It reduced the problem for me.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: LabPLot POrt

[Aleix Pol]

On Mon, Feb 16, 2015 at 2:30 PM, Garvit Khatri  wrote:
> Hi All,
>
> I am porting LabPlot app. I am getting the following error along with Ok,
> Apply, Cancel ans Default not in scope error as well. for that i used
> QDialogButtonBox::Ok. This solved problem for Ok, Apply and Cancel but not
> for Default. Can anyone help me with this.
>
> /home/garvitdelhi/dev/sok/labplot_port/src/kdefrontend/SettingsDialog.cpp:54:
> error: 'setButtons' was not declared in this scope
>  setButtons(Ok | Apply | Cancel | Default);
>  ^
>
> /home/garvitdelhi/dev/sok/labplot_port/src/kdefrontend/SettingsDialog.cpp:55:
> error: 'setDefaultButton' was not declared in this scope
>  setDefaultButton(Ok);
> ^
>
> /home/garvitdelhi/dev/sok/labplot_port/src/kdefrontend/SettingsDialog.cpp:55:
> error: 'setDefaultButton' was not declared in this scope
>  setDefaultButton(Ok);
> ^
>
> Cheers,
> Garvit Khatri
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

http://doc-snapshot.qt-project.org/qt5-5.4/qdialogbuttonbox.html#StandardButton-enum

For setDefaultButton, you can use setFocus, although QDialogButton box
should use a sane default anyway.

Aleix

PS: http://hackles.org/strips/cartoon2.png I miss hackles <3

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: [Labplot-devel] LabPLot POrt

[Aleix Pol]

On Mon, Feb 16, 2015 at 4:09 PM, Garvit Khatri  wrote:
> Hi Aleix,
>
> Thanks for help but do you have any reference for error: 'setButtons' was
> not declared in this scope.
>
> Thank you
>
> Cheers,
> Garvit Khatri
>
> On Mon, Feb 16, 2015 at 7:19 PM, Aleix Pol  wrote:
>>
>> On Mon, Feb 16, 2015 at 2:30 PM, Garvit Khatri 
>> wrote:
>> > Hi All,
>> >
>> > I am porting LabPlot app. I am getting the following error along with
>> > Ok,
>> > Apply, Cancel ans Default not in scope error as well. for that i used
>> > QDialogButtonBox::Ok. This solved problem for Ok, Apply and Cancel but
>> > not
>> > for Default. Can anyone help me with this.
>> >
>> >
>> > /home/garvitdelhi/dev/sok/labplot_port/src/kdefrontend/SettingsDialog.cpp:54:
>> > error: 'setButtons' was not declared in this scope
>> >  setButtons(Ok | Apply | Cancel | Default);
>> >  ^
>> >
>> >
>> > /home/garvitdelhi/dev/sok/labplot_port/src/kdefrontend/SettingsDialog.cpp:55:
>> > error: 'setDefaultButton' was not declared in this scope
>> >  setDefaultButton(Ok);
>> > ^
>> >
>> >
>> > /home/garvitdelhi/dev/sok/labplot_port/src/kdefrontend/SettingsDialog.cpp:55:
>> > error: 'setDefaultButton' was not declared in this scope
>> >  setDefaultButton(Ok);
>> > ^
>> >
>> > Cheers,
>> > Garvit Khatri
>> >
>> >
>> >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >>> unsubscribe
>> >>> <<
>> >
>>
>>
>> http://doc-snapshot.qt-project.org/qt5-5.4/qdialogbuttonbox.html#StandardButton-enum
>>
>> For setDefaultButton, you can use setFocus, although QDialogButton box
>> should use a sane default anyway.
>>
>> Aleix
>>
>> PS: http://hackles.org/strips/cartoon2.png I miss hackles <3
>>
>>
>> --
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>> ___
>> Labplot-devel mailing list
>> labplot-de...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/labplot-devel
>
>

You have to call setButtons on QDialogButtonBox, not on QDialog.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: [Labplot-devel] LabPLot POrt

[Aleix Pol]

On Mon, Feb 16, 2015 at 5:23 PM, Garvit Khatri  wrote:
>
> i am not getting you I tried this:
>
> setButtons(QDialogButtonBox::Ok | QDialogButtonBox::Apply |
> QDialogButtonBox::Cancel | QDialogButtonBox::Reset);
>
>
> but still the same error.The class in which i am using this is inherited
> from KPageDialog.
>
>
> Code: http://pastebin.com/95FGKXea
>
>
>
> Cheers,
> Garvit Khatri
>
> On Mon, Feb 16, 2015 at 8:47 PM, Aleix Pol  wrote:
>>
>> On Mon, Feb 16, 2015 at 4:09 PM, Garvit Khatri 
>> wrote:
>> > Hi Aleix,
>> >
>> > Thanks for help but do you have any reference for error: 'setButtons'
>> > was
>> > not declared in this scope.
>> >
>> > Thank you
>> >
>> > Cheers,
>> > Garvit Khatri
>> >
>> > On Mon, Feb 16, 2015 at 7:19 PM, Aleix Pol  wrote:
>> >>
>> >> On Mon, Feb 16, 2015 at 2:30 PM, Garvit Khatri 
>> >> wrote:
>> >> > Hi All,
>> >> >
>> >> > I am porting LabPlot app. I am getting the following error along with
>> >> > Ok,
>> >> > Apply, Cancel ans Default not in scope error as well. for that i used
>> >> > QDialogButtonBox::Ok. This solved problem for Ok, Apply and Cancel
>> >> > but
>> >> > not
>> >> > for Default. Can anyone help me with this.
>> >> >
>> >> >
>> >> >
>> >> > /home/garvitdelhi/dev/sok/labplot_port/src/kdefrontend/SettingsDialog.cpp:54:
>> >> > error: 'setButtons' was not declared in this scope
>> >> >  setButtons(Ok | Apply | Cancel | Default);
>> >> >  ^
>> >> >
>> >> >
>> >> >
>> >> > /home/garvitdelhi/dev/sok/labplot_port/src/kdefrontend/SettingsDialog.cpp:55:
>> >> > error: 'setDefaultButton' was not declared in this scope
>> >> >  setDefaultButton(Ok);
>> >> > ^
>> >> >
>> >> >
>> >> >
>> >> > /home/garvitdelhi/dev/sok/labplot_port/src/kdefrontend/SettingsDialog.cpp:55:
>> >> > error: 'setDefaultButton' was not declared in this scope
>> >> >  setDefaultButton(Ok);
>> >> > ^
>> >> >
>> >> > Cheers,
>> >> > Garvit Khatri
>> >> >
>> >> >
>> >> >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >> >>> unsubscribe
>> >> >>> <<
>> >> >
>> >>
>> >>
>> >>
>> >> http://doc-snapshot.qt-project.org/qt5-5.4/qdialogbuttonbox.html#StandardButton-enum
>> >>
>> >> For setDefaultButton, you can use setFocus, although QDialogButton box
>> >> should use a sane default anyway.
>> >>
>> >> Aleix
>> >>
>> >> PS: http://hackles.org/strips/cartoon2.png I miss hackles <3
>> >>
>> >>
>> >>
>> >> --
>> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> >> from Actuate! Instantly Supercharge Your Business Reports and
>> >> Dashboards
>> >> with Interactivity, Sharing, Native Excel Exports, App Integration &
>> >> more
>> >> Get technology previously reserved for billion-dollar corporations,
>> >> FREE
>> >>
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>> >> ___
>> >> Labplot-devel mailing list
>> >> labplot-de...@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/labplot-devel
>> >
>> >
>>
>> You have to call setButtons on QDialogButtonBox, not on QDialog.
>>
>> Aleix
>
>

http://api.kde.org/frameworks-api/frameworks5-apidocs/kwidgetsaddons/html/classKPageDialog.html#aa9c62f4350bcfefa0c11607b3dfed0d0

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Macaw-Movies: KDE-Incubator

[Aleix Pol]

On Wed, Feb 25, 2015 at 3:31 PM, Kevin Funk  wrote:
> On Wednesday 25 February 2015 11:30:48 Olivier CHURLAUD wrote:
>> Hey!
>>
>> We began last year to write a program to manage a video collection. For
>> now, it's hosted on Github and we are only 2 people working on it. We
>> realize that if we code this just the both of us we will miss a lot of
>> (good) advices from others and we may end with an unsustainable code.
>> We think of KDE community as an amazing and inspiring group from witch
>> we can learn a lot. Besides, we think our project as a useful tool for
>> movie collection management that could enrich KDE apps. So we would need
>> a mentor and some...guideline for the beginning of the process.
>>
>> It's a little long below We tried to describe the state of the art
>> honestly.
>> We hope it will work!
>
> Where are teh screenshots? ;)
>
> Get potential users interested by actually showing off some of your features
> in a wise way.
>
> Greets
>
>>
>> About us
>> 
>> We are two frenchies: I'm studying in Berlin, and Seb is working in France.
>> .
>> About the Macaw-Movies
>> ==
>>   * Macaw-Movies is written in C++ with the Qt Framework (5.4)
>>   * It is written for Linux/Mac/Windows (developed with Linux, and
>> compiles and works also on Mac/Windows)
>>
>>   * Our github is https://github.com/macaw-movies
>>   * We began a blog https://macawmovies.wordpress.com to try to be more
>> visible.
>>   * We have a logo =D
>>
>> How far is the project from a release
>> =
>>   * All the most important functions are written
>>   * We have a first acceptable design (to be improved, though)
>>   * The documentation is for now almost nonexistent  but we since the
>> core seems to be stable, we are going to write it (a draft) in the next
>> few weeks.. Maybe a first v0.1 could be released on the end of april?
>>
>> How clean is the project?
>> ==
>>   * We tried to follow rules we found on Google projects, KDE and so on.
>>   * Not enough documentation, still some black magic here and there.
>>
>> Cheers!
>>
>> Olivier & Seb
>
> --
> Kevin Funk | kf...@kde.org | http://kfunk.org
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>

Yes... I looked for screenshots as well... ^^'.

Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: QtQuick: Why is it relevant

[Aleix Pol]

On Fri, Mar 6, 2015 at 1:13 AM, Olivier CHURLAUD  wrote:
> Hi,
>
> I saw that one of the great feature of Qt was QtQuick, and that KDE chose to
> use this a lot. I went lately from fully written widgets to QtDesigner
>
> What are the real advantages of QtQuick over the old fashion Qt (I don't
> know how to call it)? Are there drawbacks? (The real question is Why should
> I write my app with QtQuick instead of old fashion Qt?)

From my point of view, a reason to use QtQuick over QtWidgets is that
you can essentially do more things. QtWidgets is designed to integrate
properly on desktop environments, that wasn't even part of the plan in
QtQuick not so long ago (also not the case anymore).
So I wouldn't go for QtWidgets if you want it to be touch-friendly, if
you want any animations or if you want to think about how information
will be presented specifically. On the other hand, there's a set of
use-cases that QtWidgets covers very well, then it's fine to use it
just as well.

>
> Another question is: are there resources (on KDE or somewhere else) to
> see/learn the power of QtQuick? Be cause when I read this for instance
This pops to mind, I haven't read it personally. I usually use the
official Qt documentation.
http://qmlbook.github.io/

> https://techbase.kde.org/Development/Tutorials/Plasma4/QML/GettingStarted it
> doesnt seems to be well designed for handling contents comming from a
> database (or very dynamic content)

The way to integrate these big chunks of contents is through models.
Keep in mind that the views in QtQuick and QtQuick Controls are very
different than those in QtWidgets, so the ways you'd approach the
problems are slightly different.

HTH,
Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<