Proposal to plan for "Milestone Releases" on the way to KDE4
js at iidea.pl
Thu Jan 26 20:04:44 GMT 2006
Boudewijn Rempt said the following, On 2006-01-24 22:35:
> Good stuff and well thought-out... Especially the recognition that app
> developers are not lib developers, which makes all the difference.
> But since I have already entered the public discussion, I'm going to going to
> reiterate my two cents here.
> * While it's certainly still possible to do cool stuff with Qt 3, that's no
> argument. It's still possible to do cool stuff with Motif, too. For some
> problems Qt3 doesn't cut it, and I happen to be very interested in some of
> these problems.
> * KDE-the-Desktop and KDE-the-development framework are two different beasts.
> A Qt4-based development framework can be very useful withouth Plasma and all
> the other wonderful kennings we've been coining for the past year.
> * A quick release of the development framework followed by a later release of
> the desktop would fit my personal agenda very well. If there are one or two
> releases of KDE application sets for 3.5 in between, fine. But KOffice isn't
> going to be among them, as far as I have any say in the matter.
> My ideal roadmap (excluding application and desktop environment releases)
> would be:
> * usable kdelibs4 by mid-March. KOffice porting starts. We'll do the text
> layout thing and fix embedding.
> * I don't care about having to do some keeping-up during the KOffice porting
> * September/October: kdelibs4 is sufficiently stable that it is possible to
> release a beta of KOffice that depends on it. This beta will run just fine in
> a KDE 3.5 desktop, perhaps with some limitations like no dcop or so.
> * November/December KOffice 2.0 is released, based on kdelibs4 and available
> on X11, Windows and OS X.
> However: I'm horribly afraid of a late release of KDE-the-desktop, though.
> It's going to cost us whatever mind and marketshare we have left if
> KDE4-the-desktop will take two years, even if we do a kde-apps-are-cool
> release. This year is going to be really interesting.
My opinion here is that 'The New Desktop' features, as presented by our
marketing, are not #1 priority _if_ the goal has to be
"Let's be #1 desktop _and_ desktop framework of choice on UNIX and _important_
on win32 or maxosx as well". At least I rarely heard users asking for these
features like transparent , whil most of them screamed for good applications.
I know, I know, you're owner of your spare time, and it's damn boring to make
application nearly-feature-complete and usable while it can be damn nice to
implement some special effects and show them to friend. I am just calling here
for an equilibrium between the se two worlds. I can see KDE4 as a complete
operating system containing much improved _apps_, compared to KDE3.
So, my first private choice (not very novel) could be to give up with binary
and source compatibility policy between KDElibs 4.0.x and 4.1.x, and let
1) to ask for changes making their apps' code clean (sometimes they have been
waiting for this opportunity since 3.0)
2) to propose framework's features they need and give them ability to
implement the features in reusability in mind.
In my department, I've already declared some cool features for kdelibs4, like
- advanced data-aware widgets and higher level database framework
- improved KActions framework that fixes the problem of too many (flickering!)
toolbars on the screen without any idea about current context user is working
with. Funny, in the meantime M$, having the same trouble, decided to fix it
moving to Ribbon[tm] paradigm, aka tabbed toolbars known since HomeSite era as
I mentioned at http://www.kdedevelopers.org/node/1617.
- KDE standards-compliant (maybe web page-like) Wizard as mentioned here
I think quite a few of apps authors would want to address these issues in an
organized manner, probably within kdelibs4. Having unstable KDElibs4.0 API
could help us to realize our good and wrong decisions and fix this in 4.1 as
the topic is too hard to draw it with pencil. That's a part of my point.
A tale with Qt4.0 comes to my mind: I know developers considering Qt4.0.x as
de-facto beta and they accepted Qt4.1.x as much better (after adding some new
missing methods). I am with them. It's not mentioned to blame TT for too early
release, this is for-profit activity after all, and I am doing the same with
my for-profit activities. It's how our world has changed. After so many
Google's BETAs, people begun to understand this idea.
Somewhat other thing can be important here: let's be with our users during our
development, so even if kdelibs4.1 will require developers to update 1% or 5%
of their source code, maybe it's just how things work in such cases? It's
something different idea compared to WINAPI maintaining
no-removed-unsafe/forgotten-C-functions-since-1990 policy (vide the WMF hole) ;)
Let the strategy be "Milestone Releases". Good. Users and app authors ask
"when kdelibs4 release is planned?". My favourite "When it's ready" answer
could mean that deadlines set for particular milestones should be rather
flexible, than based on competition's deadlines as is sometimes suggested
among KDE users and devs (let me mention Vista and Vienna Uber Vaporware).
Speaking about deadlines I am also wondering about our dear packages. These
teams made KDE so well known and available more than anyone. The world we live
in is such that distros are our door to the matrix^h^h^h^h^h^hmass market.
What I'd see _much more_ sane than other ideas, is: help packagers to keep
compatibility (settings, data) between KDE4 and KDE3 apps in the "Intermediate
release" of the KDE4.
I have feeling that there will be mainstream distros prefering to package such
a hybrid beast (if well prepared) and not:
- an (then) oldish KDE3 that does not provide new important marketing-friendly
- nor, an KDE4.0 (let it be -pre relase) that only contains a selection of the
apps offered by 3.x series.
Let the first, hybrid, KDE4 release EVEN be 'KDE3.9.9' (to avoid waste of
marketing value of the counter turning to "real" 4). What about this?
Compatibility: Sometimes it doesn't matter how to keep it. This can be even
performed throught saving the same data twice (in two formats) if really
needed. But keep things just working, thus making the transition easier also
for distro makers.
(Eventually, for "real" KDE 4.x reelase there could be format converters
implemented removing the backward compatibility sometimes making the data
formats unclear or redundand).
I am sure some of you know this much more in depth than me, since 2.0->3.0
transition already introduced this issue. However now we have more apps, these
are more integrated each other, the kdelibs provides more features previously
impleemnted inside apps, we even have entire software suites like Kontact,
KOffice, to name only these two.
BTW, I don't know about others but at least I'll be forced to maintain active
development of 3.x and 4.x Kexi branches for some time in 2006, thus providing
at least one major release within 3.x branch. In my case it's not hard as in
others as the new features will most probably be easily portable to Qt4, and I
try to limit myself by not implementing Qt3 stuff that would need a painful
rewrite/refactoring for Qt4. While proting and refactoring the code I will be
trying to help to make some features "officially" reusable.
I am curious how these things look in case of other projects?
Thanks for reading this long deduction.
regards / pozdrawiam,
Jaroslaw Staniek / OpenOffice Polska
Kexi Developer: http://www.kexi-project.org | http://koffice.org/kexi
Kexi Support: http://www.kexi-project.org/support.html
Kexi For MS Windows: http://kexi.pl/wiki/index.php/Kexi_for_MS_Windows
KDE3, KDE4 Libraries For Developing MS Windows Applications:
More information about the kde-core-devel