kdeutils/kcalc broken from recent kcfg changes
pino at kde.org
Wed Jul 8 02:28:16 BST 2009
> (If kcfg is not relevant to k-c-d, please drop them with my apologies.)
(the opposite, actually)
> kcalc fails to build due to the additions of _helper methods, since the
> code relies on variable declarations from previous settings.
> Unfortunately, things are not as simple as just adding copies of the
> declarations to each setting, since the code also appears in the ctor.
Yes, I know about it.
> Is there a way to fix this without making many copies of the same
> variable with different names?
Given that adding accessors for the default value, as done originally in a
recent patch by Albert, can have two down-sides
a) not being 100% sure <code> snippets are totally independent one from each
b) avoid people getting "grown" generated cpp/h files for a feature they don't
I propose, with Albert's approval, the following: explicitely adding in the
.kcfgc file the option DefaultValueGetters=true for eanbling it (default:
false). This way, nothing should change in the generated cpp/h files wrt KDE
4.3, and only users of that would enable it.
What do you (all) think about it?
> (Also, who do I yell at for changing the code generation w/o checking
> that it didn't break existing users? ;-) </friendly ribbing>)
Given that the feature was committed by Albert, who left for akademy the day
after, I fixed it on my own making it working (modulo <code> snippets for
default values depending on other ones); so I guess I could (but I won't) take
Although, given that akademy people had a crappy (at most) internet working
(so had difficulties in reaching him), and that after all trunk is open since
few days (and the breakage is there since not even half a week), what about
being a bit more patient, instead to "have to yell" at first? </friendly
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel