KDE 4.0.x Requirement

[ivan.cukic]

"The used Qt 4 technology must have been released, i.e. not snapshots. Plasmoid entries must compile against KDE 4.0.x."

Could somebody please explain why there's a request for using 4.0.x branch of KDE for Plasmoid development?

I kindly ask you to reconsider this decision because of the following:

* According to the KDE 4.1 roadmap, it will be released two months before the contest deadline (and a month later than 4.1.1). In the eventuality that the release is late for more than two months (highly unlikely), it will be stable enough, and APIs will be frozen by that time.

* In 4.1, plasma will use Widgets on Canvas which is not a small change and is likely to break compatibility. This means that the developers that want to participate in this contest and to have their plasmoids ready for 4.1, will have to keep and develop two separate versions of their plasmoids.

[wysota]

We might think about it but I personally doubt it is going to happen. Why? Because if we asked people to compile against 4.1, they'd have to wait until 4.1 gets stable enough before they start working on their plasmoids.

What we possibly could do is to allow both 4.0 and 4.1 if 4.1.0 gets released early enough. The idea behind the rule was to make sure people don't use unstable releases. Based on the fact that KDE releases are usually late (ekhm.... sorry, but that's has been the truth so far), we're facing a race condition here.

As for widgets on canvas, this is a Qt not KDE feature, so you might safely use it with KDE 4.0.x as long as you build the latter against Qt 4.4. Or am I wrong here?

Either way let's wait until 4.1 starts crystalizing. I can promise we'll be monitoring the situation. People developing against 4.0.x can be almost sure that their plasmoids will compile against 4.1 if they do compile against 4.0 (at least provided KDE's API will be fully backward compatible).

Edit: Oh, one more thing...

* In the eventuality that the release is late for more than two months (highly unlikely), it will be stable enough, and APIs will be frozen by that time.
Well, yes, but in this situation you're forcing the judges to battle unstable KDE installations instead of reviewing your code. Stable release is not only about robustness of the API...



Feel free to comment. The contest is for you people and so are the rules, so there is a possibility to change them. We only want to make sure the engagement is fair.

[Shadowfiend]

Side note: as Aaron Seigo has mentioned (http://dot.kde.org/1207154042/1207224126/1207237994/), Plasma itself will not be binary compatible between the 4.0 and 4.1 releases of KDE: instead becoming binary compatible after 4.1.

[ivan.cukic]

What we possibly could do is to allow both 4.0 and 4.1 if
Well, that would be the solution I was hoping for.

As for widgets on canvas, this is a Qt not KDE feature, so you might safely use it with KDE 4.0.x as long as you build the latter against Qt 4.4. Or am I wrong here?
Unfortunately, you are wrong :) Plasma (ATM) has its own Widget, LayoutItem, LayoutManager etc. Plasma::Widget is built on top of QGraphicsItem and the current layouting system is KDE-only. Widget will have to be changed to subclass QGraphicsWidget, and layout mechanisms will be based on QGraphicsLayout.

Although it /could/ turn out that every class will retain both its API and a bug-for-bug-feature-for-feature behaviour, I'm not too optimistic it will.

People developing against 4.0.x can be almost sure that their plasmoids will compile against 4.1 if they do compile against 4.0 (at least provided KDE's API will be fully backward compatible).
Even if that is the case (concerning the API stability) there will be a couple of new features in plasma 4.1 which will then have to be out-of-reach for the mentioned developers that build against 4.0.

I'm concerned about the other group of developers (myself included) - the ones that work on KDE and Plasma. We would have to keep two different versions of KDE 4. In order to hack on Plasma, we have to have the SVN version. And to participate in the contest, we would need to compile in parallel the 4.0 tree as well.

Well, yes, but in this situation you're forcing the judges to battle unstable KDE installations instead of reviewing your code. Stable release is not only about robustness of the API...
Call me spoiled, but I do believe that installing unstable KDE (in the case 4.1 *is* late for more than two months) is a lesser nuance than developing an application for two different library versions* :) (I've been battling with unstable KDE installations for quite some time now :) so I know what I'm talking about)

* especially when it is not the 4.0 unstable we are talking about, but 4.1

Cheers :)

[C167]

and getting an installation of KDE 4.1 is not that hard using kdesvn-build if configured to get trunk. The majority of modules build almost every time, only some stuff from extragear/playground does not.

[wysota]

and getting an installation of KDE 4.1 is not that hard using kdesvn-build if configured to get trunk. The majority of modules build almost every time, only some stuff from extragear/playground does not.

My personal problem is that I don't use KDE4 right now, so I don't have all the dependencies installed. This all can be overcome though by preparing a live-cd with KDE 4.1 and the development tools. I'll start the discussion right away - hopefully we will have a positive decision by tomorrow.

[ivan.cukic]

Thanks for your effort! :)

[aseigo]

We might think about it but I personally doubt it is going to happen. Why? Because if we asked people to compile against 4.1, they'd have to wait until 4.1 gets stable enough before they start working on their plasmoids.

4.1 is already stable enough to do so already (proof: people are writing new plasmoids against 4.1 right now), and they can also work against 4.0 if they'd prefer.

What we possibly could do is to allow both 4.0 and 4.1 if 4.1.0 gets released early enough. The idea behind the rule was to make sure people don't use unstable releases.

i don't see why we can't just leave it up to the submitter.

Based on the fact that KDE releases are usually late (ekhm.... sorry, but that's has been the truth so far)

that's wildly innacurate. 4.0 was a long time coming, but our non-BC-breaking/rework-the-api releases (e.g. all of 1.x, 2.x, 3.x) have been on time with occasional slippage of a week here or there. our 4.0.x releases have been on time, and i don't see that changing for 4.1 either. your opinion here seems purely based on 4.0 which is a highly anomalous release, akin to 2.0.

As for widgets on canvas, this is a Qt not KDE feature, so you might safely use it with KDE 4.0.x as long as you build the latter against Qt 4.4. Or am I wrong here?

KDE 4.0 should run without relinking; the issue is integrating nicely with plasma's layout system. not a huge deal either way, but WoC really isn't a driving issue here imho.

Either way let's wait until 4.1 starts crystalizing. I can promise we'll be monitoring the situation. People developing against 4.0.x can be almost sure that their plasmoids will compile against 4.1 if they do compile against 4.0 (at least provided KDE's API will be fully backward compatible).

it isn't. over a year ago it was clearly stated that libplasma would break BC and even possibly SC between 4.0 and 4.1. the SC changes are thus far minor to say the least, as far impact on applets go, however. so it's not a big issue.

Well, yes, but in this situation you're forcing the judges to battle unstable KDE installations instead of reviewing your code.

the code in trunk/ is already more stable than what is in 4.0.x, so this isn't a real concern. what would be a concern is getting easy access to a testing env (e.g. without spending hours compiling and setting up kdelibs, kdebase). that said, how many of the judges. that will be grading the plasmoid entries don't have access already to a 4.1 release? personally it's what i run daily. i'm fine with vetting any 4.1 based entries we get.

my big concern with saying "4.0 only" is that it really makes it more difficult for people who'd like to contribute but who are tracking kde's svn as well.

[wysota]

Hi Aaron,

4.1 is already stable enough to do so already (proof: people are writing new plasmoids against 4.1 right now), and they can also work against 4.0 if they'd prefer.
Ok, you know best.

i don't see why we can't just leave it up to the submitter.
Oh, this is easy to answer - without a frozen release we'd be battling situations where some project works on a particular snapshot and doesn't work on some other. That's why we denied Qt snapshots and that was the idea of forbidding the use of unstable releases of KDE (as a natural consequence to the former) and the 4.1 branch was just being born at the time of writing the rules.

your opinion here seems purely based on 4.0 which is a highly anomalous release, akin to 2.0.
Actually it was based on 3.x. I know how much work it was to release 4.0 and my personal opinion was you could have even waited longer to do that (though I fully understand reasons of releasing 4.0 when it was released). A leap between 4.0 and 4.1 will be quite significant, thus we have to assume a possibility of some show-stoppers delaying the release more than one week.

the code in trunk/ is already more stable than what is in 4.0.x, so this isn't a real concern. what would be a concern is getting easy access to a testing env (e.g. without spending hours compiling and setting up kdelibs, kdebase). that said, how many of the judges. that will be grading the plasmoid entries don't have access already to a 4.1 release? personally it's what i run daily. i'm fine with vetting any 4.1 based entries we get.
I won't argue with that although my personal experiences differ. I don't have trouble building and running my own programs which isn't necessarily the case for others ;)

my big concern with saying "4.0 only" is that it really makes it more difficult for people who'd like to contribute but who are tracking kde's svn as well.
True. And we want to void that concern of yours as we share your point of view :)

I wanted to assure you and everybody else we have nothing against KDE 4.1, we're just keepers of order in the competition. Last year the evaluation process was too long and this year we want to reduce it significantly. At some point you have to freeze things and have some certainty what to expect. The competition is for the Community and it is the Community that decides how rules should look. We're the ones trying to keep them coherent, sane and fair.

Bottom line - the rule shall get changed, we all agree to that (with a minor oposition from one of us).

[e8johan]

The rules have been updated (see paragraph 7).