Hi there,

On Tue, Oct 21, 2008 at 1:10 AM, Diederik van Lierop <mail@...1689...> wrote:

Hello Krzysztof,

Using a pre-compiled rev. 20019 on XP, I run into an assertion when I select a few objects and hit ctrl-shift-a to align them:

ERROR:src/preferences.cpp:470:Inkscape::XML::Node* Inkscape::Preferences::_getNode(const Glib::ustring&, bool): assertion failed: <pref_key.at(0) == '/')

I can confirm this error happens for me as well. The problem seems to have occurred at build 20019 (I just tested build 20018, and it doesn't exhibit this problem), and is still present in build 20028.

The gdb backtrace is below if it helps.

--Mike

----------------- (gdb) bt #0 0x0000003064632215 in raise () from /lib64/libc.so.6 #1 0x0000003064633d83 in abort () from /lib64/libc.so.6 #2 0x00000031a525ced7 in g_assertion_message () from /lib64/libglib-2.0.so.0 #3 0x00000031a525d372 in g_assertion_message_expr () from /lib64/libglib-2.0.so.0 #4 0x0000000000465f23 in Inkscape::Preferences::_getNode () #5 0x0000000000466319 in Inkscape::Preferences::_getRawValue () #6 0x00000000004663c9 in Inkscape::Preferences::getEntry () #7 0x00000000008c1e1d in Inkscape::UI::Widget::Panel::_init () #8 0x00000000008c3bb9 in Inkscape::UI::Widget::Panel::Panel () #9 0x00000000005d35b6 in Inkscape::UI::Dialog::AlignAndDistribute::AlignAndDistribute () #10 0x00000000005c9c92 in Inkscape::UI::Dialog::PanelDialogInkscape::UI::Dialog::Behavior::DockBehavior::createInkscape::UI::Dialog::AlignAndDistribute () #11 0x00000000005c7429 in Inkscape::UI::Dialog::(anonymous namespace)::createInkscape::UI::Dialog::AlignAndDistribute, Inkscape::UI::Dialog::Behavior::DockBehavior () #12 0x00000000005c6103 in Inkscape::UI::Dialog::DialogManager::getDialog () #13 0x00000000005c6199 in Inkscape::UI::Dialog::DialogManager::showDialog () #14 0x000000000079615b in sp_action_perform () #15 0x000000000047cfd8 in sp_shortcut_invoke () #16 0x0000000001236132 in ?? () from /usr/lib64/libgtkmm-2.4.so.1 #17 0x00000031a8387452 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #18 0x00000031a560b6cd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #19 0x00000031a561fbc2 in ?? () from /lib64/libgobject-2.0.so.0 ---Type <return> to continue, or q <return> to quit--- #20 0x00000031a5620a0f in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #21 0x00000031a56210d3 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #22 0x00000031a84f48be in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #23 0x00000031a84f4406 in gtk_widget_event () from /usr/lib64/libgtk-x11-2.0.so.0 #24 0x00000031a83859a0 in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0 #25 0x00000031a8384625 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0 #26 0x00000031a6e57c29 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #27 0x00000031a523742b in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #28 0x00000031a523ac0d in ?? () from /lib64/libglib-2.0.so.0 #29 0x00000031a523b13d in g_main_loop_run () from /lib64/libglib-2.0.so.0 #30 0x00000031a8383db0 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #31 0x0000000000449a39 in sp_main_gui () #32 0x0000000000449e9d in main () -----------------

Ctrl+Shift+O also crashes with the same diagnostic:

** ERROR **: file preferences.cpp: line 482 (Inkscape::XML::Node* Inkscape::Preferences::_getNode(const Glib::ustring&, bool)): assertion failed: (pref_key.at(0) == '/') aborting...

The two assertion triggering bugs and an extra one (triggered by opening the messages dialog) were removed in rev 20038. I'm investigating the 3D Box problem now.

Regards, Krzysztof Kosiński

On Oct 21, 2008, at 2:20 PM, Krzysztof Kosiński wrote:

Regarding the GConf backend: the XML file backend will always be present, and when GConf is not installed on the system the XML backend will be used instead of GConf. For the Windows version it won't even be compiled in.

So how does this relate to the XDG directory support?

Using those, one can launch multiple instances of Inkscape with completely independent sets of settings, assets, etc.

Jon A. Cruz wrote:

So how does this relate to the XDG directory support?

Using those, one can launch multiple instances of Inkscape with completely independent sets of settings, assets, etc.

GConf stored the user database in ~/.gconf, so it's outside XDG directories, but for the relevant use cases (Inkscape would use GConf only in Gnome) it shouldn't be a problem. The settings for each user are still completely independent. Can you describe a use case that demonstrates the XDG features you mentioned in more detail?

BTW, the backend could be selectable via the command line or an environment variable like the GC mode is. For now I can think of XML file, GConf, and a dummy backend that doesn't save anything on exit for testing and debug purposes.

Regards, Krzysztof Kosiński

Joshua L. Blocher wrote:

I'm not sure that having more than one way to store preferences is a "good thing". Seems to me to it adds unneeded complexity. It will make cross-platform troubleshooting harder.

The solution is to add a switch to the command line that will tell the program to ignore the saved preferences altogether, or reload the defaults. Additionally, I think the GConf backend won't cause much headaches after it is implemented. It will be much simpler because most of the work will be done by GConf. By the way, clearing GConf data is as easy as deleting the prefs file - just remove ~/.gconf/apps/inkscape.

Joshua L. Blocher wrote:

It is harder to explain to users if its stored in a different way on every platform

It would only be stored differently for Gnome. In Gnome, there is a GUI tool to tweak the GConf settings (gconf-editor). It shows the name and description for each setting, so it's self documenting. It's actually easier to tweak because everything is documented. One of my motivations for GConf is that it will require documenting user-settable preferences in the GConf schema files (undocumented settings are still permitted, but discouraged).

Joshua L. Blocher wrote:

Especially since it looks like gconf backend loses us any gain on XDG compliance.

I had a look into this. XDG basedir spec only defines directories in which to place and search for specific kinds of files. If you don't have a file, XDG basedir doesn't concern you. With GConf we are not breaking compliance, because we are not using a file. Similarly we wouldn't break compliance if we decided to store our settings in some location on the Web. The purpose of this spec is to ensure that you can place your config in any dir you like, and then be sure the application finds its stuff. With GConf we don't even have to look for the stuff (we're just talking to the GConf daemon).

By the way, using ~/.config/Inkscape is not correct. It's also wrong to store palettes, templates and the like there. The right way to do this is to use g_get_user_config_dir for the configuration directory and g_get_user_data_dir for the data directory (palettes, templates, extensions...).

Links: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html http://library.gnome.org/devel/glib/unstable/glib-Miscellaneous-Utility-Func...

Regards, Krzysztof Kosiński

On Oct 22, 2008, at 2:34 PM, Joshua L. Blocher wrote:

I have to disagree the spec clearing states, ~/.config is the default location (configuration files) unless otherwise set. It is IMO is where gconf should be putting all configuration files it deals with.

<quote> $XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used. </quote>

So, ~/.config/Inkscape is where we should be if everything is default which to my knowledge is true on most *nix systems. And if not we get it by grabbing the correct directory. As to where palettes and other media supplies go, You maybe correct I'm not sure on that point but I thing the CREATE project covers those. :)

Yes, that's about how it works. Krzysztof, you should look into the mailing list archives for the last few months, as there was discussion of it, and I committed some changes to switch to use the XDG stuff.

Some quickies:

XDG_CONFIG_HOME=~/newConfig ~/devel/inkscape/src/inkscape

XDG_CONFIG_HOME=~/iconWorkConfig inkscape

XDG_CONFIG_HOME=~/portraitWorkConfig inkscape

XDG_CONFIG_HOME=~/.inkscape inkscape

I don't trust the download numbers by any means to be an accurate measurement of where our user base is. You should take into account that on the Linux side people generally get packages via the maintainers of their distribution rather than SF. Plus, the savvy users (of all platforms) pull via svn. Just throwing that out there.

Cheers, Josh

Agreed. Doesn't change my opinion about possible confusion of having multiple back ends for preferences. Or the extra work diverging methods of doing the same thing makes. But since I'm the lone dissenter about this (like the Windows File Dialog) I'll close my mouth.

Joshua L. Blocher verbalshadow

jiho wrote:

I think that this issue relates to something that was already discussed several times before, which is: is it better to favour identical behaviour for Inkscape on all platforms or to integrate it as much as possible in the conventions of each platform? I, for one, strongly lean toward the second possibility. I think the most common scenario, by far, is people using Inkscape on *one* platform, rather than on several different ones. And it would make the life of those people a lot easier if the conventions of their platform of choice were respected. Of course, it will make support more complicated, but the support community of Inkscape is wide and probably can cover that (plus, if you tell users to go and check their preferences file and that they don't know where it is, it is not Inkscape support they need, but basic platform support). On this particular "preferences" question, I have a long standing to-do which is to move the preferences from .inkscape to ~/Library/Preferences/Inkscape/ as it should be on OS X. I believe it is a good idea because it is the first place people will look for them, it does not require resorting to the terminal to access them, it would get along well with backup systems and many other stuff that are standard on OS X. I just never got around to doing it. I also think that gconf is based on a marvellous concept and that it should be generalised, with an even more user friendly interface, to all linux desktops; so if Inkscape can push towards this way on Gnome at least, that would be great... but that is a personal opinion of course ;)

JiHO

http://jo.irisson.free.fr/

I disagree about most users only using one platform, maybe I'm just basing it on my experience to much but for a long while I was using Linux and Windows. I wonder what percent of devs use more than one platform.

Anyway where the preference file is stored on each platform is not the issue never has been(except for XDG compliance) , the issue is different backends to store preferences for what is essentially the same platform Linux but with Gnome or KDE installed. What happens if both are install? Do my preference depend on if I'm running Gnome to use gconf? Does KDE use the XML or gconf backend? So a basic question is will my settings stay the same across Gnome and KDE sessions without extra effort (Yes, I use both. I find Gnome to be more power efficient when on battery then KDE4). So now instead of one possible way for this platform there are two. I think the gconf backend should be opt-in not opt-out that way it has to be a something the user sets and will know they set.

I hope I have explained my concerns well enough so everyone understands.

Joshua L. Blocher verbalshadow

On Thu, Oct 23, 2008 at 12:53 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:

The most important issue so far is running Gnome and KDE on the same machine. I'm not sure how to solve this yet. One possible dump prefs to the XML file (it's easier to write import/export routines than to implement everything using the XML document) and store a timestamp in the GConf database, then use the source that is more recent - this way GConf would be used in Gnome but the XML file would still be available. However, this gets complicated.

Oh my. Don't we have enough trouble with multiple platforms, do we really need to pile the KDE/Gnome troubles upon ourselves? One bright spot so far was that, whenever I need to troubleshoot someone's Inkscape problem, I could tell them to find their preferences.xml and edit it in a simple way, and that worked with every version on every platform. Moving this file to ~/.config in 0.47 was already trouble enough, can we please stop here and not go into anything potentially much worse?

I hold nothing against the refactoring changes in the code, but there's absolutely nothing wrong IMHO with storing prefs in a simple XML file portable across platforms and versions. Let's not fix what is not broken. The "advantage" of it being editable by some 3rd party tool is not really an advantage at all, because it will reqiure, when troubleshooting, to find first an Inkscape expert who knows and uses this tool and can help the user with it. It will just fragment the support community and make remote debugging a nightmare.

One more preferences related bug here:

When I check radiobutton: Create object with - Last Used Style for any tool, I get (all rev. starting at rev. 20019 on XP):

Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x0071d083 in Inkscape::XML::CompositeNodeObserver::notifyAttributeChanged () #2 0x0051ddfd in Inkscape::XML::SimpleNode::setAttribute () #3 0x0044bf30 in Inkscape::Preferences::_setRawValue () #4 0x0044c08f in Inkscape::Preferences::setInt () #5 0x0096e3e4 in Inkscape::UI::Widget::PrefRadioButton::on_toggled () #6 0x018cde91 in Gtk::ToggleButton_Class::toggled_callback (self=0x9ad5a80) at togglebutton.cc:140 #7 0x63a43945 in g_closure_invoke () from c:\program files\inkscape\libgobject-2.0-0.dll #8 0x63a57872 in signal_emit_unlocked_R () from c:\program files\inkscape\libgobject-2.0-0.dll #9 0x00000000 in ?? ()

The settings in preferences.xml will be updated before the program crash.

Preben

-----Original Message----- From: Krzysztof Kosiński [mailto:tweenk.pl@...400...] Sent: 22 October, 2008 05:34 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Preferences refactoring - important changes

The two assertion triggering bugs and an extra one (triggered by opening the messages dialog) were removed in rev 20038. I'm investigating the 3D Box problem now.

Regards, Krzysztof Kosiński

View this message in context: http://www.nabble.com/Preferences- refactoring---important-changes-tp20072337p20100862.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

---

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Thu, 2008-10-23 at 13:45 -0300, bulia byak wrote:

On Thu, Oct 23, 2008 at 12:53 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:

...

The most important issue so far is running Gnome and KDE on the same machine. I'm not sure how to solve this yet. One possible dump prefs to the XML file (it's easier to write import/export routines than to implement everything using the XML document) and store a timestamp in the GConf database, then use the source that is more recent - this way GConf would be used in Gnome but the XML file would still be available. However, this gets complicated.

Oh my. Don't we have enough trouble with multiple platforms, do we really need to pile the KDE/Gnome troubles upon ourselves? One bright spot so far was that, whenever I need to troubleshoot someone's Inkscape problem, I could tell them to find their preferences.xml and edit it in a simple way, and that worked with every version on every platform. Moving this file to ~/.config in 0.47 was already trouble enough, can we please stop here and not go into anything potentially much worse?

Perhaps we should add a command line option to dump the configuration then. I really do think that GConf provides a ton of advantages and should be a goal long term. I do believe that GConf is running on Windows though, so it should be the same tools regardless of platform.

All in all, I think it's worth waiting as it's likely that GConf will be replaced here shortly with something that is DBus based rather than CORBA based. Then would be a good time to switch rather than switching to something with a limited lifespan.

--Ted

On Mon, Oct 27, 2008 at 7:35 PM, Ted Gould wrote:

Perhaps we should add a command line option to dump the configuration then. I really do think that GConf provides a ton of advantages and should be a goal long term. I do believe that GConf is running on Windows though, so it should be the same tools regardless of platform.

Isn't GNOME has a switch to dconf in its roadmap?

Alexandre

Alexandre Prokoudine wrote:

Isn't GNOME has a switch to dconf in its roadmap? Alexandre

http://live.gnome.org/dconf Yeah, it looks like this will replace GConf in the future. Thanks for the information that it exists. But it looks like the GSettings API is what will be interesting, while dconf is an implementation detail. GConf can also implement GSettings. It's a pity that the file format will be binary though.

Regarding GConf on Windows, it doesn't work :( Maybe the new dconf + GSettings system will.

Regards, Krzysztof Kosiński.