- Inkscape Devel - Inkscape Mailman

Extension system
by Krzysztof Kosiński 15 Jan '09

15 Jan '09

Migrating to GIO for file handling means modifying the extension system rather extensively, so I think it might be worth refactoring it as well, keeping compatibility with existing extensions. Currently there is a class for every type of extension, but they don't define much - everything of substance is handled by the "implementation" class which contains methods for everything. A subclass of it is mandatory for every extension. I understand the reason for this was to support XSLT and script extensions transparently, but I don't think this is the proper way to do it. Since each extension only provides one function (either an effect, or an input filter, etc. but not more than one of those types at a time) the proper inheritance would be e.g.: Extension -> Output -> XsltOutput Extension -> Effect -> ScriptEffect Extension -> Input -> SvgzInput If there are common methods among XSLT or scripted extensions, those could be put in a separate class from which all other extensions implemented in this way derive (multiple inheritance). This wouldn't preclude putting more than one function/effect in the .inx file, since more than one object could be created for a given .inx file by the manager. There should also be a proper manager object, instead of some things being done via Extension::DB (which BTW is not a singleton but a statically constructed object) and some via global functions. GIO would be used in input and output extensions - parameters to save() and load() would be GInputStreams or GOutputStreams instead of filenames. This way extensions could save to memory and to remote locations without any special handling in the extensions themselves. Do you have any other ideas for improvements or changes? Regards, Krzysztof Kosiński -- View this message in context: http://www.nabble.com/Extension-system-tp21448270p21448270.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 4

spiro mode in freehand tool
by Thomas Holder 14 Jan '09

14 Jan '09

Hi, spiro mode in freehand pen tool does not make sense. I'd suggest to remove the button. Even for bezier tool the spiro mode is not that useful, as you don't see the spiro while drawing (which would be nice indeed). But since you still draw beziers and spiro just gets applied _after_ path finishing, you could likewise apply it via the path effects dialog. Thomas

4 4

CMYK Proposal
by Felipe Sanches 14 Jan '09

14 Jan '09

* I think that we should remove the CMS tab from fill&stroke dialog. Color profiles should be selected globaly for the whole document. * Then, I think that we should display the palletes and the color pickers with colors transformed by the currently selected profile. Comments, please. Juca

2 1

Re: [Inkscape-devel] Tango Icon Theme - Renewed - ALL ICONS MADE (I hope!)
by Guillermo Espertino 14 Jan '09

14 Jan '09

JonCruz wrote: > This does seem to match the behavior of one bug I'm working through. And after that is it finally possible that the Tango set will be the default icon set? The new Tango set needs a couple of minor bug fixes, but it looks pretty finished to me. I'm already using it, and I'd love to have it as default for 0.47 These icons look very professional and polished. The current set is ok, but it really doesn't honor the quality of Inkscape as the awesome program it is. I think a lot of people overlooks Inkscape because its look. Besides, the default icon sets in Scribus and Gimp are already Tango, so unifying them would be a nice step towards the idea of a truly free-software design workflow. Kudos to Jesusda and the Michael Grosberg for the excellent work in this theme. Gez

2 1

Tango Icon Theme - Renewed
by jEsuSdA 8) 14 Jan '09

14 Jan '09

Hello! I'm working hard to complete and bug-free the tango icon theme for Inkscape. Some bugs are solved, new icons are added and some old icons are retouched. Now I'm working to finish it, but some bugs are depending to the way the icons are show on toolbars and may be solved. ;) Please, report me the bugs and ideas you have to this work. Thanks! ;) INKSCAPE TANGO ICON THEME: http://jesusda.com/files/inkscape-tango-theme/ Salu2 de jEsuSdA 8)

10 22

Disable the snapping toolbar
by Krzysztof Kosiński 14 Jan '09

14 Jan '09

I never use snapping, and this toolbar takes up lots of space (which I have in very short supply on a 1024x768 display)! Please add a way to turn it off ASAP. I haven't noticed any in the preferences. It would be best if right-clicking it brought up an option to disable the toolbar. Regards, Krzysztof Kosiński. -- View this message in context: http://www.nabble.com/Disable-the-snapping-toolbar-tp21446041p21446041.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 2

Inkscape dll imports
by Jasper van de Gronde 13 Jan '09

13 Jan '09

I've had a quick look at Inkscape's dll imports using dependency viewer, and it looks like it imports libpoppler3 about a dozen times or so... Any idea why it behaves like this? It might not directly give problems, but it seems a bit odd nonetheless.

2 1

New Mac Build(s)
by step21 13 Jan '09

13 Jan '09

Hey, I offered to do some mac builds on a more or less regular basis. I got native to build (but could build x11 too), and now I'm in the process of packaging it (there are still some issues with the app bundle script) I hope to resolve these tomorrow, or maybe write my own, simple script if that doesn't work. So anyway on irc verbalshadow just told me to say hi to the list and that eventual problems / upload possibilities would/could be handled here better. I'll continue with the packaging tomorrow cause it's going to be 5 am soonish, but currently I have the following issues if anyone has a quick thought on one of those. I was under the impression I could use osx-app.sh for native packaging too, but so far: (note: in the paths below /opt/local/ is the macports install path passed to "osx-app.sh" with --libraries) /opt/local/etc/pango/pangox.aliases is not in my macports install (which it tries to copy) so is this a file specific to x11 pango (pango was installed with macports using +no_x11 ofc) Also the script is looking for: /opt/local/lib/libgtk-x11-2.0.0.dylib /opt/local/lib/libgdk-x11-2.0.0.dylib Only in a native version those would have to be: /opt/local/lib/libgtk-quartz-2.0.0.dylib /opt/local/lib/libgdk-quartz-2.0.0.dylib And so far I'm not quite sure how it gets the impression that it needs the x11 version, at first I thought it was hardcoded in the script, but it's not. Best regards ...

7 18

Version reporting improvement
by Krzysztof Kosiński 13 Jan '09

13 Jan '09

The CMake build system doesn't seem to be functional (link failure), so in the meantime I have an improvement to the Automake one. I added a micro-library libinkversion.a that contains only the version string. It is built from a single source file which is generated based on configure.ac $(VERSION) and SVN information (if present), and is only replaced if it changes. This way the About box always has the SVN revision, with only a relink necessary (it would have been necessary anyway in most cases). The version string looks like: 0.46+devel r20503 custom The first part is the version from configure.ac; The second is the SVN revision; the third part "custom" is only present if there are any files modified in the src/ directory with respect to the SVN repository (checked with svn status -q). Because of the way "svn info" works, the version will be wrong if you compile after commiting all changes (it won't have "custom" added even though it should). Currently I don't know how to handle this, but this shouldn't be a problem as this feature is mainly intended for users and testers. If anyone wants to fix this case, the code is in src/Makefile_insert Regards, Krzysztof Kosiński -- View this message in context: http://www.nabble.com/Version-reporting-improvement-tp21428431p21428431.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

3 4

Fwd: [Openicc] [Printing-japan] My Color Management Patch for poppler has been accepted
by Alexandre Prokoudine 13 Jan '09

13 Jan '09

FYI ---------- Forwarded message ---------- From: Till Kamppeter <till.kamppeter [at] gmail.com> Date: 2009/1/13 Subject: Re: [Openicc] [Printing-japan] My Color Management Patch for poppler has been accepted To: Koji Otani <sho [at] bbr.jp> $B','`'a'Z'q(B: "printing-architecture@...2115..." <printing-architecture@...2115...>, printing-japan@...2115..., OpenICC Liste <openicc@...626...> Does it mean that Poppler will have full Color Management support in its next release? Can you compare with Ghostscript 8.64? Which renderer will be better in color management then? Till Koji Otani wrote: > My color management patch has been accepted by poppler. > Now poppler can draw ICCBased color correctly. > It uses liblcms (little color management system library) and can > handle ICC Version 4 profiles. > > --------------------- > $BBgC+$G$9!#(B > > $B%+%i!<%^%M!<%8%a%s%H!&%Q%C%A$,(Bpoppler$B$N%j%]%8%H%j$K<h$jF~$l$i$l$^$7$?!#(B > ICC Based Color$BEy$r@...1333...$7$/I=<($G$-$k$h$&$K$J$j$^$7$?!#(B > > little color management system$B$r;HMQ$7$F$$$F!"(BICC Version 4$B$K$bBP1~$7(B > $B$F$$$^$9!#(B > _______________________________________________ > Printing-japan mailing list > Printing-japan@...2115... > https://lists.linux-foundation.org/mailman/listinfo/printing-japan

1 0