I have committed a rewrite of the preferences system. The old Inkscape::Preferences stub class was replaced by a meaningful singleton, and everything in prefs-utils.h except the recent file list was replaced with stub functions using the new class. I replaced all instances of prefs_get_string_attribute(), create_pref(), pref_path_number_of_children() and pref_path_get_nth_children(). I'll now concentrate on refactoring code which contains calls to inkscape_get_repr() - it is equivalent to the new _getNode member function, but it should be private. I have also introduced boolean preferences in a backwards-compatible way - generally you can replace prefs_get_int_attribute_limited(blah1, blah2, 0, 1, 0) with prefs->getBool(blah1, blah2).
There is however some weird breakage in the Calligraphy tool - e.g. sometimes it seems that tracing is on while the widgets indicate that it is off. I don't know whether this is something introduced by the rewrite or a pre-existing bug. Can someone more familiar with this code (widgets/toolbox.cpp) take a look?
On Tue, Sep 16, 2008 at 2:36 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
I have committed a rewrite of the preferences system. The old Inkscape::Preferences stub class was replaced by a meaningful singleton, and everything in prefs-utils.h except the recent file list was replaced with stub functions using the new class. I replaced all instances of prefs_get_string_attribute(), create_pref(), pref_path_number_of_children() and pref_path_get_nth_children().
Just curious, what are the advantages of this? Performance, maintainability?
I'll now concentrate on refactoring code which contains calls to inkscape_get_repr() - it is equivalent to the new _getNode member function, but it should be private. I have also introduced boolean preferences in a backwards-compatible way - generally you can replace prefs_get_int_attribute_limited(blah1, blah2, 0, 1, 0) with prefs->getBool(blah1, blah2).
and what happens to the default which was returned if no such repr was in the prefs?
There is however some weird breakage in the Calligraphy tool - e.g. sometimes it seems that tracing is on while the widgets indicate that it is off. I don't know whether this is something introduced by the rewrite or a pre-existing bug. Can someone more familiar with this code (widgets/toolbox.cpp) take a look?
The widget simply does not watch for changes in the repr, so if it is changed by someone outside, such a discrepancy will arise. Typically the repr is changed by the button's toggle callback only, and therefore there's no discrepancy. Please check if something else can change this pref value (e.g. for this reason, such prefs that are editable on the control bars of tools, should not be in the Preferences dialog).
Also it fails to compiled for me:
preferences.cpp: In member function 'void Inkscape::Preferences::_load()': preferences.cpp:85: error: 'compose' is not a member of 'Glib::ustring' preferences.cpp:99: error: 'compose' is not a member of 'Glib::ustring' preferences.cpp:106: error: 'compose' is not a member of 'Glib::ustring' preferences.cpp:120: error: 'compose' is not a member of 'Glib::ustring' preferences.cpp:128: error: 'compose' is not a member of 'Glib::ustring' preferences.cpp:136: error: 'compose' is not a member of 'Glib::ustring' preferences.cpp:142: error: 'compose' is not a member of 'Glib::ustring'
I have glib 2.14.4
The bugs in the calligraphy tool and build failure on glib 2.14 are fixed now. It was an interaction with the event context code that used inkscape_get_repr and assumed that booleans are stored as "0" and "1", while I insisted on using "true" and "false". Sorry for the problems this caused.
Regards, Krzysztof Kosiński
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Krzysztof Kosinski Sent: woensdag 17 september 2008 0:17
The bugs in the calligraphy tool and build failure on glib 2.14 are fixed now. It was an interaction with the event context code that used inkscape_get_repr and assumed that booleans are stored as "0" and "1", while I insisted on using "true" and "false". Sorry for the problems this caused.
How are "old" preference files handled with this change? (are my preferences maintained when updating inkscape?)
-johan
There are no preference file changes yet, so everything should work exactly as before.
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Krzysztof Kosinski Sent: woensdag 17 september 2008 0:17
The bugs in the calligraphy tool and build failure on glib 2.14 are fixed now. It was an interaction with the event context code that used inkscape_get_repr and assumed that booleans are stored as "0" and "1", while I insisted on using "true" and "false". Sorry for the problems this caused.
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Krzysztof Kosinski Sent: vrijdag 19 september 2008 1:32
There are no preference file changes yet, so everything should work exactly as before.
I meant: how is e.g. "1" from old preference files handled, when the new code 'insists' on "true" ? Or did you change the "true" back to "1"?
"true" and "1" are interpreted as true, while "false" and "0" are interpreted as false. Additionally, when the getInt method is called, "true" is interpreted as 1 and "false" as 0. This accommodates integer preferences that were partially converted to booleans and ave some leftover getInt calls in the code.
-----Original Message----- From: Krzysztof Kosiński [mailto:tweenk.pl@...400...] Sent: maandag 22 september 2008 17:39 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Preferences refactoring + Calligraphy tool
"true" and "1" are interpreted as true, while "false" and "0" are interpreted as false. Additionally, when the getInt method is called, "true" is interpreted as 1 and "false" as 0. This accommodates integer preferences that were partially converted to booleans and ave some leftover getInt calls in the code.
Super! :-) Johan
bulia byak wrote:
Just curious, what are the advantages of this? Performance, maintainability?
Maintainability.
bulia byak wrote:
and what happens to the default which was returned if no such repr was in the prefs?
The default is still there, I just specified implicit parameters for this method (in this case, false is the "default default" :) for setBool - look at preferences.h).
bulia byak wrote:
The widget simply does not watch for changes in the repr, so if it is changed by someone outside, such a discrepancy will arise. Typically the repr is changed by the button's toggle callback only, and therefore there's no discrepancy. Please check if something else can change this pref value (e.g. for this reason, such prefs that are editable on the control bars of tools, should not be in the Preferences dialog).
No, the tracing button is the only thing that can change this pref. I'm suspecting that the code responsible for actually drawing the stroke uses inkscape_get_repr() instead of the functions in prefs-utils.h.
Regarding the build failure, I'll replace Glib::ustring::compose with something else.
Regards, Krzysztof Kosiński
participants (3)
-
unknown＠example.com -
bulia byak -
Krzysztof Kosiński