- Inkscape Devel - Inkscape Mailman

update-inkscape - a build/update bash script (Linux)
by Michael Park 22 Oct '08

22 Oct '08

Hi there, So a while ago I hacked together a script to do the legwork of downloading/building/installing. To date, I've been using it w/o any real grief (yet), so I thought I'd clean it up and send it out there on the tubes.. who knows, maybe someone else will find it handy (or wants to adapt it to a real package manager or something). Sorry, I'm not savvy on creating RPMs, DEBs, or what-have-you, so yeah.. I can't help with that just yet. At any rate, here's the useage (pretty simple): # first time build from SVN (no source yet) update-inkscape # catch up your build to the latest from SVN update-inkscape # build a specific SVN version (in this case, -r20036) update-inkscape 20036 Btw, some notes about the script: 1 - This script doesn't take care of Inkscape's build dependencies.. sorry, but the package names differ by distro, so unfortunately I have to leave that up to the user to take care of first 2 - Putting it to work is the usual deal.. put it in ~/bin and 'chmod u+x ~/bin/update-inkscape' 3 - I prefer to keep my source in ~/install/apps/inkscape/trunk (you can change this by editing the ${BUILD_DIR} variable) 4 - when it installs - it installs to /opt/inkscape/${revnum} (I keep a couple revs handy in case the latest doesn't work out) - if you ever want to uninstall/remove an old build, simply 'sudo rm -rf /opt/inkscape/${revnum}' (also don't forget to rm the symlinks in ~/bin) - if you ever want to switch your default 'inkscape' command to an older version, simply run 'ln -sf /opt/inkscape/${revum}/bin/* ~/bin' 5 - it uses 'sudo' for the root privilege stuff (which isn't setup by default on Fedora, but it's pretty easy to, let me know if you got q's) 6 - I did away w/ the normal output flood, and instead replaced them with 'busy dots'... sorry, I didn't implement a toggle switch for this - however, output is by default saved to: ~/install/apps/inkscape/trunk/${cmdname}.log ~/install/apps/inkscape/trunk/${cmdname}-error.log - the one downside to this is that 'sudo make install' is unfortunately saved to the unhelpfully named 'sudo.log' and 'sudo-error.log' Let me know if you folks have any questions/run into any problems. Hopefully the script source is clear enough to grok, but my bash-fu is still pretty grasshopper.. so if you've got any suggestions for improvement, feel free to let me know. Cheers. --Mike

1 0

Recent Documents list
by Josh Andler 22 Oct '08

22 Oct '08

Unfortunately the recent change seems to nuke the recent documents list within Inkscape. However, this has been a long standing wishlist item. Krzysztov, is this wishlist item now fulfilled? https://bugs.launchpad.net/inkscape/+bug/170016 Cheers, Josh

3 5

NEW: Lots of stuff
by Ted Gould 22 Oct '08

22 Oct '08

Sorry, I got off on a branch and ended up with a bunch of things. I'm just going to flatten and merge... Here's the list. * Added a focus mode activated by Shift+F11. The goal of this mode is to remove all toolbars for a short period so that you maximize screen area. Useful on small screens. Also when you know lots of shortcuts. * Created what I'm calling "Quick Zoom." The idea here is to have a modal zoom for touching up something with fine detail and then returning to what you're doing. This is activated with the letter "Q" on the keyboard. When you release it, you return back to where you were. This will zoom in on selected objects, or if you're in the node tool selected nodes. * Added .svg on the temporary files in extensions. This'll make many of them happier. This only works on recent versions of GLib, but shouldn't break older ones more than they already are. * Moved the Inkscape configuration directory on Linux from ~/.inkscape to ~/.config/Inkscape. This is the new way to do things with the cross desktop naming spec. I'm unsure whether we should be putting crash dumps in .config or .cache though. * Removed 'tools_switch_current' because every usage of it already had a pointer to where it needed to go. Removes usage of globals. * Made it so that dialogs will be transparent when not focused. This is an alternate to having the docked, and one that I like better as I feel it gives me more screen area. You can adjust how much transparency and the speed of the animation in the preferences dialog. (Note: this requires GTK+ 2.12 and a compositor, but gracefully degrades if you don't have either)

12 45

Re factoring effort
by Krzysztof Kosiński 21 Oct '08

21 Oct '08

Since the main focus of 0.47 is refactoring, I'm posting some ideas for discussion I've come up with while refactoring the preferences code (the final version of which just made it into SVN). 1. id-clashes.cpp - this is a stopgap solution at best. The roadmap proposes to solve this problem by making SPObjects ref-aware. I think this isn't a good idea, as it uses a canvas level API to solve an XML level problem. The real solution would be to make the XML tree CSS-aware (to detect ID references in CSS), and handle this transparently by special-casing the "id" attribute so that setAttribute("id", "something") would automatically update every ID in the document. An alternative approach would be to have an XML::Document level API like alterID(gchar const *oldid, gchar const *newid) which would do the same. 2. Tools tree. This is one of the last big chunks of GObject left in the codebase. It's also rather messy - for example, every tool has a gradient dragger but in reality it only makes sense for the Node and Gradient tools. Converting this hierarchy to C++ would be a great step forward. It would also get rid of toolbox.cpp. 3. Namespace proliferation. Many namespaces contain just a few members and their fully qualified names are very long. The record is namespace depth of 4 for internal bitmap extensions and a few other things. Is this level of granularity really necessary? There's also the UI namespace - its purpose is unclear to me because Inkscape::UI::Widget::SuperGizmo conveys no additional information compared to Inkscape::Widget::SuperGizmo. It's obvious to me that widgets and dialogs are parts of the UI, so why put Widget and Dialog namespaces in another namespace? On top of that, names of many classes are redundant, like Inkscape::UI::Dialog::SomeDialog. It should be either Inkscape::UI::SomeDialog or Inkscape::Dialog::Some. BTW: The "using namespace" directive is discouraged in the coding practices. 4. Transferring data between Inkscape and other apps. The new clipboard code is a step in the right direction (by the way - thanks for everyone for fixing the issues with it I weren't able to find), but the "import/export drawing data as some format" functionality should be split off into another function/object, so that the same code is used for importing and exporting via drag-and-drop, the Import and Export dialogs and the clipboard. 5. Memory leak problem (?). Inkscape is constantly eating memory even when idle. Is anyone aware of why is this happening? Also of note is the fact that creating a single rect can take up to 250 kilobytes. 6. Verbs. It looks like verbs.cpp is a reimplementation of Gtk::Action with some extra features. I don't know this part of Inkscape very well but it looks like we could create an Inkscape::UndoableAction deriving from Gtk::Action and use it instead of verbs. We could then use Gtk::UIManager to build menus and toolbars. Please let me know if you have any suggestions / objections regarding those refactoring problems, and whether they make sense to you. Regards, Krzysztof Kosiński. -- View this message in context: http://www.nabble.com/Refactoring-effort-tp20079146p20079146.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

4 5

Cannot compile
by Preben Soeberg 21 Oct '08

21 Oct '08

Hi, Missing a file (was deleted in SVN 20013) after a "btool clean": Make error line 294: problem compiling: mingw32-g++: src/fontsize-expansion.cpp: No such file or directory mingw32-g++: no input files >svn up At revision 20028.

2 3

Re: [Inkscape-devel] Preferences refactoring - important changes
by Diederik en Rezi 21 Oct '08

21 Oct '08

Op Di, 21 oktober, 2008 11:05, schreef Alvin Penner: > similar to : https://bugs.launchpad.net/inkscape/+bug/286496 ? No, I don't think so. That one doesn't invoke a crash. Diederik

1 0

gradient fill swap (tooltip?)
by MilesTogoe 21 Oct '08

21 Oct '08

speaking of tooltips - I can never remember the cntrl key to swap a gradient fill from inside-out to outside-in. I've thought about what would be the best way to do this in the gradient editor or the gradient edit bars but really haven't come up with something good. Maybe an extra button on the type of fill. Maybe dragging the bars from positive to negative would do it or maybe just a tooltip that gives the cntrl key - well worth the dwell :)

1 0

Preferences refactoring - important changes
by Krzysztof Kosiński 20 Oct '08

20 Oct '08

Rev 20019 is a preferences refactoring mega-commit. Most of the changes are there in order to simplify adding a GConf backend soon (I'll get to this after cleaning up in the preferences.xml file and handling enum and color preferences sanely). Here are the most important changes from the developer perspective: 1. Preference path syntax has changed to use a single path and slashes instead of dots as separators. The old syntax was based on the fact that preferences are stored as attributes of XML nodes, which was the reason for separation of the two path parameters. The new syntax uses a familiar file system metaphor, and will simplify adding GConf and possibly other backends, like the Mac OS X settings files mentioned somewhere here (?). 2. Preferences are handled through the singleton object Inkscape::Preferences. Use its methods instead of the prefs-utils.h functions. They are mostly equivalent. Be sure to use the correct type. 3. There is no inkscape_get_repr() any more. To retrieve a CSS style from preferences, use the getStyle() or getInheritedStyle() methods. 4. You cannot add an XML observer to the prefs document. Instead, use the inner class Inkscape::Preferences::Observer. Additionally, you can't add the same observer to more than one preference path - you'll have to create multiple instances. There are no changes to the preferences.xml format yet. There will be changes to it in the future, to remove things like /options/somerandomoption/value (which should be /options/some_random_option in GConf, or even better /options/some_appropriate_group/some_random_option) but I'll try to handle them transparently. -- View this message in context: http://www.nabble.com/Preferences-refactoring---important-changes-tp2007233… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

3 3

Attribute lock ratio proposal
by Patrick 20 Oct '08

20 Oct '08

Like many of you I would like to advance the use of SVG only web design. Unless I am missing something, one problem that exists is the automatic Y-axis scaling of designs with text. Specifically what I am referring to is the fact that the flow text box "dead ends" once it is full unlike an html div that can continue to autosize in the Y-Axis(or X). In addition even if the flow text box did resize other elements in the design would not. If for instance we had a blue square for a background and some text in the center then the blue box would also need to resize to prevent the text from flowing past the bottom of it. My programming skills are not up to standard with the rest of you but if you would like, I could hack together a proof of concept in Python, if it was of value someone could re-do it in C and you folks could figure out a where and how to use it in the GUI. By counting line numbers and the pixel height of the letters, I should be able to calculate the size the flow text box should be and then I could use those attributes to resize other attributes. Am I missing something? Is this a dumb idea? -Patrick

2 1

documentation effort
by unknown＠example.com 19 Oct '08

19 Oct '08

Hi all, (cc. Inkscape devel, maybe there are some documentation wizzards out there) I've started a bit of documentation work. The Doxyfile configuration file for doxygen has been updated to the latest version. I've also made some tweaks that I found useful, or want to try a bit. First hour I am using doxygen so... Go to lib2geom's root and run doxygen. Then, you should get doc/html/index.html, which is the homepage of the generated documentation. As you can see, there is a lot to do. Please read a bit of the doxygen manual if you want to contribute a lot. Note 1: Doxygen can generate nice equations: http://www.stack.nl/~dimitri/doxygen/formulas.html Put your LaTeX equations between a pair of "\f$" commands: \f$ x = 1 \f$ Note 2: Doxygen makes use of special commands you can put in your code, such as: /** \brief Scales this vector to make it a unit vector (within rounding error). * * The current version tries to handle infinite coordinates gracefully, * but it's not clear that any callers need that. * * \pre \f$this \neq (0, 0)\f$ * \pre Neither component is NaN. * \post \f$-\epsilon<\left|this\right|-1<\epsilon\f$ */ void Point::normalize() { ... It is worth checking out other commands like \param, \see and \return. Note 3: The documentation is filled with "Geom::" namespace. I have not yet figured out how to tell doxygen to only document the Geom:: namespace and leave all other things (like std!!!!?!??!) out. Note 4: Doxygen accepts two command styles: \pre and @pre. They can be mingled without a problem I think, but shall we try to use the slash? \file, \brief, etc. Note 5: I'll be adding a lot of empty template documentation comments, so you don't have to think much about how to add documentation. This way, many people can help without much knowledge of doxygen. Note 6: We should get a server to run this every day and put it on the web somewhere! (including a tar so people can download it?) Cheers, Johan

5 10

lpe/verbs
by Alexandre Prokoudine 17 Oct '08

17 Oct '08

Hi, Can live path effects have verbs and would it be reasonable at all? Alexandre

1 0

Spiro & "piecewise clothoid curves"
by Bill Baxter 17 Oct '08

17 Oct '08

Saw this paper at SBIM 2008. Sketching Piecewise Clothoid Curves http://www.dgp.toronto.edu/~mccrae/clothoid/ It may be very similar to how Spiro is implemented, but last time I looked at Spiro I couldn't find any sort of an algorithmic description. Anyway, the approach presented by this paper seems pretty simple and logical to me, so maybe it could suggest some ideas for Spiro. Or not. It's a good read either way. The video is nice too. --bb

1 0

Re: [Inkscape-devel] 20,000!
by Bob Jamison 17 Oct '08

17 Oct '08

And of course: http://inkscape.modevia.com/win32/Inkscape20001-0810171634.7z -----Original Message----- >From: Martin Owens <doctormo@...400...> >Sent: Oct 17, 2008 9:45 AM >To: Bryce Harrington <bryce@...1798...> >Cc: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> >Subject: Re: [Inkscape-devel] 20,000! > >Indeed! it's absa'fookin'tastic'a'licious. And any inkscape developer at >USD will get free drinks from me. > >2008/10/16 Bryce Harrington <bryce@...1798...>: >> On Thu, Oct 16, 2008 at 03:47:34PM -0700, Josh Andler wrote: >>> Hey all, >>> >>> I think it's worth noting that Inkscape has passed the 20,000 commit >>> mark. Wow! >>> >>> Johan, nice that it was a refactoring commit! :) >> >> Wow, congrats again everyone! >> >> Bryce >> > >------------------------------------------------------------------------- >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(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

20,000!
by Josh Andler 17 Oct '08

17 Oct '08

Hey all, I think it's worth noting that Inkscape has passed the 20,000 commit mark. Wow! Johan, nice that it was a refactoring commit! :) Cheers, Josh

3 2

inkboard
by monroy-lopez 14 Oct '08

14 Oct '08

Hello. I have been trying out Inkboard without much success. Sorry about being so vague but I haven't noticed a pattern. It just... doesn't work :( I'm wondering... what's the status of Inkboard? In case it's just my configuration, this was the set-up: Inkscape 0.46-r5 on Gentoo. Two computers were connecting to gristle.org. Connecting (and sometimes chatting) works without problems. So far, I have not been able to share a canvas... Best wishes, ivan

2 2

icons
by unknown＠example.com 14 Oct '08

14 Oct '08

Hi all, Inkscape on Windows has had this warning for a looong time now: (inkscape.exe:2628): Gtk-WARNING **: Could not find the icon 'edit-select-all'. The 'hicolor' theme was not found either, perhaps you need to install it. You can get a copy from: http://icon-theme.freedesktop.org/releases The select-all icon is displayed correctly in the menu, but is not displayed in the toolbar. I've been trying to get rid of this warning/error; and as a result I think I've found some legacy dead code concerning icons. Are /src/ui/icons.h and icons.cpp ever used sensibly? The only one calling to these files is edit-widget.cpp. If I remove that call "Icons::init();", nothing changes for me. (all icons are displayed correctly, except for the select all icon in the toolbar) the code in similar files seems very old and not used: stock-items.cpp stock.h Who can tell me more about these files? I am planning on deleting them. Thanks, Johan

3 2

vectorsection
by Alexandre Prokoudine 14 Oct '08

14 Oct '08

FYI: http://groups.google.com/group/vectorsection/browse_thread/thread/6e5d4d820… Eric, are you back? :-) Alexandre

1 0

Appreciation for migration work
by Bob Jamison 13 Oct '08

13 Oct '08

Hi all, I mentioned this on #inkscape, but I thought I should post this on the list, too. For the last several weeks, Johan, Josh, and others have been making huge commits, migrating the vector math code from libnr to 2geom. And for the last few weeks, the grumpier among us (like me :-) have been grouching about build breaks and/or the requirement to perform a complete build after every "svn up." But, hey, that's natural. We like to complain. But nobody should ever forget the fact that we really appreciate the huge amounts of work that they have been doing, the massive commits they have been making, and all of the headaches they have been suffering. These guys deserve our heartfelt thanks for moving ahead and giving the migration the momentum it needs. bob (ishmal)

6 5

Next version(0.47) string freeze
by Lucas Vieites 13 Oct '08

13 Oct '08

Hi, a few days ago someone mentioned how close the string freeze was for the new version (0.47). Is this real? Has a release calendar been set for 0.47? If so, where can I find it? The Roadmap data on the website is generic and has no dates. I'm just being curious and anxious to start translating the new strings in es.po. Thanks in advance. -- Lucas Vieites

6 5

lpe and transforms
by jf barraud 10 Oct '08

10 Oct '08

Hi, Transforms (translate, rotate, etc...) and lpe do not get on well... If you are not familiar to it, consider lpe-bend for instance: Imagine you rotate the input, but not the path parameter (along which the input is bent) the new result is completely different. So transforms need a particular treatment in presence of lpes. Our solution to this problem up to now is to transform the parameters along with the object (or more precisely, to let each lpe decide what todo on transform). This (good!) solution is user friendly, as your lpe parameters nicely move along with your object. However, it implies some limitations (please invalidate if I'm wrong!): I think it prevents from sharing lpes accross different objects, as if one is moved but not the other, which one should be followed by the lpe-parameters? Note that atm, lpe are automatically forked/made unique when you move one object, and I guess that's the reason (?right?). A related (but different) question is about "cloned" path parameters (i.e. references). I might be wrong, but I think path-reference parameters are not transformed atm. (Marginally, one can even think of lpe that depend on the object location, but not relatively to a path or point parameter --- "underlying objects color" for instance?!?--- in which case, transfering the transform to parameters is useless; hmmm! I agree, this is pure abstraction ;-) Although this is not a critical issue ("sharing lpe" jsut does not make sens for a lot of them!!), I think it's a good thing to have, so let's discuss possible strategies! One easy workaround is to add a "lpe-transform" at the end of the lpe-stack whenever the object is transformed (of course, if the last lpe is already a (non shared) transform-lpe, we should just update it instead of adding a new one). This is easy to implement and solves the issue. I think it is a bit cleaner as pes don't have to care about transforms anymore, etc... The (serious) drawback however, common to all solution you can think of, is that if the lpe-parameters do not follow the object anymore, you'll have to look for them all the time and everywhere: if you applied your lpe somewhere, and moved your object a lot, at edition time you'll wonder why the lpe parameter shows up at the other corner of the page, which was the original place, but you completely forgot about. :-( As a conclusion, if we want to keep track of the objects transforms *and* allow lpe to be shared, lpe must be able to strore object specific information at objects level (not in the lpe itself in the defs). Maybe we could add one more attribute to the object, where lpes could register all the data they need (this would be usefull for other purposes anyway). This would make it possible to remember the original position of the object when the lpe was applied: lpe paramters could then be suitably transformed at apply/display/edition time, but stored untransformed. What do you think? jfb.

3 3

Re: [Inkscape-devel] inkscape_version.h is not being updated
by Bob Jamison 09 Oct '08

09 Oct '08

Hi! Thanks for this info. Well, until recently, the SVN revision was not being dynamically fetched at all, so the dependency on inkscape_version.h has remained the same. I have seen this, too, and have added inkscape_version.h to the "touchabout" and "clean" targets. It should have been listed there already, but I guess that since it was never dynamic before, it didn't matter previously. Creating inkscape_version.h -every- time would be overkill and a burden for people wanting to only compile their own files, since that would force aboutbox.cpp to be compiled every time. So... for the typical build/code/build/code cycle, just occasionally do "btool touchabout". "btool clean" will take care of a complete build. -However-, I can see where it might be necessary for <makefile> to make a file every time, regardless if it is up-to-date. So I added an attribute, 'force="true"' to <makefile> to allow this. bob -----Original Message----- >From: Preben Soeberg <prsodk@...400...> >Sent: Oct 9, 2008 1:44 AM >To: inkscape-devel(a)lists.sourceforge.net >Subject: [Inkscape-devel] inkscape_version.h is not being updated > >Hi, > > > >On Windows XP, if inkscape.version.h exists, it is not being updated with >the new revision number, and the old revision number appears in the help >about splash. > >After deleting inkscape_version.h, it is generated with correct revision >number. > >I have seen this behavior since revision 19964. > > > >Preben >

1 0

inkscape_version.h is not being updated
by Preben Soeberg 09 Oct '08

09 Oct '08

Hi, On Windows XP, if inkscape.version.h exists, it is not being updated with the new revision number, and the old revision number appears in the help about splash. After deleting inkscape_version.h, it is generated with correct revision number. I have seen this behavior since revision 19964. Preben

1 0

Re: [Inkscape-devel] Win32 btool problem
by Bob Jamison 08 Oct '08

08 Oct '08

Done. Give it a try, see if it works. Works fine for me on windows and linux. But of course, "works for me" is one of the most hated phrases in CS. :-) bob -----Original Message----- >From: Bob Jamison <rwjj@...127...> >Sent: Oct 7, 2008 1:40 PM >To: J.B.C.Engelen@...1578..., john.cliff@...400..., docsonic@...58..., inkscape-devel(a)lists.sourceforge.net >Subject: Re: [Inkscape-devel] Win32 btool problem > >Hi, all, > >Yes, that is the idea. One thing I need to learn first is the format >of that file. The svn properties are fetched as ${svn.fieldname}, >so I need to know which fields are which. > > >bob > > > >-----Original Message----- >>From: J.B.C.Engelen@...1578... >>Sent: Oct 7, 2008 1:18 PM >>To: john.cliff@...400..., docsonic@...58..., inkscape-devel(a)lists.sourceforge.net >>Subject: Re: [Inkscape-devel] Win32 btool problem >> >>> -----Original Message----- >>> From: john cliff [mailto:john.cliff@...400...] >>> Sent: dinsdag 7 oktober 2008 15:03 >>> To: Docsonic; inkscape-devel >>> Subject: Re: [Inkscape-devel] Win32 btool problem >>> >>> You need to get the command line svn executable. or edit out >>> the bit in build tool that calls it. >>> I think ishmal was going to make it optional... >> >>Even beter: ishmal was thinking about not using the svn executable, but >>the .svn/entries file. That would make it universal. >> >>:) >> Johan >> >>------------------------------------------------------------------------- >>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(a)lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > >------------------------------------------------------------------------- >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(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 1

Text to Path conversion limitation
by Aurélio A. Heckert 07 Oct '08

07 Oct '08

Hi, Is normal to me convert works on PDF and some times i need to make changes on the text, because i need to convert the text in path, and the text has some color or opacity variations. I'm trying to generate a lot of PDF automatically, with automatically generated SVG. That is cool! But i lost some information. Please, see my explanation in the bug report: https://bugs.launchpad.net/inkscape/+bug/279897 This image show what we lost in a Text to Path conversion: http://launchpadlibrarian.net/18305828/text2path.png I compile the Inkscape every week. I'll be really glad to test this feature if a developer like the idea. Thanks! Aurium -- Aurélio A. Heckert http://colivre.coop.br/Aurium GNU/Linux User #312507 http://counter.li.org - - - - - - - - - - - - - - - - - - - - - - - - - Ilustração Vetorial Livre: http://InkscapeBrasil.org Coop. de Tecnologias Livres: http://Colivre.coop.br - - - - - - - - - - - - - - - - - - - - - - - - - "Eu temo pela minha espécie quando penso que Deus é justo." Thomas Jefferson Antes de imprimir esta mensagem reflita sobre a sua responsabilidade com a preservação do Meio Ambiente.

1 0

r19979 - crash on open of SVG
by Michael Park 07 Oct '08

07 Oct '08

Hi there, I've been doing a more er less daily build of inkscape, and the last few days have been crashing when I try to open an existing SVG file (through the file open dialog). The last stable working version for me was r19967 (Fedora 9 x86_64, KDE4.1.1, using 'updates-testing' repo). Here's the output I get at the console: ------- ** ERROR:(display/nr-filter-units.cpp:44):void NR::FilterUnits::set_resolution(double, double): assertion failed: (x_res > 0) Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it. ------- And I hope I did this right, here's the gdb backtrace I got when following the instructions from http://www.inkscape.org/report_bugs.php?lang=en ------- (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 0x0000000000784944 in NR::FilterUnits::set_resolution () #5 0x000000000077036c in NR::Filter::render () #6 0x000000000074670b in nr_arena_item_invoke_render () #7 0x00000000007481ad in nr_arena_group_render () #8 0x000000000074663d in nr_arena_item_invoke_render () #9 0x00000000007481ad in nr_arena_group_render () #10 0x000000000074663d in nr_arena_item_invoke_render () #11 0x00000000007481ad in nr_arena_group_render () #12 0x000000000074663d in nr_arena_item_invoke_render () #13 0x00000000007481ad in nr_arena_group_render () #14 0x000000000074663d in nr_arena_item_invoke_render () #15 0x00000000007481ad in nr_arena_group_render () #16 0x000000000074663d in nr_arena_item_invoke_render () #17 0x0000000000751ddb in sp_canvas_arena_render () #18 0x000000000076b095 in sp_canvas_group_render () #19 0x000000000076b095 in sp_canvas_group_render () #20 0x000000000076d6b1 in sp_canvas_paint_rect_internal () #21 0x000000000076d8f6 in sp_canvas_paint_rect () #22 0x000000000076dd69 in do_update () #23 0x000000000076ddf2 in idle_handler () #24 0x00000031a523742b in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #25 0x00000031a523ac0d in ?? () from /lib64/libglib-2.0.so.0 #26 0x00000031a523b13d in g_main_loop_run () from /lib64/libglib-2.0.so.0 #27 0x00000031a82e7027 in gtk_dialog_run () from /usr/lib64/libgtk-x11-2.0.so.0 #28 0x00000000005e54a4 in Inkscape::UI::Dialog::FileOpenDialogImplGtk::show () #29 0x0000000000453a95 in sp_file_open_dialog () #30 0x0000000000789ccb in sp_action_perform () #31 0x00000031a560b6cd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #32 0x00000031a561f6b1 in ?? () from /lib64/libgobject-2.0.so.0 #33 0x00000031a5620b8c in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #34 0x00000031a56210d3 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #35 0x00000031a826b85b in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #36 0x00000031a826b90c in gtk_action_activate () from /usr/lib64/libgtk-x11-2.0.so.0 #37 0x00000031a560b6cd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #38 0x00000031a561f6b1 in ?? () from /lib64/libgobject-2.0.so.0 #39 0x00000031a5620b8c in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #40 0x00000031a5620f1d in g_signal_emit_by_name () from /lib64/libgobject-2.0.so.0 #41 0x00000031a848e0b2 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #42 0x00000031a560b6cd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #43 0x00000031a561f6b1 in ?? () from /lib64/libgobject-2.0.so.0 #44 0x00000031a5620b8c in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #45 0x00000031a56210d3 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #46 0x00000031a8285e13 in gtk_button_clicked () from /usr/lib64/libgtk-x11-2.0.so.0 #47 0x00000031a828722b in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #48 0x00000031a560b6cd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #49 0x00000031a561efc6 in ?? () from /lib64/libgobject-2.0.so.0 #50 0x00000031a5620b8c in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #51 0x00000031a56210d3 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #52 0x00000031a8285d7c in gtk_button_released () from /usr/lib64/libgtk-x11-2.0.so.0 #53 0x00000031a8286fb2 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #54 0x00000031a8387452 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #55 0x00000031a560b6cd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #56 0x00000031a561f382 in ?? () from /lib64/libgobject-2.0.so.0 #57 0x00000031a5620a0f in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #58 0x00000031a56210d3 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #59 0x00000031a84f48be in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #60 0x00000031a84f4406 in gtk_widget_event () from /usr/lib64/libgtk-x11-2.0.so.0 #61 0x00000031a83859ee in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0 #62 0x00000031a8384625 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0 #63 0x00000031a6e57c29 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #64 0x00000031a523742b in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #65 0x00000031a523ac0d in ?? () from /lib64/libglib-2.0.so.0 #66 0x00000031a523b13d in g_main_loop_run () from /lib64/libglib-2.0.so.0 #67 0x00000031a8383db0 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #68 0x00000000004498b9 in sp_main_gui () #69 0x0000000000449d1d in main () ------- Please let me know if I did the backtrace wrong, I did see some message fly by about missing debuginfo of some packages. Also, I'll see if I can bisect down to which build this behaviour started happening. Thanks. --Mike

2 2