[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-28 17:52:17
Message-ID: 3446136.Croy2OrJyD () eriador
[Download RAW message or body]

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.
answer 2: because someone needs to port it, and the current code works.
answer 3: does it really support everything we need, or would we still need
          to work around some shortcomings?

Greetings :-)
Dominik
[prev in list] [next in list] [prev in thread] [next in thread]