[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Fwd: Re: What to do after 2.2?
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-07-15 20:32:51
[Download RAW message or body]

Please note though that having a discussion on both mailing lists is very 
hard to keep in sync. I mostly summarized the thread on core-devel below for 
people who didn't follow core-devel and do not mention anything that is not 
also mentioned there.

I know that kde-core-devel is not usually writeable for everyone, but if you 
have something useful to add to the discussion, I'm sure that your message 
will be approved by the moderators. Marc's message got through as well, just 
shortly after he cross-posted here. Please reply to the core-devel thread 
instead!

On Sunday 15 July 2001 20:43, James Bryant wrote:
> While I'm not absolutely sure either, isn't library linking and loading
> times the main problem with speed that kdeinit has been having in the past?
> Perhaps Qt3's libloader could erase the 4 seconds I have to wait before
> Konqueror loads vs. less than 1 sec for IE 5

The Qt version does essentially exactly the same. See David Faure's reply on 
kde-core-devel: http://lists.kde.org/?l=kde-core-devel&m=99512516411233&w=2

> > - KDE's KConfig should be replaced by QSettings
>
> I agree here. Or better yet, rewrite KConfig entirely to use an advanced
> configuration tree similar to Windows Registry.  While I abhor Microsoft
> mostly, some ideas that they've had have been good. It's just the way they
> implement them (or lack thereof) that kills it. A nice, neatly organized,
> unintimidating, unconfusing, editable configuration tree would do wonders
> for KDE.

Ugh, no! Search the archives of kde-core-devel of why a registry is a bad 
idea. See the above link to David's reply as on why QConfig is another bad 
idea for KDE.

> > At least the KPart and KConfig changes should be pretty deep if we want
> > to make use of the full Qt3 potential in that area. And they affect a
> > very large part of the core source code base.
>
> That's my thinking as well.

Yeah, if we change them. But changing them won't do anyone good. Just 
changing because Qt has something similar is not exactly wise to do if it 
differs with our approach on critical points.

> Now for my analysis of KDE thus far:
>
> My main beef so far with KDE has been with accesibility. Not with disabled
> people or people who speak other languages than English mind you, but with
> people of different levels of computer skill. KDE has come a long way in
> the installation process, but as of yet it is neither intuitive nor visual.
> Installing any other KDE application also includes the pain of compilation
> or the lack of feedback that prepackaged binaries provide. KDE desparately
> need some sort of InstallShield type app that will make it easy for
> beginners to install the application and tools that they need. However,

See Kent Nguyen's KInstaller which he plans for a 1.0 release by end of this 
year. I think there already is an alpha version available, not sure though.

> another problem is the amount of codebuilding duplication that occurs. I
> can appreciate the fact that people want to approach a problem from
> different angles, however, many times this leaves us with two half-done
> barely usable programs instead of one full program that does what a user
> may need.

And on Windows the same doesn't exist? Two examples: 1. WinZip, WinAce, 
WinRar, Pkzip for Windows and 2. GetRight, Go!Zilla, Download Accellerator. 
It took me about 2 seconds to come up with these examples so expect many more 
of them. Actually, competition is good, because it forces you to keep 
improving your code.

> The menus are cluttered, disorganized, and counter-intuitive. 'Nuff said.

The code is available, so you can change and improve it if you want (I'm sure 
the author will give you permission if it improves usability).

> Something else that would be helpful would be some sort of device manager
> to handle the various aspects of devices and thier respective kernel
> modules, unfortunately, the way the kernel handles devices varies to
> greatly depending on the device that I'm sure this would be a hard project
> to tackle.

See the Ximian Setup Tools and KSysConfig, both trying to share the same Perl 
backend code. This is the only way to get it done: having a shared code base 
well-supported by all major projects. Otherwise not a single distro will 
adopt it, because the hardware config is one of the strong selling points for 
a distro.

> Konqueror is GOD. KOffice is almost, as well.
>
> The Recent Documents folder doesn't seem to be supported by Konqueror
> fully. When opening a file in Konqueror, whether by clicking in the File
> Manager or opening it through the menu, it should be placed into the Recent
> Documents folder. However, this action should not occur when opening a file
> from a kio_slave like http:/ or ftp:/ and such. Not sure how such a
> destinction could be easily made.

Why not? Every KDE app can read HTTP or FTP files just as well as a local 
file. That's the true power of KIO. Every opened document should be 
considered a 'recent' document, regardless of whether it is located on Mars 
or on your own harddisk.

> Generic polish is needed as well. KDE still feels like many different
> unrelated parts mashed into one program. When working towards that 3.0
> release, I hope that this can be corrected some. More strict organization
> in the KDE community is going to be needed if 3.0 is going to be the
> proverbial Windows XP buster. I have no doubt that it will be.

Yes and no. KDE 3.0's main focus is to get the libraries in shape for the 
next few years because it gives us the opportunity to break binary 
compatibility for once. Improving the applications can be done before, during 
or after the move, but should not really affect a decision to do KDE 3.0 or 
not.


 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]