- Inkscape Devel - Inkscape Mailman

0.47 splash contest?
by Alexandre Prokoudine 27 Apr '09

27 Apr '09

Hi, It seems that there is a general agreement that we are moving to .47 release phase. Should we start thinking about a splash contest then? With winning image going to 0.47 and 2nd place -- to .48/SVN like the last time? Alexandre

8 15

Problem noticed with preferences
by Jon A. Cruz 27 Apr '09

27 Apr '09

In working on some code debugging, I noticed that the preferences were not loaded as the program was first using them. Among other immediate issues this had blocked some debug toggle code from ever being invoked. https://bugs.launchpad.net/inkscape/+bug/367752 As the program starts, preferences are just set to the defaults but not loaded. Then part-way through startup they *do* get loaded. So among other things bits of code might be initialized one way and used another. It would be very helpful if anyone who is looking into a bug might check to see if this is complicating the issue they are working on. If so, then there might be a few cascaded bugs we can reproduce now and then close as soon as the prefs initialization is fixed.

1 0

Change in marker rendering
by Jasper van de Gronde 26 Apr '09

26 Apr '09

For some reason the marker test in SVN is now rendered differently. It seems to be neither a regression nor an improvement (where it is different from the previous rendering both renderings are in error), but given that we're working towards a release I thought I'd mention it in case it was changed accidentally. Both the test file and the references are in SVN (specifically, it's the basic/markers.svg test): https://inkscape.svn.sourceforge.net/svnroot/inkscape/gsoc-testsuite The current rendering test results: http://home.hccnet.nl/th.v.d.gronde/inkscape/ResultViewer.html (The result is still listed as new. I've updated the references, but not rerun the tests.)

1 0

Compile error on XP
by Preben Soeberg 25 Apr '09

25 Apr '09

Got this compiling svn 21229 on XP: Make error line 291: problem compiling: src/ui/widget/dock-item.cpp: In constructor 'Inkscape::UI::Widget::DockItem::DockItem(Inkscape::UI::Widget::Dock&, const Glib::ustring&, const Glib::u string&, const Glib::ustring&, Inkscape::UI::Widget::DockItem::State)': src/ui/widget/dock-item.cpp:47: error: no matching function for call to 'Gtk::IconTheme::load_icon(const Glib::ustring&, int&)' c:/devlibs/include/gtkmm-2.4/gtkmm/icontheme.h:336: note: candidates are: Glib::RefPtr<Gdk::Pixbuf> Gtk::IconTheme::load_icon(const Glib::ustring&, int, Gtk::IconLookupFlags) const

2 1

Showcase call
by Alexandre Prokoudine 25 Apr '09

25 Apr '09

Hi, Our Showcase section at inkscape.org [1] is aging. I did update it quite a bit today, but surely we can do better than that :) So this is an official call to submit the best of your work, used in commercial work at preference. Please forward this to the users list. [1] http://inkscape.org/showcase/index.php?lang=en&css=css/base.css Alexandre

2 1

Re: [Inkscape-devel] Tooltips in 0.47
by John & Melonie Curwood 24 Apr '09

24 Apr '09

Thanks for your Advice Diederik and Alexandre, with regards, to the tools tips, I think once you are proficient with using Inkscape, you won't notice the contents of the tools tips as you know what each Icon stands for. When you are a novice and are just learning Inkscape, (Which I was not so long ago you are constantly reading the tooltips to make sure you are using the right tool and at the same time noticing the keyboard shortcut, and after a few times using a particular tool, you start to remember the shortcut and then start using it, which helps you to become more proficient with Inkscape. Cheers, John

2 1

SVG Filter Effects and Raster filters
by Ivan Louette 24 Apr '09

24 Apr '09

Is there any plan to make Raster filters non destructive ? Or perhaps a more long term proposal for SVG people : adding "Raster filter" (or matrix filter) as a primitive in SVG Filters. ivan

1 0

Inkscape recommended by wacom.ru
by Alexandre Prokoudine 24 Apr '09

24 Apr '09

Hey, I was just pointed to http://wacom.ru/art_list.html (official local Wacom web-site) which lists Inkscape among recommended applications (along with GIMP) and says: "A very efficient vector illustration package. A symbiosis of Corel DRAW and Adobe® Illustrator. Excellent support for pen pressure sensitivity, is rare in the vector world of illustrations, which makes Inkscape a powerful tool for those who does serious calligraphy work.". Alexandre

1 0

more 0.47 planning :)
by Alexandre Prokoudine 24 Apr '09

24 Apr '09

Hi, It seems to me that what we are missing is a screenshots call :) Alexandre

1 0

Re: [Inkscape-devel] [Inkscape-user] Nightly/Testing Builds
by Aaron Spike 24 Apr '09

24 Apr '09

Elwin Estle wrote: > How involved is the Linux process? I am familiar with basic > ./configure, make, make install...but that's about it (I am guessing > this is a bit more complex process?) I think one time I might have > done something from an SVN tree...can't remember what it was or if > the process even worked. I have an AMD Athlon machine running > Slackware 12.2, also a Mac Mini with Leopard. While we have traditionally favored autopackage because it allowed the work put into making a single package to serve users of many different linux distros, I don't think it is a bad idea to make distro specific packages at this point. Slackware has always been a distro on which using the autopackage and even just building inkscape have been difficult for people. I'm not sure why as I've never used slackware. Anything you can do to better the situation for slackware users will be much appreciated. What other distros should we look for packagers for? I believe Ubuntu is already covered by the PPA someone set up. Does fedora have any sort of continuous building system we could make use of? Do other people think contacting the normal distro packagers for platform specific help is appropriate? Making autopackages is no harder than a typical configure, make process. There are different commands to call, that's all. Now setting up the dependencies and the build configuration is a slightly different story. Autopackaging is complicated by the fact that a single package can serve both the old and current c++ ABI and now even both x86 and x86_64 architectures. Building autopackages requires a willingness to learn about linking and check that libraries are linked properly so as to cause as little trouble as possible. There are also a few places in the codebase where we could use relaytool to make libraries optional at runtime. I think we will require a little bit of help from the autopackage project if we are going to get this service up and running again. Aaron Spike

1 0