The KDE CVS-Digest for this week: KDevelop has a new project builder. KMail now supports kwallet for mail account passwords. Krita adds KJSEmbed scripting support. KOffice now supports Indic.
Wasn't KDE 4 the next major scheduled release? Why are the KDE team sticking with 3.4 atm? Are D-BUS, Qt 4, and other techologies too immature for now?
When should 3.4 be released, will it be the same blazing release schedule as 3.3 or a bit faster?
Now, that's a starting point for my opinion. I wish the KDE project was split into two major parts. The 'core', and the applications. The core should only consist of the libraries lots of programs use (probably what is called 'kdelibs' now), the main user interface (kwin?), and not a huge lot more (maybe kdebase).
Then one should have the applications. The applications should be decoupled from the main releases, so that users can get new versions of their applications without having to upgrade the _entire_ system, or track CVS-HEAD.
There should be no reason, in my opinion, for the applications all to be released at the same time. They could be released as their maintainers saw fit. Maybe with a policy of trying to support the main release (3.0, in this case) - but with added features for 3.1, 3.2, 3.3 and HEAD - as they use more recent additions to the libraries.
I would love it if I could fetch a new release of kMail sooner than the next major release of kMail is released. The same goes for speed improvements of konqueror, and so forth.
A complete decoupling of the app-releases from the core-releases would be _great_ - in my opinion.
> There should be no reason, in my opinion, for the applications all to be released at the same time
What about translations and documentation? Do you really believe that the translations would be as good as they are now, when the translator have to track 50 different message freeze dates? Same goes for the documentation and there translation.
What about translations and documentation? Do you really believe that the translations would be as good as they are now, when the translator have to track 50 different message freeze dates? Same goes for the documentation and there translation.
Without _knowing_, I would think that those currently engaging in translations would continue to translate their favorite programs as they're currently doing.
Heck, I know that I would be _more_ interested in translating into norwegian if I could track the programs I used without having to upgrade my entire system to CVS-HEAD to be able to translate them and see the effects.
If I could track, say, the latest versions of kMail and kOrganizer, without having to care about the rest of KDE, I would be far more interesting in contributing translations for those programs. Having to wait until the next release of all of KDE is not exactly encouraging in that department.
what's so dramatic if translations are only updated in 3.3.1 or 3.3.2? It is not so much later and the .0 releases are not so stable anyway (as the later ones).
Having to do everything at the same time can slow things down. The string freeze sometimes required people to do silly things (re-using not 100% matching strings or leaving obviously wrong ones).
So instead of requiring all apps to slow down development by staying compatible for one release more, I suggest to just wait till it's stable, even packaged as binaries and then make sure that translation is down with the bug fix releases together.
Well, the string freeze has to take place one time or another.
And whatever the timepoint it will not please somebody. But I do not think that losing KDE's strong point, to have translations from the .0 version on, has to be dropped.
Also between .0 and .1, there are mostly only a month or so. For most teams, that is much too few time.
Well, translations are beside the point. I was arguing for app-releases being split out from the 'big' releases. I don't think it will slow translations down as another person argued.
for coolo's blog with some details. Feature freeze at the end of november, final release march.
QT4 is a ways off, hence KDE4 would probably be around a year away (at least). There probably will be a KDE4 library port branch started as soon as QT4 code becomes available.
If KDE wants to keep all the apps and libraries together for release, a 6 month cycle is necessary. Otherwise the major applications will do their own releases.
KDE3 is a massive pile of code. Moving it to Qt4 will be a reasonably large task, but due to the Trolls good compatibility layers, probably not ultra painful.
Adding a miniscule amount of code to allow the use of DBUS/HAL/Composite is not going to change that very much at all.
Removing/adapting DCOP in favour of DBUS is another matter. It won't be binary compatible, so it won't happen before KDE4.
> KDE3 is a massive pile of code. Moving it to Qt4 will be a reasonably large
> task, but due to the Trolls good compatibility layers, probably not ultra
> painful.
In porting KDElibs3 to Qt4, we can _of course_ _not_ make use of the Qt3 compatibility layer. Apps can, but KDElibs needs to be pure Qt4 _and_ provide compat libs/layers of it's own for kdelibs3 (source) compat.
All in all, I think you grossly underestimate the work that is needed for the Qt4 port.
would it be possible to make a converter ?
there is probably few known differences between Qt 3.3 and 4.
just parse the code for each of these and apply the necessary fixes.
a faster than 3.3 ?
what is that...
3.3 has been the fastest release ever,... the actually push it that fast in order to have a fresh version to play with for the aKademy.
Looks to me easier to fix selinux and fireflier instead of getting rid of kdeinit. If I look at the output from 'ps x', I see what programs/slaves are running. Just strip of 'kdeinit: '. So they could either support kdeinit directly (as KDE is not just an application), or add some finer grid configuration tools per application (as wine and probably others have these issues too).
the use of fork() and the loading of libraries *is* a security problem, you know that: it's pretty obvious.
one process being compromised results in it being able to poison all threads, and also in it being able to utilise any file handles and other stuff [that i am not as familiar with as, say stephen smalley and the other selinux developers] to then compromise any child process etc.
the only way to obtain _complete_ security separation is to exec().
that is the reason why selinux "domain" tracking is done on an exec() and why fork() is most certainly not.
the bottom line is that kdeinit _used_ to provide a significant speedup, on older machines. now it not only gets in the way but there is a better solution (prelink) and its use makes it impossible to do selinux "domains" for the separate kio handlers and the programs that utilise them.
what if i want to write an selinux policy for konqueror that only allows it to do HTTP and IMAP, but nothing else?
i can't even _begin_ that - because of kdeinit: i can't even track the different programs, because they are all named "kdeinit".
if i want to make konqueror only be able to access HTTP, i can't because it's handled by _one_ program that loads all of the kioslave .so libraries.
selinux, like i said, works by tracking "exec"()d programs, so it is _necessary_ to have a kioslave_http program, a kioslave_imap program.
I hope they build it from stratch with simplicity in mind. But obviously not going as far as Gnome 2.* went. And a different default theme which is not plastik and has no round corners unless it uses SVG.
Rewrite from scratch? Why? I think you don't have clue what you're talking about if you suggest to rewrite KDE from scratch. It's a huge, complex piece of code, that generally works very well at the moment. Gradual changes is the way to go. This [1] article is informative on this matter.
They did, for KDE 2. Because 1.0 kind of grew up in a very ad hoc kind of way (I still loved it) the rewrote KDE 2 from the ground up, they thought through the 'problems' of KDE 1, and they learnt. KDE 3 was an easier port (As Qt had changed its interfaces less.). KDE is now a huge chunk of good code that has aged well. Major changes will occur in the 4.0 timeframe, but starting over from scratch is just insane, there's nothing like fixing an obscure bug you crushed in the KDE 2 era, for KDE 4.0.1 .
It'd be pointless to rebuild KDE from the ground up, because most of the guts are quite solid. There are bits here and there that need restructuring (I'd love to see the KIO API rebuilt on top of a cross-desktop core), and the UI needs work (yay for Aaron Siego), but stuff like that can be built on top of the existing core.
Comments
I'm a bit suprised to find the feature plan for KDE 3.4. http://developer.kde.org/development-versions/kde-3.4-features.html
Wasn't KDE 4 the next major scheduled release? Why are the KDE team sticking with 3.4 atm? Are D-BUS, Qt 4, and other techologies too immature for now?
When should 3.4 be released, will it be the same blazing release schedule as 3.3 or a bit faster?
See here for further information:
http://wiki.kde.org/tiki-index.php?page=KDE+3.4+or+4.0+Discussion
Regards, Juergen
I love KDE. I hate the release schedule.
Now, that's a starting point for my opinion. I wish the KDE project was split into two major parts. The 'core', and the applications. The core should only consist of the libraries lots of programs use (probably what is called 'kdelibs' now), the main user interface (kwin?), and not a huge lot more (maybe kdebase).
Then one should have the applications. The applications should be decoupled from the main releases, so that users can get new versions of their applications without having to upgrade the _entire_ system, or track CVS-HEAD.
There should be no reason, in my opinion, for the applications all to be released at the same time. They could be released as their maintainers saw fit. Maybe with a policy of trying to support the main release (3.0, in this case) - but with added features for 3.1, 3.2, 3.3 and HEAD - as they use more recent additions to the libraries.
I would love it if I could fetch a new release of kMail sooner than the next major release of kMail is released. The same goes for speed improvements of konqueror, and so forth.
A complete decoupling of the app-releases from the core-releases would be _great_ - in my opinion.
> There should be no reason, in my opinion, for the applications all to be released at the same time
What about translations and documentation? Do you really believe that the translations would be as good as they are now, when the translator have to track 50 different message freeze dates? Same goes for the documentation and there translation.
What about translations and documentation? Do you really believe that the translations would be as good as they are now, when the translator have to track 50 different message freeze dates? Same goes for the documentation and there translation.
Without _knowing_, I would think that those currently engaging in translations would continue to translate their favorite programs as they're currently doing.
Heck, I know that I would be _more_ interested in translating into norwegian if I could track the programs I used without having to upgrade my entire system to CVS-HEAD to be able to translate them and see the effects.
If I could track, say, the latest versions of kMail and kOrganizer, without having to care about the rest of KDE, I would be far more interesting in contributing translations for those programs. Having to wait until the next release of all of KDE is not exactly encouraging in that department.
In this particular case, KDEPIM keeps compatibilty to kdelibs 3.2, so you could help translating.
Have a nice day!
Nope. KDE PIM HEAD must be compatible to kdelibs 3.3. See http://lists.kde.org/?l=kde-pim&m=109351225402353.
Ah, sorry!
Well, nevertheless, it is the last stable version, so it should be easier to translate it.
Have a nice day!
Hello,
what's so dramatic if translations are only updated in 3.3.1 or 3.3.2? It is not so much later and the .0 releases are not so stable anyway (as the later ones).
Having to do everything at the same time can slow things down. The string freeze sometimes required people to do silly things (re-using not 100% matching strings or leaving obviously wrong ones).
So instead of requiring all apps to slow down development by staying compatible for one release more, I suggest to just wait till it's stable, even packaged as binaries and then make sure that translation is down with the bug fix releases together.
Yours, Kay
Well, the string freeze has to take place one time or another.
And whatever the timepoint it will not please somebody. But I do not think that losing KDE's strong point, to have translations from the .0 version on, has to be dropped.
Also between .0 and .1, there are mostly only a month or so. For most teams, that is much too few time.
Have a nice day!
Well, translations are beside the point. I was arguing for app-releases being split out from the 'big' releases. I don't think it will slow translations down as another person argued.
http://www.kdedevelopers.org/node/view/600
for coolo's blog with some details. Feature freeze at the end of november, final release march.
QT4 is a ways off, hence KDE4 would probably be around a year away (at least). There probably will be a KDE4 library port branch started as soon as QT4 code becomes available.
If KDE wants to keep all the apps and libraries together for release, a 6 month cycle is necessary. Otherwise the major applications will do their own releases.
Derek
i think we can integrate dbus and the all other fancy stuff (xorg composite) , HAL ... with 3.4 as long as it does not break binary compatibility.
I second that!
And then have a lot of work to port it to KDE 4, introducing more bugs...
I don't think that is a good idea.
Sorry, that is just clueless.
KDE3 is a massive pile of code. Moving it to Qt4 will be a reasonably large task, but due to the Trolls good compatibility layers, probably not ultra painful.
Adding a miniscule amount of code to allow the use of DBUS/HAL/Composite is not going to change that very much at all.
Removing/adapting DCOP in favour of DBUS is another matter. It won't be binary compatible, so it won't happen before KDE4.
> Sorry, that is just clueless.
Sorry, dito.
> KDE3 is a massive pile of code. Moving it to Qt4 will be a reasonably large
> task, but due to the Trolls good compatibility layers, probably not ultra
> painful.
In porting KDElibs3 to Qt4, we can _of course_ _not_ make use of the Qt3 compatibility layer. Apps can, but KDElibs needs to be pure Qt4 _and_ provide compat libs/layers of it's own for kdelibs3 (source) compat.
All in all, I think you grossly underestimate the work that is needed for the Qt4 port.
would it be possible to make a converter ?
there is probably few known differences between Qt 3.3 and 4.
just parse the code for each of these and apply the necessary fixes.
i meant "would not it be possible to ...."
"I'm a bit suprised to find the feature plan for KDE 3.4. http://developer.kde.org/development-versions/kde-3.4-features.html"
I am not ;)
http://dot.kde.org/1091864563/1091892781/1091954569/1091961571/1091965418/
a faster than 3.3 ?
what is that...
3.3 has been the fastest release ever,... the actually push it that fast in order to have a fresh version to play with for the aKademy.
no way any version should be faster...
"Enrico is god!", and he made using konqueror a real pleasure, and I wonder
if there are and other speed improvements in the pipeline...
Let us users know!
Would now not be a good moment to get rid of kdeinit?
I use my system with KDE_IS_PRELINKED=1 and KDE_FORK_SLAVES=1 and see no
noticeable slowdown
Security-wise it could have advantages as a recent thread on kde-devel exposed.
Is your system prelinked? I still don't think the large amount of systems are.
No, it's not!
Speed does not seem to suffer (much) by setting these options, even on an unprelinked system.
Just give it a try!
I heard about these options, but don't know where to set them. Compile-time variables? Or do you just have to export them?
TIA
Michael Jahn
exporting seems to be ok...
my /etc/environment holds:
export KDE_IS_PRELINKED=1
export KDE_FORK_SLAVES=1
Dude, thanks so much for that tip! I've never liked kdeinit and being able to switch it off is a godsend!
On my (prelinked gentoo) system, there is no slowdown as a result. Subjectively, it even feels a bit snappier without kdeinit.
Strange, on my system application launch time and memory consumptions is noticeable worse with these options set.
I stick with kdeinit for now ..
Btw. what thread on security, have you got a link?
http://lists.kde.org/?l=kde-devel&m=109396400731118&w=2
Looks to me easier to fix selinux and fireflier instead of getting rid of kdeinit. If I look at the output from 'ps x', I see what programs/slaves are running. Just strip of 'kdeinit: '. So they could either support kdeinit directly (as KDE is not just an application), or add some finer grid configuration tools per application (as wine and probably others have these issues too).
> Looks to me easier to fix selinux and f
Wrong - absolutely dead wrong.
the use of fork() and the loading of libraries *is* a security problem, you know that: it's pretty obvious.
one process being compromised results in it being able to poison all threads, and also in it being able to utilise any file handles and other stuff [that i am not as familiar with as, say stephen smalley and the other selinux developers] to then compromise any child process etc.
the only way to obtain _complete_ security separation is to exec().
that is the reason why selinux "domain" tracking is done on an exec() and why fork() is most certainly not.
the bottom line is that kdeinit _used_ to provide a significant speedup, on older machines. now it not only gets in the way but there is a better solution (prelink) and its use makes it impossible to do selinux "domains" for the separate kio handlers and the programs that utilise them.
what if i want to write an selinux policy for konqueror that only allows it to do HTTP and IMAP, but nothing else?
i can't even _begin_ that - because of kdeinit: i can't even track the different programs, because they are all named "kdeinit".
if i want to make konqueror only be able to access HTTP, i can't because it's handled by _one_ program that loads all of the kioslave .so libraries.
selinux, like i said, works by tracking "exec"()d programs, so it is _necessary_ to have a kioslave_http program, a kioslave_imap program.
l.
Does KDE_FORK_SLAVES actually work for you? For me on kde-3.3.0, it doesn't:
http://bugs.kde.org/show_bug.cgi?id=88557
I hope they build it from stratch with simplicity in mind. But obviously not going as far as Gnome 2.* went. And a different default theme which is not plastik and has no round corners unless it uses SVG.
Rewrite from scratch? Why? I think you don't have clue what you're talking about if you suggest to rewrite KDE from scratch. It's a huge, complex piece of code, that generally works very well at the moment. Gradual changes is the way to go. This [1] article is informative on this matter.
[1] http://www.joelonsoftware.com/articles/fog0000000069.html
They did, for KDE 2. Because 1.0 kind of grew up in a very ad hoc kind of way (I still loved it) the rewrote KDE 2 from the ground up, they thought through the 'problems' of KDE 1, and they learnt. KDE 3 was an easier port (As Qt had changed its interfaces less.). KDE is now a huge chunk of good code that has aged well. Major changes will occur in the 4.0 timeframe, but starting over from scratch is just insane, there's nothing like fixing an obscure bug you crushed in the KDE 2 era, for KDE 4.0.1 .
It'd be pointless to rebuild KDE from the ground up, because most of the guts are quite solid. There are bits here and there that need restructuring (I'd love to see the KIO API rebuilt on top of a cross-desktop core), and the UI needs work (yay for Aaron Siego), but stuff like that can be built on top of the existing core.
Why don't you file a wishlist bug report on this, blahster?
Bug 89761: Rewrite KDE from scratch.
/ Martin
(Not an actual bug number.)
Hmm. My name is still shown as my login, ingwa, instead of my full name Inge Wallin. See the Games section in the digest for an example.
Is there anything that I can do to fix this or do I have to wait until somebody else fixes it? If so, what can I do to help?
It's fixed now.
Derek
Thank you! What was the problem?
didn't update the kde-common/accounts file.
Derek