<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Kevin Krammer wrote:
<blockquote cite="mid:200806272131.59393.kevin.krammer@gmx.at"
type="cite"><br>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
That would be fine if there were specs for config files for konqueror,
kwin, etc.<br>
One of the first things I do on a new install is to turn off the
[Access Keys] feature <br>
in konqueror. When the feature was introduced I was going nuts trying
to find <br>
the means to disable it. Could not find anything on the web. Finally I
started <br>
digging into a project and found the code. I could not find any specs
covering<br>
the rc files.<br>
<br>
One could say "it's open source so fix it yourself" but anyone who has <br>
coded _anything_ knows it takes a LOT of time and dedication to learn a
<br>
project -- especially a huge project like KDE.<br>
<blockquote cite="mid:200806272131.59393.kevin.krammer@gmx.at"
type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
Understood - There is always some balance of tradeoffs in large
projects like KDE <br>
however if features power users rely on are hidden by default with no
GUI to change<br>
it but the code is present, the project site should at least contain a
spec for the<br>
config files - even if it contains nothing more than<br>
<br>
[all possible sections]<br>
possible item1 = flag type (boolean, string, etc.)<br>
possible item2 = flag type (boolean, string, etc.)<br>
<br>
etc.<br>
<blockquote cite="mid:200806272131.59393.kevin.krammer@gmx.at"
type="cite">
<pre wrap="">
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 :(
</pre>
</blockquote>
Again there was no intention to slight anyone. Honest! :)<br>
<blockquote cite="mid:200806272131.59393.kevin.krammer@gmx.at"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">(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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
No it doesn't, that's true. See below on the location bar.<br>
<blockquote cite="mid:200806272131.59393.kevin.krammer@gmx.at"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
Interesting! that actually sounds more flexible than 3.5.x. It's
unfortunate that the <br>
beta was feature-incomplete. <br>
<br>
PR: to help restore the rep of KDE, wouldn't it make sense to use
definitions<br>
that the proprietary software vendors use? That is, alpha is
feature-incomplete <br>
but runs and may be usable but unstable; beta is feature-complete and
stable<br>
enough to be used but has known and unknown defects, and release is
stable<br>
enough for production, is of course feature-complete, and has no known
fatal<br>
defects and known defects are documented (release notes, web site,
bugzilla, <br>
etc.). <br>
<blockquote cite="mid:200806272131.59393.kevin.krammer@gmx.at"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
I am pretty sure the location bar is editable in the traditional sense,
the "bread crumbs" navigation is just one possible visualization.
</pre>
</blockquote>
But in the 4.0 build I ran (admittedly a beta) on OpenSuSE 10.3 the
address bar was <br>
not editable -- at all. :-( Now I'd accept that from
Nautilus because Gnome has been <br>
dumbed down so much that it's an insult
to monkeys ;) but I was really disappointed <br>
in KDE4. Now I see that's
been changed since then and I have an incorrect assessment<br>
of it based on my experience with the beta. Sorry, my bad! <br>
<blockquote cite="mid:200806272131.59393.kevin.krammer@gmx.at"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
Understood -- and that's what makes KDE is so powerful. :) KDE is what
<br>
Windows tried to be (and failed miserably).<br>
<blockquote cite="mid:200806272131.59393.kevin.krammer@gmx.at"
type="cite">
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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).]
</pre>
</blockquote>
Based on what you and others stated in replies much has changed since I
ran it. <br>
It <i>was </i>a beta, but what people have been ranting about in KDE
threads on various<br>
sites reaffirmed my impressions. My guess is that they are also basing
their <br>
statements on experiences with the beta builds?<br>
<br>
--Kim<br>
<br>
=<br>
<blockquote cite="mid:200806272131.59393.kevin.krammer@gmx.at"
type="cite">
<pre wrap="">
Cheers,
Kevin
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
kde-quality mailing list
<a class="moz-txt-link-abbreviated" href="mailto:kde-quality@kde.org">kde-quality@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/kde-quality">https://mail.kde.org/mailman/listinfo/kde-quality</a>
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<div align="left">
<table border="0" cellpadding="2" cellspacing="2" height="103"
width="768">
<tbody>
<tr>
<td valign="top" width="120"><img alt="Biyn logo"
src="cid:part1.01010602.06050909@biyn.com" height="91" width="112"></td>
<td valign="top">Kimberly Lazarski<br>
Biyn Development * 193 Rockland Street * Hanover, MA 02339<br>
781-826-2601 * <a class="moz-txt-link-abbreviated" href="http://www.biyndesigns.com">www.biyndesigns.com</a></td>
</tr>
</tbody>
</table>
</div>
</div>
</body>
</html>