Re: [OS X] should kauth-policy-gen be an app bundle?

[Aleix Pol]

On Sun, Nov 15, 2015 at 12:38 PM, René J. V. <rjvber...@gmail.com> wrote:
> Aleix Pol wrote:
>
>
>> Not really, as anything installed in libexec.
>
> Is it OK to push the change to the respective CMakeLists.txt without doing a 
> RR
> first, and if so, is there any risk to changing this on all platforms instead 
> of
> only ifdef(APPLE) ?

Please make a RR, if you had done we I would have reviewed it instead
of replying to this e-mail.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kpackage: reasons not to use ecm_mark_nongui_executable?

[Aleix Pol]

On Wed, Nov 11, 2015 at 12:35 AM, René J. V.  wrote:
> Alex Merry wrote:
>
>
>> I would expect that they should be nongui. We've realised that there are
>> some cases where we want to be marked GUI on windows and not on OS X,
>> but I doubt that's the case for KPackage.
>
> Do you know if applications marked non-gui initialise the windowserver
> connection on startup, on OS X? Apps that don't will crash when they attempt 
> to
> do anything GUI or event processing related, but apps that do cannot be run 
> from
> a remote terminal if the same user is not logged into the desktop too.

That's what the macro does, nothing more:
set_target_properties(${_target}
   PROPERTIES
   WIN32_EXECUTABLE FALSE
   MACOSX_BUNDLE FALSE
 )

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Muon build fails to start

[Aleix Pol]

On Wed, Nov 4, 2015 at 1:59 PM, Praneeth Tss  wrote:
> Hi,
>
> So sitter just pointed out that I needed to pass
> -DKDE_INSTALL_USE_QT_SYS_PATHS=ON and the app now runs fine.
>
> Thanks a lot.
>
> Praneeth TSS
> Amrita university
>
> On Wed, Nov 4, 2015 at 6:12 PM, Praneeth Tss 
> wrote:
>>
>> Hi,
>>
>> I wish to fix a bug[3] in muon-discover. I've was able to successfully
>> build muon from source. However, it crashes on startup.[5]
>>
>> Thomas previously indicated[4] that the error could be because of the
>> plugin paths being improperly configured. I was first trying to install in
>> custom path in my home directory[1].  Later, I even built the app in the
>> default directory(without passing any arguments to cmake)[2] but the app
>> still crashes during execution.
>>
>> I just can't seem to understand what I'm missing. Can you please take a
>> look ?
>>
>> Thanks !
>>
>> [1] https://paste.kde.org/pnrbn4sdw
>> [2] https://paste.kde.org/plrheaymy
>> [3] https://bugs.kde.org/show_bug.cgi?id=341523
>> [4] https://www.mail-archive.com/kde-devel@kde.org/msg07692.html
>> [5] https://paste.kde.org/pitw9gsmh
>>
>> Praneeth TSS
>> Amrita University
>
>

By the way, it's either that or set up the environment to point to your prefix.
https://community.kde.org/Frameworks/Building#Adjust_the_paths

Maybe KDE_INSTALL_USE_QT_SYS_PATHS should be enabled by default though
as it generally only should be disabled when using kde-src-build or
similar.

Aleix

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

Re: Failure while executing KTar::open while using KCompressionDevice as the device

[Aleix Pol]

On Mon, Nov 2, 2015 at 6:53 PM, Luiz Romário Santana Rios
 wrote:
> Hello,
>
> I'm trying to decompress a XZ archive downloaded using
> QNetworkAccessManager, so, according to the documents, I have to pass
> the QNetworkReply pointer to a KCompressionDevice and, then, use it as
> Ktar's device like this:
>
> https://gist.github.com/anonymous/b8fb686367f518a7dbb5
>
> The problem is that KTar::open() fails and returns false. The file I'm
> trying to extract has the following structure more or less:
> /root
> /root/dir
> /root/dir/file1
> /root/dir/file2
> ...
>
> So, as far as I've seen, the code runs normally when entering /root
> and /root/dir, but, pretty high in the stack, at
> KXzFilter::uncompress(), the call to lzma_code returns
> LZMA_FORMAT_ERROR while trying to uncompress file1 (or file2, I'm not
> sure). Here's the call stack:
>
> https://gist.github.com/anonymous/9ea380cfe48daadb5971
>
> Is this a bug? If it's a bug, how can I proceed to fix it?
>
> Thanks for the attention.

Hi,
A good first step would be coming up with a unit test like the ones
you can find in karchive/autotests. If we have a reproducible test
case it will be much faster to fix (for you and for us).

Regards,
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Failure while executing KTar::open while using KCompressionDevice as the device

[Aleix Pol]

On Fri, Nov 6, 2015 at 8:48 AM, David Faure  wrote:
> On Monday 02 November 2015 14:53:40 Luiz Romário Santana Rios wrote:
>>
>> I'm trying to decompress a XZ archive downloaded using
>> QNetworkAccessManager, so, according to the documents, I have to pass
>> the QNetworkReply pointer to a KCompressionDevice
>
> I don't think this can work at all.
> (and yes I've seen your review request, but while it fixes the file:/// case, 
> are you sure
> it fixes the network case as well?)
>
> Here's the issue:
> while QIODevice is indeed one single API, there are two ways to use it:
> push and pull.  Or in other words, async and sync.
>
> The push / async use case is the one used with sockets (including 
> QNetworkReply).
> You wait for data to be available and only then read it. Waiting can be done 
> blocking
> or with the event loop (signal/slot connection).
>
> The pull / sync use case is code that assumes there's always data available,
> as is the case with QFile, QBuffer etc. This is what KCompressionDevice, 
> KTar, KZip
> etc. all assume.
>
> So the reason it breaks (apart from the issue of seeking) is that when KTar
> (or KCompressionDevice) wants to read more data, it might not be available,
> and the read fails. You could add waitFor* calls, but that would make the 
> whole
> thing blocking - very bad for the main thread of a GUI program.
>
> So instead I do recommend using KIO (or QNAM) to make an async download
> (keeping the GUI reactive, allowing for a progress bar if desired...), and 
> only
> once the stuff is in a tempfile, you can create a KArchive on top.
>
> KTar is somewhat linear so your patch + waitFor* might make it work but
> KZip requires a lot more going back and forth in the file, so this will never 
> work
> without a temp file.
>
> In the special case of tar+compression in readonly mode, KTar already creates
> a temp file, for the uncompressed tar, for faster seeking. This might also be
> why you make it work in this very case, but that doesn't help for the other 
> cases
> (not tar, or not compressed)

What he could do though, is to add a QBuffer in case ::isSequential()
is true. This way we don't have specific restrictions on the API.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: SoK idea - KDE Connect

[Aleix Pol]

On Fri, Oct 30, 2015 at 6:21 PM, Ovidiu-Florin BOGDAN
 wrote:
> I have an idea that a SoK student can develop.
>
>
>
> A KDE Connect client for Kodi.
>
>
>
> This client would give the functionality to:
>
> Show notifications from the phone on the Kodi device
> Pause playback if a call is coming
> Control playback
>
> From phone as it does right now with computers
> from other paired devices, not just phone, but also computer, this would
> require a widget for the desktop client.
>
> Send text to Kodi (useful for the times Kodi asks for some text input)
>
> These would be the basic things that I thought of.
>
> I cannot be a full time mentor for this, but I can help here and there.
> Perhaps one of the KDE Connect developers can join in on this.
>
>
>
> What do you guys think? Can I add this in the Ideas Wiki page?

Hasn't the application deadline already passed for SoK?

Regarding the idea, I'd say it's good, but it's not really top
priority. For starters, if you're interested in Kodi integration, many
things should already work if they support MPRIS.

Aleix

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

Re: Failure while executing KTar::open while using KCompressionDevice as the device

[Aleix Pol]

On Tue, Nov 3, 2015 at 3:00 AM, Luiz Romário Santana Rios
<luizroma...@gmail.com> wrote:
> 2015-11-02 22:41 GMT-03:00 Aleix Pol <aleix...@kde.org>:
>> On Mon, Nov 2, 2015 at 6:53 PM, Luiz Romário Santana Rios
>> <luizroma...@gmail.com> wrote:
>>> Hello,
>>>
>>> I'm trying to decompress a XZ archive downloaded using
>>> QNetworkAccessManager, so, according to the documents, I have to pass
>>> the QNetworkReply pointer to a KCompressionDevice and, then, use it as
>>> Ktar's device like this:
>>>
>>> https://gist.github.com/anonymous/b8fb686367f518a7dbb5
>>>
>>> The problem is that KTar::open() fails and returns false. The file I'm
>>> trying to extract has the following structure more or less:
>>> /root
>>> /root/dir
>>> /root/dir/file1
>>> /root/dir/file2
>>> ...
>>>
>>> So, as far as I've seen, the code runs normally when entering /root
>>> and /root/dir, but, pretty high in the stack, at
>>> KXzFilter::uncompress(), the call to lzma_code returns
>>> LZMA_FORMAT_ERROR while trying to uncompress file1 (or file2, I'm not
>>> sure). Here's the call stack:
>>>
>>> https://gist.github.com/anonymous/9ea380cfe48daadb5971
>>>
>>> Is this a bug? If it's a bug, how can I proceed to fix it?
>>>
>>> Thanks for the attention.
>>
>> Hi,
>> A good first step would be coming up with a unit test like the ones
>> you can find in karchive/autotests. If we have a reproducible test
>> case it will be much faster to fix (for you and for us).
>>
>> Regards,
>> Aleix
>
> I'll do that, but how do I host a local file so that it can be
> "downloaded" from QNAM?
>
> --
> Luiz Romário Santana Rios

Using file:/// url scheme you can asynchronously read local files.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Aleix Pol]

On Tue, Oct 20, 2015 at 4:49 PM, Christoph Cullmann  wrote:
> Hi,
>
> after some patching, we got around to a state that allows to e.g. use KWrite
> on Windows or Mac with stock frameworks master and stock Qt 5.5, without any 
> additional
> patches and no stuff like dbus running. (as standalone installer/bundles)
>
> To have KIO working, one needs to teach it how to find the .protocol files, 
> like
> ATM done by some patches to Qt by the Windows folks (or we avoid that by 
> embedding that
> info in the slaves in the plugin meta data), for icons you need to set the 
> icon lookup
> path + theme hardcoded.
>
> My question: What is the actual goal for frameworks on non-linux like (or 
> non-xdg conform)
> or whatever called operating systems?
>
> My personal current goal is to have them in at state that allows:
>
> 1) use stock Qt as base
> 2) have frameworks in a state that allows them to be used in application 
> standalone installer/app-bundle without global stuff required
> 3) avoid the use of non-existing stuff like the dbus session bus
>
> For the "make it easy to bundle" I patched some frameworks to support stuff 
> inside qt resources.
> (xmlgui for ui files, kconfig for global default config files)
>
> That works only, if the applications bundle their ui files in resources, too, 
> otherwise, they just won't be found
> and the applications break, unless you patch again Qt to look in non-standard 
> locations.
>
> For the "non-dbus" I made some stuff bit more "failure safe", if no bus is 
> around, on cost of features.
> (like for kio, no instant segfault anymore, just no working dbus related 
> stuff)
>
> Here the applications need a bit care, too, like not exit, if they can't 
> register on the bus.
>
> Is that just my personal goal or is that what we want to have as frameworks 
> goal on such operating systems?
> Would that make the stuff more usable for Krita for example?
>
> Greetings
> Christoph

Hi,
With my Android hat on I very much welcome the initiative. Android is
more limited in this regard, as you will mostly always want to have
split packages there and it's how we've been working since the
beginning.

I think that for us Qt is a safe base in general. relying on other 3rd
parties makes things a bit more complex. (e.g. dbus or gstreamer) It's
always arguable that it is possible to run, but then it can be a
burden. While on Linux it's preferable to leverage on the system
infrastructure, we can't expect these to be available elsewhere.

I can agree to the 3 goals you mentioned, but they feel fuzzy:
1) Fully agreed
2) What's Global stuff? This could be phrased as: "Frameworks should
only require resources that can be located with QStandardPaths and can
be distributed in bundles."
3) non-existing stuff? really? Let's rephrase it as: "Frameworks will
only be advertised as available on a platform if they are just require
Qt or other available dependencies on the platform". For example,
requiring libssh could be an acceptable dependency.

Regarding dbus especifically, I see the problem in 2). You can bundle
it, but then if it's already ran by another process the other one will
have to be used, which is where the dbus mess starts.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Aleix Pol]

On Wed, Oct 21, 2015 at 1:12 AM, Ralf Habacker  wrote:
>> Christoph Cullmann  hat am 20. Oktober 2015 um 16:49
>> geschrieben:
>
>> That works only, if the applications bundle their ui files in resources,
>> too, otherwise, they just won't be found
>> and the applications break, unless you patch again Qt to look in
>> non-standard locations.
> yes, the following patch
> https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt54/mingw32-libqt5-qtbase/qt5-qstandardpath-data-location.patch?expand=0
> is a workaround to fix some of the issues.

That's why Christoph is saying: "unless you patch again Qt to look in
non-standard locations.".

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Project proposal for Season of KDE

[Aleix Pol]

On Tue, Oct 20, 2015 at 8:55 PM, Harshit Dwivedi  wrote:
> Hello Everyone,
>
> I would like to send my proposal for SOK . Please try and consider it.
>
>
> Name: Harshit Dwivedi
>
>
> Country: India
>
>
> Project Title: Porting to KF5
>
>
> Project Description: I have looked into KDF and i think i can try and port
> it to KF5 with support and help of mentor. First I will start with Build
> System then moving on to UI, then to KDE Core where i might need some help.
>
> I also wanted to know whether this project is currently active or not, as
> the last commit to this was about 6 months ago.
>
>
> Technical Requirements: Qt, QML, KF5
>
>
> Time-line: My availability and other commitments during period: I have my
> papers from 20th November to 25th December so i will not be available during
> this period but after that period I will be fully committed to KDE Project.
> Firstly I will be moving on with porting of build system and then moving on
> to port with support of KDE4LibsSupport and porting UI afterwords.
>
>
> Why me: I have past experience in contributing to various OSS like
> Cyanogenmod and i am comfortable with OOPs, algorithms and Qt.
>
> Regards,
> Harshit.
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

Hi Harshit,
I don't think you're saying on your proposal what you want to port...

Aleix

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

Re: Project proposal for Season of KDE

[Aleix Pol]

On Wed, Oct 21, 2015 at 1:33 AM, Jeremy Whiting <jpwhit...@kde.org> wrote:
> Yeah, he said KDF
>
> On Tue, Oct 20, 2015 at 5:22 PM, Aleix Pol <aleix...@kde.org> wrote:
>> On Tue, Oct 20, 2015 at 8:55 PM, Harshit Dwivedi <manasbag...@gmail.com> 
>> wrote:
>>> Hello Everyone,
>>>
>>> I would like to send my proposal for SOK . Please try and consider it.
>>>
>>>
>>> Name: Harshit Dwivedi
>>>
>>>
>>> Country: India
>>>
>>>
>>> Project Title: Porting to KF5
>>>
>>>
>>> Project Description: I have looked into KDF and i think i can try and port
>>> it to KF5 with support and help of mentor. First I will start with Build
>>> System then moving on to UI, then to KDE Core where i might need some help.
>>>
>>> I also wanted to know whether this project is currently active or not, as
>>> the last commit to this was about 6 months ago.
>>>
>>>
>>> Technical Requirements: Qt, QML, KF5
>>>
>>>
>>> Time-line: My availability and other commitments during period: I have my
>>> papers from 20th November to 25th December so i will not be available during
>>> this period but after that period I will be fully committed to KDE Project.
>>> Firstly I will be moving on with porting of build system and then moving on
>>> to port with support of KDE4LibsSupport and porting UI afterwords.
>>>
>>>
>>> Why me: I have past experience in contributing to various OSS like
>>> Cyanogenmod and i am comfortable with OOPs, algorithms and Qt.
>>>
>>> Regards,
>>> Harshit.
>>>
>>>
>>>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>>>> <<
>>>
>>
>> Hi Harshit,
>> I don't think you're saying on your proposal what you want to port...
>>
>> Aleix
>>
>>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe 
>>>> <<
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Correct. My apologies Harshit.

Aleix

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

Re: Policy for Dependencies

[Aleix Pol]

On Wed, Oct 14, 2015 at 10:28 PM, Kevin Ottens  wrote:
> Hello,
>
> On Wednesday 14 October 2015 21:20:33 Christoph Cullmann wrote:
>> Therefore my goal for frameworks is to make them actually as easy usable
>> for people in that situation. We advertise that a lot everywhere but at the
>> moment that is just not true beside for really simple stuff like "karchive".
>
> Just to put some historical perspective into this particular point. It *is*
> true, but for tier 1 and tier 2 frameworks only. That's why the dependency
> rules of the tier system were designed the way they are.
>
> So if you are "people in that situation" as described by Christoph in his
> email: stay away from anything which is above tier 2 or make it an optional
> dependency. You still have more than 30 frameworks to pick from for the other
> ones YMMV, you should be warned headaches might or might not be ahead with
> tier 3.
>
> If you are someone working on a given framework and you are just content of
> having it in KF5's tier 3, but did no refactoring or API work to get it to
> tier 2 or tier 1: you're missing the point of KF5's tier and type
> organization. You are also prematurely shrinking its potential user base and
> that should bother you, really.
>
> If you remember the talk I gave back in the days about KF5, I mentioned that
> the tier and type matrix is also a *maturity* system. It is our responsibility
> to push the frameworks down the stack as much as possible. Since then, I see
> lots of frameworks appearing, I don't see many of them lowering their tier...
>
> Regards.

Would it make sense then to define as part of the tier only the
mandatory dependencies?

Then the variable could be, instead of what Christoph proposed,
something like KDE_ENFORCE_ALL_FRAMEWORKS.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Policy for Dependencies

[Aleix Pol]

On Tue, Oct 13, 2015 at 2:20 PM, Christoph Cullmann  wrote:
> Hi,
>
> different take on that below:
>
>> Hi,
>>
>>> On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote:
 Hi,
>>>
>>> thanks for raising this topic. I think it's very important that we have a
>>> general strategy for frameworks and not have thousands of micro-fixes in
>>> various frameworks.
>> ;=)
>>
>>>
 1) "Normal" deployment like we do in on Linux => just installing it with 
 all
 features if possible. 2) "Application Bundles/Installer" like we will have
 to do it on Win/Mac and 3rdparty Linux people will need to do.

 I think the easiest solution is to make stuff optional. That will avoid 
 ugly
 "if (WIN OR APPLE OR ANDROID)".. hacks in CMake and allow people to still
 build stuff with that deps on that operating systems if really wanted.
>>>
>>> Given from the no-X11 fixes I think that we should avoid all if (WIN OR 
>>> APPLE)
>>> as that:
>>> a) is hard to maintain
>>> b) doesn't scale
>>> c) not testable for the devs working on Linux
>>>
>>> Given that it should be feature based and we should make as much usage of 
>>> the
>>> built in CMake features we have. I really like the approach we have now 
>>> found
>>> for X11 on OSX: disable certain find modules at a global level.
>>>
>>> I think that is something which could be applied for more things. Control
>>> through global ECM settings. This could if we don't want to have global
>>> changes also through convenient command switches:
>>>
>>> e.g. cmake -DECM_BUILD_FOR_OSX_APPBUNDLE
>>>
>>> which then implies e.g. no phonon and no dbus and ...
>>
>> For X11 that might cut it, as it is non-sense to compile it on mac, but I 
>> doubt
>> such
>> global magic will cut it for other stuff like phonon or dbus.
>>
>> You might want to have both on mac and windows, too.
>>
>> If we start to make this global disabled, we will annoy people, too.
>> In addition: If we want to have 3rdparty devs use our stuff, it must be 
>> possible
>> to avoid these dependencies on Linux, too.
>>
>> I really would like to have the normal CMake strategy: non-required stuff is
>> optional.
>>
>> For KNotifications thats even obvious, given its internals are build in a 
>> ways
>> that this
>> stuff is an internal "plugin".
>>
>> I don't think we need yet an other level of magic, beside things like "X11 on
>> Mac/Win are non-brainers",
>> which is not much more than we do with other global compiler/cmake flags
>> specific for OSes.
>
> Ok, after the reasonable criticisms of making the sound stuff optional in 
> knotifications per default:
>
> Could we have some ECM switch like (name is just an example):
>
> option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies from 
> required to optional as possible, this might lead to a loss of 
> functionality." OFF)
>
> Based on that option, we can make stuff optional and we will have best of two 
> worlds:
>
> 1) no by accident loss of functionality and bug reports (like feared by some, 
> and I must confess that might be realistic)
> 2) an easy to use solution for people wanting minimal dependencies as this is 
> "one" switch and it will work on all operating systems

I think we're mixing different subjects here. One thing is being able
to be as portable as possible and another thing is to have few
dependencies. Dependencies are a portability problem as they make the
process a bit more complex, but also this process needs to be
standardized. The reason why dependencies are a problem when we port,
is because these pop when we as humble developers try to play the
packager role, and we're not used it it.

My proposal is that we should make sure which frameworks are viable on
each platform. If a framework is not viable on a platform (be it
because it's not an abstraction or because it doesn't make sense) then
other frameworks must either inherit the non-viability or make the
framework usage optional. And so should do applications that aspire to
be portable, which is by no means required.

I'm not sure though how acceptable is to drop functionality in favor
of just reducing the dependency list.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KDE Applications Versioning

[Aleix Pol]

On Wed, Jul 8, 2015 at 11:43 AM, Martin Klapetek
martin.klape...@gmail.com wrote:
 As the KDE Apps release is getting near, is this being considered/deployed?
 Should we be setting some CMake variables?

 Cheers
 --
 Martin Klapetek | KDE Developer

Yes, that's why Albert was asking for a blog/wiki documentation.

Aleix

Prunning KDeclarative dependencies

[Aleix Pol]

Hi,
I've been thinking about looking into pushing Purpose as a framework. One
of its dependencies is KDeclarative, which means all of the things. In this
case KDeclarative is used for the i18n() integration.
I think this is especially bad because it raises the Qt Quick adoption
barrier quite a bit for KDE applications as well, that if they want to be
translated properly as a KDE project they'll need to depend on frameworks
like KIconThemes.

Alternatives proposed that come to mind:
- Make KI18n provide a class that does what KDeclarative::KDeclarative is
currently doing.
- Move the KIconTheme and KIO integration elsewhere (for example in
KIconTheme and KIO respectively) so that applications and frameworks can
decide actively to adopt them. This though would still leave a KPackage
dependency which is also rather big and probably unused by many of the
applications as well.

What do you think?

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [OS X] should kauth-policy-gen be an app bundle?

[Aleix Pol]

On Sat, Nov 14, 2015 at 1:22 PM, René J.V.  wrote:
> Hi,
>
> I'm not really familiar with the role of kauth-policy-gen (or the one it 
> would play on OS X), or how it's supposed to be called. Is there a reason to 
> build it as an app bundle on OS X, or should it rather be a regular 
> executable as I'd expect?
>
> R.

Not really, as anything installed in libexec.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Moving KDE Connect out of playground

[Aleix Pol]

On Mon, Sep 14, 2015 at 12:52 AM, Jeremy Whiting  wrote:
> As shown here: http://developer.kde.org/~cfeck/portingstatus.html
> (under Extragear base) It is missing a manual. Needs a Feature_summary
> added to CMakeLists.txt and some .desktop files should be renamed to
> org.kde.foo.desktop.
>
> I just tried it out and it seems to work here, though I'm not seeing
> sms notifications in the desktop like I expected (I am able to control
> cantata from my phone though, which is handy). Yes I installed the
> beta on the play store.
>
> BR,
> Jeremy
>
>
> On Sat, Sep 12, 2015 at 6:29 AM, Albert Vaca  wrote:
>>> I moved the translations for both repositories. Please update the
>>> translations
>>> branches for kdeconnect-android so that trunk_kf5 is master and trunk is
>>> none;
>>> yes, it's android and it does not matter, but it's easier for us.
>>
>>
>> Done.
>>
>>>
>>> Translation branches for kdeconnect-kde are fine (translations moved few
>>> months ago). In addition to master, we track also the 'kde4' branch. Do
>>> you
>>> plan to release additional versions from there, or can we drop that
>>> branch?
>>
>>
>> Removed kde4.
>>

Hi Jeremy,
We just fixed the desktop naming issue and added the feature summary.

Regarding the documentation, we discussed it briefly during the sprint
and we have the feeling that the documentation for such a project
would look more like a simple placeholder or something easily outdated
than anything. Furthermore, since there isn't a clear main window of
the application, it would be unintuitive to get there. We're convinced
nobody would ever end up there.

Aleix

Re: Moving KDE Connect out of playground

[Aleix Pol]

On Mon, Sep 14, 2015 at 12:52 AM, Jeremy Whiting  wrote:
> As shown here: http://developer.kde.org/~cfeck/portingstatus.html
> (under Extragear base) It is missing a manual. Needs a Feature_summary
> added to CMakeLists.txt and some .desktop files should be renamed to
> org.kde.foo.desktop.
>
> I just tried it out and it seems to work here, though I'm not seeing
> sms notifications in the desktop like I expected (I am able to control
> cantata from my phone though, which is handy). Yes I installed the
> beta on the play store.
>
> BR,
> Jeremy
>
>
> On Sat, Sep 12, 2015 at 6:29 AM, Albert Vaca  wrote:
>>> I moved the translations for both repositories. Please update the
>>> translations
>>> branches for kdeconnect-android so that trunk_kf5 is master and trunk is
>>> none;
>>> yes, it's android and it does not matter, but it's easier for us.
>>
>>
>> Done.
>>
>>>
>>> Translation branches for kdeconnect-kde are fine (translations moved few
>>> months ago). In addition to master, we track also the 'kde4' branch. Do
>>> you
>>> plan to release additional versions from there, or can we drop that
>>> branch?
>>
>>
>> Removed kde4.
>>

Hi Jeremy,
We just fixed the desktop naming issue and added the feature summary.

Regarding the documentation, we discussed it briefly during the sprint
and we have the feeling that the documentation for such a project
would look more like a simple placeholder or something easily outdated
than anything. Furthermore, since there isn't a clear main window of
the application, it would be unintuitive to get there. We're convinced
nobody would ever end up there.

Aleix

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

Re: Moving KDE Connect out of playground

[Aleix Pol]

On Sat, Sep 12, 2015 at 1:03 AM, Albert Astals Cid  wrote:
> El Divendres, 11 de setembre de 2015, a les 07:52:34, Albert Vaca va escriure:
>> Our awesome sysadmins already moved the two repos (kdeconnect-android and
>> kdeconnect-kde) to Review.
>
> In LoopbackDeviceLink::sendPackageEncrypted and
> LoopbackDeviceLink::sendPackage you probably want to return false instead of
> (or at least in addition to) those Q_ASSERTS ?
>
> Do you want to do something with the success bool in FindMyPhonePlugin::ring ?
> Like send a notication to the user that it failed or something?
>
> PauseMusicPlugin::isKMixMuted returns a bool as an int?
>
> In DevicesSortProxyModel::sourceDataChanged you probably want to drop the two
> params, Qt is smart enough to do a connection if the receiving side is a
> subset of the send one; or at least make the params const &
>
> I think it may make sense to change the connects() to new style connects,
> there's an automation tool in kde-dev-scripts/kf/convert-to-new-signal-slot-
> signal.pl
>
> In case you're interested here's the clazy warnings:
>  * function-args-by-ref https://paste.kde.org/pw85h9xgh
>  * detaching-temporary https://paste.kde.org/py99b8dp1
>
> I did not include inefficient-qlist nor qstring-uneeded-heap-allocations but
> they also have lots of warnings
>
> These all just small things to improve, fine to "ignore" if you want :)
>
> Cheers,
>   Albert

Fixed.

Good morning! :)

Aleix

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

Re: Moving KDE Connect out of playground

[Aleix Pol]

On Sat, Sep 12, 2015 at 1:03 AM, Albert Astals Cid  wrote:
> El Divendres, 11 de setembre de 2015, a les 07:52:34, Albert Vaca va escriure:
>> Our awesome sysadmins already moved the two repos (kdeconnect-android and
>> kdeconnect-kde) to Review.
>
> In LoopbackDeviceLink::sendPackageEncrypted and
> LoopbackDeviceLink::sendPackage you probably want to return false instead of
> (or at least in addition to) those Q_ASSERTS ?
>
> Do you want to do something with the success bool in FindMyPhonePlugin::ring ?
> Like send a notication to the user that it failed or something?
>
> PauseMusicPlugin::isKMixMuted returns a bool as an int?
>
> In DevicesSortProxyModel::sourceDataChanged you probably want to drop the two
> params, Qt is smart enough to do a connection if the receiving side is a
> subset of the send one; or at least make the params const &
>
> I think it may make sense to change the connects() to new style connects,
> there's an automation tool in kde-dev-scripts/kf/convert-to-new-signal-slot-
> signal.pl
>
> In case you're interested here's the clazy warnings:
>  * function-args-by-ref https://paste.kde.org/pw85h9xgh
>  * detaching-temporary https://paste.kde.org/py99b8dp1
>
> I did not include inefficient-qlist nor qstring-uneeded-heap-allocations but
> they also have lots of warnings
>
> These all just small things to improve, fine to "ignore" if you want :)
>
> Cheers,
>   Albert

Fixed.

Good morning! :)

Aleix

Re: Moving KDE Connect out of playground

[Aleix Pol]

On Thu, Sep 10, 2015 at 2:20 PM, Luigi Toscano  wrote:
> On Thursday 10 of September 2015 02:33:55 Albert Vaca wrote:
>> +kde-core-devel
>>
>> Hi,
>>
>> With the latest changes we are making to KDE Connect as part of the sprint
>> in Randa, I think that the project is becoming mature enough to be moved
>> out of playground. Not only that, but Kubuntu and other distros are already
>> installing KDE Connect by default, regardless of it being in playground.
>>
>> I think that extragear/network is the best place for KDE Connect to be in,
>> as we don't want to be tied to external release schedules for now.
>>
>> Any thoughts?
>
> Nothing against moving it outside playground, it should have been done long
> time ago.
>
> From a technical point of view, shouldn't we follow the usual procedure with a
> moving to kdereview?
>
> Ciao
> --
> Luigi
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

The move to kdereview has been requested this afternoon by Albert.

I'd say the review itself can start already, I'm unsure it makes a big
difference.

Aleix

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

Re: Moving KDE Connect out of playground

[Aleix Pol]

On Thu, Sep 10, 2015 at 2:20 PM, Luigi Toscano  wrote:
> On Thursday 10 of September 2015 02:33:55 Albert Vaca wrote:
>> +kde-core-devel
>>
>> Hi,
>>
>> With the latest changes we are making to KDE Connect as part of the sprint
>> in Randa, I think that the project is becoming mature enough to be moved
>> out of playground. Not only that, but Kubuntu and other distros are already
>> installing KDE Connect by default, regardless of it being in playground.
>>
>> I think that extragear/network is the best place for KDE Connect to be in,
>> as we don't want to be tied to external release schedules for now.
>>
>> Any thoughts?
>
> Nothing against moving it outside playground, it should have been done long
> time ago.
>
> From a technical point of view, shouldn't we follow the usual procedure with a
> moving to kdereview?
>
> Ciao
> --
> Luigi
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

The move to kdereview has been requested this afternoon by Albert.

I'd say the review itself can start already, I'm unsure it makes a big
difference.

Aleix

Re: qca-qt5 (qt5 branch) merge into qca (master branch)

[Aleix Pol]

On Thu, Sep 24, 2015 at 11:02 AM, Harald Sitter  wrote:
> ahoy ahoy
>
> qca-qt5 as a "thing" is a build time switch on the same source as qca
> (qt4). so, it is the same source base but depending on how you run
> cmake you either get the qt5 or the qt4 build.
>
> originally various adjustments had to be made to qca-qt5 to make it
> work reliably without conflicting with qca (qt4), there was however a
> very long discussion on whether or not that is the right thing to do
> which eventually ended in the maintainer stepping down [anyone wanna
> maintain qca? it's like phonon but for crypto :)]. at the time qca-qt5
> as a tarball was released which had the changes and could co-exist
> with the regular qca tarball.
>
> now, since qca essentially has no lead authority we could do what was
> the original intention here. i.e. make the qca source base build two
> distinct libraries for qt4 and qt5 that do not conflict in any form or
> fashion. this would be a simple `git merge qt5` and then we can
> release a qca tarball that replaces the old qca-qt5 tarball.
>
> Q: any objections to merging qca's qt5 branch into master and
> replacing the qt5 tarball with a new release that supports both qt4
> and qt5?
>
> HS

It's the only branch I've been testing. I'd love to be able to use
master instead.

Aleix

Re: qca-qt5 (qt5 branch) merge into qca (master branch)

[Aleix Pol]

On Thu, Sep 24, 2015 at 11:02 AM, Harald Sitter  wrote:
> ahoy ahoy
>
> qca-qt5 as a "thing" is a build time switch on the same source as qca
> (qt4). so, it is the same source base but depending on how you run
> cmake you either get the qt5 or the qt4 build.
>
> originally various adjustments had to be made to qca-qt5 to make it
> work reliably without conflicting with qca (qt4), there was however a
> very long discussion on whether or not that is the right thing to do
> which eventually ended in the maintainer stepping down [anyone wanna
> maintain qca? it's like phonon but for crypto :)]. at the time qca-qt5
> as a tarball was released which had the changes and could co-exist
> with the regular qca tarball.
>
> now, since qca essentially has no lead authority we could do what was
> the original intention here. i.e. make the qca source base build two
> distinct libraries for qt4 and qt5 that do not conflict in any form or
> fashion. this would be a simple `git merge qt5` and then we can
> release a qca tarball that replaces the old qca-qt5 tarball.
>
> Q: any objections to merging qca's qt5 branch into master and
> replacing the qt5 tarball with a new release that supports both qt4
> and qt5?
>
> HS

It's the only branch I've been testing. I'd love to be able to use
master instead.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: RFC: split platformtheme plugin from frameworkintegration and move to kde/workspace

[Aleix Pol]

On Wed, Dec 9, 2015 at 3:56 PM, Mark Gaiser  wrote:
> On Wed, Dec 9, 2015 at 8:24 AM, Martin Graesslin  wrote:
>>
>> On Tuesday, December 8, 2015 6:03:47 PM CET Mark Gaiser wrote:
>> > I thought the frameworkintegration plugin was exactly that and usable
>> > for
>> > any platform if they wish to use it.
>> > Or is my assumption wrong and is it really only for Plasma and should
>> > others stay away from it?
>>
>> well obviously it's only for plasma as it's bound to env variables set by
>> startkde. And in 4.x time the qpt plugin was in kde-workspace repo, see:
>>
>> https://quickgit.kde.org/?p=kde-workspace.git=blob=4f67cc55104fe1081b05d381e9516e0215f8e24a=1b97d4427257120e305408404bff5ec6be0b65a9=qguiplatformplugin_kde
>> %2Fqguiplatformplugin_kde.cpp
>>
>> >
>> > My assumption can very well be wrong, but then i think we need to have a
>> > "base" frameworkintegration that every app dev can use with or without
>> > plasma. And a plasma specific version that integrates more in plasma i
>> > suppose.
>>
>> I don't think it's anything an app developer should care about. It's
>> integration, that's not something the app developer picks - otherwise the
>> app
>> breaks on integrating with other platforms.
>>
>> > I don't care for that either. It's logical and to be expected.
>> > I do care when i want to use the KF5 filedialog and need to install
>> > plasma
>> > (which has absolutely nothing to do with the dialog) just to get it.
>> > With "use" i mean the file open dialog, not the ones you can just call
>> > from
>> > the C++ side of things.
>> >
>> > And i definitely do not want to make a QPA just to have that working.
>>
>> Well you have to. The file dialog is part of integration. If you want to
>> have
>> a specific integration you need to provide a QPT (not QPA) plugin.
>> Application
>> developers must keep away from that.
>>
>> Please also read up on the topic of why KFileDialog got removed from our
>> API.
>>
>> Cheers
>> Martin
>
>
> I see what you mean, i understand your opinion, but... I just don't like it
> for all the reasons given earlier.
> I might be a minority here, not many people are responding besides Aleix and
> myself.
>
> Lets both take a step back and let some other opinions flow in.

I don't really understand your points...

LXQt/Other Desktops can depend on Plasma packages if they wish. Some
of them have used KWin at some point, AFAIK.

We also provide the classes to set up the QPT in our frameworks, they
can create their own (and probably should, if you ask me).

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Purpose as a KDE Framework

[Aleix Pol]

On Fri, Dec 4, 2015 at 11:26 PM, Mark Gaiser <mark...@gmail.com> wrote:
> On Thu, Dec 3, 2015 at 7:29 PM, Aleix Pol <aleix...@kde.org> wrote:
>>
>> On Wed, Dec 2, 2015 at 11:56 PM, Mark Gaiser <mark...@gmail.com> wrote:
>> > On Tue, Dec 1, 2015 at 3:01 PM, Aleix Pol <aleix...@kde.org> wrote:
>> >>
>> >> Hi,
>> >> I've been working on Purpose since some months now, with the intention
>> >> of becoming a framework some day. Some information about it can be
>> >> read here:
>> >>
>> >>
>> >> https://projects.kde.org/projects/playground/libs/purpose/repository/revisions/master/entry/README.md
>> >>
>> >> As it is right now it's a tier 2 framework (kcoreaddons and ki18n)
>> >> plus the plugins. Plugins raise the tier to 3 because of KIO which is
>> >> used by some plugins.
>> >>
>> >> As it is now, it's being used by: Kamoso, QuickShare plasmoid and
>> >> KDevelop for patch sharing. I'd like to see it used in other cases
>> >> than sharing as well as in other applications, but here's where we are
>> >> at the moment. I think it's something to build upon.
>> >>
>> >> Any thoughts?
>> >>
>> >> Aleix
>> >
>> >
>> > Hi Aleix,
>> >
>> > I'm trying to understand what Purpose is doing exactly.
>> > I've read the readme file, but i still can't quite figure out what it's
>> > doing or where i might be able to use it.
>> >
>> > Could you give a short summary with a clear example where to use it?
>> > That
>> > would help me :)
>>
>> Well, the shortcut to explaining it is that it's quite similar to
>> Android intents.
>>
>> The idea is that you identify some tasks you can group, for example:
>> - share, where you can get the different services to share
>> - getImage that would list your scanner, camera and also some web
>> services.
>> - addContact that would let you add a contact on your address book or
>> gmail directly.
>>
>> Then you receive the results in a nice and simple tuple. The input and
>> output arguments depend on the kind of task you are performing.
>>
>> I hope this made sense
>> Aleix
>>
> Thank you, that clears it up for me i think.
>
> Just curious, what would have to be done for a "send file" intent?
> Where a file can be send to (one of the following):
> - google drive
> - owncloud
> - dropbox
> - as mail attachment to someone
> - whatever other plugin
>
> I'm guessing each individual plugin would have to be fully implemented in
> Purpose?

Yes, or you can use something else that supports it. You can always
use KIO on them, which is much harder to implement.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Purpose as a KDE Framework

[Aleix Pol]

On Thu, Dec 3, 2015 at 8:15 PM, David Edmundson
<da...@davidedmundson.co.uk> wrote:
>
>
> On Thu, Dec 3, 2015 at 6:16 PM, Aleix Pol <aleix...@kde.org> wrote:
>>
>> On Tue, Dec 1, 2015 at 4:37 PM, David Edmundson
>> <da...@davidedmundson.co.uk> wrote:
>> > AlternativesModel doesn't seem like a good name. Alternate to what?
>> >
>> > -
>> >
>> > /** @returns the job that will perform the share of the specified @p
>> > data.*/
>> >
>> > what data?
>>
>> Eh... right. I'll also change the method name.
>>
>> >
>> > --
>> >
>> > Does the JSON blob in Job::setData() match the
>> > X-Purpose-OutboundArguments
>> > of that plugin?
>> >
>> > I don't seem to be able to access what those args are from C++ like
>> > Configuration::neededArguments
>> >
>> > Why JSON here rather than QVariantMap? It's all internal to C++ API.
>>
>> X-Purpose-OutboundArguments is specified in the plugin json file.
>>
>> >
>> > -
>> >
>> > In the pastebin plugin why are you registering the KJob with the job
>> > tracker?
>> >
>> > You're returning the progress via the kjob the plugin gives back, and
>> > the
>> > relevant UI should do it.
>>
>> Yeah.. maybe it doesn't make sense. I'll just remove it from there now.
>>
>> >
>> > 
>> >
>> > import Ubuntu.OnlineAccounts 0.1 as OA
>> >
>> > Can we depend on that? Seems weird.
>> >
>> > Definitely needs mentioning in CMake
>>
>> It's mentioned in here: find_package(QMLModule 0.1 COMPONENTS
>> Ubuntu.OnlineAccounts)
>>
>> >
>> > 
>> >
>> > saveas/saveasplugin.json
>> >
>> > probably best to avoid swearing in a release.
>>
>> Did it make you swear?
>
>
> I meant that you have:
>  "Description": "Dummy plugin, to test the shit out of the feature"
>
> What I like is seeing how the translators chose to deal with that.
Eh... going to change that.

>
>
>>
>> >
>> > 
>> >
>> > That ktp plugin is fine for a demo of things, but it is not release
>> > material.
>> >
>> > The job will return that you've shared things even if you click cancel,
>> > also
>> > you say it will return a URL in the json blob and it doesn't.
>>
>> Right, could use some love. I'll see if I can get it there or just
>> disable it for now.
>
>
>>
>>
>> >
>> > -
>> >
>> > There's a comment
>> >
>> >  * This shouldn't require to have the job actually running on the
>> > same
>> > process as the app.
>>
>> It means that the plugin should be able to run in a separate process.
>> In a KIO kind of way.
>
>
> Ah as in all data should be serialisable, don't pass pointers to objects or
> some such?

Yes.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Purpose as a KDE Framework

[Aleix Pol]

On Wed, Dec 2, 2015 at 11:56 PM, Mark Gaiser <mark...@gmail.com> wrote:
> On Tue, Dec 1, 2015 at 3:01 PM, Aleix Pol <aleix...@kde.org> wrote:
>>
>> Hi,
>> I've been working on Purpose since some months now, with the intention
>> of becoming a framework some day. Some information about it can be
>> read here:
>>
>> https://projects.kde.org/projects/playground/libs/purpose/repository/revisions/master/entry/README.md
>>
>> As it is right now it's a tier 2 framework (kcoreaddons and ki18n)
>> plus the plugins. Plugins raise the tier to 3 because of KIO which is
>> used by some plugins.
>>
>> As it is now, it's being used by: Kamoso, QuickShare plasmoid and
>> KDevelop for patch sharing. I'd like to see it used in other cases
>> than sharing as well as in other applications, but here's where we are
>> at the moment. I think it's something to build upon.
>>
>> Any thoughts?
>>
>> Aleix
>
>
> Hi Aleix,
>
> I'm trying to understand what Purpose is doing exactly.
> I've read the readme file, but i still can't quite figure out what it's
> doing or where i might be able to use it.
>
> Could you give a short summary with a clear example where to use it? That
> would help me :)

Well, the shortcut to explaining it is that it's quite similar to
Android intents.

The idea is that you identify some tasks you can group, for example:
- share, where you can get the different services to share
- getImage that would list your scanner, camera and also some web services.
- addContact that would let you add a contact on your address book or
gmail directly.

Then you receive the results in a nice and simple tuple. The input and
output arguments depend on the kind of task you are performing.

I hope this made sense
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Purpose as a KDE Framework

[Aleix Pol]

On Tue, Dec 1, 2015 at 5:39 PM, Emmanuel Pescosta
<emmanuelpescosta...@gmail.com> wrote:
> On Dienstag, 1. Dezember 2015 15:01:10 CET Aleix Pol wrote:
>
> Hi,
> looks really interesting!
>
>> I'd like to see it used in other cases than sharing as well as in other
> applications
>
> Would you accept a plugin which can be used to compare selected files? - e.g.
> by starting kompare
>
> This would replace the hard wired "compare" action from DolphinMainWindow with
> a nice plugin.

I'm not too sure what you have in mind. Can you point me to that code?

Shouldn't it be as easy as launching kompare?

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Purpose as a KDE Framework

[Aleix Pol]

On Tue, Dec 1, 2015 at 4:37 PM, David Edmundson
 wrote:
> AlternativesModel doesn't seem like a good name. Alternate to what?
>
> -
>
> /** @returns the job that will perform the share of the specified @p data.*/
>
> what data?

Eh... right. I'll also change the method name.

>
> --
>
> Does the JSON blob in Job::setData() match the X-Purpose-OutboundArguments
> of that plugin?
>
> I don't seem to be able to access what those args are from C++ like
> Configuration::neededArguments
>
> Why JSON here rather than QVariantMap? It's all internal to C++ API.

X-Purpose-OutboundArguments is specified in the plugin json file.

>
> -
>
> In the pastebin plugin why are you registering the KJob with the job
> tracker?
>
> You're returning the progress via the kjob the plugin gives back, and the
> relevant UI should do it.

Yeah.. maybe it doesn't make sense. I'll just remove it from there now.

>
> 
>
> import Ubuntu.OnlineAccounts 0.1 as OA
>
> Can we depend on that? Seems weird.
>
> Definitely needs mentioning in CMake

It's mentioned in here: find_package(QMLModule 0.1 COMPONENTS
Ubuntu.OnlineAccounts)

>
> 
>
> saveas/saveasplugin.json
>
> probably best to avoid swearing in a release.

Did it make you swear?

>
> 
>
> That ktp plugin is fine for a demo of things, but it is not release
> material.
>
> The job will return that you've shared things even if you click cancel, also
> you say it will return a URL in the json blob and it doesn't.

Right, could use some love. I'll see if I can get it there or just
disable it for now.

>
> -
>
> There's a comment
>
>  * This shouldn't require to have the job actually running on the same
> process as the app.

It means that the plugin should be able to run in a separate process.
In a KIO kind of way.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Purpose as a KDE Framework

[Aleix Pol]

On Tue, Dec 1, 2015 at 5:10 PM, Boudhayan Gupta <bgu...@kde.org> wrote:
> On 1 December 2015 at 20:42, Aleix Pol <aleix...@kde.org> wrote:
>>> 1. I'd like to be able to load the list of plugins available per
>>> mimetype a priori before the filename to share becomes available.
>> You can pass { "mimetype": "image/png", "urls": [] }.
>>
>> That should work.
>> I'm not sure why you'd want to list plugins before having anything to
>> share though...
>
> That lists the plugins; how do I now execute them with a URL?
Just show me the code you have to port it to Purpose and I'll try and
see how to fit it in the API... Is it in a branch?

>
> Another thing - What if I want to exclude a specific plugin from
> displaying in the menu, such as SaveAs?

We can look into this. It's not done so far. Do you think it's /that/
terrible that it's offered by default?

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Purpose as a KDE Framework

[Aleix Pol]

On Thu, Dec 3, 2015 at 11:37 AM, Marco Martin <notm...@gmail.com> wrote:
> On Tuesday 01 December 2015, Aleix Pol wrote:
>> Hi,
>> I've been working on Purpose since some months now, with the intention
>> of becoming a framework some day. Some information about it can be
>> read here:
>> https://projects.kde.org/projects/playground/libs/purpose/repository/revisi
>> ons/master/entry/README.md
>>
>> As it is right now it's a tier 2 framework (kcoreaddons and ki18n)
>> plus the plugins. Plugins raise the tier to 3 because of KIO which is
>> used by some plugins.
>>
>> As it is now, it's being used by: Kamoso, QuickShare plasmoid and
>> KDevelop for patch sharing. I'd like to see it used in other cases
>> than sharing as well as in other applications, but here's where we are
>> at the moment. I think it's something to build upon.
>>
>> Any thoughts?
>
> I really like the idea, good job:), my reservation is still that I think it
> should try really hard to have plugins scripted whenever possible, as
> webservice tend to be very api instable and change quickly (so updates out of
> order on things like get hot new stuff would be possible) plus it becomes easy
> having contributions for them, like the comic applet.
>
> but i don't think scripted plugins can be added as an aftertought as the
> structure of the framework may be influenced by that (yeah, i know,
> dependencies, but my wet dream is to have those sharing scripts findable of
> ghns/kdelook and installable with kpackage)

I'll give scripted plugins some thought.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: RFC: split platformtheme plugin from frameworkintegration and move to kde/workspace

[Aleix Pol]

On Mon, Dec 7, 2015 at 1:09 PM, Martin Graesslin  wrote:
> Hi all,
>
> based on the discussion in [1] I propose that we split out platformtheme
> plugin from frameworkintegration into a dedicated repository and move it to
> kde/workspace to be released together with Plasma 5.6.
>
> The main reasoning is that this plugin only gets loaded with env variables set
> in startkde anyway, which makes it a Plasma (Desktop) specific plugin. It's
> about integrating Qt application into Plasma and by that pretty useless for
> anything outside Plasma. Moving it to Plasma has in my opinion some advantages
> as we can better synchronize the release cycle and also allow us to depend on
> libraries provided by workspace [2].
>
> I'd like to get some feedback on the proposal and if this gets positive
> feedback, I'll look into performing the split.
>
> Best Regards
> Martin Gräßlin
>
> [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2015-November/
> 029022.html
> [2]  e.g. I need a dependency to KWayland, which is currently not yet possible
> due to KWayland not yet being moved to frameworks.

+1 I think it's a good idea.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [kde-community] Sprint: Reorganize the wikis

[Aleix Pol]

On Wed, Dec 9, 2015 at 9:40 PM, Olivier Churlaud  wrote:
> So joining in CERN would be easier.
>
> I have several small questions:
>
> - In https://sprints.kde.org/sprint/participate what should we check?
> WikiToLearn?
>
> - Could you tell us where we should arrive? I found this link:
> http://home.cern/directions
>
> - How much would cost the accommodation?
>
> Then if everything is fine, I'll send a clear informative message on the 3
> ML to give the details and I'll post the info on planetkde.
>
> Looking forward for the confirmations
>
> Cheers,
> Olivier
>
> Le 09/12/2015 19:45, Riccardo Iaconelli a écrit :
>>
>> On Monday, December 07, 2015 01:11:22 PM Olivier Churlaud wrote:
>>>
>>> So should I create a doodle? Or open a forum and put the link here? And
>>> how do we organize the discussion ahead to plan everything? Forum or ML?
>>>
>>> How much time ahead should it be prepared? I mean: what is reasonable
>>> for a sprint time? I'm currently in Berlin, and I know that a lot of
>>> contributors are there, so why not? However if we can join the people in
>>> CERN, it's great too (even better :D).
>>
>> Hi!
>> as organizer of the sprint you're mentioning, I am stepping in and joining
>> the
>> conversation! :-)
>>
>> Since you're talking of wikis, of course we'd be glad to have you with us!
>> We
>> can also add WikiToLearn to the discussion, to figure out e.g. wheteher
>> the
>> KDE book should be hosted there (IMHO, yes). Just make sure to book your
>> presence soon, so we can do the hostel booking.
>>
>> Now, just out of curiosity, what particle accelerator are you working at?
>>
>> Bye,
>> -Riccardo

We need to first request the budget and have the Board to approve it,
but KDE eV sponsors sprints both the trip and hosting.

Aleix

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

Re: Purpose as a KDE Framework

[Aleix Pol]

On Mon, Dec 7, 2015 at 12:49 PM, Marco Martin <notm...@gmail.com> wrote:
> On Thursday 03 December 2015, Aleix Pol wrote:
>> > but i don't think scripted plugins can be added as an aftertought as the
>> > structure of the framework may be influenced by that (yeah, i know,
>> > dependencies, but my wet dream is to have those sharing scripts findable
>> > of ghns/kdelook and installable with kpackage)
>>
>> I'll give scripted plugins some thought.
>>
>
> my suggestion is to try that before making it a framework, in case
> incompatible changes would be needed

I introduced scripted plugins support in master and a Twitter plugin
implemented in nodejs.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Draft split for qpt plugin from frameworkintegration

[Aleix Pol]

On Wed, Dec 16, 2015 at 4:12 PM, Martin Graesslin  wrote:
> Hi all,
>
> following up on [1] I have prepared a split of frameworkintegration to move
> the QPT plugin into a dedicated repository. You can find it in [2]. Please 
> have
> a look at the split repo to verify that it looks fine. If everything is OK,
> I'll request a new repo from sysadmins.
>
> Some general notes
> * new repo name: plasma-integration
> * new plugin name: PlasmaDesktopPlatformTheme
> * new src folder name: src/plasma-desktop-platformtheme
>
> Explaining the name changes:
> The plugin is renamed to not conflict on install with the existing plugin from
> frameworkintegration and also incorporating future changes Marco pointed out:
> we need a different QPT plugin for mobile.
>
> How to remove the plugin from frameworkintegration:
> After the split we cannot remove it from frameworkintegration yet as that
> would break setups on the next framework release. Given that I plan to only
> phase it out: Introduce a cmake option to build and install it, which defaults
> to true till at least Plasma 5.6 is released. Afterward swapping the default
> to false, with a big fat warning and keeping it like that for at least half a
> year. Then remove it. We don't provide any guarantees for it, so we can remove
> it, but I want to keep the impact small.
>
> Cheers
> Martin
>
> [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2015-December/
> 029234.html
> [2] kde:scratch/graesslin/platform-integration (https://quickgit.kde.org/?
> p=scratch%2Fgraesslin%2Fplasma-integration.git )

I have my doubts that we want a different QPT for desktop and mobile.
If we want to provide any convergence we need to strive to have the
same on both platforms.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Purpose as a KDE Framework

[Aleix Pol]

On Tue, Dec 8, 2015 at 8:07 PM, Alex Merry <alex.me...@kde.org> wrote:
> On 2015-12-03 18:29, Aleix Pol wrote:
>>
>> On Wed, Dec 2, 2015 at 11:56 PM, Mark Gaiser <mark...@gmail.com> wrote:
>>>
>>> I'm trying to understand what Purpose is doing exactly.
>>> I've read the readme file, but i still can't quite figure out what it's
>>> doing or where i might be able to use it.
>>>
>>> Could you give a short summary with a clear example where to use it? That
>>> would help me :)
>>
>>
>> Well, the shortcut to explaining it is that it's quite similar to
>> Android intents.
>>
>> The idea is that you identify some tasks you can group, for example:
>> - share, where you can get the different services to share
>> - getImage that would list your scanner, camera and also some web
>> services.
>> - addContact that would let you add a contact on your address book or
>> gmail directly.
>>
>> Then you receive the results in a nice and simple tuple. The input and
>> output arguments depend on the kind of task you are performing.
>
>
> Could you integrate this into your README.md? I had the same issue as Mark,
> and the examples really help.
>
> Alex

I did so, HTH.
https://github.com/KDE/purpose/blob/master/README.md

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KHolidays as Framework (redux)

[Aleix Pol]

On Thu, Dec 24, 2015 at 1:28 PM, John Layt  wrote:
> Hi,
>
> It's xmas holidays, so it must be time to poke a stick at KHolidays again
> for inclusion as a Framework. As far as I am aware there are no outstanding
> porting issues with KHolidays and it is ready for review to be included as a
> Tier 1 Framework in the next possible release. What's the next step? Move to
> kdereview?
>
> There is the one issue with increasing the .so number to 6 that has been
> raised for all the former kdepimlibs, what was the general consensus about
> that?

What should be happening now is that the library should be renamed to
libKF5Holidays.so and we would get the number we want.

kdereview isn't required as it's already part of the KDE released software.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

kdesrc-build and include-dependencies

[Aleix Pol]

Hello,
I've been testing kde-src-builder on a bare system (actually a docker
image) and I realized that --include-dependencies isn't doing what I
expected [1], which is to actually build and install the repository's
dependencies.

Can anybody point me out what am I missing? :/

That's my configuration file, so far: [2].

Thanks in advance!
Aleix

[1] $ ./kdesrc-build/kdesrc-build --include-dependencies kcompletion
* There do not seem to be any modules to build in your configuration.
Updating kde-build-metadata (to branch master)
* Downloading projects.kde.org project database...

Building kcompletion from guessed_from_cmdline (1/1)
   Updating kcompletion (to branch master)
   No source update, but the last configure failed
   Source update complete for kcompletion: no files affected
   Preparing build system for kcompletion.
   Removing files in build directory for kcompletion
   Old build system cleaned, starting new build system.
   Running cmake...
   Unable to configure kcompletion with CMake!
   Unable to configure kcompletion with KDE

[2] $ cat .kdesrc-buildrc
global
   branch-group kf5-qt5
   kdedir ~/kde-5
   qtdir /usr
   source-dir ~/kdesrc
   include-dependencies true
end global

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

Re: kdesrc-build and include-dependencies

[Aleix Pol]

On Thu, Dec 24, 2015 at 10:57 PM, Michael Pyne  wrote:
> On Thu, December 24, 2015 00:11:10 Michael Pyne wrote:
>> I'll be working over the next few days to try to expand out --include-
>> dependencies to include any possible kde-projects modules (how it was
>> originally intended to work), but until then hopefully this help.
>
> This /should/ now work. I still need to try to optimize it a bit (each missing
> module results in re-parsing the XML for kde_projects.xml at this point...)
> but now kdesrc-build should reach for any dependency expressible in kde-build-
> metadata (though, these are only KDE git modules).
>
> Regards,
>  - Michael Pyne

Hi Michael!
Thanks a lot for looking into it! :D

Aleix

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

Policy regarding QtWebKit and QtScript

[Aleix Pol]

Hi,
Soon Qt 5.6 will be released and with it, 2 quite widely used
frameworks will disappear: QtWebKit and QtScript. Also QtQuick 1, but
I think this is much less of a problem.

I'd say we need a plan to figure out what to do with these
dependencies. I don't think assuming that they will stay around is
very wise, so I'd suggest to come up collectively or specifically on
each project how to deal with those.

I'd say it's especially pressing on KDE Frameworks where Qt5::Script
is still quite widely used (kio, ki18n, ktexteditor,
plasma-framework).

Aleix

Re: [Development] setting default widgetStyle (and ColorScheme)

[Aleix Pol]

On Sat, Nov 28, 2015 at 3:07 AM, René JV Bertin  wrote:
>
>
> On 28 Nov 2015, at 01:07, Olivier Goffart  wrote:
>
>>>
>>> A pure KF5 system will not have ~/.kde*/share/config/kdeglobals, correct?
>>
>> That code was written for integrating into KDE 4.
>> It was not adapted to work with Plasma 5.
>>
>> A pure KF5 appliation would anyway use the KDE platform theme plugin provided
>> by KDE Frameworks.  (in frameworkintegration)
>> (So in other words: that code should not be executed when kde frameworks is
>> installed, in theory)
>
> In fact, my observations probably imply that the code *is* called when 
> running "pure Qt5" apps under X11 (it is with the xcb plugin on OS X; I 
> checked). If indeed so, I think it should be updated to comply with KF5 
> principles if KDE_SESSION_VERSION = 5 (and use the KDE4 config as a 
> fallback). No?

No, it's not run when the frameworksintegration QPlatformTheme plugin
is loaded. If it was, it would be a bug.

Aleix

PS: René, cross-posting is bad. Let's bring the issues up in the
correct channels. If it was a bug in Qt, a bug report would have been
more appropriate.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Scope of framework integration plugin?

[Aleix Pol]

On Mon, Nov 30, 2015 at 12:48 PM, Martin Graesslin  wrote:
> Hi all,
>
> there is currently a review request to add OSX specific changes to framework
> integration plugin [1].
>
> This seems wrong to me. I think our framework integration plugin is about
> integration Qt applications into the Plasma workspace. In my opinion it should
> not be used anywhere else. Not on GNOME, not on Windows and not on OSX. The
> idea of integration is that applications look native on the desired platform.
> The plugin defines the native look on Plasma and by that using it on other
> platforms is automatically breaking the integration.
>
> Now I understand that some people don't like the native look of their platform
> and would prefer using Plasma. Sorry I don't have an answer to that.
> Unfortunately I think it's completely out of scope for the integration
> platform to be considered outside Plasma.
>
> Given that: if people agree with my view that the framework integration is
> only about Plasma, I suggest that we move the framework integration to kde/
> workspace to release it together with Plasma instead of frameworks.
>
> Opinions?

Hi,
I agree with you, I've proposed the same thing as you in the past,
although there's some issues that would then need to be sorted.

What you actually want is, IMHO, to move the QPlatformTheme plugin
together with Plasma, but frameworksintegration is not entirely about
that nowadays: it has code that integrates different frameworks with
each other:
- FrameworkIntegrationPlugin: this doesn't really belong in plasma,
integrates KMessageBox with KNotifications.
- infopage: this is used by applications as well as plasma
- KStyle: Plasma can provide styles, but this seems more like a QStyle
creation framework.
- platformtheme: Plasma integration. There I agree.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Scope of framework integration plugin?

[Aleix Pol]

On Mon, Nov 30, 2015 at 2:24 PM, René J. V.  wrote:
> Boudewijn Rempt wrote:
>
>> Sort of related question... Is this also the module that picks up the font
>
> Not sort of related: I think you're spot-on. (These settings are probably moot
> on OS X, btw.)
>
>> hinting settings and applies it to KDE applications? I setup a gnome-only dev
>> env to see what Krita 3 looks like on that platform, without any kde
>> integration available, and I noticed that Qt 5.6 doesn't seem to pick up the
>> Gnome font hinting settings.
>
> Qt 5.5 does try to pick up settings in qgenericunixtheme, but hasn't been
> updated to include the new paths where those settings are stored by KF5. That
> may be related to what you're seeing.

Correct, but the fix isn't to make Qt look in the KF5 paths. Qt should
be fixed to fetch the settings wherever gnome puts them, so that the
sizes are the same.

IOW, we shouldn't expect users to open "kcmshell5 fonts" to set the
font size of KDE applications on Gnome.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Purpose as a KDE Framework

[Aleix Pol]

On Tue, Dec 1, 2015 at 4:24 PM, Kai Uwe Broulik  wrote:
>> you can build any view you want on top of it and the API is
> public and (should be) stable.
>
> Yes but some services require additional information and provide a QML UI for 
> that.‎ And that one will look out of place if using Plasma Components and 
> used in a widget environment, or limited to basic styling when using QQC. 
> Making some constraints on how they're supposed to be presented could help, 
> which is where the system-wide Plasma UI it would invoke comes to mind. Not 
> sure how feasible that it, though. Just food for thought.

Ah, true.

For the UI the plugins can provide, the plan is they should provide
QQC-based code (or bare QtQuick for that matter), but we can hardly
limit what the plugin uses.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Purpose as a KDE Framework

[Aleix Pol]

On Tue, Dec 1, 2015 at 4:01 PM, Boudhayan Gupta <bgu...@kde.org> wrote:
> On 1 December 2015 at 19:31, Aleix Pol <aleix...@kde.org> wrote:
>> Hi,
>> I've been working on Purpose since some months now, with the intention
>> of becoming a framework some day.
>
> +1. I intend to port Spectacle to use it instead of KIPI for uploading
> images to online sites, and I love the API's simplicity.
>
> I only have two concerns:
>
> 1. I'd like to be able to load the list of plugins available per
> mimetype a priori before the filename to share becomes available.
You can pass { "mimetype": "image/png", "urls": [] }.

That should work.
I'm not sure why you'd want to list plugins before having anything to
share though...

>
> 2. I'd also like some feature to load the plugins in some parallel
> thread or something. Currently KIPI has about 30 plugins and it blocks
> the GUI thread for 5-6 seconds while it loads them. I'd want to avoid
> that when the plugins grow.

That's not a problem for Purpose because by design it doesn't load the
plugins. Plugins are loaded when they're chosen.
This means we need to be able to figure out if a plugin is acceptable
by its metadata.

>
> Otherwise, looking forward to seeing it as a Framework! Splitting the
> plugins into a separate package (purpose-plugins) as Martin said
> sounds like a snazzy idea as well.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Purpose as a KDE Framework

[Aleix Pol]

On Tue, Dec 1, 2015 at 3:31 PM, Martin Graesslin <mgraess...@kde.org> wrote:
> On Tuesday, December 1, 2015 3:01:10 PM CET Aleix Pol wrote:
>> Hi,
>> I've been working on Purpose since some months now, with the intention
>> of becoming a framework some day. Some information about it can be
>> read here:
>> https://projects.kde.org/projects/playground/libs/purpose/repository/revisio
>> ns/master/entry/README.md
>>
>> As it is right now it's a tier 2 framework (kcoreaddons and ki18n)
>> plus the plugins. Plugins raise the tier to 3 because of KIO which is
>> used by some plugins.
>
> do plugins have to be inside the framework? Otherwise an option might be to
> split out the plugins and move them to frameworkintegration?

That could work. I'm not too sure how awesome that would be though...

>
>>
>> As it is now, it's being used by: Kamoso, QuickShare plasmoid and
>> KDevelop for patch sharing. I'd like to see it used in other cases
>> than sharing as well as in other applications, but here's where we are
>> at the moment. I think it's something to build upon.
>
> having started using QuickShare with it a few days ago when I learned that it
> just needs pupose to be installed: all for it!

:D

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Purpose as a KDE Framework

[Aleix Pol]

Hi,
I've been working on Purpose since some months now, with the intention
of becoming a framework some day. Some information about it can be
read here:
https://projects.kde.org/projects/playground/libs/purpose/repository/revisions/master/entry/README.md

As it is right now it's a tier 2 framework (kcoreaddons and ki18n)
plus the plugins. Plugins raise the tier to 3 because of KIO which is
used by some plugins.

As it is now, it's being used by: Kamoso, QuickShare plasmoid and
KDevelop for patch sharing. I'd like to see it used in other cases
than sharing as well as in other applications, but here's where we are
at the moment. I think it's something to build upon.

Any thoughts?

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[Aleix Pol]

On Wed, Nov 18, 2015 at 12:33 PM, René J. V.  wrote:
> Actually, there is one thing I may have missed in the documentation, if it's
> there:
>
> Is KIdleTime supposed to detect system idling, or application idling? As it
> happens, it should be possible to make a distinction between the two with the
> latest implementation I made.
>
> As to using an agent to centralise all polling: I think that agent would 
> either
> have to use poll timer with a sufficiently short interval to serve all 
> clients,
> or use a poll timer per current client. Evidently the latter option cancels 
> any
> benefit of moving to an agent-based architecture (leaving only the IPC
> overhead), while the former will lead to worse overhead than what my current
> implementation allows.
> That current implementation is not expensive in its default configuration (and
> that configuration is currently decided at build time), but I think that good
> programming practice would call anyway for deactivating any KIdleTime 
> instances
> when they are not in use, regardless of whether they're based on alarms or on
> polling.
>
> I have no idea how many applications will be using this framework concurrently
> at any given time, but it seems reasonable to expect that there will be less
> than on a system running a KF5 plasma desktop. I see it's used in Baloo, for
> instance, but that framework has dropped support for OS X.
>
> There's also always the possibility to reconsider implementing an Xcb-style
> alarm based mechanism that relies on a helper process, if it turns out in the
> future that KIdleTime/Mac is causing significant amounts of overhead. But
> KIdleTime has changed only minimally from KDE4 to KF5, and it is certainly not
> the case that it has led to any observable amount of continuous overhead until
> now.
>
> R

After a quick search, here's some relevant documentation by Apple:
https://developer.apple.com/library/mac/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/

They suggest you going "App Nap" as soon as possible. Polling from a
framework would ensure this doesn't really happen.

Here's an approach that could maybe inspire you somehow:
http://stackoverflow.com/questions/1419531/mac-screensaver-start-event

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Please review Snorenotify (Finish Incubating)

[Aleix Pol]

On Wed, Nov 18, 2015 at 11:48 PM, Hannah von Reth  wrote:
> Hi there,
>
> Mario guided me until now through the incubation process and we think it is
> time to move Snorenotify from playground to extragear.
> Snorenotify is a notification framework supporting Linux, Windows and Mac
> OSX.
> It is not meant to replace Knotifications, it is more targeted on Qt
> applications without dependency to the plasma desktop, so it might become a
> backend for Knotifications.
>
> I guess you can find the most important information here
> https://community.kde.org/Incubator/Projects/Snorenotify.
>
> Besides Snorenotify there is also Snoretoast, a sub project of Snorenotify,
> https://quickgit.kde.org/?p=snoretoast.git.
> Snoretoast  is a command line application and used within Snorenotify for
> the Windows Toast notifications.
> The application can only be build using the Microsoft compiler.
>
> So it would be great if Snorenotify could become a official KDE library and
> maybe even a framework someday.
> Currently it is used by Quassel and Tomahawk but hopefully more will start
> to use it soon.
>
> So please review Snorenotify.
>
> If you find the idea of Snorenotify useful or you fancy notifications, like
> I do, feel free to contribute ;)  or start to use Snorenotify.

Hi Hannah,
I'm happy that you're decided to push this forward, I think it's a
framework that could be definitely useful. In KDE Connect we'd like to
be able to use it instead of KNotifications because it's leaner and
more straightforward to our notifications use-case. As I said before,
I already ported KDE Connect to use snore, nevertheless there's some
issues like the API that I would suggest to review before committing
to API and ABI stability.

Here's some thoughts:
- It feels overly complex that the Notification object is passed
around by value rather than by reference. For starters, being able to
connect to the notification would be very handy. I work-arounded it by
setting a hint with the relevant information, but I have the feeling
the API would be slightly smoother.
- There's a hard dependency on QtWidgets from the very core of the
framework. This requires applications that would use it to use
QApplication. In the case of KDE Connect, for instance, the plan was
to make it possible to have it in a QCoreApplication (or
QGuiApplication at least). It's a daemon from which we consider that
it's acceptable to show notifications but we don't really plan to open
a dialog from there. Do you think it could/should be worked out?
- There's a daemon. We're kind of trying to get rid of daemons. When
is it needed?
- enum values are all-caps joined by underscore (e.g. GLOBAL_SETTING).
Camel-case would be more Qt-friendly.
- Some methods use wid as a windows id. Please use QWindow whenever
possible, it's being an issue in Plasma nowadays already.
- Maybe we can port the internal logging infrastructure to just use
QLoggingCategory?

Cheers! :)
Aleix

Re: Projects using the plasma-framework for inspiration

[Aleix Pol]

On Sat, Nov 21, 2015 at 5:36 PM, Olivier Churlaud  wrote:
> Hi,
>
> I'm porting Amarok to KF5. I'm basically done with the pure C++/Qt part.
> There is a folder that used to be powered by Plasma::Applet [1]. I have now
> to port this to plasma-framework. Could you redirect me to a project which
> use them so that it can inspire me? I have no idea of how to begin

You can look at plasma-workspace/shell. Note that most Plasmoids are
written in QML nowadays, rather than C++.

Aleix

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

Re: kdeinit5 on OS X

[Aleix Pol]

On Mon, Nov 23, 2015 at 1:29 PM, René J.V.  wrote:
> Hi,
>
> Preparing a MacPorts port for kf5-kinit, I see the following in kdeinit's 
> CMake file:
>
> add_executable(kdeinit5 ${kdeinit_SRCS})
> if (APPLE)
>   # this has to be GUI on OSX because it launches GUI apps and need a quartz 
> context
>   set_target_properties(kdeinit5 PROPERTIES MACOSX_BUNDLE_INFO_PLIST 
> ${CMAKE_CURRENT_SOURCE_DIR}/Info.plist.template)
>   set_target_properties(kdeinit5 PROPERTIES MACOSX_BUNDLE_GUI_IDENTIFIER 
> "org.kde.kdeinit5")
>   set_target_properties(kdeinit5 PROPERTIES MACOSX_BUNDLE_BUNDLE_NAME "KDE 
> Init")
> else ()
>   ecm_mark_nongui_executable(kdeinit5)
> endif ()
>
>
> Has that been verified? AFAIK, the only thing mark_nongui_exec does on OS X 
> is to build the application as a regular executable, instead of as an app 
> bundle. And also AFAIK, this makes no difference on what the resulting 
> application can do.
>
> Hence my question: has anyone verified whether the app bundle nature is 
> required? Kdeinit4 was built like that, and as a result wasn't found by the 
> library function (KToolInvocation::startKdeinit()) that is supposed to start 
> things like klauncher through kdeinit4. I see the KF5 version uses 
> QSP::findExecutable(), and its documentation is mute about whether that 
> function is able to find a BundleExec on OS X.
>
> If not: what possibilities do I have to verify this myself when I am only 
> just at the point where I could build and install kf5-kinit itself? (I see a 
> lot of leftover Q_OS_MAC tokens, suggesting the code hasn't been verified 
> beyond whether it builds.)
>
> NB: if kdeinit5 indeed has to be built as an app bundle its executable isn't 
> found because of that a wrapper script might be required, like the one I 
> wrote for KDE4:
>
> #!/bin/sh
>
> if [ "${TERM}" != "" ] ;then
>  # launched from a terminal session; do not use LaunchServices:
>  exec @KDEAPPDIR@/kdeinit5.app/Contents/MacOS/kdeinit5 "$@"
> else
>  exec open -W -a @KDEAPPDIR@/kdeinit5.app --args "$@"
> fi

I also don't see why you'd want kdeinit in a bundle. But then I'm not
very knowledgeable about OS X. Maybe ask kde-...@kde.org?

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Failure while executing KTar::open while using KCompressionDevice as the device

[Aleix Pol]

On Mon, Nov 23, 2015 at 4:54 PM, Luiz Romário Santana Rios
 wrote:
> 2015-11-02 14:53 GMT-03:00 Luiz Romário Santana Rios :
>> Hello,
>>
>> I'm trying to decompress a XZ archive downloaded using
>> QNetworkAccessManager, so, according to the documents, I have to pass
>> the QNetworkReply pointer to a KCompressionDevice and, then, use it as
>> Ktar's device like this:
>>
>> https://gist.github.com/anonymous/b8fb686367f518a7dbb5
>>
>> The problem is that KTar::open() fails and returns false. The file I'm
>> trying to extract has the following structure more or less:
>> /root
>> /root/dir
>> /root/dir/file1
>> /root/dir/file2
>> ...
>>
>> So, as far as I've seen, the code runs normally when entering /root
>> and /root/dir, but, pretty high in the stack, at
>> KXzFilter::uncompress(), the call to lzma_code returns
>> LZMA_FORMAT_ERROR while trying to uncompress file1 (or file2, I'm not
>> sure). Here's the call stack:
>>
>> https://gist.github.com/anonymous/9ea380cfe48daadb5971
>>
>> Is this a bug? If it's a bug, how can I proceed to fix it?
>>
>> Thanks for the attention.
>>
>> --
>> Luiz Romário Santana Rios
>
> After some discussion in a review request
> (https://git.reviewboard.kde.org/r/125974/), I found out that the
> problem is that QNetworkReply is a sequential device. This, as I
> understand it, is only a problem because KCompressionDevice is able to
> open any file it wants in any sequence; after all, tars are
> serializable, which means there's no need to seek back to extract a
> stream of data. Knowing that, I can think of two solutions:
>
> - Make KCompressionDevice check if the device it is receiving is
> sequential. If it is, remove the ability to open any file and just
> ensure KTar::copyTo() works properly.
> - Check if the device passed to KCompressionDevice is sequential and
> make it invalid if it is; create a new KSequentialCompressionDevice
> class which only extracts the data from a sequential QIODevice and
> does not have the ability to extract individual files in any order
> like KCompressionDevice.
>
> In short: either limit the functionalities of KCompressionDevice if
> the device is sequential or forbid sequential devs in
> KCompressionDevice and create a new class to handle them. If
> KCompressionDevice relies too much on the device being sequential, the
> second option is the way to go.
>
> What do you think?

I don't think you want to do something like:
if (dev->isSequiential()) {
   new KCopyCompressionDevice;
   //do stuff
} else {
   new KCompressionDevice;
   //do essentially the same stuff
}

We aren't adding any semantics by offering a new class. I'd say that
KCompressionDevice should either take it all or just assert on
isSequential and expect the users to actually implement it on the app
side.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Jenkins-kde-ci: ki18n master kf5-qt5 » Linux,gcc - Build # 25 - Still Unstable!

[Aleix Pol]

On Mon, Nov 23, 2015 at 4:38 PM,   wrote:
>
> GENERAL INFO
>
> BUILD UNSTABLE
> Build URL: 
> https://build.kde.org/job/ki18n%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/25/
> Project: PLATFORM=Linux,compiler=gcc
> Date of build: Mon, 23 Nov 2015 15:26:55 +
> Build duration: 1 min 27 sec
>
> CHANGE SET
> Revision 8688c200d099ac4474d4151d32e29dbcb76e71f4 by aleixpol: (Fix @since 
> statement in the documentation)
>   change: edit src/klocalizedcontext.h
>
>
> JUNIT RESULTS
>
> Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 
> 4 test(s)Failed: TestSuite.ki18n-declarativetest
>
> COBERTURA RESULTS
>
> Cobertura Coverage Report
>   PACKAGES 2/2 (100%)FILES 15/19 (79%)CLASSES 15/19 (79%)LINE 1756/2949 
> (60%)CONDITIONAL 850/1338 (64%)
>
> By packages
>
> autotests
> FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 373/442 
> (84%)CONDITIONAL 163/324 (50%)
> src
> FILES 8/12 (67%)CLASSES 8/12 (67%)LINE 1383/2507 
> (55%)CONDITIONAL 687/1014 (68%)
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>

Hi,
I cannot reproduce this issue. Would it be possible to get a backtrace
to figure something out?

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIOGui ?

[Aleix Pol]

On Wed, Jan 13, 2016 at 12:33 AM, David Faure  wrote:
> I'm about to write a class to handle favicons in a KIO library, rather than 
> using DBus
> communication to a (currently kded, could be kiod otherwise) module.
>
> I think there just isn't any point in using a central DBus module to handle a 
> shared cache
> when a lock file can do the job.
>
> The question is: this would only depend on KIOCore and QImage. Shall I put it 
> in KIOWidgets
> or shall I create a new KIOGui library, for QML apps to avoid the QWidget 
> dependency ?

IMHO, being able to stay away from QtWidget is a good things, even
though we haven't really managed on many projects so far because
QStyle. I would like to see KIOGui happening, although I'm afraid it's
not really possible to move most stuff from KF5 right now (or maybe
there's a possibility).

TLDR;
I'd like to see it happening, it would be interesting to see if there
were more things in there.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KApiDox Maintainship

[Aleix Pol]

On Tue, Jun 7, 2016 at 7:28 AM, Olivier Churlaud  wrote:
> Hi,
>
>  I did a lot of work on KApiDox the last weeks, and I have still a lot in
> mind to improve it. I spoke with Alex about the maintainship of KApidox as
> he doesn't have currently time to spend on it. He told me he was ok to pass
> me the maintainship.
>
>  I don't know how this work, so I would like some explanations about what
> being the maintainer means, what are the responsibilities and constrains,
> and of course, after I'll know that, if it's ok that I change the Alex's
> name with mine for Kapidox maintainer.

+1

Thanks Olivier! KApiDox does need that love!
And thanks Alex for the work so far! :)

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: qmlplugindump org.kde.kquickcontrolsaddons 2.0 dysfunctional

[Aleix Pol]

On Wed, Jun 15, 2016 at 12:32 PM, René J.V.  wrote:
> Hi,
>
> Building the latest Purpose git/master I just discovered this (applies to OS 
> X and Linux):
>
> %> /opt/local/libexec/qt5/bin/qmlplugindump org.kde.kquickcontrolsaddons 2.0
> QObject: Cannot create children for a parent that is in a different thread.
> (Parent is QGuiApplication(0x7ffdd69c20c0), parent's thread is 
> QThread(0x258f260), current thread is QThread(0x259a9e0)
> QObject: Cannot create children for a parent that is in a different thread.
> (Parent is QGuiApplication(0x7ffdd69c20c0), parent's thread is 
> QThread(0x258f260), current thread is QThread(0x259a9e0)
> QObject: Cannot create children for a parent that is in a different thread.
> (Parent is QGuiApplication(0x7ffdd69c20c0), parent's thread is 
> QThread(0x258f260), current thread is QThread(0x259a9e0)
> QWidget: Cannot create a QWidget without QApplication
> Abort (core dumped)
>
> which results from doing `qmlplugindump org.kde.kquickcontrolsaddons 2.0` in 
> a CMake file.
>
> Does this mean something is wrong on my system, or is this because I'm still 
> using the 5.22.0 frameworks?
>
> Cheers,
> R.

That happens because we're randomly using QWidgets code within
KDeclarative. There's not much else we can do until that's fixed,
except for passing -noinstantiate.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: QGlobalStatic and windowing specific calls in dtor

[Aleix Pol]

On Mon, May 30, 2016 at 4:25 PM, Martin Graesslin  wrote:
> Hi frameworks-dev,
>
> I have a problem with my KWayland based plugin for KIdleTime. KIdleTime uses a
> QGlobalStatic, so it gets destroyed at exit-time. At that point the
> QGuiApplication and the qpa plugin does not exist any more, so any windowing
> system specific calls will fail.
>
> In the case of the KWayland based plugin, KWayland performs cleanup calls
> which crash as the wayland connection got already destroyed. In principle the
> same could also happen for the other plugins - they just don't perform any
> cleanup and prefer to leak X resources.
>
> So what's the best way to handle such a situation? How can I tear-down the
> plugin in a clean way without crashing?

It should clean up when aboutToQuit is emitted.
http://doc.qt.io/qt-5/qcoreapplication.html#aboutToQuit

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: LGPL for Breeze QStyle and qtquickcontrols?

[Aleix Pol]

On Mon, May 23, 2016 at 9:38 AM, Martin Graesslin  wrote:
> On Sunday, May 22, 2016 12:22:28 AM CEST Jaroslaw Staniek wrote:
>> So we, in KDE, lack LGPL style code for our de-facto official look and feel.
>
> This is the crucial point. Breeze is not the de-facto official look and feel 
> of
> KDE. It's the look and feel of Plasma.

Let's stop there, please. I know where you come from, but here we're
being unhelpful for little reason. The fact that Plasma uses Breeze
doesn't mean that it's Plasma's property. In fact, it's how QtQuick is
shaping up to work for us, shunning Breeze for non-Plasma KDE
applications puts several projects in jeopardy.

We need to decide what we want before assuming everything is set.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: qmlplugindump org.kde.kquickcontrolsaddons 2.0 dysfunctional

[Aleix Pol]

On Wed, Jun 15, 2016 at 3:37 PM, René J.V. <rjvber...@gmail.com> wrote:
> On Wednesday June 15 2016 14:42:54 Aleix Pol wrote:
>
>>That happens because we're randomly using QWidgets code within
>>KDeclarative. There's not much else we can do until that's fixed,
>>except for passing -noinstantiate.
>
> Is there something against using that option? Or else simply do a 
> non-required find_package(KF5Declarative)?
>
> R

Fix pushed.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Adding Android Platform Availability to Frameworks

[Aleix Pol]

On Thu, Jun 16, 2016 at 3:47 PM, Andreas Cord-Landwehr
 wrote:
> Hi, after the recent preparations, finally I would like to get permission to
> add the line " - name: Android" to the platforms section in the metainfo.yaml
> files of the following frameworks:
>
> attica
> kapidox
> karchive
> kcodecs
> kconfig
> kcoreaddons
> kguiaddons
> ki18n
> kimageformats
> kitemmodels
> kitemviews
> kplotting
> kwidgetsaddons
> kcompletion
> kunitconversion
>
> Build is tested for all of them in my Android Builder Docker image (which soon
> will be on the CI). Unit tests hopefully will also be there soon. Besides
> these frameworks, are a couple of more frameworks, for which I need to have a
> deeper look at if they really will work. For those, I will fill individual 
> RRs.
>
> Question: Do I get permission to add the Android platform entry to the above
> named frameworks?

I'm quite impressed! Do the tests also pass? :)

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reporting bugs to frameworks

[Aleix Pol]

Hi,
I've recently found a bug in kded. I've been trying to report it but
didn't manage to find it on the list [1].

What did I miss?

Aleix

[1] https://bugs.kde.org/enter_bug.cgi?format=guided
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Deadlock in kded whith Qt 5.6

[Aleix Pol]

On Fri, Jan 15, 2016 at 1:02 PM, Aleix Pol <aleix...@kde.org> wrote:
> Hi,
> I realized earlier last week that some of my applications were
> freezing, it turns out it's because my kded is freezing and any dbus
> calls there need to time out (they take 30s to time out btw).
>
> Anyway, here's the backtrace: https://paste.kde.org/pajbfmoh8
>
> I saw David did something in that direction earlier but I couldn't
> spot exactly where's the problem, so I decided to report it here,
> hoping he'd know what's going on. :D
>
> Thanks!!
>
> Aleix

Now that I know how to report a bug to kded5, I reported it. Here it
is, for completion:
https://bugs.kde.org/show_bug.cgi?id=358017

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Reporting bugs to frameworks

[Aleix Pol]

On Fri, Jan 15, 2016 at 1:39 PM, Christoph Feck <cf...@kde.org> wrote:
> On Friday 15 January 2016 12:55:47 Aleix Pol wrote:
>> Hi,
>> I've recently found a bug in kded. I've been trying to report it
>> but didn't manage to find it on the list [1].
>>
>> What did I miss?
>
> frameworks-kdaemon

Wow, I would never have guessed that! ^^'

Fair enough then, thanks Christoph!!
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Deadlock in kded whith Qt 5.6

[Aleix Pol]

Hi,
I realized earlier last week that some of my applications were
freezing, it turns out it's because my kded is freezing and any dbus
calls there need to time out (they take 30s to time out btw).

Anyway, here's the backtrace: https://paste.kde.org/pajbfmoh8

I saw David did something in that direction earlier but I couldn't
spot exactly where's the problem, so I decided to report it here,
hoping he'd know what's going on. :D

Thanks!!

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Making polkit-qt-1 a tier1 framework

[Aleix Pol]

On Thu, Jan 14, 2016 at 1:20 PM, Martin Gräßlin  wrote:
> Hi all,
>
> I want to suggest to move polkit-qt-1 [1] from kdesupport to frameworks.
> Reasons are:
>
> * kdesupport is basically what became tier1 in frameworks
> * it's used by other frameworks, e.g. KAuth (tier 2) and in kde/workspace
> * polkit-qt-1 is currently in a not really released state (last release in
> 2014, quite a few bugfixes around)
>
> By moving it to frameworks we get closer to getting rid of kdesupport and
> get the making releases problem solved once and for all: bug fixes will get
> to users in a timely manner.
>
> Opinions?
>
> Cheers,
> Martin
>
> [1] git://anongit.kde.org/polkit-qt-1

+1

Have you checked it passes the KDE Frameworks checklist?
https://community.kde.org/Frameworks/Policies
https://community.kde.org/Frameworks/CreationGuidelines

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Deadlock in kded whith Qt 5.6

[Aleix Pol]

On Mon, Jan 18, 2016 at 9:23 AM, David Faure <fa...@kde.org> wrote:
> On Friday 15 January 2016 13:48:14 Aleix Pol wrote:
>> On Fri, Jan 15, 2016 at 1:02 PM, Aleix Pol <aleix...@kde.org> wrote:
>> > Hi,
>> > I realized earlier last week that some of my applications were
>> > freezing, it turns out it's because my kded is freezing and any dbus
>> > calls there need to time out (they take 30s to time out btw).
>> >
>> > Anyway, here's the backtrace: https://paste.kde.org/pajbfmoh8
>> >
>> > I saw David did something in that direction earlier but I couldn't
>> > spot exactly where's the problem, so I decided to report it here,
>> > hoping he'd know what's going on. :D
>> >
>> > Thanks!!
>> >
>> > Aleix
>>
>> Now that I know how to report a bug to kded5, I reported it. Here it
>> is, for completion:
>> https://bugs.kde.org/show_bug.cgi?id=358017
>
> Thiago: indeed the BlockingQueuedConnection call from messageFilter to the
> main thread occasionnally leads to deadlocks, we need your
> "postpone incoming messages" idea.

It's good to know there's a plan, would it maybe be possible to expand
a bit? I'd be interested in looking into it as my system is quite
unusable and I can expect other people will become soon enough.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [karchive] /: Fix CMP0063 warning (the one about CXX_VISIBILITY_PRESET).

[Aleix Pol]

On Tue, Jan 19, 2016 at 9:15 AM, David Faure  wrote:
> Git commit 3b13ef97925725b2a273a4d3e7d1c0c7e151522d by David Faure.
> Committed on 19/01/2016 at 08:14.
> Pushed by dfaure into branch 'master'.
>
> Fix CMP0063 warning (the one about CXX_VISIBILITY_PRESET).
>
> Any volunteer for doing this over all frameworks?
> CCMAIL: kde-frameworks-devel@kde.org
>
> M  +1-1CMakeLists.txt
>
> http://commits.kde.org/karchive/3b13ef97925725b2a273a4d3e7d1c0c7e151522d
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 1440f2f..deee520 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -11,7 +11,7 @@ feature_summary(WHAT REQUIRED_PACKAGES_NOT_FOUND 
> FATAL_ON_MISSING_REQUIRED_PACKA
>  set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH} ${ECM_KDE_MODULE_DIR})
>
>  include(KDEInstallDirs)
> -include(KDEFrameworkCompilerSettings)
> +include(KDEFrameworkCompilerSettings NO_POLICY_SCOPE)
>  include(KDECMakeSettings)

Hi,
I'll work on a GCI task over it. Should be easy enough.

Good call!

Aleix

PS: Actually we should get this in applications as well, right?
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Solid/PowerManagement deprecation

[Aleix Pol]

Hi,
I've been looking in the last days what applications and uses make our
software stick to KDELibs4Support.

My impression is that the big missing thing is Solid/PowerManagement.

Is anyone looking into the issue? Should we look into un-deprecating it?

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Finding kdesu binary

[Aleix Pol]

On Fri, Jan 29, 2016 at 3:33 PM, Andrius Štikonas  wrote:
> Hi,
>
> I would like to ask how do I find kdesu binary from the code (of 
> partitionmanager).
>
> PartitionManager tries to restart itself with root privileges and tries to 
> rerun itself with kdesu, kdesudo or gksu...
> However, KF5 based kdesu is now in libexec, something like
> /usr/lib64/libexec/kf5/kdesu
> but it varies from distribution to distribution and not in $PATH.
>
> Is there a way to find the location in the cross-platform way? There is 
> kf5-config --path libexec but it is from kdelibs4support
> and it's better not to depend on kdelibs4support.

If I understand correctly, you should use the KSu framework for that.
kdesu is not public API, that's why it's in libexec.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KCoreAddons qml plugins

[Aleix Pol]

On Thu, Jan 28, 2016 at 1:11 AM, David Faure <fa...@kde.org> wrote:
> On Wednesday 27 January 2016 18:19:49 Aleix Pol wrote:
>> Hi,
>> I would like to move KCoreAddons qml plugin into KCoreAddons. Now it's
>> KDeclarative where we are dumping all QML plugins.
>>
>> I think it's a good idea because:
>> - it simplifies usage  the plugins for such frameworks (kcoreaddons is
>> not the only one).
>> - it ensures the code related to a feature is together.
>> - it keeps the documentation together.
>> - we don't force unwanted dependencies [1].
>>
>> The only downside I see, is that KCoreAddons will end up depending on
>> QtQml. I think we can make it an optional if that's a problem on some
>> setups.
>
> That's a major downside. KCoreAddons is supposed to be only depend on QtCore.
>
> This is like saying the QML bindings for QtCore classes should be in QtCore
> (apart from the obvious technical impossibility).
>
> One of your reasons in favour is "we don't force unwanted dependencies",
> and your solution is to add a (very unexpected) dependency from KCoreAddons 
> to QtQml...
>
> "Making it optional" is only a half-solution. With distro packages or other 
> kinds
> of pre-compiled binaries, one ends up with a forced dependency. Using
> the plugin infrastructure from kcoreaddons, or the Job classes, to write a 
> core-only
> application (or a widget application) should not require QtQml, since such an
> app would having nothing to do with Qml.
>
> QML bindings are "one layer above" the class they bind. Just like kdebindings 
> is separate
> rather than "mixed into every framework". Having the javascript bindings for 
> KIO in KIO
> would tick all your criterias above ("simpler to use because part of the 
> framework",
> "all the kio related code together", "doc together", "no 
> kdebindings-depends-on-everything").
> And yet we don't do it. Because KIO users don't want to be forced to install 
> python.
> Similarly, many users of kcoreaddons don't want a dependency on QML.
>
> I honestly don't see the problem with having this in KDeclarative, but maybe 
> I'm missing
> a good reason for splitting such qml plugins into a separate framework. Or 
> maybe
> there's no point in doing that either.

Personally, I don't really see how QtQml build-time dependency is
holding back the adoption of KCoreAddons. Is QtQml something that
often isn't available?

Distributions might add the dependency, but they also end up splitting
the packages [1] if they consider appropriate, so this wouldn't have
an impact on the Linux-distro end-user.

As I see it, we shouldn't consider them bindings, but part of the API.
The fact that (some of them) are implemented using façade classes is
mostly a symptom that we need to learn to expose better to QML and
that Qt needs to improve (for example, in this regard I see Q_GADGET
in the right path). Furthermore, I don't really see kdebindings as a
good example, since it's always felt like a second-class citizen,
lacking in documentation and maintained by second or third parties.

From a KDE Frameworks point of view, QML is not Python. QML is part of
Qt (albeit not qtbase, I'll give you that) which is the direct
upstream of KDE Frameworks and as much as QtScript can be for KI18n
[2]. This is specially important I think, because it leverages that
the platform we're building on is already Qt-proof (but might not be
Python-proof, for that matter) [3].

I think the KIO example is a good. I think we should be open to making
it possible to use KIO on QML. I would say that if this hasn't
happened, it's because it's some API that is rather complex and Qt
might choke on it, but it's not my impression that the reason that KIO
has KF5::KIOWidgets and not a qml plugin is because we decided we
wanted one and not the other, but mere historic reasons.

The problem I see with having a big KDeclarative framework is that it
requires to have many KDE Frameworks available. The root
CMakeLists.txt file [4] already shows that it's full of conditionals
and it largely depends on whether the actual framework is available.

Aleix

[1] http://packages.ubuntu.com/search?keywords=qml
[2] 
http://api.kde.org/frameworks-api/frameworks5-apidocs/ki18n/html/ki18n-dependencies.html
[3] https://paste.kde.org/pb2jgs4aq
[4] 
https://quickgit.kde.org/?p=kdeclarative.git=blob=9c1a11c735aa5e5a2a3e99a5c15ce1e99a4e7515=CMakeLists.txt=plain
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [karchive] /: Fix CMP0063 warning (the one about CXX_VISIBILITY_PRESET).

[Aleix Pol]

On Sat, Jan 23, 2016 at 12:05 PM, David Faure <fa...@kde.org> wrote:
> On Tuesday 19 January 2016 10:11:06 Aleix Pol wrote:
>> On Tue, Jan 19, 2016 at 9:15 AM, David Faure <fa...@kde.org> wrote:
>> > Git commit 3b13ef97925725b2a273a4d3e7d1c0c7e151522d by David Faure.
>> > Committed on 19/01/2016 at 08:14.
>> > Pushed by dfaure into branch 'master'.
>> >
>> > Fix CMP0063 warning (the one about CXX_VISIBILITY_PRESET).
>> >
>> > Any volunteer for doing this over all frameworks?
>> > CCMAIL: kde-frameworks-devel@kde.org
>> >
>> > M  +1-1CMakeLists.txt
>> >
>> > http://commits.kde.org/karchive/3b13ef97925725b2a273a4d3e7d1c0c7e151522d
>> >
>> > diff --git a/CMakeLists.txt b/CMakeLists.txt
>> > index 1440f2f..deee520 100644
>> > --- a/CMakeLists.txt
>> > +++ b/CMakeLists.txt
>> > @@ -11,7 +11,7 @@ feature_summary(WHAT REQUIRED_PACKAGES_NOT_FOUND 
>> > FATAL_ON_MISSING_REQUIRED_PACKA
>> >  set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH} ${ECM_KDE_MODULE_DIR})
>> >
>> >  include(KDEInstallDirs)
>> > -include(KDEFrameworkCompilerSettings)
>> > +include(KDEFrameworkCompilerSettings NO_POLICY_SCOPE)
>> >  include(KDECMakeSettings)
>>
>> Hi,
>> I'll work on a GCI task over it. Should be easy enough.
>
> Excellent idea, thanks.
>
> Note: this should *not* lead to 70 reviewboard requests ;)
>
> If the person doing this has made sure he has no other local changes, then a 
> script is OK.
>
>> PS: Actually we should get this in applications as well, right?
>
> Yes, although the patch will be slightly different there 
> (KDECompilerSettings, not KDEFrameworkCompilerSettings).
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>

No student picked it up, so I'll do it myself.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KCoreAddons qml plugins

[Aleix Pol]

Hi,
I would like to move KCoreAddons qml plugin into KCoreAddons. Now it's
KDeclarative where we are dumping all QML plugins.

I think it's a good idea because:
- it simplifies usage  the plugins for such frameworks (kcoreaddons is
not the only one).
- it ensures the code related to a feature is together.
- it keeps the documentation together.
- we don't force unwanted dependencies [1].

The only downside I see, is that KCoreAddons will end up depending on
QtQml. I think we can make it an optional if that's a problem on some
setups.

This is already done by many frameworks, such as: baloo, kactivities,
solid, phonon, krunner.

Aleix

[1] 
http://api.kde.org/frameworks-api/frameworks5-apidocs/kdeclarative/html/kdeclarative-dependencies.html
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Minuet (music education software) moved to kdereview

[Aleix Pol]

On Mon, Feb 1, 2016 at 12:30 AM, Albert Astals Cid  wrote:
> El Tuesday 26 January 2016, a les 10:15:47, Andreas Cord-Landwehr va escriure:
>> On Monday 25 January 2016 21:48:27 Albert Astals Cid wrote:
>> > El Sunday 24 January 2016, a les 16:50:18, Andreas Cord-Landwehr va
>>
>> escriure:
>> > > * it looks strange to me that in minuet/cmake/ there are Config-files
>> > > for
>> > > the 3rd-party library drumstick. My understanding was that such Config
>> > > files should only be shipped with the respective library (maybe someone
>> > > with a deeper CMake-knowledge can comment?)
>> >
>> > If upstream ships a cmake file awesome, but if not then we have to find it
>> > having our own cmake file.
>>
>> Absolutely, but shouldn't that be find-files then instead of config-files?
>> I always had the perception that those are quite different.
>
> Right, it most probably be a Find file not a Config file, as far as I
> understand it Config files are mostly for projects that ship the cmake file as
> part of their install.
>
> Can someone with more cmake knowledge comment?

Yes, the idea is that *Config.cmake files should be distributed by the
framework itself, otherwise you need to find it. It probably works
though, because such things are seldom checked within cmake though.

I suggest turning it into a normal Find*.cmake file. Or get Drumstick
to provide a cmake file, which is always more convenient.

Aleix

Re: Finding kdesu binary

[Aleix Pol]

On Fri, Jan 29, 2016 at 5:03 PM, Andrius Štikonas  wrote:
>> On Fri, Jan 29, 2016 at 3:33 PM, Andrius Štikonas  
>> wrote:
>> > Hi,
>> >
>> > I would like to ask how do I find kdesu binary from the code (of 
>> > partitionmanager).
>> >
>> > PartitionManager tries to restart itself with root privileges and tries to 
>> > rerun itself with kdesu, kdesudo or gksu...
>> > However, KF5 based kdesu is now in libexec, something like
>> > /usr/lib64/libexec/kf5/kdesu
>> > but it varies from distribution to distribution and not in $PATH.
>> >
>> > Is there a way to find the location in the cross-platform way? There is 
>> > kf5-config --path libexec but it is from kdelibs4support
>> > and it's better not to depend on kdelibs4support.
>>
>> If I understand correctly, you should use the KSu framework for that.
>> kdesu is not public API, that's why it's in libexec.
>>
>> Aleix
>
> Hmm, but KSu framework does not have any GUI. And it is only used by
> kdesu binary itself and krunner_shell library.
>
> I would basically have to reimplement kdesu password dialog. Isn't this a bit 
> inefficient?
> Especially, when kdesu dialog is already shown automatically if 
> partitionmanager
> is launched from menu.

Ah yes, you are right, kdesu is in kde-cli-tools. My apologies.

You can access the libexec install dir like done in discover and
desktopexecparser [1].

Basically you need to pass the libexec directory from cmake:
target_compile_definitions(YourTarget PRIVATE
-DCMAKE_INSTALL_FULL_LIBEXECDIR_KF5=\"${CMAKE_INSTALL_FULL_LIBEXECDIR_KF5}\")

And then summon it as a full path: CMAKE_INSTALL_FULL_LIBEXECDIR_KF5 "/kdesu".

HTH,
Aleix

[1] https://lxr.kde.org/ident?_i=kdesu&_remember=1
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KCoreAddons qml plugins

[Aleix Pol]

On Thu, Jan 28, 2016 at 8:12 PM, Stephen Kelly <steve...@gmail.com> wrote:
> Aleix Pol wrote:
>>> QML bindings are "one layer above" the class they bind. Just like
>>> kdebindings is separate rather than "mixed into every framework". Having
>>> the javascript bindings for KIO in KIO would tick all your criterias
>>> above ("simpler to use because part of the framework", "all the kio
>>> related code together", "doc together", "no
>>> kdebindings-depends-on-everything"). And yet we don't do it. Because KIO
>>> users don't want to be forced to install python. Similarly, many users of
>>> kcoreaddons don't want a dependency on QML.
>>>
>>> I honestly don't see the problem with having this in KDeclarative, but
>>> maybe I'm missing a good reason for splitting such qml plugins into a
>>> separate framework. Or maybe there's no point in doing that either.
>>
>> Personally, I don't really see how QtQml build-time dependency is
>> holding back the adoption of KCoreAddons. Is QtQml something that
>> often isn't available?
>
>> Distributions might add the dependency, but they also end up splitting
>> the packages [1]
>
>> and Qt
>> might choke on it, but it's not my impression that the reason that KIO
>> has KF5::KIOWidgets and not a qml plugin is because we decided we
>> wanted one and not the other, but mere historic reasons.
>
> Sorry, I'm a bit confused.
>
> Are you suggesting libKF5CoreAddons.so should link to QtQml, or are you
> suggesting creating a new KF5::CoreAddonsQmlPlugin in the kcoreaddons repo?
>
> The latter sounds more appropriate to me.

Yes, I was referring to having the plugin there, not a library. In
fact, the only reason to depend on QtQml is the plugin itself, rather
than the bindings, which usually don't have QtQml stuff (although they
might).

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

[Aleix Pol]

On Sun, Feb 28, 2016 at 9:50 AM, Stephen Kelly <steve...@gmail.com> wrote:
> Aleix Pol Gonzalez wrote:
>>> I think it would be good to have changes be better understood,
>>> otherwise we end up with lots of mess. However, it looks like several
>>> people really want this, and I don't want to stand in the way.
>>
>> I don't mind spending some time to explain it better.
>>
>> Currently what we're doing from ECM, by default, is to _guess_ where Qt
>> will have placed things. Nowadays, `KDE_INSTALL_QTQUICKIMPORTSDIR` points
>> to `${KDE_INSTALL_QTPLUGINDIR}/imports`. See `KDEInstallDirs.cmake:440`.
>>
>> If the Qt installation is configured to get the Qt imports to go to
>> `/usr/lib/IKnowBetter/imports` and we don't change our guess, we'll get
>> both the Qt directory and a `/usr/lib64/plugins/imports` directory where
>> the cmake projects will naïvely place the plugins.
>>
>> An example of a case where we can see people suffering this (I found over
>> a fast google search) is this:
>> https://forum.kde.org/viewtopic.php?f=25=130498
>
>
> Thanks for explaining!
>
> So, this isn't being done at the request of packagers? I've asked a few
> times if packagers have complained and no answer has come back. From now I'm
> just going to assume that no packager has complained about the default of
> the variable.

No packager complained because they just know they have to enable the
variable and be done with it.

> Instead this is motivated my issues like the one in the forum post?

Correct. Also I've been bugged about the issue a couple of times.

> What actually is the problem in the forum post? Will the plugin be found at
> runtime? Does the location simply not match the expectations of the person
> writing it, or is there some bad effect resulting from this?

The problem is that Qt won't find the plugin and the user will have to
define QT_PLUGIN_PATH.

> If this is about users installing self-built things to /usr? Should that
> person be installing things to /usr? My understanding up to now has been
> 'no, they should not'.
It's about easily co-installing with Qt. It will work better if they
install to /usr, but that doesn't mean they have to.

> So, I still don't understand. Maybe this is about whether or not the plugin
> can be found at runtime, but that has not been said, unless I missed it. I
> could understand this discussion being tedious for you, and still I don't
> want to stand in the way!

I've got the ship it, I'll commit later today, we can continue
discussing though. I think it's a good discussion, especially
considering it's at the core on the experience the newcomers receive
when developing on KF5 and by extension any KDE software.

And yes, it's mainly about getting Qt to find the run-time resources
(i.e. plugins, yes) without starting to push down environment
variables to let Qt find what ECM placed naively.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KDE file dialog

[Aleix Pol]

On Sun, Feb 28, 2016 at 8:01 PM, Riccardo Iaconelli  wrote:
> On 28 February 2016 at 15:58, Luigi Toscano  wrote:
>>
>> This is what I use:
>> export QT_QPA_PLATFORMTHEME=kde
>
> (btw, shouldn't this be "plasma"?)

The string is in Qt, AFAIR. It probably can't be changed until Qt 6 if
we don't want to mess with existing installations.

Aleix

Re: File dialog filters

[Aleix Pol]

On Tue, Feb 16, 2016 at 6:27 PM, Christian Dávid  wrote:
> Hi,
>
> I noticed that in KMyMoney the filter strings for file dialogs are created "by
> hand", e.g. i18n("C++ sources (*.cpp *.cxx *.c++);;All files (*)"). So each of
> them must be translated. Alternatively something like
>
> QMimeDatabase db;
> db.mimeTypeForName("text/x-c++src").filterString()
>
> could be used to create these string lowering the burden on the translators
> and resulting in consistent translations for all mimetypes.
>
> Do we have a policy regarding this? Are there any drawbacks? Can it happen
> that the mimetype database does not include all files on some systems?
>
> I know there is QFileDialog::setMimeTypeFilters() where the mimetype can be
> set directly, but this does not work with the static functions.

That's exactly what ends up happening when you call your QFileDialog
with setMimeTypeFilters, the filters will be constructed out of
QMimeType.

Aleix

Re: RCC for icons - update: Re: Icons installed by apps

[Aleix Pol]

On Thu, Mar 10, 2016 at 9:33 AM, Jaroslaw Staniek  wrote:
> Update:
>
> Full (light) breeze.rcc theme file can be squashed to 5MiB using SVG
> optimizer SVGO, in a similar way to what Aleix's script does
> (https://quickgit.kde.org/?p=breeze-icons.git=commit=8a31ac8ac105) :)
>
> Good job, Aleix.
>
>
> On 8 March 2016 at 23:56, Jaroslaw Staniek  wrote:
>>
>>
>> Hi, published a patch for Kexi with rough explanation and list of
>> features:
>>
>> https://phabricator.kde.org/D1092
>>
>>
>>
>> On 7 March 2016 at 17:52, Jaroslaw Staniek  wrote:
>>>
>>>
>>> On 7 March 2016 at 17:29, Jaroslaw Staniek  wrote:


 On 7 March 2016 at 13:05, Kåre Särs  wrote:
>
> Hi,
>
> On Monday, March 07, 2016 12:41:52 PM Jaroslaw Staniek wrote:
> > >
> > > Thanks, it works on Windows (no platform theme).
> > > How to make it work on Linux too (KF5 5.19.0, Qt 5.5.1), i.e. I'd
> > > like
> > > to have only used icons from the .rcc regardless of availability of
> > > FrameworkIntegrationPlugin.so KDEPlatformTheme.so?
> > >
> > > We're talking about this code:
> > >
> > > https://quickgit.kde.org/?p=kate.git=blob=icons.h
> > >
> > > As soon as QResource::registerResource("breeze.rcc") is called,
> > > ":/icons"
> > > is
> > > appended to the theme search path (checked using
> > > QIcon::themeSearchPaths()).
> > >
> > > There's a line QIcon::setThemeSearchPaths(QStringList() <<
> > > QStringLiteral(":/icons")).
> > >
> > > - When I have this line enabled and I have no
> > > FrameworkIntegrationPlugin.so & KDEPlatformTheme.so installed, no
> > > icons
> > > are
> > > available at all
>
> Notice that the setThemeSearchPaths() call _replaces_ any previous
> search
> paths. Is this your problem?
>
>

 No.. but I got it sorted out after reading QIconTheme::QIconTheme and
 alike and re-reading the "The name should correspond to a directory name in
 the themeSearchPath() containing an index.theme file describing it's
 contents" sentence of  QIcon::setThemeName docs :)
>>>
>>>
>>>
>>> PS: If someone wants to experiment (I hear it's the case for KDevelop),
>>> here is the
>>> Breeze icons resource: http://kexi-project.org/tmp/breeze.rcc.bz2

\o/

Aleix

Re: RCC for icons - update: Re: Icons installed by apps

[Aleix Pol]

On Thu, Mar 10, 2016 at 9:33 AM, Jaroslaw Staniek  wrote:
> Update:
>
> Full (light) breeze.rcc theme file can be squashed to 5MiB using SVG
> optimizer SVGO, in a similar way to what Aleix's script does
> (https://quickgit.kde.org/?p=breeze-icons.git=commit=8a31ac8ac105) :)
>
> Good job, Aleix.
>
>
> On 8 March 2016 at 23:56, Jaroslaw Staniek  wrote:
>>
>>
>> Hi, published a patch for Kexi with rough explanation and list of
>> features:
>>
>> https://phabricator.kde.org/D1092
>>
>>
>>
>> On 7 March 2016 at 17:52, Jaroslaw Staniek  wrote:
>>>
>>>
>>> On 7 March 2016 at 17:29, Jaroslaw Staniek  wrote:


 On 7 March 2016 at 13:05, Kåre Särs  wrote:
>
> Hi,
>
> On Monday, March 07, 2016 12:41:52 PM Jaroslaw Staniek wrote:
> > >
> > > Thanks, it works on Windows (no platform theme).
> > > How to make it work on Linux too (KF5 5.19.0, Qt 5.5.1), i.e. I'd
> > > like
> > > to have only used icons from the .rcc regardless of availability of
> > > FrameworkIntegrationPlugin.so KDEPlatformTheme.so?
> > >
> > > We're talking about this code:
> > >
> > > https://quickgit.kde.org/?p=kate.git=blob=icons.h
> > >
> > > As soon as QResource::registerResource("breeze.rcc") is called,
> > > ":/icons"
> > > is
> > > appended to the theme search path (checked using
> > > QIcon::themeSearchPaths()).
> > >
> > > There's a line QIcon::setThemeSearchPaths(QStringList() <<
> > > QStringLiteral(":/icons")).
> > >
> > > - When I have this line enabled and I have no
> > > FrameworkIntegrationPlugin.so & KDEPlatformTheme.so installed, no
> > > icons
> > > are
> > > available at all
>
> Notice that the setThemeSearchPaths() call _replaces_ any previous
> search
> paths. Is this your problem?
>
>

 No.. but I got it sorted out after reading QIconTheme::QIconTheme and
 alike and re-reading the "The name should correspond to a directory name in
 the themeSearchPath() containing an index.theme file describing it's
 contents" sentence of  QIcon::setThemeName docs :)
>>>
>>>
>>>
>>> PS: If someone wants to experiment (I hear it's the case for KDevelop),
>>> here is the
>>> Breeze icons resource: http://kexi-project.org/tmp/breeze.rcc.bz2

\o/

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Plasma desktop scripting

[Aleix Pol]

On Mon, Mar 14, 2016 at 3:04 PM, Franklin Weng
 wrote:
> Hi,
>
>
> A simple question:
>
> https://userbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting#Activities_and_desktops
>
> Are the instructions for Plasma desktop scripting in the above link for
> Plasma 4 or Plasma 5?
>
> In the above link the activity creating API is:
>
> var activityId = newActivity("org.kde.plasma.folderview")
>
> However in Kubuntu 15.10 the syntax in layout.js is:
>
> var id = createActivity("Desktop");
> var desktopsArray = desktopsForActivity(id);
>
> I've spent months trying to customize Plasma 5 Desktop but very frustrated.
> I've tried to ask in the mailing list and irc channels but no luck.  (Please
> don't get me wrong.  I'm not blaming anyone for this.)  Would anyone please
> just tell me this simple question:  Is the information in the Techbase wiki
> (now Userbase wiki) up-to-date?  If not, is there any documents for Plasma 5
> Desktop scripting for now?
>
> If not, I may not have choices but to give up using KDE Plasma 5 as the
> default desktop in our system.
>
>
> Thanks,
> Franklin
>

Hi Franklin,
Coincidentally, I was playing with such code last week. It should be
the same (I think) as Plasma 4, and it should work.

Send an e-mail to the plasma-devel mailing list with the exact issue
you're having so we can figure out exactly what's wrong.

Aleix

Re: Qt 5.6/QtWebkit

[Aleix Pol]

On Wed, Mar 16, 2016 at 2:54 PM, René J. V.  wrote:
> David Edmundson wrote:
>
>
>> There was a thread "Policy regarding QtWebKit and QtScript" on
>> kde-core-devel a while ago.
>> http://kde.6490.n7.nabble.com/Policy-regarding-QtWebKit-and-QtScript-td1619988.html
>
> Indeed there was, a short while ago even. It mostly argues about the cost of
> building QtWebEngine (understandably ; in my experience it took about as long 
> to
> build as the rest of Qt 5.5).
>
> I also saw something about "it looks like there will be a source-only qtwebkit
> 5.6". Any pointers for that?

https://code.qt.io/cgit/qt/qtwebkit.git/

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Qt 5.6/QtWebkit

[Aleix Pol]

On Thu, Mar 17, 2016 at 10:54 AM, René J. V.  wrote:
> David Edmundson wrote:
>
>> There was a thread "Policy regarding QtWebKit and QtScript" on
>> kde-core-devel a while ago.
>> http://kde.6490.n7.nabble.com/Policy-regarding-QtWebKit-and-QtScript-td1619988.html
>
> What I'm missing (as in not getting) in that discussion is the whole thing 
> about
> (Qt)WebKit upstream.
>
> IIUC, WebKit was developed by Apple based on KHtml, and AFAIK WebKit is still
> the basis for their Safari browser, and the sources are still available (e.g.
> http://opensource.apple.com/release/os-x-10112/).
>
> Do I have to deduce that QtWebKit isn't "just" a Qt interface to WebKit,
> maintained by the Qt Comp - because it is I don't see how security updates 
> could
> have stopped?

WebKit integration was done through forking then integrating. It was
awkward because merging upstream changes meant rebasing our work on
theirs.
That's why it's Chromium is better in this regard, you get to interact
the upstream component without forking it, AFAIU.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Misbehavior when unloading KStyle

[Aleix Pol]

Hi,
I've seen a couple of times such backtrace [1] which shows Qt waiting
for something that never happens. An easy way to reproduce is to load
konversation (or any application with KDBusService::Unique), hide it
and run it again. The exit call will never be fulfilled in the second
process.

Any idea of what could be the cause of this? Or why it's happening?

Regards,
Aleix

[1] https://paste.kde.org/pstps66fj
[2] (gdb) thread 2
[Switching to thread 2 (Thread 0x7fffe180f700 (LWP 1))]
#0  0x708a3c3d in poll () from /usr/lib/libc.so.6
(gdb) where
#0  0x708a3c3d in poll () from /usr/lib/libc.so.6
#1  0x7fffedb4fae2 in ?? () from /usr/lib/libxcb.so.1
#2  0x7fffedb51757 in xcb_wait_for_event () from /usr/lib/libxcb.so.1
#3  0x7fffe513b269 in QXcbEventReader::run (this=0xe54730) at
/home/apol/devel/frameworks/qt5/qtbase/src/plugins/platforms/xcb/qxcbconnection.cpp:1321
#4  0x714ae2f9 in QThreadPrivate::start (arg=0xe54730) at
/home/apol/devel/frameworks/qt5/qtbase/src/corelib/thread/qthread_unix.cpp:340
#5  0x7fffee827424 in start_thread () from /usr/lib/libpthread.so.0
#6  0x708accbd in clone () from /usr/lib/libc.so.6
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Misbehavior when unloading KStyle

[Aleix Pol]

On Fri, Apr 8, 2016 at 3:42 PM, Andreas Hartmetz <ahartm...@gmail.com> wrote:
> On Donnerstag, 7. April 2016 20:33:19 CEST Andreas Hartmetz wrote:
>> On Mittwoch, 6. April 2016 20:10:53 CEST Aleix Pol wrote:
>> > Hi,
>> > I've seen a couple of times such backtrace [1] which shows Qt
>> > waiting
>> > for something that never happens. An easy way to reproduce is to
>> > load
>> > konversation (or any application with KDBusService::Unique), hide it
>> > and run it again. The exit call will never be fulfilled in the
>> > second
>> > process.
>> >
>> > Any idea of what could be the cause of this? Or why it's happening?
>> >
>> > Regards,
>> > Aleix
>> >
>> > [1] https://paste.kde.org/pstps66fj
>> > [2] (gdb) thread 2
>> > [Switching to thread 2 (Thread 0x7fffe180f700 (LWP 1))]
>> > #0  0x708a3c3d in poll () from /usr/lib/libc.so.6
>> > (gdb) where
>> > #0  0x708a3c3d in poll () from /usr/lib/libc.so.6
>> > #1  0x7fffedb4fae2 in ?? () from /usr/lib/libxcb.so.1
>> > #2  0x7fffedb51757 in xcb_wait_for_event () from
>> > /usr/lib/libxcb.so.1 #3  0x7fffe513b269 in QXcbEventReader::run
>> > (this=0xe54730) at
>> > /home/apol/devel/frameworks/qt5/qtbase/src/plugins/platforms/xcb/qxc
>> > b
>> > connection.cpp:1321 #4  0x714ae2f9 in QThreadPrivate::start
>> > (arg=0xe54730) at
>> > /home/apol/devel/frameworks/qt5/qtbase/src/corelib/thread/qthread_un
>> > i
>> > x.cpp:340 #5  0x7fffee827424 in start_thread () from
>> > /usr/lib/libpthread.so.0 #6  0x708accbd in clone () from
>> > /usr/lib/libc.so.6
>> > ___
>> > Kde-frameworks-devel mailing list
>> > Kde-frameworks-devel@kde.org
>> > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>>
>> I've seen this happening as well. It looks it's triggered by a certain
>> destruction order of global statics (as in Q_GLOBAL_STATIC) and
>> involves a QObject::destroyed() (not sure about that one) signal sent
>> to the (new in 5.6) DBus thread (aka QDBusConnectionManager) which is
>> moveToThread(Q_NULLPTR)-ed into some kind of limbo state when shutting
>> down because its global static container is destroyed, where it stops
>> event processing. The connection is a BlockingQueuedConnection, so it
>> hangs indefinitely.
>> If you have your environment set up in a way that Qt applications use
>> a KStyle, you only need a main function consisting of
>>
>> QApplication(argc, argv);
>> exit(EXIT_SUCCESS /* doesn't matter */);
>>
>> to trigger it.
>> Note: you should not exit() with a QApplication around, it's asking
>> for problems anyway. kactivitmanagerd does it extensively and hangs
>> very reliably currently... I have a request to change this on
>> Phabricator. Note 2: you should NEVER try to handle signals by
>> calling
>> QApplication::quit() to exit cleanly. That is very much not something
>> that's safe to do in a signal context. I have seen this in two
>> different KDE daemons so far.
>>
>> I've talked to Thiago about the apparent Qt bug. He said he'd get to
>> it next week and so I haven't filed a bug yet. I'm still planning to
>> do that.
>>
>
> https://bugreports.qt.io/browse/QTBUG-52473
>
> Good place to add any additional useful information :)

The bug report Martin pointed out leads here:
https://bugreports.qt.io/browse/QTBUG-51648

Is it the same?

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: build.kde.org What have you done to it!?!?! Serious explanation inside.

[Aleix Pol]

On Wed, Mar 23, 2016 at 11:02 PM, Scarlett Clark
 wrote:
> Ok, so we are migrating to docker builds tomorrow, (Ben's available time)
> Rather than continually mess with two set of builds I am only working on
> sandbox in preparation. The good news is many unstable builds have gone
> green, but will not be seen until we are live :) So I am hereby giving
> NOTICE of disruption in service for build.kde.org We hope for a swift and
> smooth transition.
> Thanks!!
> Scarlett

Looking forward to it!

And looking forward to the docs. :)

Good luck!
Aleix

Re: Raising Qt requirement to Qt 5.4

[Aleix Pol]

On Wed, Mar 16, 2016 at 1:13 PM, Martin Graesslin  wrote:
> Hi all,
>
> with todays release of Qt 5.6 I suggest that we raise the minimum Qt version
> requirement to 5.4. This would mean the latest three releases are supported.
>
> The important new features in Qt 5.4 in my opinion for frameworks development
> are:
> * QSignalSpy(const QObject *object, PointerToMemberFunction signal)
> * Q_LOGGING_CATEGORY(name, string, msgType)
>
> Which are already used in many frameworks and currently ifdefed.
>
> Opinions?

I'm not sure, Qt 5.4.0 has only released 1 year ago, doesn't sound
like a lot of time, I'm unsure what people are using though.
https://wiki.qt.io/Qt-5.4-release

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: gcode.xml got into KF5::KTextEditor without review

[Aleix Pol]

On Sat, Mar 5, 2016 at 1:12 AM, Sven Brauch  wrote:
> Hey Alexander,
>
> Thanks for caring and sorry for breaking the string freeze; I missed
> that. I reverted the commit and I will resubmit it after the 5.8 release
> is out.
>
> On 05/03/16 01:01, Alexander Potashev wrote:
>> [2] is clearly a feature, but it was not submitted to reviewboard
>> before pushing to ktexteditor.git:master.
> I thought it was up to the individual projects how to handle that. New
> syntax highlighting files are really not critical changes at all, and I
> consider the reviewing and fixing that happened on kwrite-devel for this
> patch sufficient. It did not seem necessary to make a new and probably
> one-time contributor go through reviewboard for this one submission.
> Additionally, we regularily receive submissions like that and we often
> handle them like this.
> If I'm mistaken here, could you please point me to the policy saying
> otherwise?

Hi Sven,
Here's the link you're requesting:
https://community.kde.org/Frameworks/Policies#Frameworks_commits_are_reviewed

And the policy does apply because ktexteditor is not a different
project. It's a KDE Framework and as such it's under it's quality
measures.

Nevertheless, you reviewed it, so it's fine.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re:

[Aleix Pol]

On Thu, Mar 3, 2016 at 7:13 PM, Alex Mourtziapis  wrote:

> Hi,
>
> Sorry for spamming...
> I wanted to ask if there's a possible way to work on Krita repo without
> messing with the whole Calligra Suite.
> (my connection is not that good as you can imagine, it ll take a lotta of
> hours just
> to get the suite)
> ᐧ
>

I'm not sure, but it looks to me like the Krita repository should be
enough. I never built Krita though.

You can ask on their own mailing list, if nobody knows around here:
https://krita.org/mailing-lists/

Happy hacking!
Aleix

Re: Re[2]: Review Request 127632: Prioritize correct extension per theme

[Aleix Pol]

On Wed, Apr 27, 2016 at 12:58 AM, Nick Shaforostoff  wrote:
> sorry, I'm a bit late. I think having extensions without dots is preferred 
> from common sense POV:
>
> KDE-Extensions=svg
> KDE-Extensions=svg,png
>
> what do you think?
>
> also, the spec would like additional params to start with X-, e.g.
>
> X-KDE-Extensions=svg
> X-KDE-Extensions=svg,png

Works for me.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Improving performance under breeze icons

[Aleix Pol]

Hi,
As assessed lately, one penalty we have when starting an application
is the icons look-up. It's not really Breeze's fault, the intersection
of the standard we're using and how we're using it makes the situation
slightly complex, hence simplifying it would improve the situation
already.

To get some context, the problem is that whenever we request an icon,
what we do is go through all the provided directories hoping we'll
find it.

Now I'm mentioning breeze because on one hand, it's really awesome how
we're using scalable icons directly but on the other hand we could
look into leveraging it better. Here's some ideas, I'd especially like
the icon designers' opinions so we can find the best situation.

* There's some sizes that we can probably trim right away. Are icons
in the 12 and 16 directory substantially different? Or 22 and 24? I've
checked and pruning these would get us about 5% of failed accesses
back.

* Furthermore, I see there's some icons that aren't on every size (for
example, vcs-added is only in 16 but not in 8 or 22). All in all,
feels like it could be specifying broader categories, especially
considering the scalable nature, such as emblems/small, emblems/big.

* Last, slightly unrelated, there's a risk when the icon differs
greatly (e.g. system-help) from a size to another we'll end up with
unpredictable UI's, maybe it would be possible to rename them to
reflect this.

Do you think there's any possibility we could improve there?

Thanks a lot!
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Ongoing documentation fixes around "KDE" terminology

[Aleix Pol]

On Mon, May 16, 2016 at 8:27 PM, Luigi Toscano  wrote:
> Hi all,
>
> the documentation (docbook) of various projects still include references to "K
> Desktop Environment", " for KDE" and so on. As fixing those strings
> is long overdue, instead of going with a review for each of those changes, if
> there are no objections, the documentation team will directly push a series of
> fixes for those terminology issues in the following days.
>
> Ciao
> --
> Luigi

+1

Thanks!!

Aleix

Re: KConfig compiler. GenerateProperties and Mutable.

[Aleix Pol]

On Fri, May 13, 2016 at 1:02 PM, Artem Fedoskin <afedosk...@gmail.com> wrote:
> Hi Aleix,
>
> I'm sorry for late reply. I was trying to compile KStars for Android and
> struggled a bit with compiling KF5.
>
> 1. I don't know whether this is a problem or a feature - When I compile my app
> for Android and use KConfig compiled for Android the ARM version of
> kconfig_compiler is executed to build options class. I had to change
> kconfig_compiler executable compiled for Android with the one compiled for
> my system to build options class. Can I somehow specify to CMake that I need
> kconfig_compiler built for my system, not Android and at the same time use
> Android version of KConfig?
Use KF5_HOST_TOOLING variable to point to your host tooling.

> 2. I found that mSettingsChanged is included only in
> kconfig/autotests/kconfig_compiler/test_signal.h.ref but there is no mention
> of it in kconfig_compiler.cpp. Could you please tell me what can be the
> reason why val on kconfig_complier.cpp:2061 is 0?

Please try to understand what's the algorithm.

> 3. Some of KF5 modules can be compiled using the script provided by KDE but
> unfortunately it doesn't support KIO. I saw from your blog posts that you
> have experience with building for Android. Could you please point me where
> should I start building KIO for Android?
https://community.kde.org/Android

Cheers!
Aleix

> Regards,
>
> Artem Fedoskin
>
>
> 2016-05-10 16:49 GMT+02:00 Aleix Pol <aleix...@kde.org>:
>>
>> On Mon, May 9, 2016 at 8:02 PM, Artem Fedoskin <afedosk...@gmail.com>
>> wrote:
>> > Dear KDE developers,
>> >
>> > For my GSoC 2016 project at KDE (Lite version of KStars for mobile
>> > devices)
>> > I need to access C++ class generated from XML configure file with
>> > KConfig
>> > compiler from QML. I found in this patch
>> > https://git.reviewboard.kde.org/r/123367/ and in the source code of
>> > KConfig
>> > compiler that I should set GenerateProperties=true in my .kcfgc file to
>> > create option properties as Q_PROPERTY. However, I got following error
>> > "Too
>> > many signals to create unique bit masks". There is some conflict between
>> > Mutators and GenerateProperties options that causes this error in my XML
>> > configure file but I can't figure out what I should change to have
>> > setters
>> > in Q_PROPERTY.
>> >
>> > Would be grateful if someone could help me with this issue.
>> >
>> > Options.kcfgc - https://paste.kde.org/pm1klcbls
>> >
>> > kstars.kcfg - https://paste.kde.org/phit6qibo
>>
>> Hi Artem,
>> KConfigCompiler is limited in this regard by an implementation detail.
>> See "uint mSettingsChanged;".
>>
>> To solve it, I would patch kconfig_compiler and turn it into an
>> std::vector or patch kstars.kcfg to use separate config files
>> rather than a huge one.
>>
>> HTH,
>> Aleix
>
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: LGPL for Breeze QStyle and qtquickcontrols?

[Aleix Pol]

On Wed, May 18, 2016 at 11:36 AM, Hugo Pereira Da Costa
 wrote:
> On 05/18/2016 11:13 AM, Jaroslaw Staniek wrote:
>
>
>
> On 17 May 2016 at 20:48, Hugo Pereira Da Costa
>  wrote:
>>
>> Hi,
>>
>> [snip]
>>>
>>>
>>> Architecturally, the eventual solution would be that breeze.git becomes
>>> layered, and routines beyond what QStyle defines are provided by an LGPL
>>> lib. It worked with libOxygen that is LGPL.
>>> The reason for liboxygen was that part of Oxygen was also used by KWin
>>> decoration. We fixed that by moving the decorations together with the
>>> style
>>> into one repository.
>>
>> liboxygen was also there to take care of code shared between the style and
>> the decoration, but internal only, no headers exported, no so version, no
>> abi, api stability guaranty of any kind. I have no clue how this could be
>> used by the external world in any way.
>
>
> It is, I explained it a bit. But anyway it's FOSS so explaining was not
> needed. I am not implementing frameworks or plasma so I am not obligated to
> rules or habits expressed here.
>
>
>>
>>
>>> Personally I think liboxygen was rather a hack and an annoyance.
>>
>> based on the above, I was seeing it as a "private" library, needed to
>> avoid code duplication and ease maintenance between two parts of oxygen.
>> As for the licensing of such a thing, no clue, but again, I never intended
>> it to be re-used by any other code.
>
>
> Like above, do you agree it to be reused or not.
>
> I would not agree with the library to be linked against because I do not
> want to provide the guaranties that goes with it (about ABI and API
> stability) or do not want to be held responsible for these to be broken. I
> do agree for people copying the code around and take over these
> responsibilities if they want.
>
> I am not asking if you intend to use it, I am asking if you are OK/open with
> others using the code in other FOSS code.
>
>
>>
>>
>>>
 Especially that QStyle is
 mostly just maintained. "Use QStyle and plugins" sounds almost like "use
 X
 "protocol instead of DWD"...
 Going LGPL is a first step for this being even considered as a task by a
 KDE contributor. Without that the easiest thing is to work downstream
 forking^w copying the design and such.

>> The request is about the freedom to use of the code from of the breeze
>> style in LGPL code freely opening freedom for experimentation and
>
> progress.
>
>> The design (by VDG) is free to use (LGPL I think), why wouldn't the
>> implementation be free-to-link?
>
> I repeat again: I object to a relicense of code I have written to GPL
> in
> the
> case of Breeze and Oxygen.

 I see much of oxygen

 is BSD-like and LGPL of the change happened in with the Breeze.
>>>
>>> I have here a file open oxygenstyleplugin.cpp which is licensed as GPL
>>> v2+.
>>> Thus the whole thing is licensed GPLv2+. Why the code is inconsistent
>>> licensed
>>> I do not know.
>>
>>
>> Probably me copying code around without caring much. I would agree to
>> re-license all the part I wrote to GPL v2+.
>>
>
> Cool but that was not my question
>
> .
>
> I know. And I did not agree to relicense to LGPL. I did agree with Martin
> about it being licenced GPL and agree to relicense the code I wrote to GPL.
>
> I am ok with the compile code being used as a plugin, and not to be linked
> against (because of the same responsibilities I do not want to take). I am
> ok with bits of code being copied and reused.
>
>
> I asked to relicense to LGPL so I don't need to reimplement the same bits of
> style for non-QStyle code. Or reuse artwork from GTK+.
>
>
>
>
>
>
>> best,
>>
>> Hugo
>>
>>
>>>
 Again what's wrong for you with libOxygen that is LGPL?
>>>
>>> liboxygen is not lgpl licensed. Look for example at
>>> liboxygen/liboxygen.h. It
>>> has a GPLv2+ header, thus is GPLv2+
>>>


>> PS: If our tech was HTML and Qt Quick only, our styles would be LGPL
>> clearly as these would be actually scripts and graphic/style files.
>> Why
>> would we have inferior situation just because we happen to use
>> compilers?
>
> I don't see what that has to do with it.

 It means that styles for HTML and Qt Quick _and_ GTK+ Breze style have
 freedoms that Breeze actually lack just because the licensing choice.
 And
 that may or may not be a missed opportunity.
>>>
>>> I just checked the folder qtquickcontrols - those files are unfortunately
>>> not
>>> licensed at all. This is clearly wrong.
>>>
>>> Concerning GTK+ Breeze style: the COPYING.lib says it's LGPL. So you also
>>> cannot just take parts of it. Though the individual files are lacking a
>>> copyright header.
>>>
>>> Cheers
>>> Martin
>>
>>

This is very gratuitous confrontation.

To be honest, I still don't really understand what's the proposal and
we're going to the details 

Re: Can we have a headersclean check for frameworks?

[Aleix Pol]

On Wed, May 11, 2016 at 10:51 PM, Stephen Kelly  wrote:
> Hi,
>
> Qt has a headersclean utility which runs each header through the compiler on
> its own. That verifies that it doesn't cause certain warnings, can compile
> in the presence of certain Qt defines, and includes or forward declares
> everything it should.
>
> We don't have such a thing in KF5, but as shown by
>
>  https://quickgit.kde.org/?p=kconfigwidgets.git=commitdiff=2900814b
>
> we would benefit from it.
>
> Does anyone want to try to implement it (or borrow the Qt implementation)
> and integrate it?
>
> We can probably add it to ECM and run it as part of the build of frameworks.

That could make sense, maybe as a clazy check?

Can you point us to Qt's so we know what we're talking about?

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [kate/Applications/16.04] kate: Close document: use icon document-close instead of window-close

[Aleix Pol]

On Sat, Apr 30, 2016 at 11:11 PM, Dominik Haumann  wrote:
> Hi all,
>
> I wonder, whether the correct fix would be to change the default icon
> for KStandardAction::Close from "window-close" to "document-close"?
>
> Cheers,
> Dominik
>
> -- Forwarded message --
> From: Dominik Haumann 
> Date: Sat, Apr 30, 2016 at 11:02 PM
> Subject: [kate/Applications/16.04] kate: Close document: use icon
> document-close instead of window-close
> To: kde-comm...@kde.org
>
>
> Git commit 72cb3b9c71fd0a300ca163b8a644bc51e7b80eaf by Dominik Haumann.
> Committed on 30/04/2016 at 21:02.
> Pushed by dhaumann into branch 'Applications/16.04'.
>
> Close document: use icon document-close instead of window-close
>
> BUG: 362447
>
> M  +3-2kate/katemainwindow.cpp
>
> http://commits.kde.org/kate/72cb3b9c71fd0a300ca163b8a644bc51e7b80eaf
>
> diff --git a/kate/katemainwindow.cpp b/kate/katemainwindow.cpp
> index f630e28..4e7e907 100644
> --- a/kate/katemainwindow.cpp
> +++ b/kate/katemainwindow.cpp
> @@ -306,8 +306,9 @@ void KateMainWindow::setupActions()
>  connect(a, SIGNAL(triggered()),
> KateApp::self()->documentManager(), SLOT(closeOrphaned()));
>  a->setWhatsThis(i18n("Close all documents in the file list that
> could not be reopened, because they are not accessible anymore."));
>
> -actionCollection()->addAction(KStandardAction::Close,
> QStringLiteral("file_close"), m_viewManager,
> SLOT(slotDocumentClose()))
> -->setWhatsThis(i18n("Close the current document."));
> +a = actionCollection()->addAction(KStandardAction::Close,
> QStringLiteral("file_close"), m_viewManager,
> SLOT(slotDocumentClose()));
> +a->setIcon(QIcon::fromTheme(QStringLiteral("document-close")));
> +a->setWhatsThis(i18n("Close the current document."));
>
>  a = actionCollection()->addAction(QStringLiteral("file_close_other"));
>  a->setText(i18n("Close Other"));
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Asking Andreas, he's all about icon names.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KConfig compiler. GenerateProperties and Mutable.

[Aleix Pol]

On Mon, May 9, 2016 at 8:02 PM, Artem Fedoskin  wrote:
> Dear KDE developers,
>
> For my GSoC 2016 project at KDE (Lite version of KStars for mobile devices)
> I need to access C++ class generated from XML configure file with KConfig
> compiler from QML. I found in this patch
> https://git.reviewboard.kde.org/r/123367/ and in the source code of KConfig
> compiler that I should set GenerateProperties=true in my .kcfgc file to
> create option properties as Q_PROPERTY. However, I got following error "Too
> many signals to create unique bit masks". There is some conflict between
> Mutators and GenerateProperties options that causes this error in my XML
> configure file but I can't figure out what I should change to have setters
> in Q_PROPERTY.
>
> Would be grateful if someone could help me with this issue.
>
> Options.kcfgc - https://paste.kde.org/pm1klcbls
>
> kstars.kcfg - https://paste.kde.org/phit6qibo

Hi Artem,
KConfigCompiler is limited in this regard by an implementation detail.
See "uint mSettingsChanged;".

To solve it, I would patch kconfig_compiler and turn it into an
std::vector or patch kstars.kcfg to use separate config files
rather than a huge one.

HTH,
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Taking over KRunner maintainership

[Aleix Pol]

On Fri, Apr 15, 2016 at 12:13 AM, Kai Uwe Broulik  
wrote:
> Hi all,
>
> as was already briefly mentioned in the Plasma hangout this Monday Vishesh
> asked me to take over maintainership of KRunner and I'm willing to accept.
>
> While I am not confident to have the skills required to really move forward
> KRunner's architecture (cf. Sprinter) I had already been the de-facto
> maintainer for the past few months and massively improved on the UX and
> fixing a share of the bug pile it has collected over the years.

Thanks a lot Kai! :)
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: appstream icons and the hicolor madness we have in KDE software

[Aleix Pol]

On Thu, Apr 21, 2016 at 1:12 AM, Rex Dieter  wrote:
> Matthias Klumpp wrote:
>
>> GNOME ships icons for all its apps in hicolor/
>
> KDE should too (in general)

Would it be enough if Breeze installed the applications icons in
hicolor or we're talking about moving every application icon into the
application's tarball?

Aleix