[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: [kate] part/utils: guard some options against setting it twice
From:       Dominik Haumann <dhaumann () kde ! org>
Date:       2013-06-30 21:36:49
Message-ID: 4672551.RytHNi8Mjo () eriador
[Download RAW message or body]

On Friday, 28. June 2013 20:09:15 Kevin Funk wrote:
> On Friday, 28. June 2013 19:52:17 Dominik Haumann wrote:
> > On Friday, 28. June 2013 19:42:35 Kevin Funk wrote:
> > > On Thursday, 27. June 2013 10:30:13 Dominik Haumann wrote:
> > > > Git commit 256f7654bd7a1dd20c60558307511b4be1c090bd by Dominik
> > > > Haumann.
> > > > Committed on 27/06/2013 at 10:30.
> > > > Pushed by dhaumann into branch 'master'.
> > > > 
> > > > guard some options against setting it twice
> > > > 
> > > > Setting an option that already is the correct value
> > > > should not emit configChanged(). So all setters should
> > > > 
> > > > have the form:
> > > >   if (!m_optionSet || m_option != option) {
> > > >   
> > > >     configStart();
> > > >     m_optionSet = true;
> > > >     m_option = option;
> > > >     configEnd();
> > > >   
> > > >   }
> > > > 
> > > > This should be done for all setters in KateConfig. Then,
> > > > potentially lots of unnecessary config-changed signals could be
> > > > suppressed. Any volunteers?
> > > > 
> > > > (snip)
> > > 
> > > Hey,
> > > 
> > > I've wondered about kateconfig.cpp the first time I saw it...
> > > 
> > > Why don't you simply use KConfigXT here? Most, if not all of the code
> > > inside kateconfig.cpp could be auto-generated. Am I missing something?
> > > 
> > > Is KConfigXT *not* used because of the distinction between global and
> > > non-
> > > global properties?
> > > 
> > > [1] https://techbase.kde.org/Development/Tutorials/Using_KConfig_XT
> > 
> > answer 1: because these config classes existed before KConfigXT was born.
> 
> I expected that :)
> 
> > answer 2: because someone needs to port it, and the current code works.
> 
> Makes sense, too.
> 
> > answer 3: does it really support everything we need, or would we still
> > need
> > 
> >           to work around some shortcomings?
> 
> That's what I actually wanted to know, because I don't really know what the
> requirements are. I was wondering if you guys evaluated KConfigXT at some
> point.
> 
> Plus I was just asking *now* because you asked someone to touch all of
> kateconfig.cpp, so it's probably time to think about a more maintainable
> solution instead of writing even more boilerplate code.

Ok, more on this: KateConfig allows to have global config values and local 
config values. For instance, if the tab width in a KateDocument is not set,
if falls back to the global tab width. If the global tab width is not set, it 
defaults to the default tab width.

So we have a config hierarchy. Does KConfigXT support that in this way out of 
the box?

Greetings,
Dominik
[prev in list] [next in list] [prev in thread] [next in thread]