October 2008 - Inkscape Devel

Direct Mailing Extension - A end-use file generator
by Aurélio A. Heckert 23 Oct '08

23 Oct '08

Hi all, I made this extension: http://www.colivre.coop.br/Aurium/InkscapeDirectMailing I don't think "Direct Mailing" is a good name, but is the better that i can think because it do part of this work. This is on it's third version after some usage and a test by the brazilian Inkscape community. For now it's being used by the DebConf organization at Argentina to make the certificates. :-) Até! 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.

4 3

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