[rekonq] Rekonq Settings

[Anton Kreuzkamp]

> > I am concerned that rekonq seems to get further and further away from
> > established standard practices in KDE.  One of the things I like about
> > KDE is that applications are very consistent in their behavior.  I
> > know pretty much what to expect when I try to do something ordinary
> > with an application, and I know pretty much where to look to find
> > something.  The way settings applications work, for instance, is very
> > consistent across all of KDE.
> 
> Todd, in my KDE vision (as user) what you call "established standard
> practices", I see as "kde3 reminiscences".
> Please, note I'm not saying they are bad, but... taking a look at my
> desktop... I use dolphin without menubar and with a right-panel; I see
> systemsettings and I usually think: "is really this a kde app?"; I'm
> forced to no more use kmail because it simply does not work here; you
> know what my default browser is... all this to say that the conventions
> we established and now consider "standard" are probably old and win98-like.
I'd like to put in my two cents here. Yes, many "established standard 
practices" seem very frumpy and I'm also rather the kind of person that likes 
to approach things in new ways. But consistency and well defined "standard 
practises" are equally important to me.
That means two things:
1. We need standards. Rather than simply doing something the way we want, we 
should discuss in a more global context (kde-wide) about the approaches and 
workflows. (Which doesn't mean we can't be the first ones to use them)
2. We need to use approaches every application can use. The menu-button is 
something everyone can do  (see menu-button in windeco). The idea of putting 
settings into the browser window is something a browser can do, but noone 
else. So this WILL break consistency, instead of highlighting a new way 
forward.

But there's one thing I'd like to show up here:
http://community.kde.org/Calligra/Usability_and_UX/Common/Startup/Startup_view_integrated_with_the_File_menu
This is not about settings, but shows nicely how interfaces can be more 
streamlined. That is an approach non-webbrowsers could use as well. Maybe that 
can give some food for thought.
> 
> > I can see the benefit from having a touch-oriented settings
> > application, but I am not sure it worth breaking consistency with the
> > rest of KDE on the desktop.  In some cases there are clear benefits to
> > breaking consistency, like the menu button, but I don't see that being
> > the case here.
> 
> This is the real point, yes. We need to think if this change will give
> our users a real benefit or not. If so, I don't mind using a
> non-standard way. If not, We'll use it as fallback solution.
Here I would propose the oposite path. See what the others do (i.e. plasma-
active/calligra(see above)) and check whether we can adapt it. If not, think 
about our own way, like showing the settings as browser-tab.

Cheers, Anton