KDE Traffic #62 was quietly released last week. A whole lot of news in this one, including some discussion on the new KPrefs, GConf2, quick tab access in Konqueror, a lot of KOffice news (beta 3 feature freeze, better support for Word 6 and Word 95), and mention of the new pim.kde.org design. Thanks Russell!
Dot Categories:
Comments
>> try to do everything the same way.
That's already happening for a long time.
The only difference is that KDE has a lot of (ie. bloat) options for the 3 geeks out there.
Better combine those efforts and create a real ass KicKing desKtop + programs..
KDE offered the Gnomes to join and even use the superior KDE technology, but they refused and continue doing their 80s style desktop.
The problem is that gnome2 removed options for the average non-geek too.
My experience with new users to gnome is that they think it's some old crusty ass desktop.
And which options are you referring to? Show/hide desktop icons? My dad will never change that. Tearoff menus? He never uses tearoff menus.
You talk of freedesktop.org as though it is a set of established standards, like the LSB. Just for clarification, for those who don't know, it is in fact all work in progress, a workshop in which DE developers can work on shared technologies. So really, you don't "adhere to freedesktop.org", you "work in freedesktop.org on certain technologies".
I think it makes sense for an awful lot of the base code to be the same, or at least work the same. Having compatable system trays, menu entries (.desktop files), drag and drop, clipboards, application messaging (D-BUS / DCOP) and other things that the user is unlikely to want to customise is a very good thing. Sure, it limits the scope for innovation, but it also makes the experience far more enjoyable for users.
Then there are base technologies which shoudn't merge. For example, Konqueror uses KHTML, whilst Epiphany uses Gecko. Both are capable renderers, and it makes no difference to the end user which one is being used, so it makes sense to develop both and reap the benefits from diversification.
It also of course makes sense to do user-end things differently where difference doesn't matter. So it's good that KDE continues to offer more configurability, whilst GNOME offers less.
Ideally, you'd be able to use GNOME, KDE and other X-apps together in any desktop environment and not lose any features that they offer, whilst still enjoying the differences each suite has to offer.
Maybe it wouldn't be a total waste of code and space to have an option to remove those tiles.
I still think it is, they are not so big and they make the Kmenu easier to navigate. It just seems that having an option for this is just too much damn configurability, if we have an option for this we might as well have an option for every single thing that could be done differently.
Sure maybe 1 or 2 people might care if they have a ___________________ separator or a spearator which also has text on it but I am certain taht 90% will not after using it a day or two and it's defintely good for new users.
If you really want you can always use the proposed patch.
..or put an option in G/KConf.
But no, all those 'hardcore' geeks out there want their options in a GUI because they can't edit text files or browse through a tree view with options.
I ask to you geeks; then WHY for god/allah/boedah/ sake do you want to have the ability to edit text files if you don't see those darn things anyway???? ??
I would really like to know the answer to that, but I guess the only thing I'll get to see after this post is a silly flame in return..
I forgot some question marks (l33t style): ???????? ???? ?!!11 ?????????
Why not edit text files or browse through a tree view with options you ask? KDE is a GUI, and its options should be accessible through a GUI as well. End of the story.
Using some KConf-like utility those options would be accessable through a GUI.
But not for Joe User. Do you really want books on the market like 'The best 500 hidden configuration options in KDE' like you have for Windows now? No thank you!
Christian
your comparision with the windows world made me think of this: to access some hidden config options in windows, several add-on packs are available. That looks like a compromis between config option for everything, and enough (UI-accessible) config options: just distribute 'extra' config UI as a separate package (kcontrol-extras) ?
>> But not for Joe User.
We were talking about those geeky options, right?
Those options aren't meant to be used by Joe User anyway (since Joe doesn't want to invest the time to find out what those options do).
And who gets do decide what is a geeky option and what not? Why is the disabling of those K-Menu titles a geeky option? Just because it's a minority that doesn't want those titles?
Christian
Indeed.. this is why there has never been any user modes in any of KDE's applications. Unlike GNOME where they've experiemented with it and failed several times. For example, take Nautilus's user mode system. 99% of users just switched to advanced and kept it that way. Case2 is GNOME 2.x's overuse of gconf. 50% of new users don't know how to do something because it's not in the configuration dialogs, and the other 50% just use gconf all the time. Hopefully GNOME 3.x's does some usability testing of what the most used gconf properties in gconf tools are and adds them back to the GUI. It's their poor usability changes that have made this a failure as well (KDE has equal problems, but in the reverse direction)
I think the best approach might be yet again, Apple's. The configuration dialogs actually have more options than GNOME 2.x's, and I have only had to edit .plist files once or twice.
>> Unlike GNOME where they've experiemented with it and failed several times.
Afaik that only happened with Nautilus.
>> KDE has equal problems, but in the reverse direction
Right, that's the whole issue.. both desktops are taking this to the extremes.. GNOME2 has too little and KDE3 has way too many options.
the close buttons are still horrid to the extreme.
im not too pleased with the icon turning into a button thing, but if this is the way it is going to be get rid of that ugly square box and have the intermediate button graphic to be a faded out version of the final graphic.
thanks.
Fully agreed... the button hover looks fugly with 99% of all styles, because 99% of styles are buggy with such small buttons. They should jsut remove the button border and have the favicon fade to the closeicon.
Another thing maybe to try using a toolbutton instead of a pushbutton. Perhaps it's less buggy.
>> Another thing maybe to try using a toolbutton instead of a pushbutton. Perhaps it's less buggy.
Very good idea, Qt Assistant is doing that as well and it looks much better.
(and more KDE apps should do that)
So when is KDE 3.2 coming?
And KOffice 1.3 with fixed tables?
Does anybody know?
Those two look like good candidates for primary schools,
to save money.
Targetted dates are 8th December and 18th September.
http://developer.kde.org/development-versions/kde-3.2-release-plan.html