KDE Traffic #62 is Out

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

by Some Guy (not verified)

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.

by Debian User (not verified)

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

by Yama (not verified)

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

by Debian User (not verified)

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

Yours, Kay

by fault (not verified)

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

by Ac (not verified)

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

by ac (not verified)

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.

by Carsten Pfeiffer (not verified)

> 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 :(

by Right... (not verified)

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.

by Debian User (not verified)

It is at least 20 I am sure.

Yours, Kay

by Carsten Pfeiffer (not verified)

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

by Christian Loose (not verified)

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

by fault (not verified)

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 .

by Snowball (not verified)

I agree please no Windows Registry on KDE.

by Yama (not verified)

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.

by fault (not verified)

> 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 =]

by ac (not verified)

<?xml version="1.0"?>
/usr//bin/metacity

How is this structured or consistent compared to KDE's ini files? It's a right mess is what it is.

by Ulrich Kaufmann (not verified)

I think having an element named 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.

by Ned Flanders (not verified)

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.

by Tom (not verified)

Agreed. Consistency is the key.

As several other browsers seem to use CTRL + , why not just make it a KDE-wide "directive" that tab switching should *always* use these keys.

by ac (not verified)

That already works in Konqueror for me.

by Jim (not verified)

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

by Ned Flanders (not verified)

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

by Sleepless (not verified)

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

by der Mosher (not verified)

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.

by Elek (not verified)

> 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

by Anonymous (not verified)

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

by David Walser (not verified)

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.

by der Mosher (not verified)

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

by portos (not verified)

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

by Tom (not verified)

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)

by AC (not verified)

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

by Rob Kaper (not verified)

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.

by ac (not verified)

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.

by fault (not verified)

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

by Joe (not verified)

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

by A C (not verified)

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

by Frank Karlitschek (not verified)

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.

by AC (not verified)

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

by Debian User (not verified)

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

Yours, Kay

by AC (not verified)

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

by anon (not verified)

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.

by Roderik (not verified)

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.

by Some Dude (not verified)

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.

by CE (not verified)

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

by Datschge (not verified)

"taht most kDE websites ar esupposed toa dopt"

Liberal use of the keyboard keys, or how do you call that?

by anonon (not verified)

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

by Some Dude (not verified)

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

by Norman (not verified)

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.

by Mystilleef (not verified)

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