The buzz about KDE 4.0

[Kimberly Lazarski]

Kevin Krammer wrote:
>
>
> I think we can agree that the customizability of KDE is valued by quite a lot 
> of people, ranging from users over developers to sysadmins.
> The perceived reduction of these options is mainly based on misunderstandings, 
> e.g. configuration done differently, configuration options not yet exposed 
> yet through a GUI, user visible parts of functionality not implemented yet, 
> etc.
>   
That would be fine if there were specs for config files for konqueror, 
kwin, etc.
One of the first things I do on a new install is to turn off the [Access 
Keys] feature
in konqueror. When the feature was introduced I was going nuts trying to 
find
the means to disable it. Could not find anything on the web. Finally I 
started
digging into a project and found the code. I could not find any specs 
covering
the rc files.

One could say "it's open source so fix it yourself" but anyone who has
coded _anything_ knows it takes a LOT of time and dedication to learn a
project -- especially a huge project like KDE.
> Additionally a lot of KDE4 code is more open for alternative configuration 
> methods than comparable KDE3 code, i.e. traditional configuration dialogs 
> could most likely be done as an addon/plugin/extension.
>
> This kind of flexibility is currently not as visible to users as it is to 
> developers, but once the knowledge about it spreads, other people than those 
> working on the default implementation can create and deploy alternative 
> feature sets without the need of a fork or from-scratch development.
>
> Unfortunately these kind of architectural changes come with a price, either 
> delaying release and future development of "finished" parts until all 
> replacements reach feature parity or release some replacements with just a 
> feature subset.
>   
Understood - There is always some balance of tradeoffs in large projects 
like KDE
however if features power users rely on are hidden by default with no 
GUI to change
it but the code is present, the project site should at least contain a 
spec for the
config files - even if it contains nothing more than

[all possible sections]
possible item1 = flag type (boolean, string, etc.)
possible item2 = flag type (boolean, string, etc.)

etc.
> Both options have their drawbacks and it is quite sad that those developers 
> who agreed to the release in favor of those who alredy had complete ports 
> take so much beating for not having reached their respective feature parity 
> yet.
> No good deed goes unpunished :(
>
>   
Again there was no intention to slight anyone. Honest! :)
>> (dolphin) is about as functional as gnome's nautilus. People in that
>> thread accuse it of being as bad as Windows Explorer, but it has /less
>> /functionality than Windows Explorer.
>>     
>
> I have to admit that I don't have very recent experience with Windows 
> Explorer, but the one I used to use on Windows XP didn't even support KIO 
> like protocols.
>
>   
No it doesn't, that's true. See below on the location bar.
>> extremely capable and configurable. Also, I missed the desktop/folder
>> metaphor. I put current and ongoing work on my desktop, and most other
>> people I know (on Macs, Windows, and Linux) do the same. Taking that
>> away was definitely a mistake. Does KDE4 still lack the
>> desktop-as-a-folder metaphor?
>>     
>
> Also a quite common misunderstanding.
> Not porting the traditional implementation of a desktop handler (e.g. KDesktop 
> in KDE3) doesn't mean that the use case of using it as a kind of intermediate 
> storage has been abandoned, far from that.
> Rather than "simply" porting the limited variant the developers decided to aim 
> for a solution which would allow the traditional usage but would also allow 
> new ones, e.g. showing results of search engine results.
>
> Again it's quite sad that the *temporary* absence of some particular details 
> like fullscreen capability resulted in mudslinging.
>
>   
Interesting! that actually sounds more flexible than 3.5.x. It's 
unfortunate that the
beta was feature-incomplete.

PR: to help restore the rep of KDE, wouldn't it make sense to use 
definitions
that the proprietary software vendors use? That is, alpha is 
feature-incomplete
but runs and may be usable but unstable; beta is feature-complete and stable
enough to be used but has known and unknown defects, and release is stable
enough for production, is of course feature-complete, and has no known fatal
defects and known defects are documented (release notes, web site, 
bugzilla,
etc.).
>> the modularity, configurability, and power KDE has given the users. If
>> you must, dolphin and other apps can stay simple by default, but please
>> make it possible for users to turn on power user options (such as an
>> editable address bar, tabs, a built in terminal windows) people have
>>     
>
> I am pretty sure the location bar is editable in the traditional sense, 
> the "bread crumbs" navigation is just one possible visualization.
>
>   
But in the 4.0 build I ran (admittedly a beta) on OpenSuSE 10.3 the 
address bar was
not editable -- at all. :-( Now I'd accept that from Nautilus because 
Gnome has been
dumbed down so much that it's an insult to monkeys ;) but I was really 
disappointed
in KDE4. Now I see that's been changed since then and I have an 
incorrect assessment
of it based on my experience with the beta. Sorry, my bad!
>> depended on for so long. I know konqueror is still there, but with two
>> separate file managers there will be temptation to not keep konqueror's
>> way of doing things up to date, leaving only a very limited file manager.
>>     
>
> While it is most likely not as visible to users as it is to developers, the 
> way KDE's architecture and applications are designed allows allmost immediate 
> reuse of the simple variants features in the advanced variant and allows the 
> advanced variant's developers to concentrate on "their" features.
>
>   
Understood -- and that's what makes  KDE is so powerful. :) KDE is what
Windows tried to be (and failed miserably).
> It is actually more taxing on the part of the simple variants developers 
> because the can not just implement a one-to-one mapping of their user 
> interface's capabilities but have to remember all implications the advanced 
> interface will introduce.
>
> It takes very dedicated engineers like Dolphin's maintainer Peter Penz to go 
> this extra mile.
>
>   
>> I'm going to give KDE 4.0 another shot next weekend - Although I keep
>> going back to OpenSuSE and KDE for desktop machines, I periodically
>> evaluate different distros and desktops, but my first experience with
>> KDE4 was a disappointment.
>>     
>
> In this case I recommend not evaluating the same, feature frozen, version 
> again, since it is highly unlikely that much has changed (the sole purpose of 
> a freeze).]
>   
Based on what you and others stated in replies much has changed since I 
ran it.
It /was /a beta, but what people have been ranting about in KDE threads 
on various
sites reaffirmed my impressions. My guess is that they are also basing 
their
statements on experiences with the beta builds?

--Kim

=
> Cheers,
> Kevin
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> kde-quality mailing list
> kde-quality at kde.org
> https://mail.kde.org/mailman/listinfo/kde-quality
>   


-- 
Biyn logo 	Kimberly Lazarski
Biyn Development * 193 Rockland Street * Hanover, MA 02339
781-826-2601 * www.biyndesigns.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-quality/attachments/20080627/bf21e5b1/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BiynRedAndBlackLogo.png
Type: image/png
Size: 22030 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-quality/attachments/20080627/bf21e5b1/attachment-0001.png