KDE Traffic #62 is Out

Friday, 29 August 2003  |  Numanee

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!

Comments:

thanks! - Some Guy - 2003-08-29

I pretty much agree that GCONF most likely sin't needed and neither is a patch to remove waldo's helpful titles. In fact, such an option would be what the GNOME camp is reffering when they say KDE has too many options. Such an option is simply not needed. It's ok to have a lot of options, but if they are well thought out and meaningful.

Re: thanks! - Debian User - 2003-08-29

Hello, I agree that gconf is not needed. After all, config should be like config was always in Unix, in files. That way it remains truly accessible for users. The rollback stuff sounds great. I would love that. Please explain to me why the choice in case of menus it is not needed. I think the problem is not a camp complaining. And it's not too many options, but the user interface to them. KDE differs from Gnome. One way it does is to provide all config that the users want to change. I want that config option. I would prefer a fully customizable RMB menu as well. I don't need many things currently there and on the other hand would add others. It should potentially be more context aware as well. If my (visible) toolbar has back button, does the RMB need to have one? If the toolbar button is not visible, shouldn't it have one? KDE is about user choice. Leave it it that way. I welcome all usablity work on KDE 3.2, but please don't confuse usability with restrictedness. Usability is about good defaults, good dialogs to change them and good hierachy in information presentation. Most of all, I hope you people finish KDE 3.2 soon. 3.1.3 feels old when I read all the new stuff :-) Yours, Kay

Re: thanks! - Yama - 2003-08-30

Why do you assume that gconf doesn't use files? All gconf settings are stored in text files, in XML format with subdirectories. The files are very readable by both humans (good for manual editing) and software (good for writing config apps).

Re: thanks! - Debian User - 2003-08-30

Files are one option. Database, registry, etc. are others. Yours, Kay

Re: thanks! - fault - 2003-08-30

> The files are very readable by both humans (good for manual editing) If you consider XML a very good format to be readable by humans, that is. I personally think .ini files are much more readable. XML does have other advantages however. But yes, the biggest myth surrounding gconf is that it uses a flat file for all of it's settings. I thought this for the longest time. In fact works just like kconfig, but uses XML files instead of .ini files. Kconfig and gconf are largely similiar and one should not replace the other in terms in the other desktop. What I still don't agree is all of gnome2's removal of useful config functions in the config dialog gui's, and expecting users to use gconf tools to edit them. I refer this to as "gconf abuse". Hopefully, with the development of kconfedit, the same thing doesn't happen with KDE.

Re: thanks! - Ac - 2003-09-04

The problem with ini is that it can't handle multi-line strings.

Re: thanks! - ac - 2003-08-30

It's actually quite a mess if you look at it and try to understand it. It's full of meaningless either empty or unstructured %gconf.xml files. What's the % for? Why are the XML files all of the same name? Ugh.

Re: thanks! - Carsten Pfeiffer - 2003-08-29

> I pretty much agree that GCONF most likely sin't needed and neither is a patch to remove waldo's helpful titles. In fact, such an option would be what the GNOME camp is reffering when they say KDE has too many options. Yeah, and those titles are the reason that my K-Menu now has two columns on my 800x600 display (laptop). Thanks a bunch :(

ugh uh - Right... - 2003-08-30

What does it matter? They don't take up so much space, don't blame them just because you were at the limit anyway! Maybe you should nest a few things. Anyway, it's bad usabiltiy to have an option for every POS that someone could potentially want changed. it needs to be an option taht more than 20 people in KDE community will use, or else it's just bloat and makes it harder for the user and developer. But, that's just me, I for example also don't like it when I get 15 choices of bread I've enver heard of for a sandwich and I ama ske dto pick one. than i need to see ach one and try each one to know, because I've never heard of any of tehm before. After I've picke dthe rbead than i pick from 15 styles of cheese etc.

Re: ugh uh - Debian User - 2003-08-30

It is at least 20 I am sure. Yours, Kay

Re: ugh uh - Carsten Pfeiffer - 2003-08-30

>What does it matter? They don't take up so much space, don't blame them just because you were at the limit anyway! Maybe you should nest a few things. Eh? We're talking about the default installation of KDE on 800x600 displays, where the K-Menu is just awful to use, now.

Re: ugh uh - Christian Loose - 2003-08-30

Did you talk with Waldo about it yet? I don't use 800x600 but if K-Menu now really shows two columns then I'm sure Waldo will re-think his decision to not include a configuration option. Christian

Re: ugh uh - fault - 2003-08-30

I think a better approach is to remove some of the application catagories in the kmenu. See the thread on kde-usability here: http://lists.kde.org/?t=106158645200001&r=1&w=2 .

Re: thanks! - Snowball - 2003-08-30

I agree please no Windows Registry on KDE.

Re: thanks! - Yama - 2003-08-30

You obviously have no idea of what gconf is. Gconf is an XML-based (text) format. It is easy to hand-edit or to create a config app for it (GNOME has both GUI and console tools to do that). It isn't radically different from the KDE system, but it is far more structured and consistent.

Re: thanks! - fault - 2003-08-30

> far more structured and consistent. because unlike, kconfig, most users will see gconf tools sometime in their time using their desktop. Kconfig, on the other hand, will probably only ever be used by system admins since most options are in configuration dialogs. Of course, some options in some of KDE's app's configuration dialogs are somewhat less useful, but I strongly urge KDE developers to never castrate their configuration dialogs like gnome2 =]

Re: thanks! - ac - 2003-08-30

<?xml version="1.0"?> <gconf><entry name="default" mtime="1059631405" muser="ac" type="string"><stringvalue>/usr//bin/metacity</stringvalue></entry></gconf> How is this structured or consistent compared to KDE's ini files? It's a right mess is what it is.

Re: thanks! - Ulrich Kaufmann - 2003-08-30

I think having an element named <stringvalue> says quite a bit about the design, unfortunately ("entry" is not much better). But configuration info is hard to structure - there are various forms of information (simple values, rules, logic...) and ways of sharing it (All Users, this user, this user on this machine...). Representation as XML vs. .ini file is really a minor detail - namespaces and hierarchies are probably the key things to get right.

Quick tab access on konqueror - Ned Flanders - 2003-08-29

The important point I think is to standardize tab access in all KDE apps. The same shortcut should be used for this in all the MDI apps of KDE (konqueror, konsole, kate, etc.). A suggestion : The behavior when changing tabs should be the same as the one when changing windows with ALT-TAB. For example, if the shortcut for changing tabs is ALT-CAPS then pressing it one time should put the focus on the previous tab and pressing it a second time should bring the focus back to the first tab.

Re: Quick tab access on konqueror - Tom - 2003-08-29

Agreed. Consistency is the key. As several other browsers seem to use CTRL + <left/right>, why not just make it a KDE-wide "directive" that tab switching should *always* use these keys.

Re: Quick tab access on konqueror - ac - 2003-08-29

That already works in Konqueror for me.

Re: Quick tab access on konqueror - Jim - 2003-08-29

> The important point I think is to standardize tab access in all KDE apps. The same shortcut should be used for this in all the MDI apps of KDE (konqueror, konsole, kate, etc.). I disagree. Ctrl+left arrow and Ctrl+right arrow are *well* established in text editors as moving backwards and forwards word-by-word. Alt-left arrow and Alt-right arrow are *well* established in web browsers as moving backwards and forwards in history. What's left? Shift-left and Shift-right?

Re: Quick tab access on konqueror - Ned Flanders - 2003-08-30

>> What's left? Shift-left and Shift-right? Maybe, as it's the solution adopted by konsole. In Windows Ctrl-Tab does the job of switching between tabs in MDI apps and I must admit that it does it well.

Re: Quick tab access on konqueror - Sleepless - 2003-08-30

That means you only move in one direction :-/ I'm all for shift+arrow keys too.

Re: Quick tab access on konqueror - der Mosher - 2003-08-30

Ctrl-Tab is for moving one tab to the right, Ctrl-Shift-Tab goes one tab to the left. This is very consistent in the Windows environment. I'm using it for my KDE as well (after removing its use for switching between virtual desktops). Shift-Arrow is used for marking text in many editors, word processors, spreadsheets... I don't like Konsole using these keys, but then, they are configurable.

Re: Quick tab access on konqueror - Elek - 2003-12-01

> I don't like Konsole using these keys, but then, they are configurable. They are? Where? I have Konsole 1.1.3 and KDE 3.0.5. No sign of anything like that in the Configure dialog box. Nor ind konsolerc, nor in the Control Center. Elek

Re: Quick tab access on konqueror - Anonymous - 2003-12-01

"Settings/Configure Shortcurts..." - but you must use a current Konsole version.

Re: Quick tab access on konqueror - David Walser - 2003-08-31

Even if you can go both directions, you can still only go to an adjacent tab. I think they should use what Gaim uses in tabbed conversation windows, Alt-TabNumber, which was even one of the suggestions in the kde list thread. His assertion that the tabs would need numbers on them if you did that is wrong though. Gaim doesn't do that, and a lot of the time I have more tabs than fit horizontally across the window so I can't see the tab I'm going to anyway (so the number is not helpful). I just have to know what number it is (I can count!). If I just close, then I can easily there easily.

Re: Quick tab access on konqueror - der Mosher - 2003-08-30

This is not related to MDI behavior. Tabs are mainly used by dialog boxes.

Re: Quick tab access on konqueror - portos - 2004-01-05

so, C-M-Tab won, at least on my version of konq. (SUSE 9.0)

RMB menus - Tom - 2003-08-29

It's good to see the Right Mouse Button (RMB) menu issue coming up again. I really hope this problem is cracked by the time 3.2 is out! Reading through the thread, it seems like the developers are trying very hard to balance features and simplicity. It seems that everybody has their own peculiar needs when using KDE, and so every developer wants to add in an entry into the RMB to suit their needs. It seems sensible, therefore, to make the default RMB menus *very* simple indeed, covering only the basic needs, and to make it easy and obvious for users to add RMB menu entries. For example: BASIC right click on a file: Open With > list of apps, plus "other" Copy Cut Rename Delete > Trash / Delete Actions > List of actions, plus "other" that lets you easily add new actions The advanced users can then add all their favourite actions in, without cluttering our menus. There could also be a repository of actions from which the user could choose from, which aren't in the menu by default. Also, I don't understand the distinction devs make between "preview" and "edit", as though they should be seperate menus. Surely it makes sense to be able to say, in the "open with > other" dialogue: "[x] embed in konqueror", and to be able to give each entry a name other than the name in kmenu. So I can have, for example: Open With > * The gimp * KView * Preview (this is set to kview embedded in konqueror)

Re: RMB menus - AC - 2003-08-29

..and any chance kde3.2 will use new a new default style? There is a new set out called Plastic http://www.kde-look.org/content/show.php?content=7559 and it just looks really slick - many seems to agree.

Re: RMB menus - Rob Kaper - 2003-08-29

No chance. WE just changed to Keramik and that was already quite a heated discussion. It's definitely not the intention to change the default look with ever single release.

Re: RMB menus - ac - 2003-08-29

What's so slick about it? It doesn't look as good as Keramik... but Keramik is improving anyway. It might look even slicker in 3.2.

Re: RMB menus - fault - 2003-08-29

Why not replace Keramik with thinkeramik? The changes to Keramik in HEAD are alright, but I'd like to have seen more, perhaps to the degree that ThinKeramik was modified. Keramik-HEAD is still way too weighty for a default style, especially buttons and tabs still. ThinKeramik preserves the unique keramik look and has enough familarilty but makes it look less weighty. =]

Re: RMB menus - Joe - 2003-08-29

But don't provide a link for those who aren't cool enough to know what it looks like.

Re: RMB menus - A C - 2003-09-06

< http://www.kde-look.org/content/show.php?content=6986 >

Re: RMB menus - Frank Karlitschek - 2003-08-29

Plastik will be in the KDE CVS soon. And it will be released with KDE 3.2 in the optional kdeartwork package. But it will no become the default theme. Keramik it pretty cool an unique and we can not change the default theme with every release. The user has the choice.

Re: RMB menus - AC - 2003-08-29

>>>But it will no become the default theme. ...... The user has the choice. And what if "the user" wants a new default look? This is not meant as a smart ass comment but a good reasonable possibility.

Re: RMB menus - Debian User - 2003-08-29

Then the user better forks KDE from the developers. ;-) Yours, Kay

Re: RMB menus - AC - 2003-08-29

OK, who's with me - im about to fork. All we need now is a knife.

Re: RMB menus - anon - 2003-08-30

Well, do we really want a different default theme for: KDE 3.0 - hicolor KDE 3.1 - keramik KDE 3.2 - plastik? No.. I don't think so.. the earliest time we can do this is KDE 4.x IMHO.

Re: RMB menus - Roderik - 2003-09-14

I think there can be a new default theme for each new KDE serie (for example 3.x, 4.x). So I think Keramic schould be the default in 3.2. In the mean time Plastic can be further inproved so that in can be the default in 4.x.

New Design!! - Some Dude - 2003-08-29

Okay this design isn't bad but WTF? Why aren't they using the same design taht most kDE websites ar esupposed toa dopt, one like KDE.ORG's!!! Or maybe we want a million websites for each KDE application!!? Why isn't it using the KDE.org design? Wouldn't we rather have a consistent loon n feel for all kde website designs. This is two steps forward from teh old design but one step backward for everything else.

Re: New Design!! - CE - 2003-08-29

I think this design is better than KDE.org's. OK, there a nice ones available at KDE.org, but only "KDE window colors" works correctly in all browsers. On my opinions the font sizes on KDE.org are too big. And so on ...

Re: New Design!! - Datschge - 2003-08-30

"taht most kDE websites ar esupposed toa dopt" Liberal use of the keyboard keys, or how do you call that?

Re: New Design!! - anonon - 2003-08-30

it's called "consistent loon n feel" ;)

TESTS INDICATE... - Some Dude - 2003-08-31

That is called "scramble typing" or ST for short, and I have conclude dthrough a multiple tests on a group of 35 people that it increases understanding by over 25% and it increases how much you remember of what I say by as much as 10%. Constantly scrambling the letters in words, forces the mind to rearrance the word as it knows it to be, fast readers may never notice that the word was scrambled to begin with due to the automatic rearranging. forcing the mind to take the time to rearrange the letters this improves attentiveness. Also, the brain is far more focused on the negatives of life and remmebers and notices them easier, so it also improves memory. Now, the above was just because I was typing fast, and connecting letters of one word to the other does decreae efficency for example: teh improtant will improve everythingm but tehim protant will not and the scrambling should never afect more than 20% of the word. If you want your message understood and remembered more, you should be "Scrambling" too!!! ;)

My opinion on g/kconf - Norman - 2003-08-29

On Thursday a contraversial article about the differences between linux desktops were posted on a number of news sties. As the comments shown (over a 1000 on slashdot!) there is a REAL demand for some standardization in the GUI. A unified configuartion shared between gnome, kde and others should make a real leap forward in this direction. Imagine being able to do this.... Select your fonts, color scheme, button order, language, keyboard settings, cut and paste setting, etc in kde and your settings will also apply to GTK, motif, TK, Xaw and fox applications and vice versa, no more plain grey apps in your kolorful environment. As a lot of users use hybrid desktops it is really essential, and I hope the gnome and kde developers work on unifying this stuff.

Re: My opinion on g/kconf - Mystilleef - 2003-08-29

I hope they don't. I hope no graphic user interface "unifications" ever bear fruits. What I do hope for is that all desktop environment projects adhere to and support the freedesktop.org standards. It is important that these developers can communicate and agree on certain basic issues (e.g. copy & paste for all unix applications irrespective of environment), through a neutral medium, but it is not necessary that they agree on everything, or more yet, try to do everything the same way. Regards, Mystilleef

Re: My opinion on g/kconf - wup - 2003-08-30

>> 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..

Re: My opinion on g/kconf - AC - 2003-08-30

KDE offered the Gnomes to join and even use the superior KDE technology, but they refused and continue doing their 80s style desktop.

Re: My opinion on g/kconf - anon - 2003-08-30

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.

Re: My opinion on g/kconf - Ac - 2003-09-04

And which options are you referring to? Show/hide desktop icons? My dad will never change that. Tearoff menus? He never uses tearoff menus.

Re: My opinion on g/kconf - Tom - 2003-08-30

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.

OKAY OKAY FINE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! - Some Guy - 2003-08-29

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.

Re: OKAY OKAY FINE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! - wup - 2003-08-30

..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/<insert yours> 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..

Re: OKAY OKAY FINE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! - wup - 2003-08-30

I forgot some question marks (l33t style): ???????? ???? ?!!11 ?????????

(Please stop with these kind of titles) - Datschge - 2003-08-30

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.

Re: (Please stop with these kind of titles) - wup - 2003-08-30

Using some KConf-like utility those options would be accessable through a GUI.

Re: (Please stop with these kind of titles) - Christian Loose - 2003-08-30

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

Re: (Please stop with these kind of titles) - ik - 2003-08-30

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) ?

Re: (Please stop with these kind of titles) - wup - 2003-08-30

>> 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).

Re: (Please stop with these kind of titles) - Christian Loose - 2003-08-30

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

Re: (Please stop with these kind of titles) - fault - 2003-08-30

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.

Re: (Please stop with these kind of titles) - wup - 2003-08-31

>> 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.

konqueror tabs - not_registered - 2003-08-30

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.

Re: konqueror tabs - anon - 2003-08-30

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.

Re: konqueror tabs - wup - 2003-08-31

>> 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)

KDE 3.2? - it for schools - 2003-08-30

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.

Re: KDE 3.2? - Anonymous - 2003-08-30

Targetted dates are 8th December and 18th September.

Re: KDE 3.2? - Christian Loose - 2003-08-30

http://developer.kde.org/development-versions/kde-3.2-release-plan.html