I have the same problem with the alignment tool. I have narrowed it down to start in SVN 20019. Getting this: --------------------------- Microsoft Visual C++ Runtime Library --------------------------- Runtime Error!

Program: C:\Program Files\Inkscape\inkscape.exe ...

I don't know how VC++ runtime comes into action, so I tried to make a clean build, but still the same. When something crashes in VC++ runtime it would normally offer me the opportunity to run Microsoft debugger, but it does not.

I also had a problem coloring the sides of a 3d-box. It seems to be unstable in SVN 20024 and 20028. Sometimes I can get color on one side but not the next. In SVN 20019 it seemed to crash every time. No problem before SVN 20019.

Preben

-----Original Message----- From: Alvin Penner [mailto:penner@...1856...] Sent: 21 October, 2008 16:05 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Preferences refactoring - important changes

Diederik van Lierop wrote:

...

Using a pre-compiled rev. 20019 on XP, I run into an assertion

similar to : https://bugs.launchpad.net/inkscape/+bug/286496 ?

-- View this message in context: http://www.nabble.com/Preferences- refactoring---important-changes-tp20072337p20086140.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

bulia byak wrote:

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) == '/')

The errors triggering the above assertion are unfortunately related to the refactoring. They are all caused by a path being specified somewhere in the old format (with dot separators). I deliberately introduced this assertion to catch all those places - otherwise bogus things would be written to prefs. I will fix the two bugs reported here today. If you encounter this assertion under different circumstances, reply in this thread. Attach a gdb backtrace or at least describe what you were doing (it should suffice).

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.

Regards, Krzysztof Kosiński

Hi Krzysztof,

Yup, r20038 looks good. I'll post back if there's anything else that crops up.

Thanks!

--Mike

On Tue, Oct 21, 2008 at 3:34 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:

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-tp20072337... 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

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

Preben Soeberg wrote:

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

Fixed in rev 20071. Forgot to add a conditional that calls removeObserver instead of removeSubtreeObserver when a preference observer that only watches for a single attribute is removed.

Preben Soeberg wrote:

Another preferences crashbug:

1. open inkscape
2. open duplicate window (view -> duplicate)
3. close duplicate window
4. press shift+3 to show grid.
5. crash

I get some "warning" and "critical" messages but no crash, maybe it was related to the above one.

Regards, Krzysztof Kosiński

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

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.

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

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.

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