Re: Moving KWayland to frameworks
On Thursday 10 December 2015 12:43:29 Martin Graesslin wrote: > On Thursday, December 10, 2015 12:24:06 PM CET Kevin Ottens wrote: > > > 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). > > > > Note that it's a waste of time which could have been easily avoided. If > > the goal was to get something like KWayland in, the white listed > > constructs were known and documented. > > KWayland originated from KWin which already used full C++11 support at that > time. The aim was to use it in other parts of workspace at that time. Moving > into frameworks was not a direct aim at that time. It's something which > showed up as possibly useful only later on. Right, hence my "if" earlier. I guess we'll see more cases like that in the future. We're in a similar situation in Zanshin, I proactively reduce the amount of C++11 I use there for anything which looks reusable in KF5. > > Bumping gcc requirements also has an impact on embedded platforms which > > tend to have older gcc. It's clearly one of the main nest of users for > > KWayland IMHO. I'm not sure what older gcc they tend to run with on the > > platforms supporting wayland but that's still something to consider > > (especially since wayland itself is not very demanding on the compiler as > > you pointed out). > > In my opinion it's not realistic to restrict the gcc compiler requirement > anyway. We don't have CI coverage for it, so we never know whether it > actually would compile. My linux distribution doesn't provide gcc < 4.8 > anymore, I wouldn't know how to ensure that the code actually works. This > makes it in my opinion unrealistic that I try to restrict the compiler > requirement again. By the same argument we would not even try to support VS2012. We have the same issue there. I agree with the fact that the CI support is not up to the task for now, I'm not sure that's a reason to ignore the issue preventing the CI to ever catch up. > Anyway, I don't see that I have time to rewind the C++11 usage. As we cannot > increase the compiler requirement we probably have to keep KWayland in kde/ > workspace and retry once frameworks increases the requirements. Fine with > me. It makes our lifes a little bit harder, especially for > plasma-frameworks, but we will be able to manage that. Fair enough. I wish the compilers would propagate faster though. :-) 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
Re: Moving KWayland to frameworks
On Thursday, December 10, 2015 12:24:06 PM CET Kevin Ottens wrote: > > 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). > > Note that it's a waste of time which could have been easily avoided. If the > goal was to get something like KWayland in, the white listed constructs were > known and documented. KWayland originated from KWin which already used full C++11 support at that time. The aim was to use it in other parts of workspace at that time. Moving into frameworks was not a direct aim at that time. It's something which showed up as possibly useful only later on. > By choosing a more liberal approach it was > necessarily creating a price to pay later on (the useless exercise, or > bumping requirements for everyone reducing user base, or opening the door > to exceptions and reducing the readability of our offer). > > > If we cannot have an exception I think I'll leave KWayland in > > kde-workspace. > As you wish. > > > > 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. > > It doesn't need to indeed. Still, exceptions are my least favorite price to > pay in the list above (second least favorite to me is bumping requirements). > > To make it clear: my opinion is that anything which reduces our user base or > might make our offer harder to read and understand should be considered > last. understood. > > 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. > > Bumping gcc requirements also has an impact on embedded platforms which tend > to have older gcc. It's clearly one of the main nest of users for KWayland > IMHO. I'm not sure what older gcc they tend to run with on the platforms > supporting wayland but that's still something to consider (especially since > wayland itself is not very demanding on the compiler as you pointed out). In my opinion it's not realistic to restrict the gcc compiler requirement anyway. We don't have CI coverage for it, so we never know whether it actually would compile. My linux distribution doesn't provide gcc < 4.8 anymore, I wouldn't know how to ensure that the code actually works. This makes it in my opinion unrealistic that I try to restrict the compiler requirement again. Anyway, I don't see that I have time to rewind the C++11 usage. As we cannot increase the compiler requirement we probably have to keep KWayland in kde/ workspace and retry once frameworks increases the requirements. Fine with me. It makes our lifes a little bit harder, especially for plasma-frameworks, but we will be able to manage that. 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
On Thursday 10 December 2015 08:02:49 Martin Graesslin wrote:
> 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.
Still that's asking for troubles IMO. You got cases already where it actually
calls detach() just that there's no existing copy (yet). Easy to add such a
copy by mistake in maintenance later on. Clearly slippery and error-prone for
everyone with no real gain.
> > > * 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).
In fact I would withdraw my comment regarding range based for loops, it's
likely one command away:
perl -npi -e 's%for\s*\((.*?)\s*:(.*?)\)%foreach (\1,\2)%' **/*.{h,cpp}
> 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).
Note that it's a waste of time which could have been easily avoided. If the
goal was to get something like KWayland in, the white listed constructs were
known and documented. By choosing a more liberal approach it was necessarily
creating a price to pay later on (the useless exercise, or bumping
requirements for everyone reducing user base, or opening the door to
exceptions and reducing the readability of our offer).
> If we cannot have an exception I think I'll leave KWayland in kde-workspace.
As you wish.
> > 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.
It doesn't need to indeed. Still, exceptions are my least favorite price to
pay in the list above (second least favorite to me is bumping requirements).
To make it clear: my opinion is that anything which reduces our user base or
might make our offer harder to read and understand should be considered last.
> 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.
Bumping gcc requirements also has an impact on embedded platforms which tend
to have older gcc. It's clearly one of the main nest of users for KWayland
IMHO. I'm not sure what older gcc they tend to run with on the platforms
supporting wayland but that's still something to consider (especially since
wayland itself is not very demanding on the compiler as you pointed out).
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
Re: Moving KWayland to frameworks
On Thursday, December 10, 2015 1:07:42 PM CET Boudhayan Gupta wrote:
> 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.
I rather doubt that this is actually the case. Wayland is a c-library and we
need to explicitly set in KWayland:
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu90")
in order to compile generated Wayland protocols.
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
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: Moving KWayland to frameworks
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
Re: Moving KWayland to frameworks
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
Re: Moving KWayland to frameworks
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: Moving KWayland to frameworks
On Thursday, November 5, 2015 10:50:06 AM CET Martin Graesslin wrote: > 2. We use Qt 5.4. Given David's suggestion on having the last three released Qt releases supported, this issue will resolve itself once Qt 5.6 is released. Given that this is on the horizon I will delay the move of KWayland to frameworks till Qt 5.6 is released and Qt 5.4 the required frameworks version. 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
On Thursday 05 November 2015 10:50:06 Martin Graesslin wrote: > Hi, > > after the Plasma 5.5 release I would like to move KWayland to frameworks. > The main reason is that it is oddly placed in plasma-workspace as it's also > a library useful for applications (example kde-connect uses it already). > +1, and i think it has been good for it to be incubating in a place outside frameworks for a while, that should be more the norm -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Moving KWayland to frameworks
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. 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
