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?

this is, IMHO, a bad idea:

• Konqueror's interface is even more complex than KControl's. unless a Konqueror with no toolbars and no menu items that could get in way of using it as a config shell was launched (in other words, basically KControl), it's a step backwards.
• KControl has features such as a search. this is not indicative of its poor usability (other things are ;), it's just one more way to find things easily. if anything, these features have not been pushed to the front enough.
• Drill-down interfaces as provided in a file manager are not particularly easy to use.
• the way services:/ looks in konqueror relies on the Konqueror settings. not only does this make it less consistent between installs (not nice for helpdesks), but it means that if something is wrong with konqueror, good luck in getting to your settings.
• opening control panels in their own windows is a poor design: users have a hell of a time managing windows.

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

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.

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.

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?

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.

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

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)

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

It was discussed on 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?

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?