Re: Possible to move some KF5 frameworks to invent?

[Albert Astals Cid]

El dilluns, 12 d’agost de 2019, a les 11:38:50 CEST, Ben Cooksley va escriure:
> Those familiar to Git will be aware that it is very much possible to
> limit the scope of hooks like our Notification hooks, while still
> allowing them to be caught when entering branches that are subject to
> Notification. At this time the only proposals i've seen for this have
> been for "everything but master and stable branches" which
> unfortunately is not a scalable solution we can support due to the
> significant variance in schemes used for naming stable branches across
> different projects (not without pushing the maintenance role for
> handling all these different naming schemes on to Sysadmin)

You have not read my email then ;)

I suggested to do it the other way around and allow force push on branches 
named review_*

This solves the problem of "naming of important branches is not consistent" by 
making consistent the "naming of the non important branches"

Cheers,
  Albert

> 
> >
> > Regards.
> > --
> > Kevin Ottens, http://ervin.ipsquad.net
> >
> > enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en
> 
> Regards,
> Ben
> 

Re: Possible to move some KF5 frameworks to invent?

[Albert Astals Cid]

El diumenge, 11 d’agost de 2019, a les 21:00:13 CEST, Ben Cooksley va escriure:
> On Mon, Aug 12, 2019 at 2:53 AM Albert Astals Cid  wrote:
> >
> > El diumenge, 11 d’agost de 2019, a les 12:33:19 CEST, Christoph Cullmann va 
> > escriure:
> > > Hi,
> > >
> > > is it possible to move individual framework modules over to
> > > invent.kde.org or will that be
> > > done at once somewhen in the future?
> >
> > Seems kde-frameworks-devel would be a better list to ask about this.
> >
> > >
> > > Would be interested to move syntax-highlighting and ktexteditor if that
> > > is possible.
> > > But if that shall be done as bulk in the future I can wait ;=)
> >
> > I personally feel the loss of "email gets sent to kde-frameworks-devel on 
> > MR" is a problem.
> >
> > Also i remember dfaure not being very thrilled about the "not possible to 
> > force push to 'my branches' on the main repo" issue.
> 
> There has been no change with regard to force pushes - they were
> restricted on main line repositories back when we initially moved to
> Git and have continued to be restricted through our move to
> Phabricator (from Reviewboard) and now on to Gitlab.

Yes and no.

Yes, there's been no change with regard to force pushes

*BUT*

With phabricator you can do a "force push" to your review[1], with gitlab you 
can not[2].

So while technically there has no been a change, the resulting workflow is now 
that you can't do the same you used to do.

So having a regexp (e.g. something like all branches starting by review_*) that 
allowed all those branches to be force pushed would help being able to maintain 
the workflow in which without having to fork a repository you can update your 
commits for reviews.

Cheers,
  Albert

[1] i.e. you make changes to your commit, run arc diff again and the new commit 
shows up in the existing review as a single commit
[2] without having your own fork of a repository, that is annoying for various 
reasons

> 
> >
> > Cheers,
> >   Albert
> 
> Regards,
> Ben
> 
> >
> > >
> > > Greetings
> > > Christoph
> > >
> > >
> >
> >
> >
> >
> 

Re: Possible to move some KF5 frameworks to invent?

[Albert Astals Cid]

El diumenge, 11 d’agost de 2019, a les 12:33:19 CEST, Christoph Cullmann va 
escriure:
> Hi,
> 
> is it possible to move individual framework modules over to 
> invent.kde.org or will that be
> done at once somewhen in the future?

Seems kde-frameworks-devel would be a better list to ask about this.

> 
> Would be interested to move syntax-highlighting and ktexteditor if that 
> is possible.
> But if that shall be done as bulk in the future I can wait ;=)

I personally feel the loss of "email gets sent to kde-frameworks-devel on MR" 
is a problem.

Also i remember dfaure not being very thrilled about the "not possible to force 
push to 'my branches' on the main repo" issue.

Cheers,
  Albert

> 
> Greetings
> Christoph
> 
> 

Re: Tipping the apple cart?

[Albert Astals Cid]

El dimarts, 2 de juliol de 2019, a les 8:42:26 CEST, Boudewijn Rempt va 
escriure:
> On maandag 1 juli 2019 23:34:14 CEST Albert Astals Cid wrote:
> > Or were you mostly getting patches sent as plain diffs uploaded to 
> > phabricator instead of by using arc? 
> 
> Yes, nearly nobody uses arc.

As a data point i went over the 50 most recent phabricator code reviews, stats 
say

48 uploaded using arc
2 uploaded not using arc

Then i went over the 20 most recent phabricator Krita code reviews, stats say

15 uploaded using arc
5 uploaded not using arc

Then again this is counting MRs not counting people, it could be that all the 
15 arc MR where made by 2 people and the other 5 by 5 different people, i was 
bored enough to check that.

I understand that you have the impression that nearly nobody uses arc, but it'd 
seem to me that stats show otherwise (but would need more investigation about 
it).

Anyway, didn't gitlab have the "send patch by email to create a MR" 
functionality?

Would that solve your issue?


> > 
> > > * Gitlab has an exceedingly confusing UI where many options are very hard 
> > > to find. The first thing I want to see when I get a MR is the diff, 
> > 
> > I guess that's your opinion, having the actual textual description and 
> > discussion is also very valuable, since you can get an overview on the MR 
> > quite fast.
> > 
> > > and that means scrolling and hunting for a very small button.
> > 
> > You mean the "Changes" button? I find it of adequate size
> 
> I guess that's _your_ opinion.

Yes, when i write "I find it of adequate size" i thought it was clear it was 
"I" stating that "find it" of "adequate size".

> > > * using the label system for approving a MR is cumbersome
> > 
> > What does this mean? 
> 
> Check that MR I linked above and you can figure out yourself how we're using 
> labels. It's the only mechanism we've found that would get close to the 
> workflow needed to pass a MR from "needs review" to "needs changes" to 
> "approved".

Right i see. Would using the "thumbs down" to say "needs changes" make sense 
instead  of using the label? I guess it was more the original idea they had.

Cheers,
  Albert

Re: Tipping the apple cart?

[Albert Astals Cid]

El dilluns, 1 de juliol de 2019, a les 9:42:34 CEST, Boudewijn Rempt va 
escriure:
> On maandag 1 juli 2019 09:10:59 CEST Valorie Zimmerman wrote:
> > 
> > This tells me that Gitlab can be worse, which is not surprising.
> > 
> > And can it be better? Will some folks who have a good experience with this
> > on Gitlab speak up?
> > 
> > This is something that all of us want and need to know.
> > 
> 
> Krita has switched from Phabricator to Gitlab a while ago, so maybe I can add 
> our experience. It's not that great, though. 
> 
> Bad:
> 
> * For new users who want to submit one or two patches, gitlab is way harder 
> to use. They need much more help and handholding.

Really? It uses the workflow all the other major review systems use, arc is a 
really weird tool (on some distros even hard to install)

Or were you mostly getting patches sent as plain diffs uploaded to phabricator 
instead of by using arc? 

> * Gitlab has an exceedingly confusing UI where many options are very hard to 
> find. The first thing I want to see when I get a MR is the diff, 

I guess that's your opinion, having the actual textual description and 
discussion is also very valuable, since you can get an overview on the MR quite 
fast.

> and that means scrolling and hunting for a very small button.

You mean the "Changes" button? I find it of adequate size

> * gitlab is slow

That's not the perception i have at all.

> * you cannot have more than one reviewer for a MR

You can have as many reviewers as you want, i guess you mean you can't have 
more than one assignee.

> * using the label system for approving a MR is cumbersome

What does this mean? 

Cheers,
  Albert

Re: Tipping the apple cart?

[Albert Astals Cid]

El dilluns, 1 de juliol de 2019, a les 8:46:39 CEST, Kai Uwe Broulik va 
escriure:
> Hi,
> 
>  > In our move to Gitlab, we can do better.
> 
> Given Gitlab emails contain even less information and context than 
> Phabricator which themselves contained even less information and context 
> than Reviewboard back then, I don't see how this will change or improve 
> anything.

What are you missing?

> 
>  > Phab sends out an email for every event and comment
> 
> And Gitlab even unexpectedly submits the comments as soon as you close 
> the editor rather than in bulk as I would have expected from a proper 
> reviewing workflow.

Most of the "modern" systems do this, i very much like this against the fact 
that people made comments on phabricator and then never submitted them because 
you had to scroll to the bottom and press the "send" button.

Cheers,
  Albert

> 
> Cheers
> Kai Uwe
> > 
> 
> 

What means having an application in "KDE Applications" - was - Re: keurocalc status

[Albert Astals Cid]

El dijous, 6 de juny de 2019, a les 12:03:17 CEST, Jonathan Riddell va escriure:
> On Thu, 6 Jun 2019 at 07:15, Eric Bischoff  wrote:
> 
> > Le mercredi 5 juin 2019, 18:23:50 CEST Jonathan Riddell a écrit :
> > > keurocalc has been ported to KF5 but there seems to have been no release.
> > > Does anyone plan to make a release?  Or should it go into KDE
> > Applications?
> > > Or should it be marked as unmaintained?
> > It is maintained (by me), but I don't know how to "make a release". I
> > would
> > need help on that. With some help, I'd be happy to do it.
> >
> 
> The easiest way to get it released is to ask for it to be moved into KDE
> Applications and then that gets taken care of for you.

Can we please discuss what being in KDE Applications is first?

You're telling apps they can join KDE Applications if they want, so to you it's 
just "release as a service".

I disagree, to me it's a "we as a community vouch to try to maintain this to 
the best of our ability/time".

So [to me] adding more things to KDE Applications needs at least a vague 
consensus that it's worth making that kind of promise.

Opinions?

Cheers,
  Albert

> 
> Otherwise it's a case of following the page here
> https://community.kde.org/ReleasingSoftware
> Much of it can be eased with the releaseme scripts which does the branching
> and tarring and tagging for you.
> 
> Let me know if you need help.
> 
> Good luck with the surgery.
> 
> Jonathan
> 

Re: konqueror.org

[Albert Astals Cid]

El dissabte, 1 de juny de 2019, a les 13:07:41 CEST, Jonathan Riddell va 
escriure:
> Can you call konqueror.org website unmaintained?  The screenshots are all
> from KDE 4 times.  We can just make it forward to the new
> kde.org/applications page instead

Or just update the screenshots and all its contents are still valid and much 
more complete than whatever is there in kde.org/applications.

Cheers,
  Albert

> 
> Jonathan
> 

Re: Moving Konsole to Gitlab

[Albert Astals Cid]

El dissabte, 25 de maig de 2019, a les 13:10:09 CEST, Tomaz Canabrava va 
escriure:
> People,
> 
> I'v talked to Kurt and Nate this week about my current frustrations with
> Phabricator, last week I got a few important patches messed up in the way
> that only phab can do for you. And we agreed that a move to Gitlab is
> desired, I talke to ben about it and he made me aware that this can impact
> KDE release schedule.
> 
> So, here I'm, I don't know what can happen if a kde-core app moves to
> gitlab now, I know that most of the apps there are from extragear. Maybe
> it's time to shift more projects to it.
> 
> I'm adding Albert as cc since I belive that he knows this more than I do.

There's already several(4) KDE Applications being released from invent.k.o

It isn't really a problem for us.

Cheers,
  Albert

> 
> Best,
> Tomaz
> 

Re: konsole website

[Albert Astals Cid]

El divendres, 24 de maig de 2019, a les 18:10:35 CEST, Jonathan Riddell va 
escriure:
> can we call this site dead? https://konsole.kde.org/

Looks like it, but to be doubly sure i think you should email the person under 
the "konsole.kde.org Webmaster" link

Cheers,
  Albert

> 
> Updating the metadata e.g.
> http://apps.kde.org.uk/applications/system/org.kde.konsole
> 
> Jonathan
> 

Re: kaudiocreator to unmaintained

[Albert Astals Cid]

El dimarts, 21 de maig de 2019, a les 18:50:36 CEST, Nate Graham va escriure:
> 
> On 5/21/19 10:48 AM, Kevin Ottens wrote:
> > I'd like it to be part of KDE Applications. Unlike Zanshin I'd rather have
> > this one tied to the Applications release cycle. That being said, it's been
> > eons since I had anything in the regular applications collection. Could
> > someone refresh me on what it entails to "make release"? Back in the day it
> > was fairly transparent, if that's still so low on work I can easily say 
> > yes...
> > if not I'll have to evaluate.
> 
> If it's a part of KDE Applications, the apps release team will take care 
> of that for you. :)
> 
> Sounds good, let's get kaudiocreator added to the bundle.

I don't want to block on this, but given it seems relatively likely the 
"community" would be doing maintaince on this if it joins KDE Applications, I'd 
really welcome if this wouldn't depend on kdelibs4support.

Has anyone attempted to port away from it?

Cheers,
  Albert

> 
> Nate
> 
> 

Re: Review Request: plasma-thunderbolt

[Albert Astals Cid]

El dimecres, 15 de maig de 2019, a les 15:27:07 CEST, Daniel Vrátil va escriure:
> Hi all,
> 
> plasma-thunderbolt is a new repo containing, you guessed it, Thunderbolt KCM 
> for Plasma. I initially submitted the code as a patch against plasma-desktop 
> [0], where it got reviewed, but it was ultimately decided to better put it 
> into a separate repository, since it's not just a KCM but also a library and 
> a 
> KDED module. I have backported all the changes from the Phabricator review 
> back to the repository, so the code in the repo is identical to the one in 
> the 
> Phab review (minus buildsystem changes and a small build fix for clang).
> 
> However, since this is still a new code, it must formally pass through 
> kdereview before I can submit it into Plasma as a new module.
> 
> Thus I'd kindly ask you to take one more look at the codebase [1] and let me 
> know if there are any more issues to fix, or if we can proceed to include 
> this 
> in the next Plasma release.

There's this cmake warning

CMake Warning at /usr/lib64/cmake/KF5Package/KF5PackageMacros.cmake:74 
(message):
  KPackage components should be specified in reverse domain notation.
  Appstream information won't be generated for kcm_bolt.
Call Stack (most recent call first):
  src/kcm/CMakeLists.txt:22 (kpackage_install_package)




clazy complains about a few Q_PROPERTY that should ideally either have a NOTIFY 
signal or be marked as CONSTANT

it also complains about a few const slots that return values. Seems like what 
you want is to actually mark them as invokable/scriptable and not as slots?

Cheers,
  Albert

> 
> Thanks,
> - Dan
> 
> [0] https://phabricator.kde.org/D19011
> [1] https://cgit.kde.org/plasma-thunderbolt.git
> 
> 

Re: ksnapshot to unmaintained

[Albert Astals Cid]

Weakly suggest emailing kde-graphics-devel mailing list about this.

Cheers,
  Albert

El divendres, 10 de maig de 2019, a les 0:09:29 CEST, Jonathan Riddell va 
escriure:
> I'd like to propose moving ksnapshot to unmaintained, it's had no code
> commits since 2017 and still uses KDElibs4 and the functionality is
> replaced by Spectacle.
> 
> Jonathan
> 

Re: krecipes to unmaintained

[Albert Astals Cid]

You should email the krecipes-devel mailing list about this.

Cheers,
  Albert

El divendres, 10 de maig de 2019, a les 0:16:47 CEST, Jonathan Riddell va 
escriure:
> I'd like to propose moving krecipes to unmaintained.  It still uses
> kdelibs4 and has had no feature commits since 2016.
> 
> Jonathan
> 

Re: Welcome CuteHMI

[Albert Astals Cid]

El dissabte, 13 d’abril de 2019, a les 17:50:23 CEST, Jonathan Riddell va 
escriure:
> Please welcome CuteHMI to KDE, it has now passed incubator into Playground

Welcome :)

> 
> description: CuteHMI is an open-source HMI (Human Machine Interface)
> software written in C++ and QML, using Qt libraries as a framework.
> 
> https://community.kde.org/Incubator/Incubated_Projects
> 
> placeholder website: https://cutehmi.kde.org/
> 
> matrix:#cutehmi:kde.org
> 
> https://community.kde.org/File:Cutehmi.png
> 
> https://cgit.kde.org/cutehmi.git/

Wow, a qbs using-codebase :o

Do you plan to "fix" that now that qbs is "dead"?

Cheers,
  Albert

> 
> Jonathan
> 

Re: [SECURITY] CVE-2019-7443 (kauth) in kdelibs

[Albert Astals Cid]

El dimarts, 19 de març de 2019, a les 11:39:54 CET, Hugo Lefeuvre va escriure:
> Hi,
> 
> I'm Hugo Lefeuvre, from the Debian LTS team. I am currently working on
> CVE-2019-7443 which appears to affect not only kauth but also kdelibs
> since it ships a very similar kdecore/auth/backends/dbus/DBusHelperProxy.cpp
> file[0].
> 
> As far as I am aware the fix for CVE-2019-7443 was not applied to
> kdelibs. Is there a specific reason for that? Do you plan addressing this
> potential vulnerability in kdelibs as well?

kdelibs last release was 4.14.35 in August 2017.

kdelibs is no longer maintained. 

Qt 4 last release was 4.8.7 in May 2015.

Qt 4 is no longer maintained. 

Our suggestion is to stop using any qt4/kdelibs based software and move to the 
future if you're concerned about security and/or want to use maintained 
software.

Best Regards,
  Albert

> 
> CC-ing publicly-archived debian-...@lists.debian.org
> 
> regards,
> Hugo Lefeuvre
> 
> [0] https://bugs.debian.org/922727
> 
> 

Re: KDiff3 1.8 release.

[Albert Astals Cid]

El dissabte, 16 de març de 2019, a les 18:13:49 CET, Jonathan Riddell va 
escriure:
> Looks good from a quick compile and run.
> 
> I take it you have no access to the obsolete sourceforge webpage?

I think this should really be our first priority, trying to either update or 
take down that page.

Cheers,
  Albert

> 
> I see Debian has a 1.7 release, where is that available?
> 
> Do you have any access to update
> https://www.linux-apps.com/content/show.php?content=9807 ?
> 
> I'm adding this to KDE neon dev unstable edition.
> 
> Eike is the Debian packaging managed in a repo somewhere?  Are you
> interested in making it part of the KDE Qt Debian team?
> 
> Jonathan
> 
> 
> 
> On Sat, 16 Mar 2019 at 14:11, Michael Reeves  wrote:
> >
> > Fixed now.
> >
> > On Thu, Mar 14, 2019, 4:31 AM Wolfgang Bauer  wrote:
> >>
> >> The latest change
> >> (https://cgit.kde.org/kdiff3.git/commit/?id=638bd5a02893dde4a1927abd0c8a611b3b3ab6a1)
> >> unfortunately breaks the build here:
> >>
> >> /usr/lib/gcc/i586-suse-linux/8/../../../../i586-suse-linux/bin/ld:
> >> CMakeFiles/kdiff3part.dir/pdiff.cpp.o: in function
> >> `debugLineCheck(Diff3LineList&, int, e_SrcSelector)':
> >> /home/abuild/rpmbuild/BUILD/kdiff3-1.7.95git/src/pdiff.cpp:82: undefined
> >> reference to `kdeMain()'
> >> /usr/lib/gcc/i586-suse-linux/8/../../../../i586-suse-linux/bin/ld:
> >> /home/abuild/rpmbuild/BUILD/kdiff3-1.7.95git/src/pdiff.cpp:96: undefined
> >> reference to `kdeMain()'
> >> ...
> >> and so on.
> >>
> >> Kind Regards,
> >> Wolfgang
> >>
> 

Re: liquidshell in kdereview

[Albert Astals Cid]

El dimarts, 12 de març de 2019, a les 9:46:19 CET, Tomaz Canabrava va escriure:
> On Tue, Mar 12, 2019 at 9:34 AM Martin Koller  wrote:
> >
> > On Montag, 11. März 2019 10:34:35 CET Tomaz Canabrava wrote:
> > > On Sun, Mar 10, 2019 at 1:25 PM Martin Koller  wrote:
> > > >
> > > > Hi,
> > > >
> > > > since some time has already passed and there was no conclusion, I'll 
> > > > try once again
> > > > to announce liquidshell.
> > > >
> > > > I have made adjustments to the README which now says:
> > > >
> > > > liquidshell is a basic Desktop Shell implemented using QtWidgets.
> > > >
> > > > Main Features:
> > > > - Wallpaper per virtual desktop
> > > > - No animations, low memory and CPU footprint
> > > > - Instant startup
> > > > - No use of activities
> > >
> > > How apps that deal with activities will work on? they will just
> > > silently ignore activities?
> >
> > Since I do not use activities, I have no idea.
> > But since liquidshell does not even offer anything related to activities,
> > why would an application face an issue with that in the first place ?
> 
> Because I could use plasma and activities and then install liquidshell
> to test, to discover that I'm unable to launch the application in the
> state that I left.
> I, as user, being unable to reach an already configured application
> state, would consider that Liquidshell has a bug related to the
> loading of applications.

Same as if you use Gnome Shell instead of liquidshell, no? 

If the application locks itself in a bad state depending the Desktop in use, 
that's a bug of the application not of the desktop.

Cheers,
  Albert

> 
> > --
> > Best regards/Schöne Grüße
> >
> > Martin
> > A: Because it breaks the logical sequence of discussion
> > Q: Why is top posting bad?
> >
> > ()  ascii ribbon campaign - against html e-mail
> > /\- against proprietary attachments
> >
> > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
> >
> >
> 

Re: liquidshell in kdereview

[Albert Astals Cid]

El diumenge, 10 de març de 2019, a les 13:25:14 CET, Martin Koller va escriure:
> Hi,
> 
> since some time has already passed and there was no conclusion, I'll try once 
> again
> to announce liquidshell.
> 
> I have made adjustments to the README which now says:
> 
> liquidshell is a basic Desktop Shell implemented using QtWidgets.
> 
> Main Features:
> - Wallpaper per virtual desktop
> - No animations, low memory and CPU footprint
> - Instant startup
> - No use of activities

I feel like this is still Plasma feature bad mouthing. To you it is somehow a 
feature because you think activities are bad, so that's why you list it as a 
feature, but honestly it is also a feature of GNOME Shell and almost every 
other single desktop environment out there, and they don't announce it, why 
should you?

Cheers,
  Albert

Re: KDE Review passes

[Albert Astals Cid]

El dissabte, 9 de març de 2019, a les 16:54:59 CET, Jonathan Riddell va 
escriure:
> We really do need to sort out the terminology for
> extragear/extra/self-released things.

Yes we do :)

Cheers,
  Albert

> 
> Jontahan
> 

Re: KDiff3 craft setup

[Albert Astals Cid]

El dijous, 7 de març de 2019, a les 11:33:16 CET, Kevin Funk va escriure:
> On Tuesday, 5 March 2019 21:11:11 CET Albert Astals Cid wrote:
> > El dimarts, 19 de febrer de 2019, a les 7:35:58 CET, Kevin Funk va escriure:
> > > On Monday, 18 February 2019 17:06:25 CET Michael Reeves wrote:
> > > > https://download.kde.org/stable/applications/18.12.1/src/kdiff3-18.12.1.
> > > > tar. xz
> > > > 
> > > > Get some one tell me how to change where it's trying to download from.
> > > > KDiff3 is not part of applications and doesn't follow the same
> > > > versioning.
> > > 
> > > Heya,
> > > 
> > > Could you please reconsider that decision and check whether it's not more
> > > worthwhile making kdiff3 part of KDE Applications? It will save you (as
> > > the
> > > maintainer) and others (distribution packagers) a major headache.
> > > 
> > > You'll be responsible for releasing kdiff3 now and in the future if you
> > > choose to do your own release schedule. Let me just say: It's not
> > > something which is particular entertaining in the long-term. Your KDiff3
> > > involvement will get less eventually, and then someone else needs to take
> > > over releasing it -- if it's part of the KDE Apps cycle it'll be done
> > > automatically, no matter what.
> > > 
> > > KDiff3 is not the type of application which needs its own release cycle,
> > > IMO, it's too small & "undynamic" [1] for that.
> > 
> > Just answering now because i did ignore an email named "KDiff3 craft setup"
> > since i don't know anything about craft and it seems now this is being used
> > as some kind of agreement that KDiff3 should be moved to KDE Applications.
> > 
> > Personally given KDiff3 has not had any release on its own for a long time I
> > would very much prefer to get a few releases on its own.
> > 
> > This way new features/fixes can be released sooner if needed and not tied to
> > the more strict KDE Applications schedule.
> 
> Well, I dont agree, but choose your pain :)
> 
> This might be true for the very first few releases, but after that you'd be 
> better off just taking part of the KDE Apps cycle.

Yes, that's exactly what i said (or wanted to say).

Cheers,
  Albert

Re: KDE Review reviews

[Albert Astals Cid]

El dijous, 7 de març de 2019, a les 17:33:27 CET, Jonathan Riddell va escriure:
> I've made a list of kdereview projects and their current status as I
> understand them and e-mailed the maintainers for updates

Cool :)

Do you think maybe it would have made more sense to do those update emails here 
(in the original thread of emails) so they would also be public?

Or do you feel private emails give you some more "sincere" answers?

Cheers,
  Albert

> https://community.kde.org/KDEReview
> (this is linked from the lifecycle wiki page).
> 
> Feel free to help keep that page up to date.
> 
> I moved kpeg and kdot to unmaintained as they haven't had any activity
> since we last discussed them in 2017.
> 
> Jonathan
> 

Re: KDiff3 craft setup

[Albert Astals Cid]

El dimarts, 19 de febrer de 2019, a les 7:35:58 CET, Kevin Funk va escriure:
> On Monday, 18 February 2019 17:06:25 CET Michael Reeves wrote:
> > https://download.kde.org/stable/applications/18.12.1/src/kdiff3-18.12.1.tar.
> > xz
> > 
> > Get some one tell me how to change where it's trying to download from.
> > KDiff3 is not part of applications and doesn't follow the same versioning.
> 
> Heya,
> 
> Could you please reconsider that decision and check whether it's not more 
> worthwhile making kdiff3 part of KDE Applications? It will save you (as the 
> maintainer) and others (distribution packagers) a major headache.
> 
> You'll be responsible for releasing kdiff3 now and in the future if you 
> choose 
> to do your own release schedule. Let me just say: It's not something which is 
> particular entertaining in the long-term. Your KDiff3 involvement will get 
> less eventually, and then someone else needs to take over releasing it -- if 
> it's part of the KDE Apps cycle it'll be done automatically, no matter what.
> 
> KDiff3 is not the type of application which needs its own release cycle, IMO, 
> it's too small & "undynamic" [1] for that.

Just answering now because i did ignore an email named "KDiff3 craft setup" 
since i don't know anything about craft and it seems now this is being used as 
some kind of agreement that KDiff3 should be moved to KDE Applications.

Personally given KDiff3 has not had any release on its own for a long time I 
would very much prefer to get a few releases on its own.

This way new features/fixes can be released sooner if needed and not tied to 
the more strict KDE Applications schedule.

There's also the matter of http://kdiff3.sourceforge.net/ being outdated/wrong. 
Do we have a plan to fix that?

Cheers,
  Albert

> 
> Regards,
> Kevin
> 
> 
> [1] "Undynamic" in a sense that we're likely not going to see drastic UI 
> changes on weekly basis which need to get out to users ASAP. At least for 
> kdiff3 I'd rather have a conservative approach in that regard, since it's a 
> complex tool by definition.
> 
> 
> 

Re: KDE's release script not functional on stable openSUSE

[Albert Astals Cid]

El dijous, 24 de gener de 2019, a les 11:28:59 CET, Jaroslaw Staniek va 
escriure:
> Hi Jonathan,
> The releaseme tools require ruby 2.3 while openSUSE 42.3 depends on 2.1.

According to https://repology.org/metapackage/ruby/versions you should have a 
ruby2.4 package available.

https://build.opensuse.org/package/show/openSUSE:Leap:42.3:Update/ruby2.4

Cheers,
  Albert

Re: Fwd: Kexi_flatpax fix and question

[Albert Astals Cid]

As far as i know:
 * The infrastructure we have at this point in KDE is more targeted to provide 
nightlies.
 * If you want to provide stable flatpak, the current recommended solution is 
do it via flathub (like we do for several of our apps already).

Cheers,
  Albert

El dijous, 24 de gener de 2019, a les 11:17:06 CET, Jaroslaw Staniek va 
escriure:
> Hi
> Can anyone approve it or confirm we can ship flatpacks for (stable) KDE
> software?
> We're close to release and Aleix seems to be silent.
> 
> 
> -- Forwarded message -
> From: Jaroslaw Staniek 
> Date: Wed, 23 Jan 2019 at 11:40
> Subject: Kexi_flatpax fix and question
> To: Aleix Pol 
> 
> 
> Hello Aleix!
> 
> I'd like to ask for a review: https://phabricator.kde.org/T10377
> .and have actual problem with lack of the stable software flatpacks (e.g.
> for KEXI it's 3.2 now). More than nigtly unstables me and I guess some
> other projects need stable flatpack packages to address the release problem
> on Linux. What can we do to have them? We have resources for that.
> Thanks.
> 
> 

Re: Review request: plasma-pass

[Albert Astals Cid]

El dilluns, 10 de desembre de 2018, a les 14:49:28 CET, Daniel Vrátil va 
escriure:
> Hi folks,
> 
> back in May I wrote a Plasma applet that serves as a GUI frontend for the 
> pass 
> password manager [0]. I blogged about it [1], but then somewhat forgot to 
> make 
> a release etc. Recently I started getting some emails from packagers where to 
> get a tarballs so I think it's time to get some translations in and start 
> doing official releases. Thus I'd like to ask for a review for inclusion in 
> extragear.
> 
> The way pass works is it has a directory in which each password is stored in 
> a 
> PGP-encrypted file, the name of the file is the name of the password. You can 
> also create subfolders to organize the passwords.
> 
> The code of the applet is a C++ model that watches said directory and exposes 
> its content as a tree. There's also a filter proxy model which uses partial 
> string matching code from KDevelop (so you can filter for "jd@f" and it 
> matches "john@fmail.com").
>  
> The applet itself sits in systray, when activated it shows the top-level list 
> of folders and password. Code-wise it contains a stack of list views, when 
> entering a subfolder it pushes a new listview with content of that folder to 
> the stack. Selecting a password decrypts it using gpg and puts it into 
> clipboard for 45 seconds. After that it clears it from the X clipboard as 
> well 
> as Klipper.
> 
> There's a bit of mess regarding focus handling in the QML, but the goal was 
> to 
> make the applet fully controllable via keyboard, which wasn't easy with my  
> QML skills :) 

You have 

plasma-pass:master$ wcgrep X-KDE-PluginInfo-Name
./package/metadata.desktop:27:X-KDE-PluginInfo-Name=plasmapass
./package/metadata.desktop:34:X-KDE-PluginInfo-Name=org.kde.plasma.pass

Which one is it? I guess the second? Then you also need to update your 
Messages.sh to match that one if you change it, see applets/colorpicker in 
kdeplasma-addons for example


You're using old style connects, use the power of the "new one".


PlasmaPass::PasswordsModel::Node has dtor but not copy-ctor, copy-assignment. 
Which means that if someone ever does
 PasswordsModel::Node a;
 PasswordsModel::Node b = a;
things will break since the default implementations will just copy the children 
vector and bad things will happen, i suggest you delete the copy and assignment 
functions.


filterChanged is already a name of an existing function on 
QSortFilterProxyModel (i know sucks), so maybe you could rename that signal to 
something else? I guess this is not very important though but some people may 
get confused when reading the code.


In the QML side you do a few == != that would be 0.001% faster doing 
=== and !==, it's considered better JS code since "weird" promotions are not 
done, but your call.


I have not actually tested whether the thing works or not, but it's small 
enough that i guess it does :D

Just had time for this quick code review, hope you find it useful :)

Cheers,
  Albert

> 
> 
> Looking forward to your feedback,
> Dan
> 
> 
> [0] https://www.passwordstore.org/
> [1] https://www.dvratil.cz/2018/05/plasma-pass/
> 
> 

Re: Time formats / LC_TIME challenge for 4-digit year support

[Albert Astals Cid]

El dilluns, 3 de desembre de 2018, a les 14:47:56 CET, Jaroslaw Staniek va 
escriure:
> Hello,
> The need: 4-digit year support for short date formats to avoid issues like
> "10/11/12" dates.

What's wrong with 10/11/12 ?

> 
> This is just my initial conclusion from for the Qt date format issue:
> 
> https://bugreports.qt.io/browse/QTBUG-59382?focusedCommentId=436861=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-436861
> lt;dr: KF5 context: KCallendarSystem is part of the old APIs and the only
> code I found related to LC_TIME.
> 
> So I've not found any common code KDE app can use instead of hard coding
> some internal logic in order to support non-Plasma environments and/or
> non-global settings. Basically even if an app implements locale name
> selection in its private settings, "pure" Qt code is not enough to support
> it in the discussed cases. Users may need alter date format globally (for
> all apps) by hand using environment's settings, setting e.g. -mm-dd. Or
> app developers may add private setting for that, one per app.
> 
> Opinions welcome.

I am not sure i understand your email/problem.

As far as i read this email your concern is:
 * localized dates use the locale date format
 * locale date format is "wrong".

So the two options are:
 a) User changes their locale
 b) Apps don't use localized dates and use a custom format.

Am I understanding your email correctly?

Cheers,
  Albert

Re: Move pulseaudio-qt to Extragear

[Albert Astals Cid]

El dissabte, 3 de novembre de 2018, a les 1:34:11 CET, Nicolas Fella va 
escriure:
> Hi,
> 
> together with David Rosca and Aleix Pol I have worked on extracting the 
> libpulse abstraction from plasma-pa into a library [0][1]. It is 
> currently optionally required by KDE Connect. plasma-pa and 
> libtaskmanager will use it at some point in the future. Long-term plan 
> is to move it to Frameworks, but until the required documentation and 
> testing is done I'd like to move it to Extragear and make an initial 
> release.

I proposed some small clazy fixes, but there's some more warnings that may make 
sense having a look over.

https://paste.kde.org/p5lhjhosn

Cheers,
  Albert

> 
> Cheers
> 
> Nicolas
> 
> [0] https://phabricator.kde.org/T7994
> 
> [1] https://cgit.kde.org/pulseaudio-qt.git
> 
> 

Re: RKWard is in kdereview

[Albert Astals Cid]

El dissabte, 6 d’octubre de 2018, a les 15:45:39 CEST, Thomas Friedrichsmeier 
va escriure:
> Hi!
> 
> KDE.org has been our home for a almost four years, now (after over a
> decade on sourceforge), but somehow I've kept procrastinating on the
> final step: Today I'd like to ask you to start reviewing RKWard for
> inclusion into exragear (coming from playground).


the i18n folder seems like from the past and something you should not need if 
in kde infrastructure. Could you delete it?

Also I'd suggest you compile enabling 
-DECM_ENABLE_SANITIZERS="address;undefined"

There's a few memory leaks (reported at exit) that you may want to have a look.

And there's also a few undefined behaviour warnings on exit, you've them marked 
as "known" things but it'd be good if you could find a way to fix them.

Your help menu is for some reason missing the Change Language option, i tried 
to do it a quick fix but could not, i would appreciate if you could find a way 
to only define the extra actions and not all of them (like we do for example in 
okular).

I've no idea about R so can't comment on the app itself ^_^

Cheers,
  Albert


> 
> RKWard is an easy to use and easily extensible IDE/GUI for R (a
> powerful language and environment for statistical computing, if you
> did not know it, yet). It aims to combine the power of the
> R-language with the ease of use of commercial statistics tools.
> 
> RKWard is used productively on Linux/BSD, Mac, and Windows.
> 
> We have quite a heavy code-base, and some of it dates back to the time
> when KDE 3.0 was still fresh. I guess reviewing this will not be an
> easy task, and honestly I have no idea where I would recommend you to
> start. So please just ask whatever you need to know, and I'll try my
> best to help you around.
> 
> Looking forward to your feedback!
> 
> Thomas Friedrichsmeier
> for the RKWard team

Re: Kdiff3 in kdereview

[Albert Astals Cid]

El dilluns, 3 de setembre de 2018, a les 17:38:35 CEST, Michael Reeves va 
escriure:
> The memory leak should be gone with the latest commit. This also resolve s
> one source of noise coming from code that is not needed as of QT 5.3.2.
> Tested up to looking at a two directory diff and opening of the files. All
> messages seem to be gone. Some unnecessary Windows specific code has been
> removed from FileAccess. It now handles directory searches the same way on
> any platform. Qt program's really shouldn't have to know the os they are
> running on in most cases. That's kind of the point of using it in the first
> place.

Sounds good :)

Cheers,
  Albert

> 
> On Fri, Aug 31, 2018, 6:45 PM Albert Astals Cid  wrote:
> 
> >
> > Good :)
> >
> > One minor thing, there seems to be some small issue with memory leaks on
> > optiondialog.
> >
> > If you compile with
> >cmake -DECM_ENABLE_SANITIZERS="undefined;address
> >
> > and then just run kdiff3 and close it, i get these leaks reported at the
> > end (amogsnst others that are noise) https://paste.kde.org/pp5k6jc6u
> >
> > Cheers,
> >   Albert
> >
> >
> >
> >
> 

Re: Kdiff3 in kdereview

[Albert Astals Cid]

El divendres, 31 d’agost de 2018, a les 14:48:53 CEST, Michael Reeves va 
escriure:
> On Wed, Aug 29, 2018, 4:34 PM Albert Astals Cid  wrote:
> 
> > El dimecres, 29 d’agost de 2018, a les 1:04:45 CEST, Michael Reeves va
> > escriure:
> > > On Tue, Aug 28, 2018, 5:45 PM Albert Astals Cid  wrote:
> > >
> > > > El divendres, 24 d’agost de 2018, a les 3:20:13 CEST, Michael Reeves va
> > > > escriure:
> > > > > On Thu, Aug 23, 2018, 6:07 PM Albert Astals Cid 
> > wrote:
> > > > >
> > > > > > El dimarts, 7 d’agost de 2018, a les 14:59:50 CEST, Michael Reeves
> > va
> > > > > > escriure:
> > > > > > > Kdiff3 has moved to review in preparation for possible release
> > > > testing. I
> > > > > > > am currently working towards having auto testing but the code
> > needs
> > > > major
> > > > > > > refactoring to make this possible. Specifically it is not well
> > > > > > modularized.
> > > > > > > The purpose of this review is to get feedback on issues that
> > need to
> > > > be
> > > > > > > addressed before moving out of playground.
> > > > > >
> > > > > > Have you seen there's 4 wrong connect signals on startup?
> > > > > > https://paste.kde.org/pcvcje3u1
> > > > > >
> > > > > Not quite sure how to resolve this. How is scrolling content properly
> > > > > implemented in qt5?
> > > >
> > > > I don't understand the question, what is missing is the signal you
> > would
> > > > emit from DiffTextWindow so it's DiffTextWindow saying it wants to
> > scroll
> > > > that is not something that it doesn't say anymore?
> > > >
> > >
> > > The code is a hack by the original author that tries to get notified when
> > > the scroll bar moves. It happens to work as of qt5 but generates this
> > > warning because QWidget::scroll is not a signal. Removing the offending
> > > connects makes text in the diff mini window not scroll at all. How is
> > > scrolling of content supposed to be implemented?
> >
> > Are you saying that removing a connect that is reporting to be broken
> > changes the behaviour of the program?
> >
> 
> I must be crazy anyway it seems to work now without those lines.

Good :)

One minor thing, there seems to be some small issue with memory leaks on 
optiondialog.

If you compile with
   cmake -DECM_ENABLE_SANITIZERS="undefined;address

and then just run kdiff3 and close it, i get these leaks reported at the end 
(amogsnst others that are noise) https://paste.kde.org/pp5k6jc6u

Cheers,
  Albert


> 
> >
> > That seems really strange, once you fix the assert if you tell me what to
> > test i can have a look :)
> >
> > Cheers,
> >   Albert
> >
> 
> The assert will no longer happen that actually was committed right after
> you reported it. The code in question seems to be triggered when using
> preprocessing comands. I still need to look at this more closely but it
> should work as is. I have been reworking the file access code to try and
> simplify it. The diff process itself should not be affected buy this. This
> code base definitely feels something that was written under time
> constraints. It took a lot of effort to make it what is now. Not
> surprisingly there's still work to be done. One of my goals is to reduce
> make this code more easily maintainable.
> 
> 
> > >
> > > >
> > > > > >
> > > > > > When trying to compare any two files i hit this assert
> > > > > >
> > > > > > if(m_lmppData.m_vSize < m_normalData.m_vSize)
> > > > > > {
> > > > > > //This a bug that needs fixed elsewhere not hacked
> > around
> > > > > > Q_ASSERT(m_lmppData.m_vSize == m_normalData.m_vSize);
> > > > > >
> > > > > > Which i do not understand what it is trying to do, i mean you just
> > > > checked
> > > > > > that they are different and the on the next line assert they are
> > not
> > > > > > different?
> > > > > >
> > > > >
> > > > > Actually that tells me what I need ed to know. I don't get this on my
> > > > > machine. The comment made it seem like this was some sort of work
> > around
> > > > > for an odd corner case. I can remove the assert now that I know the
> > > > trigger
> > > > > is an everytime thing.
> > > > > How are you doing the file comparison?
> > > >
> > > > kdiff3 file1 file2
> > > >
> > > > Cheers,
> > > >   Albert
> > > >
> > > >
> > > > > I feel like this points to an issue else where.
> > > > >
> > > > >
> > > > > > Cheers,
> > > > > >   Albert
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >
> >

Re: Kdiff3 in kdereview

[Albert Astals Cid]

El dimecres, 29 d’agost de 2018, a les 1:04:45 CEST, Michael Reeves va escriure:
> On Tue, Aug 28, 2018, 5:45 PM Albert Astals Cid  wrote:
> 
> > El divendres, 24 d’agost de 2018, a les 3:20:13 CEST, Michael Reeves va
> > escriure:
> > > On Thu, Aug 23, 2018, 6:07 PM Albert Astals Cid  wrote:
> > >
> > > > El dimarts, 7 d’agost de 2018, a les 14:59:50 CEST, Michael Reeves va
> > > > escriure:
> > > > > Kdiff3 has moved to review in preparation for possible release
> > testing. I
> > > > > am currently working towards having auto testing but the code needs
> > major
> > > > > refactoring to make this possible. Specifically it is not well
> > > > modularized.
> > > > > The purpose of this review is to get feedback on issues that need to
> > be
> > > > > addressed before moving out of playground.
> > > >
> > > > Have you seen there's 4 wrong connect signals on startup?
> > > > https://paste.kde.org/pcvcje3u1
> > > >
> > > Not quite sure how to resolve this. How is scrolling content properly
> > > implemented in qt5?
> >
> > I don't understand the question, what is missing is the signal you would
> > emit from DiffTextWindow so it's DiffTextWindow saying it wants to scroll
> > that is not something that it doesn't say anymore?
> >
> 
> The code is a hack by the original author that tries to get notified when
> the scroll bar moves. It happens to work as of qt5 but generates this
> warning because QWidget::scroll is not a signal. Removing the offending
> connects makes text in the diff mini window not scroll at all. How is
> scrolling of content supposed to be implemented?

Are you saying that removing a connect that is reporting to be broken changes 
the behaviour of the program?

That seems really strange, once you fix the assert if you tell me what to test 
i can have a look :)

Cheers,
  Albert

> 
> >
> > > >
> > > > When trying to compare any two files i hit this assert
> > > >
> > > > if(m_lmppData.m_vSize < m_normalData.m_vSize)
> > > > {
> > > > //This a bug that needs fixed elsewhere not hacked around
> > > > Q_ASSERT(m_lmppData.m_vSize == m_normalData.m_vSize);
> > > >
> > > > Which i do not understand what it is trying to do, i mean you just
> > checked
> > > > that they are different and the on the next line assert they are not
> > > > different?
> > > >
> > >
> > > Actually that tells me what I need ed to know. I don't get this on my
> > > machine. The comment made it seem like this was some sort of work around
> > > for an odd corner case. I can remove the assert now that I know the
> > trigger
> > > is an everytime thing.
> > > How are you doing the file comparison?
> >
> > kdiff3 file1 file2
> >
> > Cheers,
> >   Albert
> >
> >
> > > I feel like this points to an issue else where.
> > >
> > >
> > > > Cheers,
> > > >   Albert
> > > >
> > > >
> >
> >
> >
> >
> >

Re: Kdiff3 in kdereview

[Albert Astals Cid]

El divendres, 24 d’agost de 2018, a les 3:20:13 CEST, Michael Reeves va 
escriure:
> On Thu, Aug 23, 2018, 6:07 PM Albert Astals Cid  wrote:
> 
> > El dimarts, 7 d’agost de 2018, a les 14:59:50 CEST, Michael Reeves va
> > escriure:
> > > Kdiff3 has moved to review in preparation for possible release testing. I
> > > am currently working towards having auto testing but the code needs major
> > > refactoring to make this possible. Specifically it is not well
> > modularized.
> > > The purpose of this review is to get feedback on issues that need to be
> > > addressed before moving out of playground.
> >
> > Have you seen there's 4 wrong connect signals on startup?
> > https://paste.kde.org/pcvcje3u1
> >
> Not quite sure how to resolve this. How is scrolling content properly
> implemented in qt5?

I don't understand the question, what is missing is the signal you would emit 
from DiffTextWindow so it's DiffTextWindow saying it wants to scroll that is 
not something that it doesn't say anymore?

> >
> > When trying to compare any two files i hit this assert
> >
> > if(m_lmppData.m_vSize < m_normalData.m_vSize)
> > {
> > //This a bug that needs fixed elsewhere not hacked around
> > Q_ASSERT(m_lmppData.m_vSize == m_normalData.m_vSize);
> >
> > Which i do not understand what it is trying to do, i mean you just checked
> > that they are different and the on the next line assert they are not
> > different?
> >
> 
> Actually that tells me what I need ed to know. I don't get this on my
> machine. The comment made it seem like this was some sort of work around
> for an odd corner case. I can remove the assert now that I know the trigger
> is an everytime thing. 
> How are you doing the file comparison? 

kdiff3 file1 file2

Cheers,
  Albert


> I feel like this points to an issue else where.
> 
> 
> > Cheers,
> >   Albert
> >
> >

Re: Kdiff3 in kdereview

[Albert Astals Cid]

El dimarts, 7 d’agost de 2018, a les 14:59:50 CEST, Michael Reeves va escriure:
> Kdiff3 has moved to review in preparation for possible release testing. I
> am currently working towards having auto testing but the code needs major
> refactoring to make this possible. Specifically it is not well modularized.
> The purpose of this review is to get feedback on issues that need to be
> addressed before moving out of playground.

Have you seen there's 4 wrong connect signals on startup?
https://paste.kde.org/pcvcje3u1 


When trying to compare any two files i hit this assert

if(m_lmppData.m_vSize < m_normalData.m_vSize)
{
//This a bug that needs fixed elsewhere not hacked around
Q_ASSERT(m_lmppData.m_vSize == m_normalData.m_vSize);

Which i do not understand what it is trying to do, i mean you just checked that 
they are different and the on the next line assert they are not different?

Cheers,
  Albert

Re: Adding Kirigami Gallery to kde-sdk

[Albert Astals Cid]

I talked with Marco at akademy and he says it's fine not to include it for
KDE Applications 18.08.

Cheers,
  Albert

El dj., 9 ag. 2018 , 23:14, Albert Astals Cid  va escriure:

> El dijous, 9 d’agost de 2018, a les 12:06:18 CEST, Luigi Toscano va
> escriure:
> > Albert Astals Cid ha scritto:
> > > El diumenge, 24 de juny de 2018, a les 1:18:45 CEST, David Edmundson va
> > > escriure:
> > >> What would be the situation for releases?
> > >
> > > If it's part of kdesdk gets released with KDE Applications like all
> the other
> > > kdesdk repos.
> >
> > kirigami-gallery was added to kdesdk in sysadmin/repo-metadata, but it's
> not
> > yet in the list of the modules officially shipped as part of KDE
> Applications
> > (sysadmin/release-tools).
> >
> > Do we have a final decision on this?
>
> uh oh.
>
> So there's no packages for it for KDE Applications 18.08 being released
> next week.
>
> Marco, is it fine for you if we get it out with 18.12 or you really wanted
> to be in 18.08?
>
> Cheers,
>   Albert
>
> >
> > Ciao
> >
>
>
>
>
>

Re: Adding Kirigami Gallery to kde-sdk

[Albert Astals Cid]

El dijous, 9 d’agost de 2018, a les 12:06:18 CEST, Luigi Toscano va escriure:
> Albert Astals Cid ha scritto:
> > El diumenge, 24 de juny de 2018, a les 1:18:45 CEST, David Edmundson va
> > escriure:
> >> What would be the situation for releases?
> > 
> > If it's part of kdesdk gets released with KDE Applications like all the 
> > other
> > kdesdk repos.
> 
> kirigami-gallery was added to kdesdk in sysadmin/repo-metadata, but it's not 
> yet in the list of the modules officially shipped as part of KDE Applications 
> (sysadmin/release-tools).
> 
> Do we have a final decision on this?

uh oh.

So there's no packages for it for KDE Applications 18.08 being released next 
week.

Marco, is it fine for you if we get it out with 18.12 or you really wanted to 
be in 18.08?

Cheers,
  Albert

> 
> Ciao
> 

Re: Adding Kirigami Gallery to kde-sdk

[Albert Astals Cid]

El diumenge, 24 de juny de 2018, a les 1:18:45 CEST, David Edmundson va 
escriure:
> What would be the situation for releases?

If it's part of kdesdk gets released with KDE Applications like all the other 
kdesdk repos.

Cheers,
  Albert

Re: Kde translation.

[Albert Astals Cid]

El dijous, 26 d’abril de 2018, a les 13:59:18 CEST, Michael Reeves va 
escriure:
> How are translations handled as far distribution goes?

This question is a bit vague.

Are you asking what we do with the translations?
  We put them in the tarballs and install them as any other regular file

Are you asking how to put them in a tarball of your creation? 
  There's scripts that do it, don't roll your own, you'll do it wrong

Are you asking something else?

Cheers,
  Albert

Re: Falkon in kdereview

[Albert Astals Cid]

El dimecres, 28 de febrer de 2018, a les 12:10:36 CET, David Rosca va 
escriure:
> Hi,
> I'd like to request review for Falkon.
> 
> It's been actually in kdereview for some time already, but I never got
> to properly request review, sorry about that.
> 
> There is a project set up in bugzilla, CI build and code should be in
> accordance with guidelines too.
> There are also some autotests, although they are rather unstable on
> FreeBSD build. It looks like crash in QtWebEngine, but the backtrace
> from CI is without symbols, so it is unfortunately useless.
> 
> Target is Extragear for now, and later possibly moving to KDE Applications.

Looks really nice :)

One small fix you need to do, you need to also exclude scripts from your src/
Messages.sh

the look of your scripts/Messages.sh file looks like it's trying to be too 
smart and it'll confuse some of our tools that may try to guess which .po 
files need packaging, i'd really suggest having one Messages.sh per subfolder, 
since after all you still need to edit the python_scripts variable so it's not 
automagic that any added script will get the .po extracted.

also two random comments, probably you can ignore most of them but since i 
spent some time i'll just comment.
 * I think you need a qDeleteAll in AdBlockSubscription::loadSubscription 
before m_rules.clear();
 * The bookmarks text in https://i.imgur.com/xkELczj.png doesn't fit here

Cheers,
  Albert

> 
> Thanks,
> David

Re: Global Dependency and Release Freeze

[Albert Astals Cid]

El divendres, 2 de març de 2018, a les 11:34:30 CET, Ben Cooksley va escriure:
> Hi all,
> 
> Due to a snowball of various dependency bumps and other tickets which
> have been submitted over the past few days, i'm imposing a global
> dependency freeze upon all KDE projects.
> 
> In addition to this, due to the workload these also create, I am also
> imposing a total release freeze on all Extragear projects. Requests
> for tarballs to be released will not be actioned while the freeze is
> imposed. It would be appreciated if people could please hold off on
> filing those.

If you need handling the moving of packages i can lend a hand there since 
AFAIU I already have access to all the places needed.

Cheers,
  Albert

> 
> Sysadmin needs time to catch up and get the CI system back into a
> settled state following changes to Windows and FreeBSD images, in
> addition to sorting out the other tickets we have received over the
> past few days some of which will require some time to deal with.
> 
> Requests for exceptions to these freezes are not available, however we
> will endeavour to lift them as soon as is practicable.
> 
> Regards,
> Ben Cooksley
> KDE Sysadmin

Re: Ring-KDE in kdereview

[Albert Astals Cid]

El diumenge, 11 de febrer de 2018, a les 20:28:37 CET, Elv1313 . va escriure:
> Thanks for the review
> 
> > The automatic fetching of stuff from github on make time was weird.
> 
> It's the fallback if it's not found. It wont do that if:
> 
> 1) it is installed
> 2) the libringqt directory was put in `ring-kde/`.
> 3) It is using a release tarball instead of git-master
> 
> The automatic download was added because otherwise getting all the
> right versions of everything was near impossible.
> 
> > And it doesn't build for me. (I see it's libringqt so maybe not your
> > fault? would get "fixed" if you dodn't do the automatic fetching :D)
> Apparently the daemon and/or libring is not installed correctly. There
> is a cmake check for it, but it is a little permissive to allow
> build.kde.org to only fetch the daemon dbus headers and not compile
> it.
> 
> As I said in the mail above, the only reliable way to compile ring-kde
> is to use the Dockerfile.

That's really very unfortunate.

Cheers,
  Albert

P.S: Remember to keep the list on CC :)

Re: Ring-KDE in kdereview

[Albert Astals Cid]

El dijous, 8 de febrer de 2018, a les 20:18:51 CET, Elv1313 . va escriure:
> Hello, this I hereby announce that Ring-KDE, a secure communication client
> for the GNU Ring / IETF SIP protocol, is attempting to move to Extragear
> (from the playground). Below is a detailed email, but there is a video and
> screenshot gallery that should give you a good enough idea if you don't
> have time to read.

You want to use i18n here.
tr("All files")

The automatic fetching of stuff from github on make time was weird.

And it doesn't build for me. (I see it's libringqt so maybe not your fault? 
would get "fixed" if you dodn't do the automatic fetching :D)

make[2]: *** No rule to make target 'xml/cx.ring.Ring.PresenceManager.xml', 
needed by 'build/libringqt/presencemanager_dbus_interface.cpp'.  Stop.
make[1]: *** [CMakeFiles/Makefile2:936: 
build/libringqt/CMakeFiles/ringqt.dir/all] Error 2

Cheers,
  Albert

Re: Importing kdiff3 - was - Re: Aw: Re: KDE inclusion

[Albert Astals Cid]

El dijous, 25 de gener de 2018, a les 9:01:10 CET, Kevin Ottens va escriure:
> Hello,
> 
> On Thursday, 25 January 2018 00:08:03 CET Albert Astals Cid wrote:
> > El dimecres, 24 de gener de 2018, a les 17:34:16 CET, Kevin Funk va
> 
> escriure:
> > > On Wednesday, 24 January 2018 16:24:10 CET Michael Reeves wrote:
> > > > A little confused on where to start with this sponsor thing.
> > > 
> > > Huh? 'sponsor thing'? :)
> > 
> > I guess it's regarding the
> > https://community.kde.org/Incubator/Incubation_Process
> > 
> > Which to my understanding was supposed to be a voluntary thing but it
> > seems
> > some people are forcing it on every single new project.
> 
> Was supposed to be for any project born outside the community and joining
> in. So not quite so voluntary.

Ok, that's not really how i understood it, but fair enough.

> 
> > As I did with the last person that also was confused and annoyed by all
> > this burocracy, just ask me any question you may have.
> 
> Oh come on... the bad mean bureaucracy argument now. Wanna look at the
> Eclipse incubation process? Or the Apache one?

Can I use the "if all your friends jump from a balcony will you do it" 
defense?

> Seriously it's just about having a person already within the community
> making sure the new project needs get catered to and also making sure the
> new project is on the right path to put in place rules and procedures
> compatible with the rest of the community (and the Manifesto).

But how do you find that person? You're just an 'outsider', how do you find a 
random person to be your incubator guy? Because as it happens, it's the second 
time in a month or something that i have to volunteer.

I think it's much easier if we had guidelines and the rest was just "ask in 
kde-devel mailing list if you have further questions", and sure if you find a 
dedicated person for you, great, but requiring it feels weird, and also makes 
it for less scalability, as an example I already have an email from Michael 
that was sent only to me but anyone else in this list would have been able to 
answer, but he had to wait at least 14 hours for me to have time to answer it.

Cheers,
  Albert

> Call it bureaucracy if you wish, but I think it's good to avoid people
> dropping code in a corner to then be ignored by everyone and wondering what
> to do next.
> 
> Regards.

Re: Importing kdiff3 - was - Re: Aw: Re: KDE inclusion

[Albert Astals Cid]

El dimecres, 24 de gener de 2018, a les 17:34:16 CET, Kevin Funk va escriure:
> On Wednesday, 24 January 2018 16:24:10 CET Michael Reeves wrote:
> > A little confused on where to start with this sponsor thing.
> 
> Huh? 'sponsor thing'? :)
> 

I guess it's regarding the 
https://community.kde.org/Incubator/Incubation_Process

Which to my understanding was supposed to be a voluntary thing but it seems 
some people are forcing it on every single new project.

As I did with the last person that also was confused and annoyed by all this 
burocracy, just ask me any question you may have.

Cheers,
  Albert

> Care to elaborate what you mean?
> 
> Regards,
> Kevin
> 
> > On Jan 19, 2018 3:52 PM, "Kevin Funk" <kf...@kde.org> wrote:
> > > On Wednesday, 17 January 2018 21:40:49 CET Michael Reeves wrote:
> > > > Yes I use this myself so I won't simply abandon it. That said I work
> > > > in
> > > > mostly in Unix world and could use help with the windows specific
> > > > testing
> > > > although I should be able to setup a build envirionment to do basic
> > > > functionality testing.
> > > 
> > > Heya,
> > > 
> > > For that please join #kde-windows and get in touch with kfunk (me) or
> > > TheOneRing (Hannah von Reth) there.
> > > 
> > > We could guide setting up the development environment.
> > > 
> > > We use Craft to build Qt/KDE projects on Windows, read more here:
> > >   https://community.kde.org/Craft
> > > 
> > > Cheers,
> > > Kevin
> > > 
> > > > I'll have look at what needs done. Currently working
> > > > on getting merging in changes from Thomas as needed.  Just got through
> > > > bringing it up to date with Joachim's code. Real fun since it's still
> > > 
> > > kde4.
> > > 
> > > > On Jan 15, 2018 5:47 PM, "Albert Astals Cid" <aa...@kde.org> wrote:
> > > > 
> > > > El dimarts, 9 de gener de 2018, a les 20:06:36 CET, Michael Reeves va
> > > > 
> > > > escriure:
> > > > > I have a version of kdiff3 that I ported to kf5. I like to what
> > > > > build
> > > > > requirements kf5 as a whole has. Also what would be the process for
> > > 
> > > being
> > > 
> > > > > considered for inclusion in kde?
> > > > 
> > > > So now that we have Joachim's blessing to use the name, the process is
> > > > basically outlined at https://community.kde.org/
> > > 
> > > Incubator/Incubation_Process
> > > 
> > > > but it's basically importing the project into our git and then making
> > > 
> > > sure
> > > 
> > > > it
> > > > generally follows our rules & procedures.
> > > > 
> > > > I understand you want to continue maintaining the new kdiff3 and you
> > > > are
> > > 
> > > not
> > > 
> > > > just "dumping it" into us, right?
> > > > 
> > > > 
> > > > Cheers,
> > > > 
> > > >   Albert
> > > > 
> > > > El divendres, 12 de gener de 2018, a les 1:21:02 CET, Joachim Eibl va
> > > > 
> > > > escriure:
> > > > > Hi,
> > > > > 
> > > > > You have my blessing to use the name KDiff3.
> > > 
> > > --
> > > Kevin Funk | kf...@kde.org | http://kfunk.org

Re: Rebase of kopete branch and push it to master

[Albert Astals Cid]

El dimarts, 16 de gener de 2018, a les 21:56:34 CET, Ben Cooksley va escriure:
> I won't
> be proceeding with the push if it clashes with an Applications module
> release or freeze for which an exception has not been granted.

kopete is not part of KDE Applications 17.12 since it didn't make it on time 
with a KF5-base version. So no problem on that side.

Cheers,
  Albert

> 
> Regards,
> Ben Cooksley
> KDE Sysadmin

Re: Rebase of kopete branch and push it to master

[Albert Astals Cid]

El dimarts, 16 de gener de 2018, a les 0:45:27 CET, Pali Rohár va escriure:
> On Tuesday 16 January 2018 00:32:44 Albert Astals Cid wrote:
> > El dimarts, 16 de gener de 2018, a les 0:09:50 CET, Pali Rohár va 
escriure:
> > > On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote:
> > > > So is the problem:
> > > >  a) that you could not push that master-kf5 to master
> > > 
> > > Problem is really a).
> > 
> > Why is that? You said master-kf5 is just a rebase of kf5 on top of master,
> > what's the problem of pushing that branch?
> 
> Because it does not work.
> 
> remote: Push declined - excessive notifications would be sent
> remote: Please file a KDE Sysadmin bug to continue
> 
> Therefore I opened sysadmin ticket T7642 and I was told that I should
> discuss about it on kde-core-devel.

Please someone correct me, but that has nothing to do with rebasing no?

It's just about a big merge potentially triggering lots of emails and stuff, 
no?

Cheers,
  Albert

Re: Rebase of kopete branch and push it to master

[Albert Astals Cid]

El dimarts, 16 de gener de 2018, a les 0:09:50 CET, Pali Rohár va escriure:
> On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote:
> > So is the problem:
> >  a) that you could not push that master-kf5 to master
> 
> Problem is really a).

Why is that? You said master-kf5 is just a rebase of kf5 on top of master, 
what's the problem of pushing that branch?

Cheers,
  Albert

Re: Rebase of kopete branch and push it to master

[Albert Astals Cid]

El dilluns, 15 de gener de 2018, a les 9:50:11 CET, Pali Rohár va escriure:
> On Sunday 14 January 2018 23:59:45 Albert Astals Cid wrote:
> > El diumenge, 14 de gener de 2018, a les 21:52:29 CET, Pali Rohár va 
escriure:
> > > Hi!
> > 
> > Hello Mr Rohár
> > 
> > > From the following ticket https://phabricator.kde.org/T7642 I was
> > > suggested to open discussion on kde-core-devel list. Sending this email
> > > also to kopete-devel as it is relevant for Kopete development.
> > > 
> > > Currently in Kopete git repository https://cgit.kde.org/kopete.git/ is a
> > > branch kf5 which contains port of Kopete to KF5. That branch was created
> > > 3 years ago as part of GSoC was used as "staging area". Some patches
> > > there are incomplete and later were "fixed & cherry-picked" into master
> > > branch. Therefore you can find commits with same description/commit
> > > message in master branch and kf5, but correct (working) one is in
> > > master. Later this branch was used for pushing whole work of porting.
> > > 
> > > I took commits from this branch kf5 and rebased it on top of master with
> > > cleanup of duplicate commits and commits which are already in master
> > > branch. And this rebase I pushed into my cloned git repository
> > > https://cgit.kde.org/clones/kopete/pali/kopete.git/log/?h=master-kf5
> > > 
> > > I wanted to push these master-kf5 changes into main kopete repository
> > > into master branch, but it was rejected by commits hook, see above T7642
> > > ticket.
> > 
> > No, we can't read private sysadmin tickets.
> > 
> > > Reason is that "rebase" is not supported by KDE. ltoscano and
> > > bcooksley suggested to discuss about it on kde-core-devel.
> > > 
> > > From my side as that branch kf5 contains duplicate commits as in master
> > > branch and commits with same commit messages and different (old) patches
> > > I really do not like see these commits in master branch. It would break
> > > certain of git functionality (like bisect or blame, or log). And because
> > > it was mean as a staging area, I would really like to use that rebase
> > > for this time. I do not thing that there are advantage to merge this kf5
> > > branch as is into master and better would be rebase.
> > > 
> > > Is there anything really against rebasing this one particular branch?
> > 
> > Yes, you have not explained why you need rebasing.
> 
> I already wrote it. I do not want to see one commit in git history
> accessible from master branch two times. Or git commits with same commit
> message / same description, but with different content.

That's not really a big problem is it? Like you wrote it seemed that if you 
were unable to rebase things would be terribly broken or something.

> 
> > Just merge master-kf5 into master.
> > 
> > master as it is right now works, no?
> 
> Yes, but depends on KDE4.
> 
> > (or i hope it should, we agreed long time
> > ago to not break master), so just merge the "kf5 clean branch" into it and
> > that's it, no?
> > 
> > > For future (to prevent any such problem with rebasing), staging areas
> > > would be outside of main KDE git repository.
> > 
> > How would that fix anything? You will still not be able to rebase master.
> 
> But I never wanted such thing, nor I want in the future.

I am really lost then, you don't want to rebase master, but you wrote an email 
saying you needed to rebase the master branch, no? If not then i misunderstood 
your problem.

> > Or you're saying that you want to rebase your work branches?
> 
> Yes, take branch kf5, locally rebase it (on top of master) and then push
> changes to remote master. As already wrote, I did it and pushed this
> rebased branch into my cloned git repository under branch name
> master-kf5.

So is the problem:
 a) that you could not push that master-kf5 to master
or
 b) that you could not push that master-kf5 to kf5
or
 c) something else and Albert is still lost
?

Cheers,
  Albert

Importing kdiff3 - was - Re: Aw: Re: KDE inclusion

[Albert Astals Cid]

El dimarts, 9 de gener de 2018, a les 20:06:36 CET, Michael Reeves va 
escriure:
> I have a version of kdiff3 that I ported to kf5. I like to what build
> requirements kf5 as a whole has. Also what would be the process for being
> considered for inclusion in kde?

So now that we have Joachim's blessing to use the name, the process is 
basically outlined at https://community.kde.org/Incubator/Incubation_Process 
but it's basically importing the project into our git and then making sure it 
generally follows our rules & procedures.

I understand you want to continue maintaining the new kdiff3 and you are not 
just "dumping it" into us, right?

Cheers,
  Albert

El divendres, 12 de gener de 2018, a les 1:21:02 CET, Joachim Eibl va 
escriure:
> Hi,

> You have my blessing to use the name KDiff3.

Re: plasma-active-window-control - was -Re: 2 New Plasmoids in Kdereview

[Albert Astals Cid]

El dilluns, 15 de gener de 2018, a les 0:15:59 CET, Martin Kostolný va 
escriure:
> You are right, integration of global-menu functionality is copied from
> appmenu widget code. It is also mentioned in
> plasma-active-window-control/plugin/README.
> 
> I consider it a temporary solution before a proper appmenu datasource is
> introduced. David Edmundson wrote a while ago that the datasource is on the
> way but it needs polishing and that I could look into that. I didn't yet
> have enough time to look it up and dive in but I intend to.
> 
> In the meantime I use the copied code. Is it possible to use the existing
> code without copying? Of course I can prepare a script that would
> automatically copy it from another repo (plasma-workspace) and patch it but
> it seems a bit hacky. I also don't know how would I integrate it in cmake
> including making it work in KDE CI. Should I try to do that? Also there is
> (I believe) no way to use a private plugin of a different widget.

Nah, don't do that, if you *promise* a solution is in the works and you'll 
help with it i guess that's enough.

Any script or other solution will be a pain.

Cheers,
  Albert

> 
> Is there another way to solve this problem?
> 
> Thanks!
> Martin
> 
> PS: It seems my mails to kde-core-devel have sometimes delays more then 1
> day before they actually arrive to the archives. Is it normal or there is a
> problem on my side?
> On neděle 14. ledna 2018 23:47:53 CET Albert Astals Cid wrote:
> > El dissabte, 13 de gener de 2018, a les 10:46:01 CET, Martin Kostolný va
> > 
> > escriure:
> > > 2) On the other hand plasma-active-window-control could be part of
> > > kdeplasma-addons because it is multiplatform, has C++ plugin and uses
> > > e.g.
> > > TaskManager module of Plasma which changes from time to time. So it
> > > would
> > > be nice to release always compatible version of this widget.
> > 
> > There seems to be lots of copied code in here.
> > 
> > Why?
> > 
> > Cheers,
> > 
> >   Albert

Re: Aw: Re: KDE inclusion

[Albert Astals Cid]

El diumenge, 14 de gener de 2018, a les 12:10:07 CET, Valentin Rusu va 
escriure:
> * Joachim Eibl  [2018-01-12 01:21:02 +0100]:
> > I had a try at it myself, but was quite overwhelmed about the big
> > changes in KF5.
> > 
> > 
> > 
> > You have my blessing to use the name KDiff3.
> 
> Great news for a very useful tool! After having ported it to KDE4, I was
> also overwhelmed by the changes for KF5. Today I'm unfortunately forced
> to use the Qt version. Perhaps we should stick with that version and
> simply have it hosted and maintained as a KDE extragear project.

Or maybe we should do what the person that did the work thinks its a better 
idea :)

Cheers,
  Albert

Re: Python bindings using cppyy (was: An update on Python bindings)

[Albert Astals Cid]

El dissabte, 13 de gener de 2018, a les 18:05:45 CET, Shaheed Haque va 
escriure:
> Thanks to some upstream fixes, I have the cppyy-based bindings for KF5 and
> also Qt5 (see below) showing signs of life. 
> Notes:

This is awesome, i'm really happy we're in a point that framework-by-framework 
is possible and that it all seems to be upstream so it's a "hopefully bigger 
group of people" maintaining it :)

Keep it up!

Cheers,
  Albert

> 
> 
>1. The packaging has advanced to the point where I think ECM-based
>framework-by-framework bindings are a real possibility, with both Py2 and
> Py3. AFAICS, this addresses the main feedback received to date. 2. With
> reference to the remark about tracking dependencies between frameworks,
> apologies for the delayed response as I somehow missed the email. I note
> that the dependencies currently in CMake often seem incomplete. I'll bring
> that to the community separately.
>3. There is one issue still open upstream (
>   
> https://bitbucket.org/wlav/cppyy/issues/16/pragma-link-defined_in-seems-to-> 
> select). However, I don't consider this to be a showstopper...we might even
> be able to live with it as is.
>4. For me, the jury is still out on PyQt versus a new set of cppyy-based
>Qt bindings. Clearly PyQt is solid and mature, but the limitations really
> concern me (if anybody wants to know more, I'm happy to discuss, but let's
> do that in another thread please). Now, given that there are examples in
> the wild of interoperating cppyy/cling/ROOT with PyQt, I'm going to
> sidestep this question but am playing with a cppyy-based approach. At this
> point, all of Qt has basic cppyy-based bindings, and the next step is to
> tackle things like finding a way to express the object
>ownership/destruction rules in a more-or-less systematic way.
>5. On the P2/P3 question, I'm presently still committed to both P2 and
>P3. I *have* had a couple of minor occasions where P3-only might have
> been nice *for my code*, but if I do find an issue that tips the balance,
> or I find some serious benefit *for the bindings*, I'll drop P2. One
> possible such benefit would be if I can see a sane way to address PEP484
> type hints.
> 
> To get here, I had to build a subset of the tooling I previously had
> developed for the SIP-based approach. The big difference is the absence of
> any need to support customisation of the generated bindings. I am hopeful
> that in the worst case, there might be some minimal customisation (known as
> Pythonisations in cppyy parlance) such as for #4 above, but nothing like
> the scale needed for SIP.
> 
> The core tooling is not specific to KF5 or KDE or Qt5, and is developed in
> upstream cppyy over on bitbucket.org. The core tooling is built around
> CMake, notably for the generation phase and the C++ library build.
> 
> The PoC extends the core tooling with Pythonic packaging and installation
> using pip/wheels, also from CMake. As before I would look for help to get
> an ECM equivalent, possibly based on the same approach but perhaps
> including CI and distribution via PyPi.
> 
> Finally, now would be a good time for anybody else who wants to get
> involved to step up, especially as a new job limits my free time.
> 
> Thanks, Shaheed
> 
> P.S. Not to stoke the the P2/P3 wars unnecessarily, but while I know that
> upstream Clang just added P3 support in the clang 5.0 release, current
> Ubuntu only packages it for 2.7.14. So I won't be moving yet...
> 
> On 5 November 2017 at 13:23, Boudewijn Rempt  wrote:
> > On Sat, 4 Nov 2017, Chris Burel wrote:
> > > I think this is a remarkably short sighted statement. It assumes that
> > 
> > people that would use these bindings have no existing Python codebase at
> > all, and can afford to start a brand new project. The reality is much
> > different.
> > 
> > > Let's take a specific example. I have 6 years experience writing Python
> > 
> > for the visual effects industry. We have a 10 year old Python 2 codebase.
> > We also use an application from Autodesk called Maya. It has been a Qt 4
> > application with Python 2 embedded since 2012. In 2016 they jumped to qt 5
> > and pyside2. Now Autodesk knows that companies have built large codebase
> > around their product that requires Python 2. What would've happened if
> > pyside2 did not support Python 2.7? They'd be stuck either forcing all
> > their customers to move to Python 3 and risk people not wanting the new
> > version of the software, or they'd be prevented from moving to Qt 5.
> > 
> > 
> > You will have to switch to Python 3 by 2019, since that's what the VFX
> > Reference Platform says. If you haven't started on the migration yet,
> > you're very late. And the VFX Refernece Platform is basically Autodesk
> > telling the rest of the industry what to use, including their weird
> > patchset for Qt...
> > 
> > > So no, Python 2 is not dead. Not by a long shot.
> > 
> > For VFX, it will be dead in 2019. See 

Re: Rebase of kopete branch and push it to master

[Albert Astals Cid]

El diumenge, 14 de gener de 2018, a les 21:52:29 CET, Pali Rohár va escriure:
> Hi!

Hello Mr Rohár

> 
> From the following ticket https://phabricator.kde.org/T7642 I was
> suggested to open discussion on kde-core-devel list. Sending this email
> also to kopete-devel as it is relevant for Kopete development.
> 
> Currently in Kopete git repository https://cgit.kde.org/kopete.git/ is a
> branch kf5 which contains port of Kopete to KF5. That branch was created
> 3 years ago as part of GSoC was used as "staging area". Some patches
> there are incomplete and later were "fixed & cherry-picked" into master
> branch. Therefore you can find commits with same description/commit
> message in master branch and kf5, but correct (working) one is in
> master. Later this branch was used for pushing whole work of porting.
> 
> I took commits from this branch kf5 and rebased it on top of master with
> cleanup of duplicate commits and commits which are already in master
> branch. And this rebase I pushed into my cloned git repository
> https://cgit.kde.org/clones/kopete/pali/kopete.git/log/?h=master-kf5
> 
> I wanted to push these master-kf5 changes into main kopete repository
> into master branch, but it was rejected by commits hook, see above T7642
> ticket. 

No, we can't read private sysadmin tickets.

> Reason is that "rebase" is not supported by KDE. ltoscano and
> bcooksley suggested to discuss about it on kde-core-devel.
> 
> From my side as that branch kf5 contains duplicate commits as in master
> branch and commits with same commit messages and different (old) patches
> I really do not like see these commits in master branch. It would break
> certain of git functionality (like bisect or blame, or log). And because
> it was mean as a staging area, I would really like to use that rebase
> for this time. I do not thing that there are advantage to merge this kf5
> branch as is into master and better would be rebase.
> 
> Is there anything really against rebasing this one particular branch?

Yes, you have not explained why you need rebasing. 

Just merge master-kf5 into master.

master as it is right now works, no? (or i hope it should, we agreed long time 
ago to not break master), so just merge the "kf5 clean branch" into it and 
that's it, no?

> For future (to prevent any such problem with rebasing), staging areas
> would be outside of main KDE git repository.

How would that fix anything? You will still not be able to rebase master. Or 
you're saying that you want to rebase your work branches?

> But for now I would like to have finally KF5 port in master branch.
> 
> I'm very disappointed by KDE as I'm periodically hitting technical
> problems with KDE infrastructure which makes maintaining of Kopete
> application just harder. 

Now that you mention it, I'm very disappointed that you never answered my 
answer to your email 
https://mail.kde.org/pipermail/release-team/2017-November/010714.html

> (Problems like git push is not reflected to
> annongit servers, git push hooks are failing because of dns server
> errors and now git push failed because rebase is not supported). When I
> compare it with other servers (like Launchpad, Github or old Gitorious)
> I never hit any problem on them (yet).

I've never hit any of the problems you mention with KDE servers either.

Best Regards,
  Albert

> 
> I'm not subscribed to kde-core-devel, so please CC me on reply.

plasma-active-window-control - was -Re: 2 New Plasmoids in Kdereview

[Albert Astals Cid]

El dissabte, 13 de gener de 2018, a les 10:46:01 CET, Martin Kostolný va 
escriure:
> 2) On the other hand plasma-active-window-control could be part of
> kdeplasma-addons because it is multiplatform, has C++ plugin and uses e.g.
> TaskManager module of Plasma which changes from time to time. So it would
> be nice to release always compatible version of this widget.

There seems to be lots of copied code in here.

Why?

Cheers,
  Albert

Re: 2 New Plasmoids in Kdereview

[Albert Astals Cid]

El dissabte, 13 de gener de 2018, a les 22:08:01 CET, Ben Cooksley va 
escriure:
> On Fri, Jan 12, 2018 at 11:18 AM, Ingo Klöcker  wrote:
> > On Donnerstag, 11. Januar 2018 21:10:51 CET Ben Cooksley wrote:
> >> On Thu, Jan 11, 2018 at 1:15 PM, Martin Kostolný 
> > 
> > wrote:
> >> > I'd like to move forward with my new plasmoid projects that landed in
> >> > kdereview some time ago.
> >> > 
> >> > https://phabricator.kde.org/source/plasma-redshift-control/
> >> > https://phabricator.kde.org/source/plasma-active-window-control/
> >> 
> >> Given that the review period has long since passed I think we can
> >> safely say that these two applets can move to their final place from
> >> KDE Review.
> > 
> > I don't think that Martin has emailed "kde-core-devel and other relevant
> > mailing lists with details of your project and what the expected
> > destination is for the repo" which is point 3 under kdereview on
> > https://community.kde.org/Policies/Application_Lifecycle
> > 
> > Therefore, I think the review period did not actually start yet. Or have
> > the projects already been reviewed elsewhere, e.g. on the plasma ml?
> 
> Oops, if such a thread hasn't been started then we do indeed need to
> get a review thread underway.

Yes, Martin, please start two new threads, one for each plasmoid so we can 
actually do the review since you didn't do that yet.

Cheers,
  Albert

> 
> > Regards,
> > Ingo
> 
> Cheers,
> Ben

Re: KDE inclusion

[Albert Astals Cid]

El dijous, 11 de gener de 2018, a les 12:15:15 CET, Kevin Funk va escriure:
> On Tuesday, 9 January 2018 21:06:36 CET Michael Reeves wrote:
> > I have a version of kdiff3 that I ported to kf5. I like to what build
> > requirements kf5 as a whole has. Also what would be the process for being
> > considered for inclusion in kde?
> 
> Heya,
> 
> Note: kdiff3 right now is hosted & developed on SourceForge.
> 
> I'd love to see kdiff3 being adopted by KDE again (it former was KDE
> extragear if I understood correctly). kdiff3 is a super useful tool -- and
> right now development has stalled a bit.
> 
> Talked to Joachim (the original author) a few weeks ago, where he stated he
> just doesn't have the time maintaining it anymore, really. I've CC'd Joachim
> so he can tell us whether he's okay with having kdiff3 developed further
> under the KDE umbrella.

I guess this is the most important question, if we can keep using the kdiff3 
name under's Joachim's blessing or we have to "fork it" and find a new name.

Cheers,
  Albert

> 
> I don't really know the process of having it integrated either. I'll leave
> that to others.
> 
> Kudos for doing the KF5 port!
> 
> Regards,
> Kevin

Re: kbackup in kdereview

[Albert Astals Cid]

El dimecres, 10 de gener de 2018, a les 20:03:39 CET, Martin Koller va 
escriure:
> On Mittwoch, 10. Jänner 2018 00:05:53 CET Albert Astals Cid wrote:
> > > It is already in playground at https://cgit.kde.org/kbackup.git
> > 
> > Quick notes:
> >  * You don't need the setTranslator call in main.cxx there's automagic for
> > 
> > that
> 
> fixed now
> 
> >  * You should remove the kol...@aon.at in the about data and get a
> > 
> > bugs.kde.org product
> 
> How can I get one ?
> 
> >  * Seems there's some issues with i18n, after a quick backup i got
> > 
> > ...finished slice /home/kdeunstable/kbackup/build/
> > backup_2018.01.10-00.02.29_1.tar(I18N_ARGUMENT_MISSING)
> > -- Filtered Files: 0(I18N_ARGUMENT_MISSING)
> 
> this was already fixed by the awesome translation guys.
> 
> >  * What is the Medium: label and the percentage bar after it?
> 
> Medium: 
> is telling you to which medium you are currently writing to, e.g. the first
> ZIP disk The application was built when ZIP drives and other smaller
> removable devices were more common. Therefore the backup can be split into
> multiple slices, put onto several media.

I see, maybe it would make to hide it until you are writing on the second 
medium? 

I mean i understand you have code somewhere that checks the current medium got 
full and asks for another one or something, then it's the moment when makes 
sense to show the Medium, no? Otherwise showing always Medium: 1 or Medium: 0 
(i guess the different is done a backup vs not done any backup) is always 
weird for the newbie like me :)

Cheers,
  Albert

> 
> The percentage shows how full the medium is right now, and the size to the
> right of the bar tells you how much data you can store on it (free space).
> 
> >  * How do i get a non full backup? ( i guess it would be an incremental
> >  one? )
> right. In the profile settings, set the full backup interval to at least 2
> days, then start the backup and it will display "Next backup: Incremental
> backup"
> 
> > Also crashes on Alt+F4
> 
> Ah, damned. I introduced this just a few days ago trying to fix a hang on
> exit with dbus ... Thanks for finding.
> Fixed.

Re: kbackup in kdereview

[Albert Astals Cid]

El dilluns, 8 de gener de 2018, a les 23:47:52 CET, Martin Koller va escriure:
> Hi all,
> 
> I'd like to announce kbackup - A Backup program with an easy to use User
> Interface
> 
> KBackup is a program that lets you back up any directories or files,
> whereby it uses an easy to use directory tree to select the things to back
> up.
> 
> The program was designed to be very simple in its use so that it can be used
> by non-computer experts.
> 
> It can do full- and incremental backups.
> 
> The storage format is the well known TAR format, whereby the data is still
> stored in compressed format (bzip2 or gzip).
> 
> The backup can be put onto a local directory (mounted device, etc.) but also
> on a remote URL (thanks to KDE KIO).
> 
> I started development already a long time ago in 2006, based on Qt3(!).
> I released it on https://www.linux-apps.com/content/show.php?content=44998
> and it quickly became a much downloaded program.
> Over the years I always added new features when something I felt was
> missing. In the last year I finally managed to upgrade it to using KF5, and
> I feel it's time to integrate it more deeply with the KDE project. It has
> also a handbook and was already integrated with the translation team,
> thanks to Luigi Toscano and Burkhard Lück
> 
> I think a good harbor for it will be kdeutils.
> 
> It is already in playground at https://cgit.kde.org/kbackup.git

Also crashes on Alt+F4

==8882== Invalid read of size 8
==8882==at 0x138655: main (main.cxx:142)
==8882==  Address 0x160707a0 is 0 bytes inside a block of size 176 free'd
==8882==at 0x4C2F25B: operator delete(void*) (vg_replace_malloc.c:576)
==8882==by 0x1436B1: MainWindow::~MainWindow() (Selector.hxx:24)
==8882==by 0x831766F: QObject::event(QEvent*) (in 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.7.1)
==8882==by 0x6D68B0A: QWidget::event(QEvent*) (in 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.7.1)
==8882==by 0x6E67ABA: QMainWindow::event(QEvent*) (in 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.7.1)
==8882==by 0x5CDB636: KMainWindow::event(QEvent*) (in 
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5.31.0)
==8882==by 0x5D20DD4: KXmlGuiWindow::event(QEvent*) (in 
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5.31.0)
==8882==by 0x6D2135B: QApplicationPrivate::notify_helper(QObject*, QEvent*) 
(in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.7.1)
==8882==by 0x6D28B20: QApplication::notify(QObject*, QEvent*) (in 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.7.1)
==8882==by 0x82EABFF: QCoreApplication::notifyInternal2(QObject*, QEvent*) 
(in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.7.1)
==8882==by 0x82ED39C: QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.7.1)
==8882==by 0x833EC92: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.7.1)
==8882==  Block was alloc'd at
==8882==at 0x4C2E19F: operator new(unsigned long) (vg_replace_malloc.c:334)
==8882==by 0x1383F6: main (main.cxx:105)

Re: Phabricator: How to get the email address of contributors?

[Albert Astals Cid]

El dimarts, 2 de gener de 2018, a les 22:24:13 CET, Luigi Toscano va escriure:
> Dominik Haumann ha scritto:
> > Hi everyone,
> > 
> > it just happened to me again, that I want to commit/push a change of
> > someone else (first-time contributor) with the correct --author="x y
> > " data.
> > 
> > But Phabricator hides the email address, so I either have to ask via
> > phabricator messages for the email address, which is time consuming,
> > or I simply give up and commit in my own name, claiming work done by
> > others.
> > 
> > Is there a simple way to find out the email address (identity.kde.org
> > does not work, since phab user accounts seem to be separate).
> > 
> > Help is very much appreciated. In fact, I would love to simply see the
> > correct email addresses, once I am logged into phabricator. Could that
> > be done?
> 
> Let's restart the discussion where it stopped last time (please read it):
> 
> https://phabricator.kde.org/T5242
> 
> tl;dr
> Phabricator does not hide if the contributor used arcanist to submit the
> patch.
> 
> IMHO that should work even when git format-patch is used but there is an
> internal disagreement on this.
> 
> IMHO (more complicated) that should work even with the web submission with
> some checkbox is marked (to publish the email and name), but there is both
> internal disagreement and upstream one on this.

 * We have the info
 * We used to show it
 * No ne ever complained about us showing it (AFAIK)
 * Not showing it breaks our workflow

I can't think of no other reason to not show the email address other than "the 
software we are using is bad".

Cheers,
  Albert

Re: Reviving KAudioCreator

[Albert Astals Cid]

El divendres, 22 de desembre de 2017, a les 9:30:31 CET, Kevin Ottens va 
escriure:
> Hello all,
> 
> I happen to be one of those poor souls who still rip CDs from time to time.
> I'm using Dolphin for that right now, but I miss the convenience of using
> KAudioCreator a while back.
> 
> It looks like it's not released at all anymore. After a quick glance at the
> repository, it seems to be in a somewhat good shape (at least it builds and
> starts, I didn't push further yet).
> 
> Then, I'd like to revive it and have it part of KDE Applications. Anyone
> with an objection about that? If none, how do we proceed?
> 
> I see a couple of things which need to be improved a bit so I'll try to work
> on those in the meantime.

One kind-of-big bug i'd like fixed is that it doesn't realize the encoder 
command line is not there, i was waiting for like 5 minutes wondering why it 
took so much to encode until i realized that i don't actaully have the flac 
command line installed.

Cheers,
  Albert

> 
> Regards.

Re: krename in kdereview

[Albert Astals Cid]

El dilluns, 4 de desembre de 2017, a les 20:23:32 CET, Heiko Becker va 
escriure:
> On 12/03/17 23:39, Albert Astals Cid wrote:
> >> It's a batch renamer started outside of KDE and its infrastructure but
> >> it was kind of abandoned and I got the ok the from the original author
> >> to move it to git.kde.org.
> >> 
> >> The code can be found at kde:krename.
> >> 
> >> [..]
> > 
> > Maybe you want to use poppler instead of podofo for the pdf plugin? Since
> > Okular uses poppler most distros have it available, podofo seems to be a
> > bit more niche in that regard.
> 
> calibre also requires it here and it's also an optional dependency but
> your point might have merit nevertheless and I guess it's not that hard
> to get the same things from poppler.
> 
> > When in the Filename tab, wouldn't it make more sense for Simple Filename
> > tab to be first and not second?
> 
> Hmm, actually I only ever used the advanced tab. Which makes me think
> the UI should be improved and there shouldn't be two tabs. Maybe
> something like the advanced tab with helpful hints/shortcuts
> buttons/highlighting for new users.

To be honest i didn't really look at the tab contents, just felt a bit weird 
UI wise.

> 
> > Is it only me that Alt+4 doesn't select the 4th tab?
> 
> It seems to be only you ;-) or at least it works here.

Ok :)

> 
> > The list on the plugins tab seems to be working only on clicks instead of
> > on change, i.e. if i click on the first plugin and then use they keyboard
> > arrows to change to another plugin the right hand side contents don't
> > change.
> Fixed with 23d4701
> 
> Thanks for your review.

:)

> 
> Best regards,
> Heiko

Re: Symmy in kde-review

[Albert Astals Cid]

El dilluns, 4 de desembre de 2017, a les 22:32:41 CET, Elvis Angelaccio va 
escriure:
> On domenica 3 dicembre 2017 23:14:58 CET, Albert Astals Cid wrote:
> > El dijous, 23 de novembre de 2017, a les 10:34:41 CET, Elvis Angelaccio va
> > 
> > escriure:
> >> Hi,
> >> symmy has been moved to kde-review for the usual review process.
> >> 
> >> It's a tiny frontend for the symmetric encryption functionality of GPG.
> >> It
> >> doesn't handle signing or public/private keys, as we already have kgpg or
> >> kleopatra for that. ...
> > 
> > I built symmy and did:
> >  * cd builddir
> >  * symmy Makefile
> >  * wrote a password
> > 
> > Now what? Where is my encrypted file?
> 
> This should be fixed now, it was a QUrl bug.
> 
> > Also i'd say that the i18n from symmy/plugin won't load the
> > symmy catalog? you
> > probably want to use the i18nd variants?
> 
> I added a TRANSLATION_DOMAIN define, is that enough?

Yeah that should work too.

Cheers,
  Albert

> 
> > And you also KLocalizedString::setApplicationDomain in your main.cpp?
> 
> Added the KLocalizedString::setApplicationDomain() call in main.cpp.
> 
> > Cheers,
> > 
> >   Albert
> >> 
> >> I'd like to move it to either extragear-utils or kde-utils, if everything
> >> looks good.
> >> 
> >> Thanks,
> >> Elvis

Re: krename in kdereview

[Albert Astals Cid]

El dimarts, 28 de novembre de 2017, a les 10:08:31 CET, Heiko Becker va 
escriure:
> Hello,
> 
> thanks to the KDE Sysadmins krename was moved to kdereview today.
> 
> It's a batch renamer started outside of KDE and its infrastructure but
> it was kind of abandoned and I got the ok the from the original author
> to move it to git.kde.org.
> 
> The code can be found at kde:krename.
> 
> The intended target should be
> extragear-or-whatever-that-thing-missing-a-proper-name-is/utils
> 
> Considering KDELibs4 reached the end of its life-cycle, I'd like to
> release a beta version soon after krename passes review.
> 
> Questions? Comments?

Maybe you want to use poppler instead of podofo for the pdf plugin? Since 
Okular uses poppler most distros have it available, podofo seems to be a bit 
more niche in that regard.

When in the Filename tab, wouldn't it make more sense for Simple Filename tab 
to be first and not second?

Is it only me that Alt+4 doesn't select the 4th tab?

The list on the plugins tab seems to be working only on clicks instead of on 
change, i.e. if i click on the first plugin and then use they keyboard arrows 
to change to another plugin the right hand side contents don't change.

Cheers,
  Albert

> 
> Best regards,
> Heiko

Re: Symmy in kde-review

[Albert Astals Cid]

El dijous, 23 de novembre de 2017, a les 10:34:41 CET, Elvis Angelaccio va 
escriure:
> Hi,
> symmy has been moved to kde-review for the usual review process.
> 
> It's a tiny frontend for the symmetric encryption functionality of GPG. It
> doesn't handle signing or public/private keys, as we already have kgpg or
> kleopatra for that.
> 
> Symmy can be useful if you have to send some sensitive file to someone, of
> if you want to store it on some proprietary cloud service.
> 
> It comes with a CLI application and plugins for GUI integration with
> Dolphin/Plasma.

I built symmy and did:
 * cd builddir
 * symmy Makefile 
 * wrote a password

Now what? Where is my encrypted file?

Also i'd say that the i18n from symmy/plugin won't load the symmy catalog? you 
probably want to use the i18nd variants?

And you also KLocalizedString::setApplicationDomain in your main.cpp?

Cheers,
  Albert

> 
> I'd like to move it to either extragear-utils or kde-utils, if everything
> looks good.
> 
> Thanks,
> Elvis

Re: liquidshell in kdereview

[Albert Astals Cid]

El diumenge, 3 de desembre de 2017, a les 13:51:49 CET, Martin Flöser va 
escriure:
> Am 2017-12-03 12:28, schrieb Albert Astals Cid:
> > El dissabte, 2 de desembre de 2017, a les 13:26:18 CET, Martin Flöser
> > va
> > 
> > escriure:
> >> Am 2017-12-02 10:17, schrieb Albert Astals Cid:
> >> > El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va
> >> > 
> >> > escriure:
> >> >> Am 2017-11-29 21:23, schrieb Martin Koller:
> >> >> > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> >> >> >> Hi all,
> >> >> >> 
> >> >> >> I'd like to announce an application I've implemented over the last
> >> >> >> few
> >> >> >> weeks - liquidshell
> >> >> > 
> >> >> > since more than 3 weeks have passed, I hopefully have addressed all
> >> >> > issues and I got no further comments,
> >> >> > are there any blocking points you see or can I proceed requesting
> >> >> > the
> >> >> > move to extragear ?
> >> >> 
> >> >> Yes I still see several blocking items. E.g.
> >> >> "liquidshell is an alternative to plasmashell"
> >> >> 
> >> >> I think that should be removed. I do not want any competing or
> >> >> alternative to plasmashell provided by KDE. This would be very bad for
> >> >> our community. Please formulate the readme without mentioning Plasma.
> >> >> I'm sure you are able to find unique selling points without going into
> >> >> any part of competition with Plasma or in any part which could be
> >> >> misunderstood.
> >> >> 
> >> >> What I do not want is Phoronix: "KDE starts new desktop shell because
> >> >> Plasma sucks". Please formulate everything so that it cannot be
> >> >> misunderstood.
> >> >> 
> >> >> Also remove all the parts about the main motivation without "hog cpu
> >> >> or
> >> >> ram". We already discussed that this was a problem with your local and
> >> >> personal setup. Don't piss on Plasma because your setup has problems.
> >> >> You have all the rights to scratch your own itch, but don't piss on
> >> >> us.
> >> >> 
> >> >> Personally I'm against liquidshell getting added to extragear. I think
> >> >> this would be harming the KDE community to have a shared desktop
> >> >> shell.
> >> >> We have already too much fragmentation on the desktop area and I don't
> >> >> think KDE should support this by creating yet another desktop shell.
> >> >> We
> >> >> should think here in the big picture.
> >> > 
> >> > So you'd rather prefer he did this in github?
> >> 
> >> I did't write that and I'm surprised you come to that conclusion.
> > 
> > You said we should not take this in. Martin wants this to be published
> > it
> > somehwere, so it has to end up somewhere in github or similar. That was
> > my
> > conclusion, i really don't see how is it surprising?
> 
> Yes, I think we should not take it into extra-gear. That does not mean
> that I have anything against it being hosted on KDE's git
> infrastructure. Whether it gets released and promoted by the KDE
> community is rather orthogonal to where it is hosted.
> 
> So I don't understand your reasoning.

There's no such thing as extregear anymore (well there is in the l10n module 
sense but we should be trying to get rid of it)

Conceptually, there is:
 * stuff hosted in KDE and released as a "group", i.e.
   - Plasma
   - KDE Frameworks
   - "KDE Applications" [1] 
 * stuff hosted in KDE and released individually [2]
   - Krita
   - rsibreak
   - kaffeine
   - konversation
   - etc

So I don't understand your reasoning.

Are you suggesting that we can host something in kde repos and it gets 
released by a kde person but still not be a kde project?

Cheers,
  Albert

[1] yes we all agree it's a bad name but noone has come up with a better one
[2] formerly known as extragear

Re: liquidshell in kdereview

[Albert Astals Cid]

El dissabte, 2 de desembre de 2017, a les 13:26:18 CET, Martin Flöser va 
escriure:
> Am 2017-12-02 10:17, schrieb Albert Astals Cid:
> > El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va
> > 
> > escriure:
> >> Am 2017-11-29 21:23, schrieb Martin Koller:
> >> > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> >> >> Hi all,
> >> >> 
> >> >> I'd like to announce an application I've implemented over the last few
> >> >> weeks - liquidshell
> >> > 
> >> > since more than 3 weeks have passed, I hopefully have addressed all
> >> > issues and I got no further comments,
> >> > are there any blocking points you see or can I proceed requesting the
> >> > move to extragear ?
> >> 
> >> Yes I still see several blocking items. E.g.
> >> "liquidshell is an alternative to plasmashell"
> >> 
> >> I think that should be removed. I do not want any competing or
> >> alternative to plasmashell provided by KDE. This would be very bad for
> >> our community. Please formulate the readme without mentioning Plasma.
> >> I'm sure you are able to find unique selling points without going into
> >> any part of competition with Plasma or in any part which could be
> >> misunderstood.
> >> 
> >> What I do not want is Phoronix: "KDE starts new desktop shell because
> >> Plasma sucks". Please formulate everything so that it cannot be
> >> misunderstood.
> >> 
> >> Also remove all the parts about the main motivation without "hog cpu
> >> or
> >> ram". We already discussed that this was a problem with your local and
> >> personal setup. Don't piss on Plasma because your setup has problems.
> >> You have all the rights to scratch your own itch, but don't piss on
> >> us.
> >> 
> >> Personally I'm against liquidshell getting added to extragear. I think
> >> this would be harming the KDE community to have a shared desktop
> >> shell.
> >> We have already too much fragmentation on the desktop area and I don't
> >> think KDE should support this by creating yet another desktop shell.
> >> We
> >> should think here in the big picture.
> > 
> > So you'd rather prefer he did this in github?
> 
> I did't write that and I'm surprised you come to that conclusion.

You said we should not take this in. Martin wants this to be published it 
somehwere, so it has to end up somewhere in github or similar. That was my 
conclusion, i really don't see how is it surprising?

> 
> > I mean yes, ideally everyone would work on whathever i want them to
> > work on,
> > but since this won't happen, can we try to make KDE a nice and
> > welcoming place
> > to challenge eachother ideas and implementations?
> > 
> > I'm sure a little friendly (and yes this goes both ways in the
> > meanthing that
> > liquidshell should not piss on plasmashell) competition never hurt
> > anyone :)
> 
> Such competition exists - especially on the desktop shell area,
> especially on the QtQuick vs. QtWidgets area.
> 
> There currently are the following Qt based desktop shells:
>   * Plasma (QtQuick)
>   * LxQt (QtWidgets)
>   * Lumina (QtWidgets)
>   * Hawaii (QtQuick AFAIK)
> 
> In addition there is competition in the GTK world:
>   * GNOME Shell
>   * Pantheon
>   * Xfce
>   * Budgie
>   * Cinnamon
> 
> And there are even further desktop environments on even other toolkits
> such as E.
> 
> If there are things we need, it's yet another desktop environment. There
> is already sufficient external competition, so that we don't need
> internal competition.
> 
> As I already said: Martin is free to do in his spare time whatever he
> wants. If he thinks we need another desktop shell, fine. He can do so.
> Whether we as KDE should endorse and support this is another question.
> 
> I think for the overall Linux world yet another desktop shell is
> harming. You can have another opinion and that and that's also fine. I
> only shared my opinion stating that I consider this as harming and that
> we as KDE should IMHO not support this.
> 
> Btw. I would see this completely different if for example LxQt would
> approach KDE and ask for joining. I would support this and would be
> happy to see them becoming a part of KDE.
> 
> Also I think the project should not be added as the whole thing is
> hypocrite. According to the readme Martin has a problem with QtQuick.
> Fair enough, but why is he fine with the following are

Re: liquidshell in kdereview

[Albert Astals Cid]

El dissabte, 2 de desembre de 2017, a les 11:52:53 CET, Sebastian Kügler va 
escriure:
> On Sat, 02 Dec 2017 10:27:16 +0100
> 
> Albert Astals Cid <aa...@kde.org> wrote:
> > El divendres, 1 de desembre de 2017, a les 14:05:19 CET, Sebastian
> > 
> > Kügler va escriure:
> > > On Thu, 30 Nov 2017 18:41:28 +0100
> > > 
> > > Martin Koller <kol...@aon.at> wrote:
> > > > On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler
> > > > 
> > > > wrote:
> > > > > On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote:
> > > > > > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> > > > > > > Hi all,
> > > > > > > 
> > > > > > > I'd like to announce an application I've implemented over
> > > > > > > the last few weeks - liquidshell
> > > > > > 
> > > > > > since more than 3 weeks have passed, I hopefully have
> > > > > > addressed all issues and I got no further comments, are there
> > > > > > any blocking points you see or can I proceed requesting the
> > > > > > move to extragear ?
> > > > > > 
> > > > > > A note regarding the comment to not use the start-here-kde
> > > > > > logo: I got in contact with the visual design group and got
> > > > > > the information to stay with this logo.
> > > > > 
> > > > > I strongly disagree. Could you point me to the discussion?
> > > > 
> > > > it was mail exchange in private (german) mails with the
> > > > breeze/oxygen-icons maintainer "kainz.a" <kain...@gmail.com>
> > > 
> > > In any case, this is not just a visual design question, it's a
> > > branding and marketing question just as much, and a general
> > > communication and positioning question as well.
> > 
> > Yes, the logo has to be changed.
> > 
> > > I'm vetoing any move to released software at the very least until
> > > the logo has changed. I also don't think that a technical review of
> > > the code is enough to warrant us to ship liquidshell as a finished
> > > product, for the reasons that Martin Flöser pointed out. It would
> > > harm KDE as a whole and Plasma specifically (ironically, the
> > > product that you use most parts from).
> > 
> > This is an interesting position, are we supposed to subordinate
> > technical decisions to marketing now?
> 
> We are doing a review not just based on the code, but based on "is this
> suitable and a good idea for KDE to release in this way". It's not
> purely marketing, but general communication.
> 
> If I wrote a very simple application that just poppped up a Window that
> said "Krita is crap", the code could technically be totally fine, but
> it may still not be a good idea to do it. If Martin wants to release
> this under the KDE umbrella, we should make sure we're not actively
> harming other people working inside KDE.
> 
> > Also are you even sure we get better marketing by not allowing
> > liquidshell to be a KDE thing?
> > 
> > I can very well see headlines like "Plasma developers force other KDE
> > developers outside of KDE".
> > 
> > I would like to empathize that we are at our core Innovation.
> > 
> > And yes, I agree that doing a desktop shell in QWidgets doesn't seem
> > like Innovation to me, but Innovation is the process of having new
> > ideas and products.
> 
> Absolutely, but it should also be advertised in a healthy way, and
> liquidshell in its current form isn't.

Ok, so we're on the same page :)

Cheers,
  Albert

Re: liquidshell in kdereview

[Albert Astals Cid]

El divendres, 1 de desembre de 2017, a les 14:05:19 CET, Sebastian Kügler va 
escriure:
> On Thu, 30 Nov 2017 18:41:28 +0100
> 
> Martin Koller  wrote:
> > On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler wrote:
> > > On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote:
> > > > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> > > > > Hi all,
> > > > > 
> > > > > I'd like to announce an application I've implemented over the
> > > > > last few weeks - liquidshell
> > > > 
> > > > since more than 3 weeks have passed, I hopefully have addressed
> > > > all issues and I got no further comments, are there any blocking
> > > > points you see or can I proceed requesting the move to extragear ?
> > > > 
> > > > A note regarding the comment to not use the start-here-kde logo:
> > > > I got in contact with the visual design group and got the
> > > > information to stay with this logo.
> > > 
> > > I strongly disagree. Could you point me to the discussion?
> > 
> > it was mail exchange in private (german) mails with the
> > breeze/oxygen-icons maintainer "kainz.a" 
> 
> In any case, this is not just a visual design question, it's a branding
> and marketing question just as much, and a general communication and
> positioning question as well.

Yes, the logo has to be changed.

> 
> I'm vetoing any move to released software at the very least until the
> logo has changed. I also don't think that a technical review of the
> code is enough to warrant us to ship liquidshell as a finished product,
> for the reasons that Martin Flöser pointed out. It would harm KDE as a
> whole and Plasma specifically (ironically, the product that you use
> most parts from).

This is an interesting position, are we supposed to subordinate technical 
decisions to marketing now? 

Also are you even sure we get better marketing by not allowing liquidshell to 
be a KDE thing?

I can very well see headlines like "Plasma developers force other KDE 
developers outside of KDE".

I would like to empathize that we are at our core Innovation.

And yes, I agree that doing a desktop shell in QWidgets doesn't seem like 
Innovation to me, but Innovation is the process of having new ideas and 
products.

Maybe this one has great "external" success and against your and my prediction 
gives KDE 1000 new developers that besides contributing to it also end up 
contributing to other parts of our software range.

Let's try to think positive :)

Cheers,
  Albert



> 
> Cheers,
> 
> -- sebas

Re: liquidshell in kdereview

[Albert Astals Cid]

El dijous, 30 de novembre de 2017, a les 19:57:45 CET, Martin Flöser va 
escriure:
> Am 2017-11-29 21:23, schrieb Martin Koller:
> > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote:
> >> Hi all,
> >> 
> >> I'd like to announce an application I've implemented over the last few
> >> weeks - liquidshell
> > 
> > since more than 3 weeks have passed, I hopefully have addressed all
> > issues and I got no further comments,
> > are there any blocking points you see or can I proceed requesting the
> > move to extragear ?
> 
> Yes I still see several blocking items. E.g.
> "liquidshell is an alternative to plasmashell"
> 
> I think that should be removed. I do not want any competing or
> alternative to plasmashell provided by KDE. This would be very bad for
> our community. Please formulate the readme without mentioning Plasma.
> I'm sure you are able to find unique selling points without going into
> any part of competition with Plasma or in any part which could be
> misunderstood.
> 
> What I do not want is Phoronix: "KDE starts new desktop shell because
> Plasma sucks". Please formulate everything so that it cannot be
> misunderstood.
> 
> Also remove all the parts about the main motivation without "hog cpu or
> ram". We already discussed that this was a problem with your local and
> personal setup. Don't piss on Plasma because your setup has problems.
> You have all the rights to scratch your own itch, but don't piss on us.
> 
> Personally I'm against liquidshell getting added to extragear. I think
> this would be harming the KDE community to have a shared desktop shell.
> We have already too much fragmentation on the desktop area and I don't
> think KDE should support this by creating yet another desktop shell. We
> should think here in the big picture.

So you'd rather prefer he did this in github?

I mean yes, ideally everyone would work on whathever i want them to work on, 
but since this won't happen, can we try to make KDE a nice and welcoming place 
to challenge eachother ideas and implementations? 

I'm sure a little friendly (and yes this goes both ways in the meanthing that 
liquidshell should not piss on plasmashell) competition never hurt anyone :)

Cheers,
  Albert

> 
> Cheers
> Martin

Re: liquidshell in kdereview

[Albert Astals Cid]

+1000 to what Friedrich said :)

Cheers,
   Albert

En lunes, 6 de noviembre de 2017 17:13:04 CET, Friedrich W. H. Kossebau 
 escribió: 

Hi Martin,

Am Freitag, 3. November 2017, 21:30:19 CET schrieb Martin Koller:
> I'd like to announce an application I've implemented over the last few weeks
> - liquidshell


Congrats to the achievement. It surely feels good to run a workspace one has 
created one themselves :)

While myself I will choose Plasma over liquidshell due to my needs and 
expectations of certain features, I can see that liquidshell would satisfy 
those persons who need or want just a simple hard-coded shell following a 
well-known UI design & concept, yet stay with the usual tools and apps from 
the KDE software world, ideally perfectly integrated with the workspace (think 
filemanager, terminal, text editor, etc). People like obviously yourself :) So 
those persons might be surely happy about you sharing your work with them.

My hopes for liquidshell as another project under the KDE community umbrella:
* improvements for shared middleware, perhaps even introducing some more
  where it makes sense to share between Plasma, liquidshell & others
  (pushing for more clear UI-core separation, which in theory is for good)
  libtm might be one such thing, the weather data provider system also calls
  for being shared code with Plasma (and e.g. the Marble weather plugin)
* another testing ground for protocols & standards in development
* make more obvious that "KDE" is about a community, not a certain software
* give perhaps remaining trinity desktop developers and other
  Plasma-no-Qt-jay-fans a new center for their goals and as result also new
  contributors for the shared middleware, tools and apps (at least for their
  current QtWidgets UI variant ;) )

Re: gosh, yet another workspace
In a perfect world everybody would join work on the one true golden workspace 
solution, reality is that there is no such one-workspace-which-fits-all. Not 
to forget the mythical person-month issue.

And if people rather go and write their own software instead of joining 
existing projects, it should be the projects asking themselves why they have 
not been attractive enough in the first place.
Telling people instead "you should not do X, but Y" is rather the opposite of 
what Free Software is about. Even when first saying "Your are free, but".

I applaud you, Martin, for managing to solve your needs yourself and for 
sharing the results with the rest of the world, instead of keeping them for 
yourself.
And as KDE community we can feel honored you trust us to be the best place for 
further development of your software, instead of going github or elsewhere.

Re: liquidshell as name
When I read liquidshell I first thought about something very dynamic, highly 
animated. So not sure "liquid" is the best term to use in the name. But then 
we all know naming is hard, good luck with it :)

Cheers
Friedrich

Re: liquidshell in kdereview

[Albert Astals Cid]

Sorry for top postiing, stupid webmail.

Almost all projects start as a one man project, if you reject those you're 
basically making impossible for them to grow.

Cheers,
  Albert

En lunes, 6 de noviembre de 2017 15:31:34 CET, Tomaz Canabrava 
 escribió: 

On Mon, Nov 6, 2017 at 1:30 PM, Alexander Potashev  wrote:
> 2017-11-06 14:16 GMT+03:00 Kevin Funk :
>> You're free to work on whatever you like to of course, but to me this sounds
>> like wasted effort. Your good incentives would be better spent with joining 
>> up
>> with others aiming for the same (LxQt for instance).
> 
> Hi,
> 
> I had a bad impression of LxQt because:
>  1. it didn't work for me out of the box,

For many people kde applications don't work out of the box too.

>   2. it consists of many components, it's hard to figure out which of
> them are optional,

Also true for kde applications.

>   3. it has poor infrastructure compared to KDE, e.g. their i18n server
> hadn't been working for about a year.

I cant comment on that - but the project seems to be alive as there was a new 
release just last month with a lot of changes, also they use kf5 libraries 
where needed. 
 
>  Thus liquidshell looks better to me than lxqt; joining an inferior
> project is not a good idea.

please refrain from using words like 'inferior' for a project as it's not 
helpful. 
Currently the whole code for liquidshell is done for one person, and we (as in 
the KDE Sc) suffer for a lot of good projects and ideas that as soon as the 
original developers get tired the project stalls,
like Macaw Movie, Spectacle, Baloo and quite a few others - so I'm really 
afraid of a one-man-project that's basically what other many projects already 
do.


About liquidshell, I tried but it didn't even compile on my machine (some issue 
with Solid)


 
>  --Alexander Potashev

Re: Python bindings using cppyy (was: An update on Python bindings)

[Albert Astals Cid]

El dijous, 2 de novembre de 2017, a les 18:22:38 CET, Shaheed Haque va 
escriure:
> A progress update...
> 
> On 24 October 2017 at 13:05, Shaheed Haque  wrote:
> > Hi all,
> > 
> > I have a preliminary version of the Cppyy bindings generator CMake
> > 
> > support available here:
> > https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-ex
> > perimental-version-of-a/diff> 
> > There are some TODOs yet to be addressed,
> 
> The original TODOs and bugs have been resolved, and there is the
> beginnings of support for packaging frameworks under a Python
> namespace as in "KF5.KDCRAW". Also, as a significant datapoint, I'm
> close [1] to being able to generate a *complete* set of bindings for
> all of Akonadi driven from CMake with just 2-3 lines of custom logic.
> This contrasts with the 549 SLOC of customisation needed to produce a
> substantially slash-and-burned subset of Akonadi [2] with the
> SIP-based approach.
> 
> > but I would appreciate
> > feedback on how easy it would be to integrate this with KDE's
> > buildsystem, especially for the frameworks. I'm a CMake noob, but the
> > basic idea I have is that the packager of some_framework might do
> > something like this:
> > 
> > find_package(cppyy)
> > CPPYY_ADD_BINDINGS(
> > 
> > ...
> > LINK_LIBRARIES some_framework_LIBRARIES
> > H_DIR some_framework_INCLUDE_DIRS
> > H_FILES )
> 
> In the course of working through the "KF5" namespace implementation,
> it has become apparent to me that a framework-by-framework integration
> of the binding generation logic (as previously pioneered by Steve)
> probably cannot work in general because there are cases where multiple
> frameworks contribute to to the same C++ namespace, for example:
> 
> $ grep -r '^namespace Akonadi' /usr/include/KF5/Akonadi*
> /usr/include/KF5/AkonadiAgentBase/resourcesettings.h:namespace Akonadi
> ..
> /usr/include/KF5/AkonadiCore/agentfilterproxymodel.h:namespace Akonadi
> ..
> /usr/include/KF5/AkonadiSearch/Debug/akonadisearchdebugsearchpathcombobox.h:
> namespace Akonadi
> ..
> /usr/include/KF5/AkonadiWidgets/agenttypedialog.h:namespace Akonadi
> ..
> /usr/include/KF5/AkonadiXml/xmldocument.h:namespace Akonadi
> ..
> 
> The problem is that the Python implementation of these namespaces is a
> class, and so treating these frameworks (let's not quibble over
> whether KF5Akonadi* are truly KF5 frameworks, the point is more
> general) as separate would result in multiple colliding Python class
> definitions. The only solution I can see would be to bundle all of
> KF5Akonadi* into a single set of bindings, e.g. KF5.Akonadi, and
> AFAICS, this can only be done out of tree from the individual
> frameworks, say in kde-bindings.git [3].

Sincerely if you go with out ot tree bindings they will always be broken 
because people working on the frameworks won't even see them, if the problem 
is that frameworks have to be self-contained, this seems like a good general 
rule to me and maybe what we should do is fix the libs?

Cheers,
  Albert

> 
> The work to date attempts to maintain a clean separation such that all
> C++ builds are done from CMake, and all Python builds are done using
> setuptools/pip.
> 
> Apart from working through bugs [1], the remaining work items I can
> 
> think of are, as before:
> >> - Need to look into the exact usage of Qt-specifics: signals/slots and
> >> interoperability with SIP-based PyQt
> >> (https://root.cern.ch/root/htmldoc/guides/users-guide/PythonRuby.html#glu
> >> e-ing-applications,
> >> https://root.cern.ch/doc/v606_ORIG/guide/ROOTandQt.html)
> >> 
> >> - Need to figure out how any customisations which *are* required
> >> should be handled.
> 
> plus:
> 
> - I'm working with upstream on how to support discovery (e.g. via
> autocompletion in Python3). There is some POC-level hackery in git as
> above, but there is work ongoing with upstream to find a robust
> solution.
> 
> - Flesh out how to make one set of bindings depend on another (e.g.
> tier 2 framework bindings might depend on tier 1 bindings, or maybe it
> is better to avoid PyQt and just produce cppyy-based bindings for Qt
> and depend on those).
> 
> As always, comments/ideas/suggestions are welcome.
> 
> Thanks, Shaheed
> 
> [1] There is a bug with namespaced externs being worked on with upstream.
> 
> [2]
> https://github.com/ShaheedHaque/extra-cmake-modules/blob/shaheed_master/fin
> d-modules/module_generation/PyKF5/Akonadi.py
> 
> [3] I attach an example CMakeLists.txt which shows now this can be
> driven from CMake for the case of KF5Akonadi*...the implementation is
> intended to serve as the basis for a generic solution usable across
> KF5 at least.
> 
> > On 16 October 2017 at 16:16, Shaheed Haque  wrote:
> >> As promised, here is an interim update on the investigation into the
> >> use of cppyy-based bindings for KF5 (and more...) instead of SIP-based
> >> bindings.
> >> 
> >> The first thing is that the 

Re: Simple Menu (Plasma widget) now in kdereview

[Albert Astals Cid]

El dijous, 2 de novembre de 2017, a les 19:42:57 CET, Eike Hein va escriure:
> On 11/02/2017 07:33 PM, David Edmundson wrote:
> > ​What's the intended destination after review?
> 
> Honestly, no idea. Playground? Extragear, does that still exist? Where
> do we put random projects these days? :)

We try not to call it extragear, but it's still called like that in some 
places, the problem with extragear is two fold, it seems it's "extra" when 
some things are not, and it seems extreagear-graphics is a "bundle" when it's 
not, so let's try to call it "Independently released applications" or 
something similar until someone comes with a better term :D

> 
> I don't want it to be in kdeplasma-addons: That would be one menu too
> many, and this is intended to be distributed mainly through the Store.
> 
> My main purpose in going through kdereview is to get Phabricator and
> Bugzilla entries for it, because users are asking for a better way to
> submit bug reports than Store comments.

and translations

P.S: I did have a quick look at the code and didn't find anything obviously 
wrong

Cheers,
  Albert
> 
> > David
> 
> Cheers,
> Eike

Re: Latte Dock in review phase

[Albert Astals Cid]

El dijous, 5 d’octubre de 2017, a les 0:00:01 CEST, Michail Vourlakos va 
escriure:
> Hello everyone,
> 
> we decided to make Latte an active kde project and so now it is in review
> phase. I believe the best place to be is extragear because we would like to
> keep some independence for the first year concerning releases...

Hi, what is the latte dock kde repo git url?

Cheers,
  Albert

> 
> What is Latte Dock?
> 
> Latte is a project that is trying to provide a unified solution concering
> docks and panels for the user. To achieve this it provides,
> the Latte app, a Latte qml library, a Latte containment, a Latte plasmoid,
> a Latte shell that uses plasma shell as base and 2 applets (a separator and
> a specialized spacer)
> 
> for more infos concerning the capabilities of the Latte suite you can find
> at:
> https://psifidotos.blogspot.nl/2017/04/latte-dock-v06-fresh-air.html
> https://psifidotos.blogspot.nl/2017/08/latte-dock-v07-tornado-is-coming.html
> 
> the project before entering the kde infrastructure could be found at:
> https://github.com/psifidotos/Latte-Dock
> 
> in review you can find our 0.7.1 version which is our stable version and
> the plan is that after we succeed in the review phase to release a 0.7.2
> version only through kde infrastructure...
> 
> regards,
> michail

Re: Review Request 130239: Exclude kconf_update from catching by uac on Windows

[Albert Astals Cid]

> On set. 26, 2017, 6:02 p.m., Albert Astals Cid wrote:
> > cmake/modules/Win32Macros.cmake
> > Lines 61 (patched)
> > <https://git.reviewboard.kde.org/r/130239/diff/2/?file=513534#file513534line61>
> >
> > I don't think it makes sense adding a new public-ish macro in 4.14.lots
> 
> Ralf Habacker wrote:
> See revision 1 of this patch at 
> https://git.reviewboard.kde.org/r/130239/diff/1/
> 
> Albert Astals Cid wrote:
> I'm personally happier with that patch for almost dead 4.14 (it has 2 
> releases left), now you're going to need someone with a win32 build/knowledge 
> to approve since honestly i have no idea what this does.
> 
> Ralf Habacker wrote:
> > for almost dead 4.14 (it has 2 releases left),
> 
> Looking at the number of open KF5 related windows issues I guess kmymoney 
> and umbrello for Windows will depends on KDE4 at least a year. 
> 
> >i have no idea what this does.
> 
> From 
> https://stackoverflow.com/questions/20096706/how-does-windows-decide-whether-to-display-the-uac-prompt
> 
> kconf_update is "hitting a Windows Installer Detection Technology 
> compatibility heuristic. Windows will try to detect when an application is an 
> installer, and probably needs to be elevated."
> 
> BTW: The same issue happens also with KF5
> 
> Alexey Min wrote:
> This looks good and harmless actually. As I understood, it adds a .rc 
> (windows resource file) with embedded manifest resource, saying that no 
> elevation is needed for this .exe file.
> We at our work also had problems with this windows heuristic (we had a 
> helper program, containing "setup" in its name, so it magically required 
> administrator rights with no real need for this).
> So if this really works and helps for windows, why not.

> Looking at the number of open KF5 related windows issues I guess kmymoney and 
> umbrello for Windows will depends on KDE4 at least a year. 

That has nothing to do with kdelibs 4.14.x not being released anymore after KDE 
Applications 17.08.3, which is what i said


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130239/#review103738
---


On set. 27, 2017, 9:19 a.m., Ralf Habacker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130239/
> ---
> 
> (Updated set. 27, 2017, 9:19 a.m.)
> 
> 
> Review request for kdelibs and Albert Astals Cid.
> 
> 
> Bugs: 384334
> http://bugs.kde.org/show_bug.cgi?id=384334
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This patch fixes an issue that on the first start of KMyMoney (and on some 
> computers on every start for example reported by 
> https://forum.kde.org/viewtopic.php?f=69=141673=ba4dcaa26018f16e19d21c58c34ad4e9)
>  on running kconf_update the user account control pops up and forces the user 
> to allow or deny  this application.
> 
> Commit message
> 
>Add Windows manifest to  kconf_update.exe
> 
> This explicitly sets the execution level to 'asInvoker', preventing
> Windows' UAC heuristics from deciding that because its name mentions
> "update", it probably needs to escalate privileges.
> 
> FIXED-IN:4.14.36
> BUG:384334
> 
> 
> Diffs
> -
> 
>   kconf_update/CMakeLists.txt 6bf3bf1f923baf11aad63e10fe249d70ce1b4d33 
> 
> 
> Diff: https://git.reviewboard.kde.org/r/130239/diff/3/
> 
> 
> Testing
> ---
> 
> Compiled at 
> https://build.opensuse.org/package/show/windows%3Amingw%3Awin32/mingw32-kdelibs4
>  and tested with KMyMoney snapshot for Windows downloadable from 
> https://software.opensuse.org/package/mingw32-kmymoney-portable
> 
> 
> Thanks,
> 
> Ralf Habacker
> 
>

Re: Review Request 130239: Exclude kconf_update from catching by uac on Windows

[Albert Astals Cid]

> On set. 26, 2017, 6:02 p.m., Albert Astals Cid wrote:
> > cmake/modules/Win32Macros.cmake
> > Lines 61 (patched)
> > <https://git.reviewboard.kde.org/r/130239/diff/2/?file=513534#file513534line61>
> >
> > I don't think it makes sense adding a new public-ish macro in 4.14.lots
> 
> Ralf Habacker wrote:
> See revision 1 of this patch at 
> https://git.reviewboard.kde.org/r/130239/diff/1/

I'm personally happier with that patch for almost dead 4.14 (it has 2 releases 
left), now you're going to need someone with a win32 build/knowledge to approve 
since honestly i have no idea what this does.


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130239/#review103738
---


On set. 26, 2017, 7:54 a.m., Ralf Habacker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130239/
> ---
> 
> (Updated set. 26, 2017, 7:54 a.m.)
> 
> 
> Review request for kdelibs and Albert Astals Cid.
> 
> 
> Bugs: 384334
> http://bugs.kde.org/show_bug.cgi?id=384334
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This patch fixes an issue that on the first start of KMyMoney (and on some 
> computers on every start for example reported by 
> https://forum.kde.org/viewtopic.php?f=69=141673=ba4dcaa26018f16e19d21c58c34ad4e9)
>  on running kconf_update the user account control pops up and forces the user 
> to allow or deny  this application.
> 
> 
> Diffs
> -
> 
>   cmake/modules/Win32Macros.cmake e5a3655b018c56f1d394c224b1f1496741171781 
>   kconf_update/CMakeLists.txt 6bf3bf1f923baf11aad63e10fe249d70ce1b4d33 
> 
> 
> Diff: https://git.reviewboard.kde.org/r/130239/diff/2/
> 
> 
> Testing
> ---
> 
> Compiled at 
> https://build.opensuse.org/package/show/windows%3Amingw%3Awin32/mingw32-kdelibs4
>  and tested with KMyMoney snapshot for Windows downloadable from 
> https://software.opensuse.org/package/mingw32-kmymoney-portable
> 
> 
> Thanks,
> 
> Ralf Habacker
> 
>

Re: Review Request 130239: Exclude kconf_update from catching by uac on Windows

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130239/#review103738
---




cmake/modules/Win32Macros.cmake
Lines 61 (patched)
<https://git.reviewboard.kde.org/r/130239/#comment69004>

I don't think it makes sense adding a new public-ish macro in 4.14.lots


- Albert Astals Cid


On set. 26, 2017, 7:54 a.m., Ralf Habacker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130239/
> ---
> 
> (Updated set. 26, 2017, 7:54 a.m.)
> 
> 
> Review request for kdelibs and Albert Astals Cid.
> 
> 
> Bugs: 384334
> http://bugs.kde.org/show_bug.cgi?id=384334
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This patch fixes an issue that on the first start of KMyMoney (and on some 
> computers on every start for example reported by 
> https://forum.kde.org/viewtopic.php?f=69=141673=ba4dcaa26018f16e19d21c58c34ad4e9)
>  on running kconf_update the user account control pops up and forces the user 
> to allow or deny  this application.
> 
> 
> Diffs
> -
> 
>   cmake/modules/Win32Macros.cmake e5a3655b018c56f1d394c224b1f1496741171781 
>   kconf_update/CMakeLists.txt 6bf3bf1f923baf11aad63e10fe249d70ce1b4d33 
> 
> 
> Diff: https://git.reviewboard.kde.org/r/130239/diff/2/
> 
> 
> Testing
> ---
> 
> Compiled at 
> https://build.opensuse.org/package/show/windows%3Amingw%3Awin32/mingw32-kdelibs4
>  and tested with KMyMoney snapshot for Windows downloadable from 
> https://software.opensuse.org/package/mingw32-kmymoney-portable
> 
> 
> Thanks,
> 
> Ralf Habacker
> 
>

Re: Review Request 130245: Fix Crash on JoyStick Config when js device did not contain regular joystick button

[Albert Astals Cid]

> On set. 16, 2017, 9:19 a.m., Albert Astals Cid wrote:
> > Are you sure this fixes anything?
> > 
> > Just before the lines you changed we have
> > 
> > 
> > if ( ! buttonTbl->item(number, 0) )
> >   buttonTbl->setItem(number, 0, new QTableWidgetItem());
> >   
> > Which will create the item, no?
> > 
> > Or is it because number is a negative value somehow?
> 
> TOM Harrison wrote:
> no, It still NULL after that.
> 
> I think because "btnx keyboard" is not a real joystick, so It may not 
> accept any button.
> 
> Albert Astals Cid wrote:
> Can you please check what is the value of number? Because what you're 
> saying kind of falls on the "can't be" territory. We just set an item, it 
> can't be null just on the next line.
> 
> TOM Harrison wrote:
> number is 0, it did has execute the setItem. but still null after that.
> 
> TOM Harrison wrote:
> I found every button is all execute setItem, but still null after that.
> 
> Albert Astals Cid wrote:
> i'm going to guess this has not worked in a long time and needs a 
> buttonTbl->setColumnCount(1) after 
> buttonTbl->setRowCount(joydev->numButtons());?
> 
> Does that fix it?
> 
> TOM Harrison wrote:
> Not fix. still crash after add buttonTbl->setColumnCount(1)
> 
> TOM Harrison wrote:
> I have test a real joystick. It working. It only not working on "btnx 
> Keyboard" which is generated by btnx.
> 
> Albert Astals Cid wrote:
> What is btnx?
> 
> TOM Harrison wrote:
> A kind of mouse key re-routing software. I use for define custom hotkey 
> for extra mouse key.
> Its github: https://github.com/cdobrich/btnx
> 
> Albert Astals Cid wrote:
> Would you share the configuration you're using that makes this crash so i 
> can try to reproduce it?
> 
> TOM Harrison wrote:
> https://www.mediafire.com/file/95k5d81s2qi5un2/btnx.tar
> btnx.tar contain directly btnx directory under /etc. I do not know that 
> it will working or not. btnx has remember productID and vendorID in config.
> 
> Albert Astals Cid wrote:
> The problem is that btnx reports a negative number of buttons, so 
> https://phabricator.kde.org/D7900 is the proper fix.

Please close this request review since D7900 already landed for Plasma 5.11


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130245/#review103704
---


On set. 16, 2017, 7:07 a.m., TOM Harrison wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130245/
> ---
> 
> (Updated set. 16, 2017, 7:07 a.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch will fix the joystick config when detect "btnx keyboard" as 
> joystick, It will crash.
> Due to Btnx keyboard is not a regular joystick.
> Just add one more if to fix this crash.
> 
> 
> Diffs
> -
> 
>   kcms/hardware/joystick/joywidget.cpp 6007d867 
> 
> 
> Diff: https://git.reviewboard.kde.org/r/130245/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> TOM Harrison
> 
>

Re: Review Request 130245: Fix Crash on JoyStick Config when js device did not contain regular joystick button

[Albert Astals Cid]

> On Sept. 16, 2017, 9:19 a.m., Albert Astals Cid wrote:
> > Are you sure this fixes anything?
> > 
> > Just before the lines you changed we have
> > 
> > 
> > if ( ! buttonTbl->item(number, 0) )
> >   buttonTbl->setItem(number, 0, new QTableWidgetItem());
> >   
> > Which will create the item, no?
> > 
> > Or is it because number is a negative value somehow?
> 
> TOM Harrison wrote:
> no, It still NULL after that.
> 
> I think because "btnx keyboard" is not a real joystick, so It may not 
> accept any button.
> 
> Albert Astals Cid wrote:
> Can you please check what is the value of number? Because what you're 
> saying kind of falls on the "can't be" territory. We just set an item, it 
> can't be null just on the next line.
> 
> TOM Harrison wrote:
> number is 0, it did has execute the setItem. but still null after that.
> 
> TOM Harrison wrote:
> I found every button is all execute setItem, but still null after that.
> 
> Albert Astals Cid wrote:
> i'm going to guess this has not worked in a long time and needs a 
> buttonTbl->setColumnCount(1) after 
> buttonTbl->setRowCount(joydev->numButtons());?
> 
> Does that fix it?
> 
> TOM Harrison wrote:
> Not fix. still crash after add buttonTbl->setColumnCount(1)
> 
> TOM Harrison wrote:
> I have test a real joystick. It working. It only not working on "btnx 
> Keyboard" which is generated by btnx.
> 
> Albert Astals Cid wrote:
> What is btnx?
> 
> TOM Harrison wrote:
> A kind of mouse key re-routing software. I use for define custom hotkey 
> for extra mouse key.
> Its github: https://github.com/cdobrich/btnx
> 
> Albert Astals Cid wrote:
> Would you share the configuration you're using that makes this crash so i 
> can try to reproduce it?
> 
> TOM Harrison wrote:
> https://www.mediafire.com/file/95k5d81s2qi5un2/btnx.tar
> btnx.tar contain directly btnx directory under /etc. I do not know that 
> it will working or not. btnx has remember productID and vendorID in config.

The problem is that btnx reports a negative number of buttons, so 
https://phabricator.kde.org/D7900 is the proper fix.


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130245/#review103704
---


On Sept. 16, 2017, 7:07 a.m., TOM Harrison wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130245/
> ---
> 
> (Updated Sept. 16, 2017, 7:07 a.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch will fix the joystick config when detect "btnx keyboard" as 
> joystick, It will crash.
> Due to Btnx keyboard is not a regular joystick.
> Just add one more if to fix this crash.
> 
> 
> Diffs
> -
> 
>   kcms/hardware/joystick/joywidget.cpp 6007d867 
> 
> 
> Diff: https://git.reviewboard.kde.org/r/130245/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> TOM Harrison
> 
>

Re: Review Request 130245: Fix Crash on JoyStick Config when js device did not contain regular joystick button

[Albert Astals Cid]

> On set. 16, 2017, 9:19 a.m., Albert Astals Cid wrote:
> > Are you sure this fixes anything?
> > 
> > Just before the lines you changed we have
> > 
> > 
> > if ( ! buttonTbl->item(number, 0) )
> >   buttonTbl->setItem(number, 0, new QTableWidgetItem());
> >   
> > Which will create the item, no?
> > 
> > Or is it because number is a negative value somehow?
> 
> TOM Harrison wrote:
> no, It still NULL after that.
> 
> I think because "btnx keyboard" is not a real joystick, so It may not 
> accept any button.
> 
> Albert Astals Cid wrote:
> Can you please check what is the value of number? Because what you're 
> saying kind of falls on the "can't be" territory. We just set an item, it 
> can't be null just on the next line.
> 
> TOM Harrison wrote:
> number is 0, it did has execute the setItem. but still null after that.
> 
> TOM Harrison wrote:
> I found every button is all execute setItem, but still null after that.
> 
> Albert Astals Cid wrote:
> i'm going to guess this has not worked in a long time and needs a 
> buttonTbl->setColumnCount(1) after 
> buttonTbl->setRowCount(joydev->numButtons());?
> 
> Does that fix it?
> 
> TOM Harrison wrote:
> Not fix. still crash after add buttonTbl->setColumnCount(1)
> 
> TOM Harrison wrote:
> I have test a real joystick. It working. It only not working on "btnx 
> Keyboard" which is generated by btnx.
> 
> Albert Astals Cid wrote:
> What is btnx?
> 
> TOM Harrison wrote:
> A kind of mouse key re-routing software. I use for define custom hotkey 
> for extra mouse key.
> Its github: https://github.com/cdobrich/btnx

Would you share the configuration you're using that makes this crash so i can 
try to reproduce it?


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130245/#review103704
---


On set. 16, 2017, 7:07 a.m., TOM Harrison wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130245/
> ---
> 
> (Updated set. 16, 2017, 7:07 a.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch will fix the joystick config when detect "btnx keyboard" as 
> joystick, It will crash.
> Due to Btnx keyboard is not a regular joystick.
> Just add one more if to fix this crash.
> 
> 
> Diffs
> -
> 
>   kcms/hardware/joystick/joywidget.cpp 6007d867 
> 
> 
> Diff: https://git.reviewboard.kde.org/r/130245/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> TOM Harrison
> 
>

Re: Review Request 130245: Fix Crash on JoyStick Config when js device did not contain regular joystick button

[Albert Astals Cid]

> On set. 16, 2017, 9:19 a.m., Albert Astals Cid wrote:
> > Are you sure this fixes anything?
> > 
> > Just before the lines you changed we have
> > 
> > 
> > if ( ! buttonTbl->item(number, 0) )
> >   buttonTbl->setItem(number, 0, new QTableWidgetItem());
> >   
> > Which will create the item, no?
> > 
> > Or is it because number is a negative value somehow?
> 
> TOM Harrison wrote:
> no, It still NULL after that.
> 
> I think because "btnx keyboard" is not a real joystick, so It may not 
> accept any button.
> 
> Albert Astals Cid wrote:
> Can you please check what is the value of number? Because what you're 
> saying kind of falls on the "can't be" territory. We just set an item, it 
> can't be null just on the next line.
> 
> TOM Harrison wrote:
> number is 0, it did has execute the setItem. but still null after that.
> 
> TOM Harrison wrote:
> I found every button is all execute setItem, but still null after that.
> 
> Albert Astals Cid wrote:
> i'm going to guess this has not worked in a long time and needs a 
> buttonTbl->setColumnCount(1) after 
> buttonTbl->setRowCount(joydev->numButtons());?
> 
> Does that fix it?
> 
> TOM Harrison wrote:
> Not fix. still crash after add buttonTbl->setColumnCount(1)
> 
> TOM Harrison wrote:
> I have test a real joystick. It working. It only not working on "btnx 
> Keyboard" which is generated by btnx.

What is btnx?


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130245/#review103704
---


On set. 16, 2017, 7:07 a.m., TOM Harrison wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130245/
> ---
> 
> (Updated set. 16, 2017, 7:07 a.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch will fix the joystick config when detect "btnx keyboard" as 
> joystick, It will crash.
> Due to Btnx keyboard is not a regular joystick.
> Just add one more if to fix this crash.
> 
> 
> Diffs
> -
> 
>   kcms/hardware/joystick/joywidget.cpp 6007d867 
> 
> 
> Diff: https://git.reviewboard.kde.org/r/130245/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> TOM Harrison
> 
>

Re: Review Request 130245: Fix Crash on JoyStick Config when js device did not contain regular joystick button

[Albert Astals Cid]

> On set. 16, 2017, 9:19 a.m., Albert Astals Cid wrote:
> > Are you sure this fixes anything?
> > 
> > Just before the lines you changed we have
> > 
> > 
> > if ( ! buttonTbl->item(number, 0) )
> >   buttonTbl->setItem(number, 0, new QTableWidgetItem());
> >   
> > Which will create the item, no?
> > 
> > Or is it because number is a negative value somehow?
> 
> TOM Harrison wrote:
> no, It still NULL after that.
> 
> I think because "btnx keyboard" is not a real joystick, so It may not 
> accept any button.

Can you please check what is the value of number? Because what you're saying 
kind of falls on the "can't be" territory. We just set an item, it can't be 
null just on the next line.


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130245/#review103704
---


On set. 16, 2017, 7:07 a.m., TOM Harrison wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130245/
> ---
> 
> (Updated set. 16, 2017, 7:07 a.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch will fix the joystick config when detect "btnx keyboard" as 
> joystick, It will crash.
> Due to Btnx keyboard is not a regular joystick.
> Just add one more if to fix this crash.
> 
> 
> Diffs
> -
> 
>   kcms/hardware/joystick/joywidget.cpp 6007d867 
> 
> 
> Diff: https://git.reviewboard.kde.org/r/130245/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> TOM Harrison
> 
>

Re: Review Request 130245: Fix Crash on JoyStick Config when js device did not contain regular joystick button

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130245/#review103704
---



Are you sure this fixes anything?

Just before the lines you changed we have


if ( ! buttonTbl->item(number, 0) )
  buttonTbl->setItem(number, 0, new QTableWidgetItem());
  
Which will create the item, no?

Or is it because number is a negative value somehow?

- Albert Astals Cid


On set. 16, 2017, 7:07 a.m., TOM Harrison wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130245/
> ---
> 
> (Updated set. 16, 2017, 7:07 a.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch will fix the joystick config when detect "btnx keyboard" as 
> joystick, It will crash.
> Due to Btnx keyboard is not a regular joystick.
> Just add one more if to fix this crash.
> 
> 
> Diffs
> -
> 
>   kcms/hardware/joystick/joywidget.cpp 6007d867 
> 
> 
> Diff: https://git.reviewboard.kde.org/r/130245/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> TOM Harrison
> 
>

Re: An update on Python bindings (Re: A new attempt on PyKDE5 binding generation)

[Albert Astals Cid]

El dimarts, 5 de setembre de 2017, a les 22:12:26 CEST, Shaheed Haque va 
escriure:
> A lot of progress has been made in the last 18 months or so:

Looks great :)

You may want to email kde-frameworks-de...@kde.org though since that list is 
the one where specific KF5 things (like this one seems to be) are discussed.

Besides that I'm not either a KF5 maintainer nor a Python expert so can't 
really do anything else than wishing you good luck with what's missing :)

Cheers,
  Albert

> 
> THE TOOLING
> ===
> 
> We have:
> 
> - A pretty powerful KDE-independent automatic binding generation capability.
> 
> - Supplemented by a powerful/fine-grained manual override "rule" capability.
> 
> - Comprehensive (rule-based) support for the main Qt templates (QList,
> QVector, QHash, QSet and QFlags), some selected std:: and boost::
> templates support, multi-dimensional arrays and lots more.
> 
> - CMake-based portability (the frontend is solid enough to "read" KDE,
> only the final C++ compilation remains to be moved to either CMake or
> a Python-centric packaging form [2]).
> 
> The code can be seen here:
> 
> https://github.com/ShaheedHaque/extra-cmake-modules/tree/shaheed_master/find
> -modules/module_generation
> 
> The KDE framework bindings
> =
> 
> For 120 out of 167 KDE 5 frameworks (I'm using the term loosely, see
> [6]), I have created all the manual override "rules" to get the
> bindings through the SIP intermediate tooling and the g++ compiler.
> 
> These rules mentioned are in the PyKF5 subdirectory, and it should be
> made clear that they are in proof-of-concept form, and some hopefully
> modest work would be needed (per framework, for some frameworks) to
> get actual useful bindings.
> 
> Also, note that the bindings have not actually been run [1] because
> the focus till now has been to ensure the feasibility of the approach.
> The whole point of automation is of course that any fixes needed to
> get them going would be easy to apply (think any fixes needed for
> templates, arrays, unions, exceptions, threading etc etc).
> 
> THE GOOD NEWS
> ==
> 
> The good news is that the approach appears to have lived up to my hope
> in that the amount of rule code for PyKF5 needed appears to be
> minimal:
> 
> - A *LOT* of the bindings are completely automatically generated.
> 
> - Very few rules are anything more than 1-2 lines of code.
> 
> - A *LOT* of the rules are merely invocations of a small set of
> pre-provided rule helpers. There is a HOWTO/FAQ that should provide
> most of the needed idiomatic knowledge to help move things along.
> 
> THE BAD NEWS
> =
> 
> While SIP provides a huge amount of capability, and my tooling covers
> many of the gaps, there are a bunch of things that are going to be
> hard to deal with. Some of this is on a one off basis [3], others on
> an ongoing basis [4], and yet others simply have no obvious solution
> [5].
> 
> (Notice however, that SIP does seemingly successfully handle something
> as complex as Qt).
> 
> NEXT STEPS
> ===
> 
> Based on THE GOOD NEWS it would be easy to conclude that continuing
> down the current route would result in usable bindings, assuming (say)
> that I would facilitate a couple of hours of effort/consultancy per
> framework with ,
> and consolidate any needed info as Techbase documentation.
> 
> However, I'm also concerned that THE BAD NEWS means this will result
> in a set of bindings which are just different enough from the C++ to
> be vaguely irritating, and run the risk of a similar fate as befell
> PyKDE4.
> 
> There is a possible alternative way forward:
> https://pypi.python.org/pypi/cppyy. This seems to offer a significant
> step forward by (a) dispensing with a highly "opinionated"
> intermediate layer like SIP and (b) using a "C++ interpreter". (Note,
> IIUC, the resulting bindings will depend on the presence of the Cling
> interpreter to function).
> 
> Now, I have no doubt that there will still be issues with things like
> overloaded functions in C++ mapping to a single function in Python,
> but I suspect the issues will be a strict subset of the issues with
> the SIP approach (for example, it looks as though the "native"
> approach to the evolution of C++, templates etc will be a big help).
> AFAIK, there should be no issue in using the resulting bindings with
> PyQt (except that PyQt is tied to CPython, whereas cppyy also supports
> PyPy).
> 
> On balance, as despite the work that has gone into the SIP approach, I
> propose to explore the cppyy option.
> 
> Comments, thoughts?
> 
> Thanks, Shaheed
> 
> [1] I'm ignoring the 5-6 bindings which Stephen Kelly's fork of the
> code got going. As far as I know, Stephen has not continued with that
> work.
> 
> [2] Stephen's solution to this only addressed the inner layer of the
> tooling. The outer layer, needed for much of the SIP workaround logic,
> was not addressed.
> 
> [3] For example, there is a big impedance mismatch 

Re: Retirement of Reviewboard - Transition to Phabricator

[Albert Astals Cid]

El dijous, 24 d’agost de 2017, a les 21:07:49 CEST, Ben Cooksley va escriure:
> Hi all,
> 
> The following is Sysadmin's suggested plan for the retirement of
> Reviewboard now that Phabricator is fully up and running for hosting
> of code reviews.
> 
> Phase 1: Commences September 2: All repositories are closed for
> accepting new reviews on Reviewboard. A notice is added to the top of
> the main page indicating that reviews should now be done on
> Phabricator.
> 
> Phase 2: Commences September 16: Login to Reviewboard is disabled, and
> final backups are taken. A static copy of Reviewboard is generated and
> published online, and the software itself is taken down.

Does this mean i can still see:
 * Diffs
 * emails of the people that made those diffs

After phase 2?

Cheers,
  Albert

> 
> The vast majority of projects should now be migrated to Phabricator,
> with only historical reviews needing to be cleaned up.
> 
> Note that due to how Reviewboard stores diffs and reproduces them for
> use, some reviews may have decayed and may no longer be readable. This
> is due to short-hashes which are used by Git/Reviewboard in diffs now
> having collisions with other commits which previously did not exist.
> Unfortunately there is nothing we can do about this.
> 
> Any comments on the above?
> 
> Regards,
> Ben

Re: KMarkdownWebView (kpart) in KDE Review

[Albert Astals Cid]

El dimarts, 22 d’agost de 2017, a les 0:18:19 CEST, Friedrich W. H. Kossebau 
va escriure:
> Hi,
> 
> KMarkdownWebView today entered KDE Review. This repo contains a kpart for
> rendered display of Markdown files, using web technologies (webpage with
> JavaScript library which creates HTML from the plaintext handed in).
> 
> I consider it rather a hack and would favour something done natively in Qt
> (e.g. like the Markdown Okular generator in https://phabricator.kde.org/
> D7382). But for now it serves the use-case of providing a webpage-like
> rendered display of markdown documents. Especially for the live preview
> plugin for Kate & KDevelop currently worked on*.
> 
> * https://frinring.wordpress.com/2017/08/21/look-what-you-have-donewwdo
> 
> See also https://cgit.kde.org/kmarkdownwebview.git/about/
> 
> The separate library libKMarkdownWebView is done for sharing code with a
> thumbnailer plugin, whose code yet is to be committed to this repo, as it
> resists to work right now.
> 
> Initial build on CI looks good:
> https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20SUSEQt5.9
> /
> https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20FreeBSDQ
> t5.7/
> 
> And people on #kde-devel & #kdevelop also reported successful builds and
> usage.
> 
> 
> Target would be extragear/$SOMETHING, with $SOMETHING possibly "utils".
> 
> Initial release planned right after leaving kdereview.

You don't have a Messages.sh

Cheers,
  Albert

> 
> Question: is there any appstream metadata possible for plugins?
> 
> Cheers
> Friedrich

Re: kdelibs-4.14.35 bug report

[Albert Astals Cid]

El divendres, 18 d’agost de 2017, a les 7:25:44 CEST, David Binderman va 
escriure:
> Hello there,
> 
> Some suspicious code:
> 
> [kdelibs-4.14.35/kde3support/kdeui/k3listview.cpp:505]: (style) Same
> expression on both sides of '||'.
> 
> Source code is
> 
> if ( ca == Qt::AlignLeft || ca == Qt::AlignLeft ) {
> 
> Maybe better code
> 
> if ( ca == Qt::AlignLeft || ca == Qt::AlignRight ) {

Most probably

But at this point i'd rather not change the kde3support code, it's vry old 
and mostly frozen, anyone that was affected by this bug probably workarounded 
it already so i'd rather not touch it since it may as well break the 
workaround they had.

Thanks for the report :)

Cheers,
  Albert

> 
> Regards
> 
> David Binderman

Re: Elisa is in kdereview

[Albert Astals Cid]

El dilluns, 17 de juliol de 2017, a les 11:22:15 CEST, Matthieu Gallien va 
escriure:
> Hello,
> 
> On vendredi 23 juin 2017 15:21:49 CEST Harald Sitter wrote:
> > On Wed, Jun 21, 2017 at 11:15 PM, Matthieu Gallien
> > 
> > <gallien.matth...@gmail.com> wrote:
> > > Hello,
> > > 
> > > On mercredi 21 juin 2017 23:01:23 CEST Albert Astals Cid wrote:
> > >> El divendres, 16 de juny de 2017, a les 22:44:03 CEST, Matthieu Gallien
> > >> va
> > >> 
> > >> escriure:
> > >> > Hello,
> > >> > 
> > >> > Elisa is now in kdereview and aiming for extragear/multimedia.
> > >> > 
> > >> > It is a music player from a design from Andrew Lake.
> > >> > It is using Qt multimedia for playback and a few KDE frameworks. Its
> > >> > UI
> > >> > is
> > >> > using Qml.
> > >> > 
> > >> > Its aim is to be simple to use and hopefully in the future powerfull
> > >> > when
> > >> > needed.
> > >> > 
> > >> > It should be usable without needing online services but will use them
> > >> > in
> > >> > the future.
> > >> > 
> > >> > A few integration bits are missing with respect to Baloo before I can
> > >> > do a
> > >> > release. Currently music can only be read if in its database that can
> > >> > be
> > >> > filled by Baloo or a custom file indexer if Baloo is not there.
> > >> 
> > >> That's kind of a weird design decision, basically i started elisa, it
> > >> didn't see any of my music, i didn't find a way to add it, so i removed
> > >> elisa.>
> > > 
> > > It is not a design decision but the current state. I want to also
> > > support
> > > the "let's play this file now" use case. I just had not yet enough time
> > > to do it.
> > > 
> > > I am also planning to add a "busy" indicator to show that Elisa is
> > > currently getting tracks from Baloo or default music directory (as per
> > > QStandardPaths). If no music is found, I also want to add a passive
> > > notification offering the possibility to configure the path to use to
> > > search music. I even have a task in phabricator for that.
> > > 
> > >> That'd be my workflow as a regular user.
> > > 
> > > I am already convinced that first impression is important. At the same
> > > time, I did request to move to extragear to get covered by CI and to get
> > > feedback from kde-core-devel.
> > 
> > I think it's fine. Not perfect, but good enough for starters.
> > The error case handling could definitely be better (no baloo database,
> > indexing in progress, baloo disabled, baloo broken, no music in
> > database).
> 
> I am still working on improving those lacking areas. I am currently
> integrating KConfig for configuration especially of the file indexers.
> The next step is to provide more user notifications about what happen (and
> not just a busy indicator when waiting music to be indexed).
> Due to holydays and being busy with real life, this could take a few weeks
> to land in a finished state. Should Elisa stay in review or move back to
> playground ?

At Akademy we codified a project should not stay in kdereview for more than 
two months, this should give you some rule of thumb of whether we should bring 
it back to playground or not.

Cheers,
  Albert

> 
> > User experience quirks aside, Elisa seems to be in really good shape.
> > Builds. Plays music. I18n seems to be in order as well.
> > 
> > HS
> 
> Thanks for your review and sorry for the late reply.
> 
> Best regards

Re: libqaccessibilityclient now in kdereview

[Albert Astals Cid]

El dimarts, 25 de juliol de 2017, a les 16:54:33 CEST, Luigi Toscano va 
escriure:
> In data martedì 25 luglio 2017 16:44:32 CEST, Frederik Gladhorn ha scritto:
> > On tirsdag 25. juli 2017 14.47.44 CEST Albert Astals Cid wrote:
> > > El dimarts, 25 de juliol de 2017, a les 13:25:39 CEST, Jonathan Riddell
> > > va
> > > 
> > > escriure:
> > > > libqaccessibilityclient is now in kdereview.  It's in a git repo
> > > > called libkdeaccessibilityclient but we filed a sysadmin request to
> > > > rename it.
> > > > 
> > > > We just released 0.2.0 in unstable (for some reason 0.1.1 was released
> > > > in stable some years ago).
> > > 
> > > What's your target? Frameworks? KDE Applications? Independent release?
> > 
> > It's closest to being a framework, considering that it's a tiny helper
> > lib.
> 
> We would still need an independent release before, at least to enable users
> to use it for KDE Applications 17.08. Not sure what is the best way though.

Jonathan said they just had 0.2 out, i guess that's the one you mean?

Cheers,
  Albert

> 
> Ciao

Re: libqaccessibilityclient now in kdereview

[Albert Astals Cid]

El dimarts, 25 de juliol de 2017, a les 13:25:39 CEST, Jonathan Riddell va 
escriure:
> libqaccessibilityclient is now in kdereview.  It's in a git repo
> called libkdeaccessibilityclient but we filed a sysadmin request to
> rename it.
> 
> We just released 0.2.0 in unstable (for some reason 0.1.1 was released
> in stable some years ago).

It does not compile with clang.

Cheers,
  Albert

> 
> What is it?
> 
> Since it's hard to grasp all the bits related to accessibility, I'll try to
> explain what the lib is for.
> Most of the stack is part of Qt 5, so nothing to worry about, that's the
> part that lets applications expose their UI over DBus for AT-SPI, so they
> work nicely with assisitve tools (e.g. Orca). In accessibility language,
> the applications act as "servers" and the screen reader for example is a
> client.
> 
> This library is for writing clients, so applications that are assistive,
> such as screen readers. It currently has two users: KMag and Simon.
> KMag can use it to follow the focus (e.g. when editing text, it can
> automatically magnify the part of the document where the cursor is.
> 
> For Simon Listens, the use is to be able to let the user trigger menus and
> buttons by voice input.

Re: libqaccessibilityclient now in kdereview

[Albert Astals Cid]

El dimarts, 25 de juliol de 2017, a les 13:25:39 CEST, Jonathan Riddell va 
escriure:
> libqaccessibilityclient is now in kdereview.  It's in a git repo
> called libkdeaccessibilityclient but we filed a sysadmin request to
> rename it.
> 
> We just released 0.2.0 in unstable (for some reason 0.1.1 was released
> in stable some years ago).

Do we really have to keep the Qt4 compatibility or can we kill it?

Cheers,
  Albert

> 
> What is it?
> 
> Since it's hard to grasp all the bits related to accessibility, I'll try to
> explain what the lib is for.
> Most of the stack is part of Qt 5, so nothing to worry about, that's the
> part that lets applications expose their UI over DBus for AT-SPI, so they
> work nicely with assisitve tools (e.g. Orca). In accessibility language,
> the applications act as "servers" and the screen reader for example is a
> client.
> 
> This library is for writing clients, so applications that are assistive,
> such as screen readers. It currently has two users: KMag and Simon.
> KMag can use it to follow the focus (e.g. when editing text, it can
> automatically magnify the part of the document where the cursor is.
> 
> For Simon Listens, the use is to be able to let the user trigger menus and
> buttons by voice input.

Re: libqaccessibilityclient now in kdereview

[Albert Astals Cid]

El dimarts, 25 de juliol de 2017, a les 13:25:39 CEST, Jonathan Riddell va 
escriure:
> libqaccessibilityclient is now in kdereview.  It's in a git repo
> called libkdeaccessibilityclient but we filed a sysadmin request to
> rename it.
> 
> We just released 0.2.0 in unstable (for some reason 0.1.1 was released
> in stable some years ago).

What's your target? Frameworks? KDE Applications? Independent release?


It seems to have autotests but they are not run by either of these
  ctest  
  make check  
  make test




AccessibleObject seems like a dumping group, having functions like
double maximumValue() const;
and
QString imageDescription() const;
that if you read the description seems to me like they apply to "different 
types" of objects. Is it because it is mimic-ing the ATSPI API? Is there a way 
to have these things more split so they are grouped together more logically?



Interfaces supportedInterfaces() const;
documentation is wrong, it says "return QStringList"


Can we remove the commented functions, i.e. managesDescendants, isRequired, 
etc.?


Thanks for pushing this forward :)


Cheers,
  Albert

> 
> What is it?
> 
> Since it's hard to grasp all the bits related to accessibility, I'll try to
> explain what the lib is for.
> Most of the stack is part of Qt 5, so nothing to worry about, that's the
> part that lets applications expose their UI over DBus for AT-SPI, so they
> work nicely with assisitve tools (e.g. Orca). In accessibility language,
> the applications act as "servers" and the screen reader for example is a
> client.
> 
> This library is for writing clients, so applications that are assistive,
> such as screen readers. It currently has two users: KMag and Simon.
> KMag can use it to follow the focus (e.g. when editing text, it can
> automatically magnify the part of the document where the cursor is.
> 
> For Simon Listens, the use is to be able to let the user trigger menus and
> buttons by voice input.

Re: KUserFeedback in/on its way to KDE Review

[Albert Astals Cid]

El dissabte, 15 de juliol de 2017, a les 11:32:19 CEST, Volker Krause va 
escriure:
> No objections? :)
> 
> It's been three weeks now, can this proceed to extragear/libs?

I guess yes.

Cheers,
  Albert

> 
> On Saturday, 24 June 2017 11:37:49 CEST Volker Krause wrote:
> > Hi,
> > 
> > I've asked for KUserFeedback to be moved to KDE Review, aiming for
> > extragear/ libs initially, with a possible future option to continue on to
> > frameworks.
> > 
> > KUserFeedback is a framework for gathering user feedback using application
> > telemetry and targeted surveys while providing decent transparency and
> > control to the user.
> > 
> > For more details see the previous announcement on this list here: https://
> > marc.info/?l=kde-core-devel=149294623025111=2 Since then we also got a
> > QML API and a few more data sources, and KUserFeedback has been shipped
> > with the recent GammaRay 2.8 release.
> > 
> > Please review :)
> > 
> > Thanks!
> > Volker

Re: AtCore on KDE Review

[Albert Astals Cid]

El divendres, 7 de juliol de 2017, a les 15:05:38 CEST, Luigi Toscano va 
escriure:
> On Friday, 7 July 2017 15:02:21 CEST you wrote:
> > On Thu, Jul 6, 2017 at 2:03 PM, Luigi Toscano 
> > 
> > > > -> Luigui
> > > > "In addition to Albert's comment, I noticed now (still going
> > > > through
> > > 
> > > the
> > > 
> > > > backlog after vacation) that atcore use tr() for messages, but
> > > > there
> > > 
> > > is no
> > > 
> > > > Messages.sh file to extract the strings (which should be called
> > > 
> > > atcore_qt,
> > > 
> > > > check the similar files in step or marble or in tier1
> > > > frameworks)."​
> > > 
> > > I don't think that this has been addressed
> > 
> > It was not, and it's my fault.
> > I was looking on marble sources but I didn't understood how the
> > Messages.sh
> > works,
> > I'm reading and will update that as soon as I can.
> 
> Or tier1 Frameworks.
> 
> https://cgit.kde.org/kuserfeedback.git/tree/src/provider/Messages.sh
> 
> To test it:
> 
> http://tsdgeos.blogspot.cz/2010/08/how-to-run-messagessh-file-to-create.html

Or the actual wiki page that should contain kind of updated contents hopefully

https://techbase.kde.org/Development/Tutorials/Localization/
i18n_Build_Systems#Writing_a_Messages.sh_script

Cheers,
  Albert

> 
> Ciao

Re: Zanshin is in kdereview

[Albert Astals Cid]

El diumenge, 2 de juliol de 2017, a les 1:58:52 CEST, Kevin Ottens va 
escriure:
> Hello,
> 
> On Sunday, 25 June 2017 14:00:05 CEST Kevin Ottens wrote:
> > On Thursday, 8 June 2017 09:36:51 CEST Kevin Ottens wrote:
> > > OK, this time it's the right one. :-)
> > > 
> > > Zanshin is now in kdereview and aiming for extragear/pim. Please review
> > > away!
> > > 
> > > Thanks in advance.
> > 
> > So I pushed just now all the patches mentioned in this thread. They should
> > address all the feedback I got so far *except* the license "issue" (means
> > it's effectively GPLv2) since I didn't get a reply from all the necessary
> > people yet to allow relicensing. I don't think I can do much more about
> > that one right now.
> > 
> > Any issue still preventing the move in extragear/pim?
> 
> It's been a week now without objection or further change requests. It's been
> in kdereview for three weeks now. Shall we more to extragear/pim now?

+1

> 
> Regards.

Re: Elisa is in kdereview

[Albert Astals Cid]

El dimecres, 21 de juny de 2017, a les 23:15:58 CEST, Matthieu Gallien va 
escriure:
> Hello,
> 
> On mercredi 21 juin 2017 23:01:23 CEST Albert Astals Cid wrote:
> > El divendres, 16 de juny de 2017, a les 22:44:03 CEST, Matthieu Gallien va
> > 
> > escriure:
> > > Hello,
> > > 
> > > Elisa is now in kdereview and aiming for extragear/multimedia.
> > > 
> > > It is a music player from a design from Andrew Lake.
> > > It is using Qt multimedia for playback and a few KDE frameworks. Its UI
> > > is
> > > using Qml.
> > > 
> > > Its aim is to be simple to use and hopefully in the future powerfull
> > > when
> > > needed.
> > > 
> > > It should be usable without needing online services but will use them in
> > > the future.
> > > 
> > > A few integration bits are missing with respect to Baloo before I can do
> > > a
> > > release. Currently music can only be read if in its database that can be
> > > filled by Baloo or a custom file indexer if Baloo is not there.
> > 
> > That's kind of a weird design decision, basically i started elisa, it
> > didn't see any of my music, i didn't find a way to add it, so i removed
> > elisa.
> It is not a design decision but the current state. I want to also support
> the "let's play this file now" use case. I just had not yet enough time to
> do it.
> 
> I am also planning to add a "busy" indicator to show that Elisa is currently
> getting tracks from Baloo or default music directory (as per
> QStandardPaths). If no music is found, I also want to add a passive
> notification offering the possibility to configure the path to use to
> search music. I even have a task in phabricator for that.
> 
> > That'd be my workflow as a regular user.
> 
> I am already convinced that first impression is important. At the same time,
> I did request to move to extragear to get covered by CI and to get feedback
> from kde-core-devel.
> 
> > Cheers,
> > 
> >   Albert
> 
> [...]
> 
> By the way, did you build Elisa with Baloo ?

Yes

Cheers,
  Albert

> 
> Best regards

Re: kdereview - qtcurve

[Albert Astals Cid]

El dijous, 22 de juny de 2017, a les 16:07:01 CEST, David Edmundson va 
escriure:
> On Mon, Jun 19, 2017 at 11:42 PM, Albert Astals Cid <aa...@kde.org> wrote:
> > El divendres, 16 de juny de 2017, a les 11:07:19 CEST, Yichao Yu va
> > 
> > escriure:
> > > QtCurve is now in kdereview with the intention of being in
> > > extragear/base
> > 
> > By default it assumes i want a Qt4 build and then fails because i don't
> > have
> > the necessary packages. Maybe it could be a bit gentler and just give me a
> > nice warning?
> 
> Possibly fixed. You'll need to wipe your CMakeCache though.

Not fixed for me https://paste.kde.org/pzgvpred2

Maybe the detection of KDE4 also needs to be optional and not REQUIRED?

Cheers,
  Albert

> 
> David

Re: kdereview - qtcurve

[Albert Astals Cid]

El divendres, 16 de juny de 2017, a les 11:07:19 CEST, Yichao Yu va escriure:
> QtCurve is now in kdereview with the intention of being in extragear/base

For the record, I also asked Yichao to have a look at a comment one of our 
translators did in the i18n mailing list (via a CC'ing), haven't heard back 
about it yet, so i'm mentioning it here too.

Cheers,
  Albert

Re: Elisa is in kdereview

[Albert Astals Cid]

El divendres, 16 de juny de 2017, a les 22:44:03 CEST, Matthieu Gallien va 
escriure:
> Hello,
> 
> Elisa is now in kdereview and aiming for extragear/multimedia.
> 
> It is a music player from a design from Andrew Lake.
> It is using Qt multimedia for playback and a few KDE frameworks. Its UI is
> using Qml.
> 
> Its aim is to be simple to use and hopefully in the future powerfull when
> needed.
> 
> It should be usable without needing online services but will use them in the
> future.
> 
> A few integration bits are missing with respect to Baloo before I can do a
> release. Currently music can only be read if in its database that can be
> filled by Baloo or a custom file indexer if Baloo is not there.

That's kind of a weird design decision, basically i started elisa, it didn't 
see any of my music, i didn't find a way to add it, so i removed elisa.

That'd be my workflow as a regular user.

Cheers,
  Albert

> 
> A broken and experimental support for UPnP DLNA exists and depends on an
> external library not yet in KDE.
> 
> If the review succeed, I would like to have CI support for Elisa.
> 
> Thanks in advance for any review as this my first "real" project with Qml
> and Qt.
> 
> Best regards

Re: Moving AtCore to Extragear

[Albert Astals Cid]

El diumenge, 18 de juny de 2017, a les 9:48:07 CEST, Lays Rodrigues va 
escriure:
> Hey guys, good morning. =D
> Any more comments on AtCore code?
> How the moving to Extragear work?

Are you planning to at least answer my last comments saying "we don't really 
care about that level of perfection"? (which is a fair position)

Cheers,
  Albert

> Thanks
> 
> On Mon, Jun 12, 2017 at 7:42 PM, Albert Astals Cid <aa...@kde.org> wrote:
> > El divendres, 9 de juny de 2017, a les 16:52:55 CEST, Lays Rodrigues va
> > 
> > escriure:
> > > Hey Albert, is that what you were in mind?
> > > https://phabricator.kde.org/D6165
> > 
> > Partially, i personally still think it'd be better if you move the
> > PrinterState AXIS and MeasuramentUnits enums inside AtCore (or make them
> > C++11
> > "enum class").
> > 
> > Also note how PrinterState AXIS MeasuramentUnits is not consistent naming
> > 
> > Cheers,
> > 
> >   Albert
> >   
> > > Thanks
> > > 
> > > 
> > > On Thu, Jun 8, 2017 at 7:32 PM, Lays Rodrigues <
> > 
> > laysrodriguessi...@gmail.com
> > 
> > > > wrote:
> > > > 
> > > > On Thu, Jun 8, 2017 at 6:36 PM, Albert Astals Cid <aa...@kde.org>
> > 
> > wrote:
> > > >> El dimarts, 23 de maig de 2017, a les 10:17:46 CEST, Lays Rodrigues
> > > >> va
> > > >> 
> > > >> escriure:
> > > >> > Good morning everyone,
> > > >> > For you that don't know me, I'm Lays Rodrigues, and I work with 3
> > 
> > more
> > 
> > > >> > guys(Patrick, Chris, Tomaz) on Atelier.
> > > >> > Atelier is a software for 3DPrinting that we are building inside
> > 
> > KDE.
> > 
> > > >> > So
> > > >> > far we have 10 months of work, and we are ready for the launch of
> > 
> > our
> > 
> > > >> core,
> > > >> 
> > > >> > in this case, is AtCore.
> > > >> > AtCore is the API responsible for all serial communication, and for
> > > >> > validating more of our work, we would like to launch the 0.1
> > > >> > version
> > > >> 
> > > >> with
> > > >> 
> > > >> > the next KDE Applications release.
> > > >> 
> > > >> You understand that if you are on extragear you don't get released
> > 
> > with
> > 
> > > >> "KDE
> > > >> Applications", right? You need to do the release yourself.
> > > > 
> > > > ​Yes, we are aware of that now.
> > > > Was some confusing learn all of this politcs but I got some help, and
> > 
> > now
> > 
> > > > I think that we are on the right path. =D
> > > > I will pass your comments forward, and look to fix it.
> > > > Thanks
> > > > 
> > > > --
> > > > *Lays Rodrigues*
> > > > *Software Developer at KDE*
> > > > *Intern at Rede Globo*
> > > > *Computer Science student at Federal Fluminense University*
> > > > *laysrodriguesdev.wordpress.com <http://laysrodriguesdev.wordpress.com
> > >
> > >*
> > >
> > > > *Telegram: @lays147*
> > > > *IRC: lays147*
> > > > *Phone: +55 22 981520012 <+55%2022%2098152-0012>*