- Inkscape Devel - Inkscape Mailman

Inkscape accepted for GSoC 2008
by Bryce Harrington 17 Mar '08

17 Mar '08

http://code.google.com/soc/2008/ Bryce

2 1

Inkscape 0.47 Development Plans
by Bryce Harrington 17 Mar '08

17 Mar '08

Hi all, With Inkscape 0.46 wrapping up, it's time to look forward to our next release, 0.47, and our plans for its development. When we started Inkscape, we began with a codebase with lots of potential but with some architectural limitations that we've never quite resolved. Inkscape has grown rapidly, especially thanks to Google's Summer of Code program. Unfortunately, while we've gained a lot of new features, it hasn't addressed the underlying issues - and in some cases has exposed new problems. Inkscape's also been extremely successful at gaining a lot of contributors, yet this comes with a price: Stylistic differences, accidental code duplication, unfinished code, obsoleted code, etc. What will the codebase cleanup work entail? The work will range from straightforward "grunt" work like making some simple code changes to all files in the codebase, to meatier work like abstracting widely used code into a more concise and powerful algorithm, to advanced work such as extracting distinct code into independent code packages. To boil this down into five high level objectives: 0. Complete some of the big architectural refactoring efforts 1. Reduce source code line count 2. Break useful code out into stand-alone libraries 3. Increase code stylistic consistency 4. Make the codebase more convenient to code in Now, architectural reworkings can often risk incur massive breakages since fundamental pieces of the code are being changed. In order to minimize this, I'd like to suggest the following principles: * Always keep the tree buildable * Do major refactorings in small steps * Hold code review parties with 2-3 others to brainstorm * Drop copied-in codebases in favor of external dependencies * Make sure every function you touch has some doxygen comments Further, this kind of work can go on indefinitely without a clear stopping point, so I think for this release we should use a schedule with a date-based stopping point. This will help everyone know how they should time their work. Mar 10 Release 0.46. 0.47 Refactoring / Cleanup work begins Apr May Jun Jul 1 Completion of refactoring. Focus on Bug Fixing begins. Open 0.48 development tree early, for GSoC work. Aug Put out 0.47-pre releases. Sep Release 0.47. For reference, here are some key GSoC dates: May 26 GSoC work begins. Jul 14 GSoC midterm. First delivery of GSoC code Aug 18 GSoC work ends. This schedule permits us to focus exclusively on refactoring for several months, with a due date of July 1st to complete it. It uses a very early branch point, where we'll split into a stable branch for doing bug fix and release work, and a development branch for the GSoC students to use and for folks to continue right on with refactoring projects if they wish. Bryce

17 69

Matrix multiplication reversed?
by Jasper van de Gronde 17 Mar '08

17 Mar '08

I am attempting to eliminate some redundant types, at the moment I have just tried eliminating NRPoint and NRMatrix in favour of NR::Point and NR::Matrix (patch available soon, I'm currently double-checking it). While looking at the matrix multiplication as defined in nr-matrix.cpp it looks like the definition is reversed (compared to the usualy mathematical definition). That is: A*B=BA ... The reason I think it is reversed is simply that if C=A*B (with C, A and B NR::Matrix's), then C[0] is the dot product between the first column of A and the first row of B (and similarly for the other elements). Am I missing something or is it indeed reversed? And if it is, is there a reason for this?

3 6

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