KDE Traffic #73 For 31 Dec 2003

By Henrique Pinto

If you like KDE Traffic, please consider making a donation to the KDE project.
Visit http://www.kde.org/support/ for details.

Table Of Contents

Introduction

Welcome to KDE Traffic!

The end-of-year holidays slowed things down in KDE. Not much discussion happened in the past week. There were, however, some interesting threads, that are being covered here.

This is the last issue of KDE Traffic in 2003. 2003 was a wonderful year for KDE, but 2004 promisses to be even better. It all starts with two wonderful releases: the long awaited KOffice 1.3 and KDE 3.2 are going out soon! But it doesn't end there: lots of interesting things will happen. The KDEPIM guys are scheduling a promissing standalone release of that module for next year (including nice things such as HTML mail composing, the most wanted feature in KDE Bugzilla), the folks at the KDE in Debian are working hard at providing many things you'll surely love (think about an APT, DebConf and Alternatives frontends, a GUI for managing KIOSK, ioslaves for all applications, OpenOffice.org integration), the Quality Team proposal you read about at our previous issue is getting implemented, wonderful features are scheduled for development for KDE 3.3 (or 4.0, if that is our next release), people are engaged in promoting KDE...

Wonderful news, aren't they?

A happy new year for you!

1. Using settings:/ instead of KControl [kde-devel, kde-usability]

22 Dec 2003 - 24 Dec 2003 (18 posts) Archive Link: "Use settings:/ in Konqeuror instead of KControl in 3.2?"

Topics: KControl

People: Jason KeirsteadCraig DrummondAaron J. SeigoCasey Allen Shobe

Jason Keirstead suggested:

I make this suggestion after talking with a few people who feel that KControl is horribly difficult to use, but find settings:/ much simpler. settings:/ Is a drill down view, which is very familiar to both Windows and Mac users for adjusting their control settings. It also gets rd of the scary monstrous tree that makes many wary of KControl.

What I suggest is to make KMenu->Settings->Control Center launch a Konqueror window pointed at settings:/, instead of launching KControl.

We can still keep the KControl application around for people who are used to it, if desired.

What do people think of this?

There were concerns regarding the usability of the settings ioslave. Some of its current problems were shown and discussed. Craig Drummond pointed out that "There's no way (easy) to distinguish if clicking on an icon will open up a kcontrol module, or will go deeper into the KControl tree. i.e. Top level icons should be "folder"like" and that "There's no way to access the "admin" mode of a module that can work in both user and admin mode - e.g. the font installer" . Troels Tolstrup stated that such a major change was out-of-question at this time in the release cycle. Aaron J. Seigo also opposed the idea:

this is, IMHO, a bad idea:

really, this is just replacing one poor nav system with a different one. if we could even offer than in Konqi we'd have a nice sidebar with extra useful links and information, that _might_ make it a bit more attractive. but it's way too near to 3.2 to make such a change, and for ++3.2 it is probably better to address the issues in kcontrol in a comprehensive manner. some prelim work on this has already been done by others...

Casey Allen Shobe replied:

If we consolidate as much into (an improved) Konqueror, then everything will have a more consistant interface that the users will feel more instinctive with.

In response to that, Aaron said:

if we remove all the unnecessary instrumentation and add all the purpose-specific pieces for each of these items, the user will hardly notice it's konqueror at all and the "consistency" between the modes will be no more than would be achieved with separate applications.

the downside is that this makes konqueror more complex code-wise, which usually equates to more quirks and bugs.

the interfaces between KDE apps is already pretty consistent. and while there's something to be said about allowing for the merging of similar applications (e.g. kontact) the trade-offs for merging all the apps seems to me at least to be not worth it.

2. BiDi support in Kate [kde-devel]

23 Dec 2003 - 24 Dec 2003 (2 posts) Archive Link: "bidi in kate"

Topics: Kate

People: Arash BijanzadehHamish Rodda

Arash Bijanzadeh asked:

Some days back I have seen in the kate cvs that the kate bidi merged in head. But yesterday when I updated and compiled my kde cvs there was no RTL support for kate?
Can somebody inform me about the situation?

Hamish Rodda answered:

No, kate's bidi support is still in an alpha state, in the kate_goes_bidi branch of kdelibs/kate/part.  It will (obviously) not be ready for 3.2.

You are welcome to check that out, and submit comments/patches etc. to kwrite-devel@mail.kde.org (mailto:kwrite-devel@mail.kde.org) .

3. GNOME Apps in the K Menu [kde-usability]

24 Dec 2003 - 25 Dec 2003 (9 posts) Archive Link: "KMenu, gnome/kde app clashes"

Topics: Integration

People: Frans EnglichWaldo BastianAaron J. Seigo

Frans Englich said:

On my Slackware 9.0 system my (KDE-HEAD) KMenu have a small problem - all over it is spread with 100% _irrelevant_ gnome apps. Do not misunderstand me, I don't mind GNOME, quite the opposite, and want them to live peacefully together, but "gnome control center" is not very useful in KDE and it would be most appropriate if they had a NotShowIn=KDE. Or what do do you think? There's alot of those obvious gnome system-specific. But when it comes to apps with _very_ similar functionality like Terminal/konsole Text Editor/Kedit it becomes hard and political tense to judge. Should we do a NotShowIn=GNOME on konsole and a NotShowIn=KDE on Terminal, etc?

I really have no clue in this matter, but, I think it is clear that the current situation/KMenu is usability wise could be better.

Should I make a pile of oneliners and this time not only bother kde developers but also gnomers? :) What do the wise people say in this matter? :)

Waldo Bastian replied:

Yes, I think it would be helpful if you could make a list of applications in gnome and kde that you think should be restricted to their own environment and then run that past the involved gnome/kde developers to see if there can be found some concensus on that.

Problem with these kind of things is that as a KDE developer you are unlikely to be very aware of how your application pops up in the other desktop. (And the same with gnome developers I assume)

William Leese stated that that would mean war, to what Frank answered:

Yes, we don't want war.

I think a small note to why I'm pushing this idea would be in place.

If this is handled correctly I don't think it leads to war. The only place I've found WAR(aka FUD etc) is really on the dot, slashdot and Userinux::Discuss. I'm not worried this leads to war because it involves sane people and the idea in itself is not flamebait, it is purely pragmatic, just as fruitful for both projects and AFAIST a win-win situation.

I don't get upset or feel insulted if someone says they prefer gedit in front of kedit( no names made up :) ) when running gnome. And I find it quite natural if someone says they prefer konsole infront of Terminal when running KDE - it is not about functionality, or the applications themselves because they *are* actually very similar and there really is no reason choosing the other in front of another. Except, when it comes to the desktop integration aspect, which makes us prefer one, even though they are functionality wise identical.
There _are_ cases where having both the KDE and GNOME version around is just exsessive, there is no reason. If you choose gedit in front of kedit you really do it because you like GNOME/GTK feel not because of the app, and then you should be running GNOME(and probably is - problem naturally gone). There's a bunch of these highly identical apps, ie. System Monitor vs ksysguard.
There's nothing to fight about, no reason to feel upset because this proposal does not say "KDE is bad", or "GNOME is bad", it only highlights the fact that we are two different DE projects with some duplicated functionality and then goes on to correct the usability problem the fd-menu-spec unfortunately leads to.

Because usability wise the fd-menu-spec(FMS) when fully followed up by both DE's wont work. For example, the GNOME menu will be _flooded_ with tons of small, really-only-useful-for-1%-of-the-userbase KDE apps(and no X-KDE-More support..). If they pursue the FMS their menu will be useless. And our too when they have followed up.
Our current situation of tons of apps, and those who are DE-dependent(some configuration apps, among others) could actually hinder the deployment of the FMS(thus a crucial part of desktop inegration), If you read between the line of the FMS it basically says "Applications conforming to the FMS _will_ run in different desktop enviroments, regardless of their belonging" and when the spec is fully followed up kde apps is (roughly) as much valued as gnome apps in the GNOME DE, and vice versa. To empasize, the spec does a giant blow for intergration. But, if the current situation remains, it won't work.
The FMS is further important since the DE's implementing it conveys an (official) policy saying "This DE works with 'foreign' apps and sees it as a Good Thing". This is already implicit stated but is important for integration and stopping the FUD in massmedia and our "forums"(or what to call slashdot? Chicken run? :) ).

I think my proposal is interesting because it forces GNOME/KDE to explicitly talk about these issues. There's a tension/FUD which says KDE hate GNOME, KDE apps are always better and not wanted(and vice versa) - my proposal forces us to talk about our apps in a way where FUD won't exist. As outlined above, the reasons to not have those particular GNOME apps in the KDE menu and vice versa is well funded, not BS - it is quite resonable and understandable and thus flameproof. To put it in another way, my proposal helps us to "ventilate" something that does not exist(a hostility and polarization between the DEs).
Another interesting, important point is that it further forces us to explicit say "That gnome app is superior, please don't do a NotShowIn=KDE - because _we want it_"(and vice versa), it will bring the "KDEvsGNOME" discussion to a rational level. It demands a dialog - KDE will ask GNOME to change for KDE's improvement and GNOME will ask KDE for GNOME's improvement - it is a moral relationship which leads to collaboration, helps both projects, deploying FMS and boosts integration. It will be fun.
It's very easy for us KDE developers(and vice versa actually) to think GNOME will "hurt" the most(and then you got everything backward). The proposal has a positive outcome, but most important, it requires, and gives as equally much to both projects - because it is not only GNOME apps that will be abscent in KDE, KDE apps will also be abscent in GNOME(and again, that is not a bad thing for KDE).
When the FMS is deployed and the boundaries between the DE's will blur, intergration will be further pushed, people will start asking "Why is there Bug Report Tool and Konqi crash handler?"(suggesting bug reporting infrastructure to be merged) or perhaps "What is the difference between the GDM configurator and the thingy in the kontrol panel? Which one should I choose?"(perhaps leading to an ultimate, shared login manager with common config interface....).

Regarding Frans' cluttered menus, Aaron J. Seigo suggested not installing so many apps...

4. Zoom shortcuts in khtml [kde-usability, kfm-devel]

24 Dec 2003 - 30 Dec 2003 (9 posts) Archive Link: "CTRL+Key_Plus and CTRL+Key_Minus as zoom shortcuts in khtml"

Topics: Integration, Konqueror

People: Simon PerreaultWaldo BastianLeo Savernik

Simon Perreault said:

It was discussed on fedora-devel-list@redhat.com (mailto:fedora-devel-list@redhat.com) of some integration work involving Konqueror. It was suggested that CTRL+Key_Plus and CTRL+Key_Minus be used as default zoom shortcuts in khtml. Those keys do not conflict with other shortcuts.

I've looked at the code, and the change would not be trivial since all zoom-related actions are in fact only one action.

Would these shortcuts be acceptable as defaults? If so, what are the odds of having this integrated in time for 3.2?

Waldo Bastian stated that "this has already been implemented but for some reason the shortcuts are not shown in the menu." It was later pointed out that the zoom action activated by the keyboard accelerators was not the same as the one in the menus - in fact, the zoom steps are very different, the keyboard-activated one being much bigger than the other. Leo Savernik stated that "Actually the zoom stepping of the visible action should be as big as the stepping for the keyboard action" in his opinion and that he "intended to implement it this way originally, but no agreement on an optimal zoom stepping could be reached. Therefore, this two pronged approach exists."

Later, Simon Perreault provided a patch for making the two action be the same, but no consensus on the stepping size was reached.

5. KDE screen resolution policy [kde-usability, kde-accessibility]

25 Dec 2003 - 28 Dec 2003 (13 posts) Archive Link: "KDE screen resolution policy"

Topics: Accessibility

People: Frans EnglichWaldo Bastian

Frans Englich proposed:

Hi everyone,

I run KDE HEAD on a 15" monitor in 800x600 and some KDE applications are simply not usable in the sense that dialogs expand outside the screen and can not be resized to fit inside the screen. Another situation is the KMenu which when is too big expands into two rows, making it practically cumbersome to use(it would be better to drop the "Most Used Applications" count, IMHO). A two row KMenu takes up about 80% of the sceen space.

AFAICT, the KIG says nothing about in what resolutions an conforming application should be usable in, nor in what resolution/screen size relationships the content should be easily interpreted/readable. For example, on my screen the date in clock applet is very small and hard to read.

Should we add to the KIG(or some other KDE policy paper) what resolutions and screen sizes an conforming application must be usable in? Note, it is ofcourse ok if an app is more convenient to use at higher resolutions but it must be possible to use it at the defined minimum level(ok/apply buttons not outside the screen for example). Further, it must ofcourse be as usable as possible at that minimum level.

I propose setting the resolution treshold at 800x600 because we can assume a lot of users run it. It is easily to say "no one runs that small screens anymore" but consider for one second where open source solutions is currently deployed - developing countries. And when setting up servers you sometimes use old monitors. Theoretically it doesn't harm to have a low threshold, except it can be hard to practically conform to the policy. A positive side effect of 800x600 is that it will be easy to conform to the policy. I don't know if exceptions to the policy should be allowed, there is perhaps cases where it is impossible to design GUI's for 800x600.. Otoh, the KIG is just guidelines..
I volunteer to writing the texts and in those cases where I can follow it up, such as filling bug reports and fixing the layouts.

What do people think? Is it a good idea? Do we need such a policy/guideline? Pros/Cons?

Waldo Bastian stated that "the rule so far is that KDE as a whole should work with 800x600 and that individual windows should not exceed 640x480" . It was considered whether some "automatic-scaling" funcionallity could be provided, or, at least, automatically adding scrollbars to dialogs that would otherwise not fit in the screen. It was asked whether this functionallity could be added in Qt 3.3, but Harald Fernengel said that Qt 3.3 was already in beta, and no new features could be added at this time. However, Harry stated that he'll keep the feature request and ask the right people about it later.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.