Re: Moving KWayland to frameworks

2015-12-09 Thread Martin Graesslin 
On Thursday, November 5, 2015 11:10:49 AM CET Kevin Ottens wrote:
> Hello,
> 
> On Thursday 05 November 2015 10:50:06 Martin Graesslin wrote:
> > There are two things which make the move to frameworks difficult and I
> > don't see a solution to it at the moment:
> > 
> > 1. We require C++11 without exceptions: reason, it's designed for Linux
> > and
> > it didn't come to my mind to restrict us on the compiler due to lack of
> > support in Visual Studio.
> > 
> > 2. We use Qt 5.4.
> > 
> > For item 1 I only see the possibility of adding an exception [1].
> 
> I personally don't like exceptions, it gets complex fast.
> 
> Now are you sure it is really problematic? To me it looks like you're using
> almost exclusively features from the white list. It is probably just a
> matter of s/nullptr/Q_NULLPTR/ and s/override/Q_DECL_OVERRIDE/ in your
> case.

I just started looking into doing the replacement and noticed that I'm also 
using:
* Non-static data member initializers (N2756), gcc 4.7
* Range-based for (N2930), gcc 4.6
* constexpr, gcc 4.6
* possibly also delegating ctors, gcc 4.7 (difficult to find)

Overall it looks to me like I cannot make this code base to work again with 
gcc 4.5 without spending a lot of time and possibly introducing regressions.

So how should we go on?

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

2015-12-09 Thread Alex Merry 

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



cmake/KF5I18NMacros.cmake (lines 55 - 58)


If a project uses ki18n_install_ts_files, it will still fail with this 
change. It just won't be at all obvious to the user *why* it failed: they will 
get a message about an unknown command, which they may or may not realise is 
linked to an earlier vague message about Python and Gettext being needed.

If you're going to take this approach, I think you still need to define 
k18n_install_ts_files in the else() branch, but make it spit out an error about 
exactly what package(s) are missing.


- Alex Merry


On Dec. 4, 2015, 12:17 a.m., Boudewijn Rempt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126230/
> ---
> 
> (Updated Dec. 4, 2015, 12:17 a.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Aleix Pol Gonzalez, 
> Chusslove Illich, and Luigi Toscano.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> When building ki18n as a dependency framework for shipping with an 
> application, the tools to actually create and manage translations are 
> superfluous. These tools have some big dependencies that are a pain to have 
> around, especially gettext on Windows. This patch makes the requirement for 
> Python and Gettext optional.
> 
> This patch checks the BUILD_TESTING variable to see if the autotests should 
> be built, because when we just need the library to build an application we 
> shouldn't waste electicity building the tests (and the Qt5::QML dependency).
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 59917fa 
>   cmake/KF5I18NMacros.cmake 53ba812 
> 
> Diff: https://git.reviewboard.kde.org/r/126230/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Boudewijn Rempt
> 
>

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

[OS X/Wayland] using WIds created by a different process to create KMessageBox'es and other widgets/windows

2015-12-09 Thread René J . V . Bertin 
Hi,

Several classes exist that have the possibility to create widgets or windows 
from a Qt WId, and those are used (exclusively? mostly?) by certain helper 
agents like the kwalletd to display dialogs parented by a window from the 
application that sent the request that justified posting the dialog in question.

This procedure works fine on X11 where there is a single server that provides 
and controls the basic UI elements (windows) and where a WId is (presumable) 
something that translates to an X11 window reference. On OS X (and MS 
Windows?), a WId is in fact cast from a pointer to an instance of a native 
widget class (QNSView, QNSWindow; QCocoaView in Qt4), and using these from a 
different process can evidently lead to a SIGSEGV.

Yet applications like kwalletd are not out of place on platforms that are not 
X11 ... and I understand from Martin that the same or a highly comparable 
situation exists with Wayland.

I'd like to start a discussion on how this can be dealt with. Qt does not keep 
track of who "owns" each existing WId (not on OS X at least), but until now 
QWidget::find(WId) has always returned NULL for me when given an invalid WId 
(including those owned by another process).

A function like createWIdDialog (in KWidgetsAddons) already detects this, and 
can be adapted to handle this situation differently where required (it 
currently calls setMainWindow() when QWidget::find returned NULL and the WId 
isn't NULL itself). For a KMessageBox it would then make sense on OS X to call 
a platform function to ensure that the dialog is posted in front; i.o.w. in 
front of all windows rather than where the owning application decided to place 
the window (WId). (Not doing anything of the sort would mean the dialog opens 
in the "layer" of the background application, i.e. somewhere behind most or all 
other open windows).

I'm working on an OS X plugin for KWindowSystem, so a priori I should be able 
to provide an appropriate activateWindow implementation.
I'd appreciate suggestions what classes that allow to create instances from 
WIds should provide this "in your face" approach if the target WId comes from 
another process.

KWindowSystem::setMainWindow() is a different matter. Firstly, it does NOT use 
the plugin architecture currently, but simply assumes that QWindow::fromWinId() 
will always work (and never crash). For the time being it will thus require 
ifdefs. Beyond that, exactly how should I adapt it? Never do anything on OS X 
(the solution used currently in KDELibs4/MacPorts)? Or check the result from 
QWidget::find() and only do its job when that function returns a valid pointer 
(which could actually be the general approach if that find() function isn't 
expensive on platforms where calling it is redundant).

Beyond that I suppose that setMainWindow() is *not* the place to push the new 
window to the foreground so that it doesn't get overlooked - or is it?
In other words, what exactly is the role of KWindowSystem's main window?

Thanks,
René

PS: I did indeed write a native, "Keychain backend" (SecKeyChain) for KWallet4, 
but after having used and polished that backed for over a year I think it is 
not feasible to provide a satisfactory implementation that maps enough of the 
KWallet feature set to the much more restricted SecKeyChain API. Applications 
depending on KWallet (and their users) are better off with an adapted kwalletd 
that functions correctly, IMHO.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126185: Make the KAppTemplate CMake module global

2015-12-09 Thread Marco Martin 

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

(Updated Dec. 9, 2015, 11:27 a.m.)


Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
and Simon Wächter.


Changes
---

* it's now a function
* uses cmake -E tar


Repository: extra-cmake-modules


Description
---

templates are very useful as teaching tool in order to make
a minimal application that uses a certain framework.
templates in the KAppTemplate repository will always get forgotten
(plus kapptemplate is not really necessary as they work in kdevelop as well)
An ideal situation would be frameworks having templates in their own repos
with templates of barebone apps using the main framework features.
In order to do that, the cmake stuff needed in order to correctly install
a template needs to be ported to a place avaiable to all frameworks


Diffs (updated)
-

  kde-modules/KDETemplateGenerator.cmake PRE-CREATION 
  kde-modules/KDEInstallDirs.cmake b7cd34d 

Diff: https://git.reviewboard.kde.org/r/126185/diff/


Testing
---

done some templates installed by plasma-framework


Thanks,

Marco Martin

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

Re: Review Request 126185: Make the KAppTemplate CMake module global

2015-12-09 Thread Marco Martin 

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

(Updated Dec. 9, 2015, 12:12 p.m.)


Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
and Simon Wächter.


Repository: extra-cmake-modules


Description
---

templates are very useful as teaching tool in order to make
a minimal application that uses a certain framework.
templates in the KAppTemplate repository will always get forgotten
(plus kapptemplate is not really necessary as they work in kdevelop as well)
An ideal situation would be frameworks having templates in their own repos
with templates of barebone apps using the main framework features.
In order to do that, the cmake stuff needed in order to correctly install
a template needs to be ported to a place avaiable to all frameworks


Diffs (updated)
-

  kde-modules/KDETemplateGenerator.cmake PRE-CREATION 
  kde-modules/KDEInstallDirs.cmake b7cd34d 

Diff: https://git.reviewboard.kde.org/r/126185/diff/


Testing
---

done some templates installed by plasma-framework


Thanks,

Marco Martin

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

Re: Review Request 126185: Make the KAppTemplate CMake module global

2015-12-09 Thread Marco Martin 


> On Dec. 9, 2015, 12:03 p.m., Aleix Pol Gonzalez wrote:
> > kde-modules/KDETemplateGenerator.cmake, line 59
> > 
> >
> > Naming them .zip on windows, won't make it a zip file, if you use tar 
> > j. I suggest just using .tar.bz2 everywhere.

is it guaranteed that the .tar.bz2 file will be correctly generated on windows 
too?


- Marco


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


On Dec. 9, 2015, 12:12 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 9, 2015, 12:12 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDETemplateGenerator.cmake PRE-CREATION 
>   kde-modules/KDEInstallDirs.cmake b7cd34d 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: [OS X/Wayland] using WIds created by a different process to create KMessageBox'es and other widgets/windows

2015-12-09 Thread Martin Graesslin 
On Wednesday, December 9, 2015 1:29:41 PM CET René J.V. Bertin wrote:
> KWindowSystem::setMainWindow() is a different matter. Firstly, it does NOT
> use the plugin architecture currently, but simply assumes that
> QWindow::fromWinId() will always work (and never crash).

oh that explains a lot... Like why couldn't I find it in my Wayland backend, 
why do random applications crash on Wayland...

> For the time being
> it will thus require ifdefs.

nah, won't help. Well would help for OSX, but not for Linux/Wayland. I think 
we need to move it to plugin architecture, too.

> Beyond that, exactly how should I adapt it?
> Never do anything on OS X (the solution used currently in
> KDELibs4/MacPorts)? Or check the result from QWidget::find() and only do
> its job when that function returns a valid pointer (which could actually be
> the general approach if that find() function isn't expensive on platforms
> where calling it is redundant).
> 
> Beyond that I suppose that setMainWindow() is *not* the place to push the
> new window to the foreground so that it doesn't get overlooked - or is it?
> In other words, what exactly is the role of KWindowSystem's main window?

It's an X11 thing (like most KWindowSystem methods) for parent-child 
relationship. It's not about raising windows, etc. That's up to the windowing 
system.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [OS X/Wayland] using WIds created by a different process to create KMessageBox'es and other widgets/windows

2015-12-09 Thread Kai Uwe Broulik 
‎> On OS X (and MS Windows?), 

And Wayland, so it affects Linux, too.



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

Re: Review Request 126185: Make the KAppTemplate CMake module global

2015-12-09 Thread Aleix Pol Gonzalez 

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



kde-modules/KDETemplateGenerator.cmake (line 59)


Naming them .zip on windows, won't make it a zip file, if you use tar j. I 
suggest just using .tar.bz2 everywhere.


- Aleix Pol Gonzalez


On Dec. 9, 2015, 12:27 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 9, 2015, 12:27 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDETemplateGenerator.cmake PRE-CREATION 
>   kde-modules/KDEInstallDirs.cmake b7cd34d 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 126185: Make the KAppTemplate CMake module global

2015-12-09 Thread Aleix Pol Gonzalez 


> On Dec. 9, 2015, 1:03 p.m., Aleix Pol Gonzalez wrote:
> > kde-modules/KDETemplateGenerator.cmake, line 59
> > 
> >
> > Naming them .zip on windows, won't make it a zip file, if you use tar 
> > j. I suggest just using .tar.bz2 everywhere.
> 
> Marco Martin wrote:
> is it guaranteed that the .tar.bz2 file will be correctly generated on 
> windows too?

cmake generates it, so yes. I'm less sure of whether .tar.bz2 is available 
commonly on windows on runtime, but we're talking project templates anyway, so 
it should be fine.


- Aleix


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


On Dec. 9, 2015, 1:12 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 9, 2015, 1:12 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDETemplateGenerator.cmake PRE-CREATION 
>   kde-modules/KDEInstallDirs.cmake b7cd34d 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: [OS X/Wayland] using WIds created by a different process to create KMessageBox'es and other widgets/windows

2015-12-09 Thread René J . V . Bertin 
On Wednesday December 09 2015 13:51:47 Martin Graesslin wrote:

> > KWindowSystem::setMainWindow() is a different matter. Firstly, it does NOT
> > use the plugin architecture currently, but simply assumes that
> > QWindow::fromWinId() will always work (and never crash).
> 
> oh that explains a lot... Like why couldn't I find it in my Wayland backend, 
> why do random applications crash on Wayland...

You actually missed this? :)

> nah, won't help. Well would help for OSX, but not for Linux/Wayland. I think 
> we need to move it to plugin architecture, too.

I agree. When I said "for the time being" that was also because I have been 
developing my MacPorts build/packaging scripts at the same time as installing 
(bootstrapping) KF5, and even the current KWindowSystem git/head refuses to 
build against 5.16.0 (and I'd just as well have only a single set of build 
directories). Oh well...

Is Wayland detection purely a runtime thing?

> > Beyond that I suppose that setMainWindow() is *not* the place to push the
> > new window to the foreground so that it doesn't get overlooked - or is it?
> > In other words, what exactly is the role of KWindowSystem's main window?
> 
> It's an X11 thing (like most KWindowSystem methods) for parent-child 
> relationship. It's not about raising windows, etc. That's up to the windowing 
> system.

That confirms my impression about setMainWindow(). As to the "up to the 
windowing system" bit, that's a lot less simple.
From what I understand, the purpose of using a WId from another application is 
to ensure that the newly created window/dialog displays alongside the windows 
of that application (above them if the window manager is set to stack new 
windows that way). On OS X, windows are always opened in front of the other 
windows of the same application (unless the application instructs differently). 
Assuming that that owning application is frontmost (the one being used 
interactively) when the dialog is created, that should be a sufficient way to 
ensure that the dialog is seen by the user, without forcing it to the front or 
even setting a WM hint.

In practice it doesn't always work that way; even on X11 things like wallet 
password requests tend to "pop down" somewhere behind a random amount of other 
windows. That happens often enough that I patched the akonadi mail transport 
agent so that it handles wallet unlock timeouts more intelligently.
On OS X it would be systematic, which was among the reasons I made a Keychain 
backend for KWallet; at least the native API puts password unlock requests up 
right in your face. Annoying at times, but appropriately so IMHO.

This is why I asked if there are classes where it would make sense to force a 
window to the foreground if it cannot be opened alongside (= just above) the 
windows of the application that's responsible for that new window's creation. 
KMessageBox seems like a justifiable candidate to me.

Note: if an application posts an alert on OS X it will depend on certain things 
if that alert is posted in front of everything else (alert type among others). 
I'm not sure I really know the rules but it's a fact that every so often you'll 
happen upon an alert that got posted somewhere behind other things (or on a 
different "Space", virtual desktop) ... or you are alerted by another signal 
that draws your attention to some background app that requires it. Typically 
that will be a bouncing Dock icon ... and evidently that's not possible in a 
background app ("agent") that doesn't have Dock presence.

R.
___
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

2015-12-09 Thread Mark Gaiser 
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.
___
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

2015-12-09 Thread 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: Moving KWayland to frameworks

2015-12-09 Thread Kevin Ottens 
Hello,

On Wednesday 09 December 2015 10:07:50 Martin Graesslin wrote:
> On Thursday, November 5, 2015 11:10:49 AM CET Kevin Ottens wrote:
> > Hello,
> > 
> > On Thursday 05 November 2015 10:50:06 Martin Graesslin wrote:
> > > There are two things which make the move to frameworks difficult and I
> > > don't see a solution to it at the moment:
> > > 
> > > 1. We require C++11 without exceptions: reason, it's designed for Linux
> > > and
> > > it didn't come to my mind to restrict us on the compiler due to lack of
> > > support in Visual Studio.
> > > 
> > > 2. We use Qt 5.4.
> > > 
> > > For item 1 I only see the possibility of adding an exception [1].
> > 
> > I personally don't like exceptions, it gets complex fast.
> > 
> > Now are you sure it is really problematic? To me it looks like you're
> > using almost exclusively features from the white list. It is probably just
> > a matter of s/nullptr/Q_NULLPTR/ and s/override/Q_DECL_OVERRIDE/ in your
> > case.
> 
> I just started looking into doing the replacement and noticed that I'm also
> using:
> * Non-static data member initializers (N2756), gcc 4.7
> * Range-based for (N2930), gcc 4.6

Note that if you do that with Qt containers it's likely a bad idea. It's 
likely to detach and copy whole containers if they are non-const. Qt 
containers should be used with foreach always to avoid problems (and yes 
that's a shame IMHO).

> * constexpr, gcc 4.6
> * possibly also delegating ctors, gcc 4.7 (difficult to find)
> 
> Overall it looks to me like I cannot make this code base to work again with
> gcc 4.5 without spending a lot of time and possibly introducing regressions.

I would disagree here, it's not exactly difficult for all the cases to move 
back to being supported by gcc 4.5. Most of the features you mentioned are 
almost unused in your code base. I found only one constexpr use, two inherited 
ctors, no delegated ctors. The only annoying ones could be the data member 
initializers since you got a few in private headers and the for range loop 
(which I think you should change anyway).

> So how should we go on?

My opinion still stands: fix it. :-)

Alternatively, we could bump the compiler requirements globally for KF5 again. 
But I think it's too early for that, I'd wait for Qt 5.7 to be out (since 
they'll move their baseline as well at that point anyway).

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

2015-12-09 Thread René J . V . Bertin 

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

Review request for KDE Software on Mac OS X and KDE Frameworks.


Repository: kwindowsystem


Description
---

KWindowSystem has been lacking a platform plugin for OS X. This RR presents a 
"backport" of the modified KDE4 KWindowSystem implementation that has been used 
in the MacPorts kdelibs4 port for the last 2 or 3 (or more) years.

I have made some initial steps to remove deprecated Carbon API calls, but this 
is clearly a work in progress.

Open questions include
- is there any justification to run an event handler (or Cocoa observer) to 
keep track of running applications, possibly even listing all their open 
windows?
- is there any use for the Qt event listener framework (cf. the NETEventFilter 
in the X11 plugin)? I haven't yet had time to try to figure out what this 
"could be good for", and am very open to suggestions in this departments.
- one application for such an event filter would be a listener that catches the 
opening and closing of all windows by the running process, and keeps track of 
their `WId`s. A new method could then be added (to `KWindowInfo`?) to 
distinguish `WId`s created by the running application from "foreign" ones 
(useful also on Wayland and MS Windows).

`KWindowSystem::setMainWindow` should become a front for payload provided by 
the plugins. I'll leave that to the regular/official maintainer(s) of this 
framework.

This code could probably do with *lots* of comments; I'll try to add them as 
questions about this or that bit of code arise.


Diffs
-

  src/platforms/osx/plugin.cpp PRE-CREATION 
  src/platforms/osx/plugin.h PRE-CREATION 
  src/platforms/osx/kwindowsystem_macobjc.mm PRE-CREATION 
  src/platforms/osx/kwindowsystem_p_cocoa.h PRE-CREATION 
  src/platforms/osx/kwindowsystem_mac_p.h PRE-CREATION 
  src/platforms/osx/kwindowsystem.cpp 2fcec18 
  src/platforms/osx/kwindowinfo_mac_p.h 26ff790 
  src/platforms/osx/kwindowinfo_p_cocoa.h PRE-CREATION 
  src/platforms/osx/kwindowinfo.mm PRE-CREATION 
  src/platforms/osx/cocoa.json PRE-CREATION 
  src/platforms/osx/kwindowinfo.cpp 328d6a9 
  src/kwindowsystem.cpp 9ef273f 
  src/platforms/osx/CMakeLists.txt 4fc3347 

Diff: https://git.reviewboard.kde.org/r/126291/diff/


Testing
---

On OS X 10.9.5 with Qt 5.5.1 and frameworks 5.16.0 .


Thanks,

René J.V. Bertin

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

Review Request 126295: Fix wrong button in KUrlNavigator issue caused by 9dbe36f734b5b839b2a6a934fad29d639e954498

2015-12-09 Thread Xuetian Weng 

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

Review request for KDE Frameworks, David Faure and Emmanuel Pescosta.


Repository: kio


Description
---

9dbe36f734b5b839b2a6a934fad29d639e954498 breaks some assumption on startIndex. 
The argument index passed to buttonUrl is based number of '/'in full url. 
Because of that, url like "sftp://a...@b.com/a/b; is now shown as 
"sftp:a...@b.com" / "b" / "b" in dolphin url bar.

This patch changes all relevant code that calls buttonUrl() to use url.path() 
instead of url.toDisplayString() to count the number of "/".


Diffs
-

  src/filewidgets/fix-url-navigator.patch PRE-CREATION 
  src/filewidgets/kurlnavigator.cpp 848e98b 

Diff: https://git.reviewboard.kde.org/r/126295/diff/


Testing
---

Remote url -> ok
Local url -> ok
Remote url in places and try browse some sub folder -> ok
Local url in places and try browse some sub folder -> ok


Thanks,

Xuetian Weng

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

Re: [OS X/Wayland] using WIds created by a different process to create KMessageBox'es and other widgets/windows

2015-12-09 Thread René J . V . Bertin 
Kai Uwe Broulik wrote:

> ‎> On OS X (and MS Windows?),
> 
> And Wayland, so it affects Linux, too.

Yes, I learned that while composing my message (cf. the subject).

FWIW, I just provided an initial/WIP implementation of a KWindowSystem plugin 
for OS X: https://git.reviewboard.kde.org/r/126291/

R.

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

Jenkins-kde-ci: threadweaver master kf5-qt5 » Linux,gcc - Build # 22 - Failure!

2015-12-09 Thread no-reply 

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/threadweaver%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/22/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 09 Dec 2015 23:31:32 +
Build duration: 33 sec

CHANGE SET
Revision 85df33387e65fe9c0c1e3e37baedf9fea017072f by Alex Richardson: (No 
longer use deprecated qt5_use_modules)
  change: edit examples/HelloInternet/CMakeLists.txt
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: threadweaver master stable-kf5-qt5 » Linux,gcc - Build # 23 - Failure!

2015-12-09 Thread no-reply 

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/threadweaver%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/23/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 09 Dec 2015 23:31:32 +
Build duration: 1 min 4 sec

CHANGE SET
Revision 85df33387e65fe9c0c1e3e37baedf9fea017072f by Alex Richardson: (No 
longer use deprecated qt5_use_modules)
  change: edit examples/HelloInternet/CMakeLists.txt
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124147: Create Data Dir If it Does Not Exist

2015-12-09 Thread David Narváez 

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

(Updated Dec. 10, 2015, 6:55 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 308155ba6f095e37c348fbb3a74774948280fc7c by David E. 
Narvaez to branch master.


Repository: kio


Description
---

Prevents a cold start bug when the data dir is not created. Also, by
storing the file name as a member of the KCookieServer class we avoid
calculating it every time cookies are saved.


Diffs
-

  src/ioslaves/http/kcookiejar/kcookieserver.h 
f61c7d0e4da58b805565632cf3dd484445c21275 
  src/ioslaves/http/kcookiejar/kcookieserver.cpp 
ac585a0b04637c485647564d18a89a75d6c11d97 

Diff: https://git.reviewboard.kde.org/r/124147/diff/


Testing
---

Restarted kded5 with no file named kcookiejar inside ~/.local/share and with a 
regular file named kcookiejar in that location.

In my setup, the message box is not showing properly but I am not sure if this 
is somethign that happens only on my computer or if this is something wrong 
with the code, can somebody confirm?


Thanks,

David Narváez

___
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

2015-12-09 Thread Martin Graesslin 
On Wednesday, December 9, 2015 4:03:24 PM CET Aleix Pol wrote:
> 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=4f67cc55104fe1081b
> >> 05d381e9516e0215f8e24a=1b97d4427257120e305408404bff5ec6be0b65a9=qgui
> >> platformplugin_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.

+1. I also just don't get Mark's points. It sounds to me like the "oh gosh a 
dependency on Plasma is EVIL". If users have a problem with installing the 
dependency because it's part of Plasma and not part of Frameworks I'd say bad 
luck for them. We shouldn't code around barriers in people's mind.

> 
> 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).

+1. And as I said: if other desktop environments consider our file dialog 
superior, we should make sure they can use it through a framework in their 
QPT. But they should not use our QPT. If they use our QPT they will hit a 
problem somewhen in future when we change something for better integration 
with Plasma and that just doesn't work at all with $DE.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Moving KWayland to frameworks

2015-12-09 Thread Martin Graesslin 
On Wednesday, December 9, 2015 6:14:47 PM CET Kevin Ottens wrote:
> > I just started looking into doing the replacement and noticed that I'm
> > also
> > using:
> > * Non-static data member initializers (N2756), gcc 4.7
> > * Range-based for (N2930), gcc 4.6
> 
> Note that if you do that with Qt containers it's likely a bad idea. It's
> likely to detach and copy whole containers if they are non-const. Qt
> containers should be used with foreach always to avoid problems (and yes
> that's a shame IMHO).

I'm aware of that and my usage of the range-based for is only in cases where 
it's not going to detach.

> 
> > * constexpr, gcc 4.6
> > * possibly also delegating ctors, gcc 4.7 (difficult to find)
> > 
> > Overall it looks to me like I cannot make this code base to work again
> > with
> > gcc 4.5 without spending a lot of time and possibly introducing
> > regressions.
> I would disagree here, it's not exactly difficult for all the cases to move
> back to being supported by gcc 4.5. Most of the features you mentioned are
> almost unused in your code base. I found only one constexpr use, two
> inherited ctors, no delegated ctors. The only annoying ones could be the
> data member initializers since you got a few in private headers and the for
> range loop (which I think you should change anyway).

yes, that's the annoying one which is lots of work and lots of possible 
regressions. I'm not sure whether I'm willing to do that work which I consider 
a useless exercise.

> 
> > So how should we go on?
> 
> My opinion still stands: fix it. :-)

As I just said: I consider this as a useless exercise and a waste of my time 
(and of anybody else who would do that). If we cannot have an exception I 
think I'll leave KWayland in kde-workspace.

> 
> Alternatively, we could bump the compiler requirements globally for KF5
> again. But I think it's too early for that, I'd wait for Qt 5.7 to be out
> (since they'll move their baseline as well at that point anyway).

Well it doesn't need to be a global bump of compiler requirements. But we 
could consider different compiler requirements for frameworks which are non-
portable. KWayland will never be built on Windows neither on OSX. So any 
compiler restrictions on it just shouldn't matter.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kio master stable-kf5-qt5 » Linux,gcc - Build # 173 - Fixed!

2015-12-09 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/173/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 10 Dec 2015 06:56:02 +
Build duration: 5 min 9 sec

CHANGE SET
Revision 308155ba6f095e37c348fbb3a74774948280fc7c by david.narvaez: (Create 
Data Dir If it Does Not Exist)
  change: edit src/ioslaves/http/kcookiejar/kcookieserver.h
  change: edit src/ioslaves/http/kcookiejar/kcookieserver.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 47 test(s), Skipped: 0 test(s), Total: 
47 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 24808/50035 
(50%)CONDITIONAL 13414/20713 (65%)

By packages
  
autotests
FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7047/7264 
(97%)CONDITIONAL 3851/7067 (54%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 
(100%)CONDITIONAL 166/272 (61%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 
60/90 (67%)
src.core
FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7397/14021 
(53%)CONDITIONAL 3874/5383 (72%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2286/7590 
(30%)CONDITIONAL 915/1409 (65%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 430/843 (51%)CONDITIONAL 
313/459 (68%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3799 
(20%)CONDITIONAL 547/678 (81%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 
602/758 (79%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 684/1182 (58%)CONDITIONAL 
358/495 (72%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 
433/820 (53%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 
86/108 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 384/600 (64%)CONDITIONAL 
280/408 (69%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 
146/254 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 
42/52 (81%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 
147/194 (76%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 
14/18 (78%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 226/256 (88%)CONDITIONAL 
292/358 (82%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2684/10636 
(25%)CONDITIONAL 1280/1874 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kio master stable-kf5-qt5 » Linux,gcc - Build # 173 - Fixed!

2015-12-09 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/173/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 10 Dec 2015 06:56:02 +
Build duration: 5 min 9 sec

CHANGE SET
Revision 308155ba6f095e37c348fbb3a74774948280fc7c by david.narvaez: (Create 
Data Dir If it Does Not Exist)
  change: edit src/ioslaves/http/kcookiejar/kcookieserver.h
  change: edit src/ioslaves/http/kcookiejar/kcookieserver.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 47 test(s), Skipped: 0 test(s), Total: 
47 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 24808/50035 
(50%)CONDITIONAL 13414/20713 (65%)

By packages
  
autotests
FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7047/7264 
(97%)CONDITIONAL 3851/7067 (54%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 
(100%)CONDITIONAL 166/272 (61%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 
60/90 (67%)
src.core
FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7397/14021 
(53%)CONDITIONAL 3874/5383 (72%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2286/7590 
(30%)CONDITIONAL 915/1409 (65%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 430/843 (51%)CONDITIONAL 
313/459 (68%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3799 
(20%)CONDITIONAL 547/678 (81%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 
602/758 (79%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 684/1182 (58%)CONDITIONAL 
358/495 (72%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 
433/820 (53%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 
86/108 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 384/600 (64%)CONDITIONAL 
280/408 (69%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 
146/254 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 
42/52 (81%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 
147/194 (76%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 
14/18 (78%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 226/256 (88%)CONDITIONAL 
292/358 (82%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2684/10636 
(25%)CONDITIONAL 1280/1874 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Moving KWayland to frameworks

2015-12-09 Thread Boudhayan Gupta 
On 10 December 2015 at 12:32, Martin Graesslin  wrote:
> yes, that's the annoying one which is lots of work and lots of possible
> regressions. I'm not sure whether I'm willing to do that work which I consider
> a useless exercise.

In my opinion this discussion is an useless exercise, because:

> Well it doesn't need to be a global bump of compiler requirements. But we
> could consider different compiler requirements for frameworks which are non-
> portable. KWayland will never be built on Windows neither on OSX. So any
> compiler restrictions on it just shouldn't matter.

Exactly. Anything that's Wayland related is supposed to be on the
bleeding edge right now. Setting compiler restrictions on this
particular framework will serve only to (apologies for my language,
but there really is not a more apt term for this) cockblock KWayland
development. Developing new technologies from scratch is hard; being
unable to use easier constructs for solving problems not only makes
your job harder but frustrates you more (it's there, why can't I use
this?)

I may be wrong, but I'm guessing Wayland came quite a while after
gcc-4.5 did, and that they use features that require gcc>4.5.

IMO non-portable frameworks should not be subject to the global
compiler requirements at all, but use more platform-appropriate
compiler requirements.

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

Re: Review Request 123229: Ensure we don't crash when using KIO from non-QApplication process

2015-12-09 Thread Aleix Pol Gonzalez 


> On April 7, 2015, 5:38 p.m., Aleix Pol Gonzalez wrote:
> > src/widgets/jobuidelegate.cpp, line 391
> > 
> >
> > This is not correct, it's too early to figure out if it's going to have 
> > a QApplication or not. Breaks some test.
> 
> David Faure wrote:
> Which test? Can you be more specific?

Actually not. I've been trying to reproduce and I really cannot...


- Aleix


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


On Dec. 7, 2015, 2:29 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123229/
> ---
> 
> (Updated Dec. 7, 2015, 2:29 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Prevents the UiDelegate and UiTracker to get initialized, because they'll try 
> to create windows and dialogs when some things happen and these will 
> immediately end in a crash.
> 
> 
> Diffs
> -
> 
>   src/widgets/kdynamicjobtracker.cpp 14924d5 
> 
> Diff: https://git.reviewboard.kde.org/r/123229/diff/
> 
> 
> Testing
> ---
> 
> Ran the tests, my unit test doesn't crash anymore.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
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

2015-12-09 Thread Aleix Pol 
On Tue, Dec 8, 2015 at 8:07 PM, Alex Merry  wrote:
> On 2015-12-03 18:29, Aleix Pol wrote:
>>
>> On Wed, Dec 2, 2015 at 11:56 PM, Mark Gaiser  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: Review Request 123229: Ensure we don't crash when using KIO from non-QApplication process

2015-12-09 Thread Aleix Pol Gonzalez 


> On Dec. 8, 2015, 9 a.m., David Faure wrote:
> > I don't understand why the move to Q_COREAPP_STARTUP_FUNCTION. That startup 
> > function is only about creating some singleton, not about registering a 
> > KJob (which is where the qApp type check happens).
> > 
> > If the startup function needs to see a fully constructed app (why?) - then 
> > Q_COREAPP_STARTUP_FUNCTION is too early, it's called by the 
> > QCoreApplication constructor.
> > But I don't understand what was the problem with the function being called 
> > even earlier. Do we have a case where a kio job is created before the app 
> > is constructed? (that sounds wrong).

Well, it doesn't make sense to have it until there's a QApplication, so it's a 
sensible change. I can also propose it separately if you prefer.

OTOH, you are right, it doesn't seem to have an impact on the tests run. At 
least on the ones within KIO. I shouldn't have let this patch stay for so 
long...


- Aleix


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


On Dec. 7, 2015, 2:29 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123229/
> ---
> 
> (Updated Dec. 7, 2015, 2:29 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Prevents the UiDelegate and UiTracker to get initialized, because they'll try 
> to create windows and dialogs when some things happen and these will 
> immediately end in a crash.
> 
> 
> Diffs
> -
> 
>   src/widgets/kdynamicjobtracker.cpp 14924d5 
> 
> Diff: https://git.reviewboard.kde.org/r/123229/diff/
> 
> 
> Testing
> ---
> 
> Ran the tests, my unit test doesn't crash anymore.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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