[rekonq] Rekonq Settings

Andrea Diamantini adjam7 at gmail.com
Wed Mar 21 23:45:32 UTC 2012


On 03/21/2012 12:18 PM, todd rme wrote:
> On Tue, Mar 20, 2012 at 11:26 AM, Andrea Diamantini<adjam7 at gmail.com>  wrote:
>> Hi all,
>> working on the next rekonq 0.10 and following users requests (see i.e.
>> bug:259192), I'm prototyping some news for rekonq settings: a privacy and an
>> advanced tab. See screenshots, easier to explain :)
>> While working on them, I was thinking on... isn't it time to move settings
>> to an "about:settings" window in the same way chrom* does, letting users to
>> change them on the fly (which means,  NO MORE ok-apply-cancel buttons)?
>> What do you think about?
>
> 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 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.

> -Todd

Andrea.


More information about the rekonq mailing list