- Inkscape Devel - Inkscape Mailman

IO extensions should accept Writers
by Krzysztof Kosiński 17 Mar '08

17 Mar '08

Hello I strongly believe Inkscape input and output extensions should accept Writers, not URIs. Currently much of Gnome-VFS boilerplate is duplicated between the extensions. If we used Writers instead of URIs: 1. The GnomeVFS code would be contained to a particular OutputStream, and could be easily replaced with GVFS once it's around. 2. Adding KIO support would be easy, just create a new OutputStream and use it. There could be a function that automatically creates the best OutputStream for a given platform. 3. Memory output ability - this is what I need for the clipboard work. 4. Windows-specific filename hacking could be contained to a particular OutputStream. Regards, Krzysztof (Chris) Kosiński -- View this message in context: http://www.nabble.com/IO-extensions-should-accept-Writers-tp16046549p160465… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 1

Re: [Inkscape-devel] DVCS again
by jiho 17 Mar '08

17 Mar '08

On 2008-March-14 , at 17:45 , Joel Holdsworth wrote: > I'm still a little uncertain about this. Git seems increasingly > popular, > and very powerful, it just doesn't seem very obvious to use for new > users. SVN is great at the moment, because there's a great GUI client > for windows (TortoiseSVN), and quite a good one for linux (RapidSVN). > Having easy source control clients seems like an easy way to get > people > involved. So I'm wondering: are there any good GUI clients for git, > mercurial or bazaar? you can see the previous message on forked thread about that ("DVCS again"). TortoiseHG and TortoiseBZR exists, TortoiseGIT does not. I don't know the status of the first two compared to TortoiseSVN. On linux there are apparently many clients for all three systems (from the look on the wiki's of each project) but it is difficult to assess their quality from just screenshots. I have not seen any file browser integration (i.e. tortoiseSVN like) for linux, which unfortunately would probably be the most useful thing to have (I read some stuff about nautilus plugins but never saw anything actually working). For OS X there's shell integration and a bunch of clients for SVN, not much for the rest. But most of them are not good enough to avoid the command line altogether, so I personally don't even use one. There is however integration with a nice text editor (textmate) for svn, git, and mercurial. nothing I can see for bazaar. I'm not sure how critical having a good GUI is to get new developers. To compile Inkscape you eventually have to go to the command line and type stuff so... I agree however that TortoiseSVN probably makes the life of existing windows developers easier. So has anyone tested TortoiseHG/BZR ? JiHO --- http://jo.irisson.free.fr/

3 2

Re: [Inkscape-devel] DVCS Again: end-of-line conversion
by jiho 17 Mar '08

17 Mar '08

On 2008-March-15 , at 08:09 , Peter Moulder wrote: > On Sat, Mar 15, 2008 at 12:21:47AM +0100, jiho wrote: >> I'm not sure there's really a need to continue counting points right >> now. It seems bazaar is the clear winner. > > I've been composing the below before the above was posted. > > Looking at > http://en.wikipedia.org/wiki/Comparison_of_revision_control_software, > there is one startling difference among git,hg,bzr: it is stated that > bzr cannot do end-of-line conversions, i.e. cannot adapt the end > of line characters for text files such that they match the end of line > style for the operating system under which it is used. > (Status: http://bazaar-vcs.org/LineEndings) > > I wonder how much of an issue this is; could it actually be fatal for > what is otherwise a very promising alternative? Let's look at how we > would address this issue if we were to choose bzr. OK, let's start counting again then. I removed mercurial since no one really stepped up to give advice on it. Right now it seems that both solution have different flaws. However git ones seems to be just a matter of changing habits (e.g. rely more on the command line, learn a few new commands), while on the other hand bazzar would be more enjoyable to use but has some more "deep" flaws (e.g. line endings and slowness). -- GIT ---------------------------- + faster: . local commits: <1s vs 4s . push a new branch: instantaneous vs 35 min + ability to follow chunk of codes around, without relying on file names. Probably useful from a refactoring point of view + probably the fastest growing user base => many tools + TextMate bundle - git is designed with the Linux kernel's hierarchical workflow in mind (few 'push'ers to the central repos), so may require alteration in how Inkscape's workflow works (any dev can commit) - we would need to set up and administer this ourselves - revisions are indicated with SHA's rather than numbers - commands dissimilar to what we're used to with svn (e.g., no 'git update') - have to git add all modified files before committing them (or resort to a non specific commit -a) - no decent GUI (for windows?) -- BZR ---------------------------- + already integrated in launchpad http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.… . Associating branches to bugs . Associating branches to blueprints . Changes state of bugs in LP when committing in Bazaar . Web interface for creating branches quickly and easily + supports renames (could be considered a - by git users) + supports bundling changesets + tortoiseBZR + Fewer commands - makes it easier to learn + Supports multiple workflows, including what we use for Inkscape (See http://bazaar-vcs.org/Workflows) + Easy administration. Mostly done through Launchpad, plus Bzr folks are available to help. - no support for line-endings conversion/convention enforcing (but such systems may create the risk of wrongly recognizing binary files) JiHO --- http://jo.irisson.free.fr/

4 4

DVCS (Bazaar clone performance / eol conversions)
by Bryce Harrington 17 Mar '08

17 Mar '08

I asked the bzr developers for feedback on the two issues raised regarding bzr; response is below. Bryce ----- Forwarded message from Martin Pool <mbp@...1798...> ----- Date: Mon, 17 Mar 2008 10:52:07 +1100 From: Martin Pool <mbp@...1798...> To: Bryce Harrington <bryce@...1798...> Cc: Ian Clatworthy <ian.clatworthy@...1211...>, warthogs@...1799..., Canonical Bazaar <bazaar-canonical@...1799...> Subject: Re: Interest in and usage of Bazaar by open source projects On 17/03/2008, Bryce Harrington <bryce@...1798...> wrote: > Hi Ian, > > As I suspected, the topic of changing to a DVCS came up [1] almost as > soon our 0.46 release was finished. This sparked off a lengthy > discussion and comparisons between bzr and git, yet we've still not > reached a firm consensus. > > In general, people are open to bzr due to the ease of use and launchpad > integration benefits, but there were two technical issues that cause > concern. First, we were seeing significant differences in clone times > [2] between git and bzr for our repo. Second, there is concern about > treatment of end-of-line conversion between *nix and dos[3]. I was > hoping you could provide some insight or more authoratative word on it > than we have currently. > > Bryce > > [1]: http://www.nabble.com/Inkscape-0.47-Development-Plans-to16044924.html > [2]: http://www.nabble.com/forum/ViewPost.jtp?post=16064712&framed=y > [3]: http://www.nabble.com/forum/ViewPost.jtp?post=16065313&framed=y Thanks Bryce, The times reported there can be greatly reduced by a few things: * create a shared repository using bzr init-repo, and put all your branch directories under that; then local branching is just a matter of building a new working tree * similarly for pushing to your own server * make sure you're using the packs repository format (which is the default since 1.0) Pushing new branches to Launchpad is currently quite slow, because there is no shared storage between different branches of the same project. For medium-large projects, I can't currently generally recommend hosted branches. What I would suggest is pushing to your own server, then registering the branch to be mirrored to Launchpad. Making hosted branches much faster, through sharing storage between them, is (imo) _the_ major goal for lpcode2.0. Implementation for it is well underway but not live yet. Also, eols are improved by the checkeol plugin, and I think there will be better builtin support soon. I haven't read the whole large thread but please point out important bits. -- Martin ----- End forwarded message -----

1 0

Fit Text
by Edward Flick 16 Mar '08

16 Mar '08

Hello, I'm looking to add (or looking for) a feature which shrinks text to fit inside of a text box (per line preferably or per box). I couldn't find a part of the SVG spec which covers this. Could an addition be made inside of the Inkscape namespace for an attribute that would fit on a <text> or <tspan> element (which applies the same font size to the whole block in which it was declared to fit the widest line, IOW if it is applied to <text> block the whole block would get that new font size or when applied to <tspan> it would be a line by line fit) which would be specified something along the lines of: fitText = none | increaseTextSize | decreaseTextSize What do you guys think? Edward Flick

2 3

New extended input devices dialog
by Jon A. Cruz 15 Mar '08

15 Mar '08

I've got the work-in-progress of the new input devices dialog in, but disabled. If anyone wants to give it a try, verbs.cpp needs USE_NEW_INPUT_DEVICES defined to switch it on. The main thing it will allow is that the test area should show device button and mouse events from devices, and should list all that are configured. Some feedback on what goes on there could be handy.

3 5

Inkscape 0.46 in Ubuntu Hardy
by Bryce Harrington 15 Mar '08

15 Mar '08

Inkscape 0.46 was accepted into Ubuntu Hardy today, just meeting the Beta Freeze deadline. (Anyone know if we made it in Fedora?) Bryce

6 10

Examples with Inkscape: Designs for animation project
by Bernardo González Reinfeld 14 Mar '08

14 Mar '08

Hello, First than all, THANKS! Inkscape is great and we love what you do! We talk about Inkscape with colleagues and partners, and We try to help you spreading the voice. Also we teached (short courses) how to use Inkscape, in our local Fine Arts Faculty (La Laguna University). We're a small studio from Spain that work with open source tools and we like show you what we're doing right now. http://www.cejasbravas.com All the images that you can see in our site was created with Inkscape (we added this point in our FAQ). And also all the scenes of our pilot (CB is a project for a tv series -2D animation- for childs. We're trying to find funds to produce it) has been draw it with your software. (We have a St Patrick's day banner right now :)). You can add our images to your site, if you like show it like examples. Just add a link to our site and write us to see what images you choose... if you do :) We like show that open source tools can be used in studios without problem. And our Creative Director love it! Well, that's all. We add our sites to gallery's wiki. And again, THANKS. We hope that you like what we do. Cheers PS: Please, this isn't spam. We just like show you examples and applications of Inkscape in real world. -- *Bernardo G. Reinfeld* General Manager * http://www.organicadtm.com * Tel. (+ 34) 922 152 660 * Mobile (+ 34) 637 160 308 * Fax (+ 34) 922 299 479 Calle Bethencourt Alfonso, nº 2, Edf. Trianon, piso 5, centro 38001. Santa Cruz de Tenerife. Canary Islands. Spain En cumplimiento con la Ley de Servicios de la Sociedad de la Información y de Comercio Electrónico (LSSI-CE) aprobada por el parlamento español y de la vigente Ley Orgánica 15 13/12/1999 de Protección de Datos española, le comunicamos que su dirección de correo figura en este momento suscrita a nuestro mailing, formando parte de un fichero automatizado de datos. Si no quiere recibir mas información responda a este correo indicando en el asunto "DAR DE BAJA".

1 0

Renaming SPObjects proposal
by unknown＠example.com 14 Mar '08

14 Mar '08

Hello all, In spirit of codebase cleanup, I'd like to propose a simple renaming idea, to make things more clear to the developer (to me, at least :) I think, apart from C++-ifying, it would be a lot clearer when the SPObjects are renamed to either "SPObject" (the same :P) or "SVGObject". An example: SPPath represents <svg:path> in the SVG. When <svg:path> is added to SVG, Inkscape immediately generates an SPPath for it. I therefore propose to rename it to something that reflects this aspect of SPPath: that it is directly linked to something in SVG. SPDesktop for example is *not*. SPDesktop => SPDesktop, stays the same SPPath => SVGPath, meaning it represents some element in the SVG. SPShape => SVGShape (since all its derivates are SVG elements) SP_IS_PATH => IS_SVG_PATH (I never understood why it isn't named IS_SP_PATH) SPNamedview => SVGNamedview ? Now this one is a troublemaker. Because it is linked to <sodipodi:namedview> in the XML. I still think we should rename it with SVG up front, because it is linked to something in the SVG, does not matter what its name in XML is. Please, if this above all is non-sense, slanted or incorrect in any way, let me know! I do not know what to do with the filename. I propose to keep them sp-path and such, to avoid losing SVN history, which is absolutely unacceptable to me. (I don't know how to rename files in SVN, is that possible?) Note that we actually already have a file called svg-path... If no (negative) comments have reached me, I'd like to start this in a week or two. I really think it clears up things. It is sort of a first step into grouping things. Thanks, Johan

6 8

NEW: smaller SVG files
by bulia byak 14 Mar '08

14 Mar '08

As a file size optimization, Inkscape does not write into SVG some of the stroke properties if the object has stroke:none and some of the fill properties when it has fill:none. The only situation where this might affect you is if you remove stroke from an object and then turn it back on - the object will get the default stroke instead of the same as it had before. Also, in manually-edited SVG where a parent group has no stroke but sets some stroke properties to be inherited by its descendants, you will need to set stroke property to other than none on the group, and suppress inheritance with stroke:none on those children that don't need it. Specifically, if stroke:none, the following properties do not get written to SVG: stroke-width stroke-linecap stroke-linejoin stroke-miterlimit stroke-opacity stroke-dasharray stroke-dashoffset Note that this does not include marker properties, which means you can still have markers on a path without visible stroke. If fill:none, the following properties do not get written to SVG: fill-opacity fill-rule -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0