- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] plans on 0.49
by gespertino＠...400... 18 Mar '11

18 Mar '11

> From: Jasper van de Gronde <th.v.d.gronde@...528...> > Subject: Re: [Inkscape-devel] plans on 0.49 > > I do have a few questions though. I love the idea to bring developers > together, as I think this could indeed help increase and maintain > motivation, as well as providing a moment to simply "get things done". > However, what kind of numbers and funding are we talking about? If we > want to meet physically the costs could be quite high. (And if we don't > meet physically, then what is the funding for?) That's where linux vendors come in. It's unlikely to fund a sprint with individual donations, but if we can get companies like Google, Canonical, Novell, Red Hat, etc. to get involved, things seem more feasible. Of course we have to do it first, but I'm sure that we have interesting things to offer to those companies: better, more integrated software for something as important as design is undoubtedly something their platforms (and their business) could benefit of. Another option is to organize regional sprints. For instance, it's considerably cheaper (for the physical meeting) if the participants are all europeans, or all north-americans, etc. Of course people from other regions could follow the sprint and collaborate on-line. One sprint could be europe-based, the next in north-america, and so on. I guess that doing it this way costs would be reduced considerably, and people from other areas would still be able to join to the event on-line. I can't talk about numbers because I don't know them. Probably LGM organization could give us some estimations about how much is involved so we can do some calculations and see what's possible and what not. > Also, what you describe still requires quite a bit of organization, how > would you propose to deal with that? (Are you proposing to head up > the operation?) Not being a programmer and living in south america (where a pretty small amount of developers are) makes me a bad candidate for that, I guess. I commit myself to help in whatever is needed to materialize this project, but I'm sure there is a lot of people better prepared for the task than me. I think we should all discuss the organization details. I know it's not something easy to co-ordinate and I didn't think about all the details, but I'm sure that we as community can manage to make it work. > And how do we deal with disgruntled donors? > If we define groups of features/fixes as targets, that's cool for helping > focus donations and such, but afterward I am sure that some things > won't have been addressed and people won't like that if they donated > because of that specific item. > This is of course not "fair", in the sense that we would be (and should > be) clear about how this process works, but human psychology is hardly > ever fair. Well, first we have to define achievable goals. Being too ambitious and making a very interesting list of goals would of course get more funding but it would also increase the chance of disgruntled donors at the end. If the goals of the sprint are manageable and the resources and time are planned correctly, the outcome should be enough to make donors happy. Of course, s**t happens. Things can turn more difficult than expected and some goals could end up unfinished. I guess that commitment from the coders to give those unfinished goals exclusive priority for the next days/weeks after the event should be enough to make donors know that their money wasn't given in vain. I mean, if coders say "I commit myself to make my best to finish these tasks in the defined timeframe or, if it's not possible, in the following weeks" no donors should feel deceived if things don't turn out as expected after the sprint. I think it's just matter of good communication. First of all we should avoid the wrong conception that donors are paying for X feature. Donors would be contributing to make a sprint with specific goals happen and developers involved should commit to complete those goals. Sounds fair enough. :-) Thanks for your comments, Jasper.

2 1

SVG Compositing Specification
by Tavmjong Bah 17 Mar '11

17 Mar '11

Hi, The SVG Compositing Specification has been published: http://www.w3.org/TR/SVGCompositing/ This specification adds quite a few new compositing modes. Note, this is not yet an approved standard but is in the process of "last call" which is a period of time interested persons can comment on the specification. Comments can be submitted until April 12th 2011. Tav

4 4

Re: [Inkscape-devel] plans on 0.49
by gespertino＠...400... 17 Mar '11

17 Mar '11

A couple of days ago I mentioned to Prokoudine an idea that probably is worth to discuss. It's a known fact that bounties never worked for Inkscape and GIMP, but that doesn't mean necessarily that money wouldn't help. What is needed is to find a different way to use the money that comes from donations and could come from companies (like linux vendors, for instance). This isn't a new idea. It's just a mix of some ideas that already work (crowd funding, GSoC, hacking sprints, etc). Instead of picking individual feature requests, developers could make a list of targets, following project's roadmap. In that point community (and companies interested) could express their needs and wishes, and project active developers could decide if some of those requests fit with the existing plans. Once a targets lists is created and cleaned up, developers should make an estimation of time and people needed to reach those targets. The idea is to group those targets in small "packs" so it's not too ambitious to expect their completion in a limited period of time. Also in that stage would be good to define if more people than the available is needed, and what upstream projects are connected to the planned goals in order to contact their mantainers and communicate what would be needed and in what timeframe. Once that information is ready and available publicly, then money comes into play. People can start to donate and companies could be contacted to get sponsoring. That money wouldn't be used to pay for features. The idea is to organize a hacking sprint, giving developers a chance to meet and more importantly, companies could lend developers who could benefit from having core and active developers in a common physical space to ask them about project particularities. This would be also a good opportunity to document code and details that could be useful for other developers in the future. I think this could refresh the motivation of existing developers and attract new people, while at the same time it could make companies commit to the development of graphic applications. After all, having quality applications is what free operative systems need to reach more people and be more interesting to users, so this could be a good opportunity for linux vendors. I know this is just an idea and it making it work it won't be as easy as talking, but at least I'm interested to know what developers and the rest of the community thinks about it. Is it possible? Could it work for projects like Inkscape, GIMP or Scribus?

3 3

[Fwd: [Merge] lp:~ado-papas/inkscape/bug_167419 into lp:inkscape]
by ~suv 16 Mar '11

16 Mar '11

Anyone willing to help with testing/reviewing? IMHO this would fix an annoying issue with linked offsets. It would be great to have it merged into trunk before another pending merge (gsoc-cairo) possibly requires yet again a rewrite, as well as backporting the fix to the 0.48.x branch for 0.48.2 (if doable). ~suv -------- Original Message -------- Subject: [Merge] lp:~ado-papas/inkscape/bug_167419 into lp:inkscape Date: Thu, 10 Mar 2011 18:26:38 -0000 From: Adonis Papaderos <ado.papas@...1244...> Reply-To: mp+52899@...2499... To: mp+52899@...2499... Adonis Papaderos has proposed merging lp:~ado-papas/inkscape/bug_167419 into lp:inkscape. Requested reviews: Adonis Papaderos (ado-papas) ~suv (suv-lp) Related bugs: Bug #167419 in Inkscape: "square/circle/polygon/spiral and linked offset misbehaviours" https://bugs.launchpad.net/inkscape/+bug/167419 Bug #184341 in Inkscape: "Linked offsets ignore clone movement preferences" https://bugs.launchpad.net/inkscape/+bug/184341 Bug #239430 in Inkscape: "linked offset ungroup issue" https://bugs.launchpad.net/inkscape/+bug/239430 For more details, see: https://code.launchpad.net/~ado-papas/inkscape/bug_167419/+merge/52899 Fix some issues with linked offsets. Changed the rendering of the offset to take into account the transformation of the source object, as is the case with the use element, and copied the move compensation logic from uses to offsets. There is a speed penalty though because of this, since I cannot find a reliable method to predict whether there is a change to the source object data or a transformation applied to it. The second patch removes an optimization I implemented using the transform event, since this event is not emitted on undo and redo actions. -- https://code.launchpad.net/~ado-papas/inkscape/bug_167419/+merge/52899 You are requested to review the proposed merge of lp:~ado-papas/inkscape/bug_167419 into lp:inkscape.

1 0

Extensions - Slider in Int and Float widgets
by Nicolas Dufour 16 Mar '11

16 Mar '11

Hello, Revision 10103 adds horizontal sliders to the Int and Float extension widgets in order to make parameters a bit easier to handle. It perfectly fits large numbers (colors or angles related values) but may be less efficient with small range parameters (as in the SVG calendar extension). Thus I've implemented two modes (mimicking the radiobutton parameter), full (default, with slider) and minimal (no slider) that can be used by adding an appearance="<mode>" attribute to the int or float element in the inx file or internal extension structure. The size of the slider is the same for all widgets, 200px (about the same as the sliders used in Gimp). Please test and comment! Regards, -- Nicolas

3 5

plans on 0.49
by Alexandre Prokoudine 16 Mar '11

16 Mar '11

Hi, Do we have any plans re 0.49 and GSoC? Do we want releasing 0.49 before work on GSoC projects starts (in case we are accepted) which means end of May? If not, do we want releasing once a year which means 0.49 around August? Would it make sense figuring out now where we are currently and what we could for 0.49? Alexandre Prokoudine http://libregraphicsworld.org

8 21

Command line interface on Windows
by Jason La 16 Mar '11

16 Mar '11

Hi Inkscape community, Thanks for the app, it is proving to be very useful. For whatever reason, the .NET framework does not include any kind of SVG handling -- so Inkscape has been endlessly useful. I'm using it for a pretty simple purpose - converting SVG files to PNG or JPEG images. I'm just following the instructions from the FAQ to let the devs of our common usage of the CLI. Thanks again, Jason Jason La Associate Software Developer Tel: 805-898-8508 www.alg.com <http://www.alg.com/> Confidentiality Notice: This e-mail may contain confidential, proprietary information of ALG, A DealerTrack Company. It is intended solely for the named recipient(s) listed above and should be maintained in strictest confidence. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you have received this e-mail in error, please immediately notify the sender and delete this information from your computer and destroy any related paper copies.

1 0

possible save dialog bugs on Windows
by Michael Grosberg 15 Mar '11

15 Mar '11

I'm only seeing it on a single machine at work, but please take the time to see if you can reproduce it. perhaps it's just that one machine. I waited for 48.1 just to be sure it's not already solved but it seems like I still have this problem: When I create a new file and then attempt to save it, I have to explicitly add the "svg" extension. If I don't, the file is saved without an extension. Another issue I see on all both home and office machines: When I do a "Save As...", the save dialog opens with the file name field empty, when in most other applicatios it contains the current file name. Both issues are on Windows, I haven't tested on my Linux partition yet.

3 2

Re: [Inkscape-devel] Merging the Cairo branch
by john cliff 15 Mar '11

15 Mar '11

2011/3/15 Josh Andler <scislac@...400...>: > Hey, > > So, I really think that we should entertain the idea of merging the cairo > branch into trunk. The plan has been for us to not release 0.49 until it is > ready, so the couple outstanding bugs in cairo shouldn't be a huge > deterrent. We could also set up a PPA to produce the trunk builds of cairo & > pixman so that fixed libs are easily installable in the meantime (at least > for people using debian-based systems). I was talking to John Cliff and he > put forth a very good point which is that we really need to get as much > testing as possible on it prior to a release. > > Before it gets asked, yes Jon, color management is broken in it atm. The > likelihood of it getting fixed in a branch as opposed to trunk is next to > non-existent though... > > So, would people be okay with a little breakage of existing functionality to > get more testing of a cairofied Inkscape? bulia, I included you in the to > line here to help gauge the acceptability of this proposal. > > Cheers, > Josh > I think the more we can use this code the better, and having it tucked away in a branch isnt achieving that. Putting it in trunk forces us to fix what we find, and means we dont only start that process once cairo is uptodate enough in the distros. If we're gonna have to wait for the distros to be ready for us, we might as well be good and ready for them. Cheers John (sim)

1 0

Fwd: [Fwd: [Bug 733966] [NEW] Inkscape way to SLOW - Refactor]
by Igor Novikov 15 Mar '11

15 Mar '11

On Tue, Mar 15, 2011 at 11:53 AM, Jasper van de Gronde < th.v.d.gronde@...528...> wrote: > On 2011-03-13 15:52, Vladimir Savic wrote: > > On Sun, 2011-03-13 at 15:37 +0100, the Adib wrote: > >> Is there any plan how we will speed-up performance in future. I mean: > >> - fast (visual) response to the user > >> - fast rendering > >> > >> I know that we have: > >> - tiling the image into pieces to decrease user response time > >> - add OpenMP to filter functions > >> > >> On the roadmap is conversion to cairo. But cairo does not render filters > at all. > >> I read that LLVM could speedup when generating the filter code ..... > > Maybe I misunderstood the concept behind filter rendering, but what > > about joining efforts with GEGL guys and using that library? I guess it > > will develop faster, both big apps that would use it (Inkscape and GIMP) > > will benefit from joined development, bugs will be fixed faster, etc. If > > I understand correctly, GIMP will use GEGL for pixel computations too > > and pass the resoult to cairo for drawing on canvas. > Could we please slow down just a bit. Basically someone has come and > claimed, with some justification, that Inkscape is slow. It is, at least > in some respects (no one files bugs for cases in which Inkscape performs > marvelously). But we are working on performance issues continuously and > I think pretty much any Inkscape developer knows at least a few things > he would like to speed up. > > As for getting some results, apart from some UI issues, which are > important but which are not exactly my specialty, filters are probably > the main cause of perceived slowness. I would like to make a couple of > remarks about that. Inkscape mostly has implementations that are quite > accurate, which often results in slightly worse performance than you > might otherwise see. > May be Inkscape has accurate implementation but Inkscape document model is highly non effective. There is a simple comparing test. Just create 1000 rectangles, convert they into paths and measure memory usage in Inkscape, CorelDRAW and sK1. You will get approximately following numbers: Cold start/With document Inkscape 0.48 62Mb/140Mb CorelDRAW X3 47Mb/63Mb sK1 0.9.1 51Mb/62Mb So for the same drawing applications use: Inkscape 0.48 78Mb CorelDRAW X3 16Mb sK1 0.9.1 11Mb The test file you can fetch here: http://sk1project.org/files/test1000_rects.svg If you multiply objects (10k or more) you will see that Inkscape allocates 0.5Gb and more whereas Corel/sK1 uses less than 100Mb. Actually similar issues are observed in all mature applications because initial architecture was not designed with all the implemented features. Gimp, Scribus, Inkscape and our sK1 already faced with this problem. CorelDRAW has passed this milestone in ver.10 I think you remember that we have presented Cairo-based rendering in sK1 on LGM2007 and since that time we have a lot of experience in this issue (whereas "cairofication" for Inkscape is upcoming feature). Using this experience I would say that "cairofication" doesn't resolve all Inkscape rendering problems because Cairo (at least current stable version) is not fast. Concerning our project we have decided reimplementing sK1 and UniConvertor from scratch because the further development of just stuck in the architectural issues. We hope reporting results in our presentation on LGM2011, so I think we could discussing this in Montreal and it could be really useful for further Inkscape development. -- Regards, Igor Novikov sK1 Project http://sk1project.org

2 3