April 2015 - Inkscape Devel - Inkscape Mailman

Beer search
by Jabier Arraiza 29 Apr '15

29 Apr '15

Hi any one could give me the direction of LGM fest for tonight?

2 1

decript(HF)
by Jabier Arraiza 29 Apr '15

29 Apr '15

To thouse dont have a glass ball to decript, the new branches are amelia and insaner.com

1 0

NIGHT 3
by Jabier Arraiza 29 Apr '15

29 Apr '15

Shhhhhhhhhhhh!!!

1 0

DAY 3
by Jabier Arraiza 29 Apr '15

29 Apr '15

Dedicated to Jenkins. A good day also. Our live is incremented by almost 100 years because new health to our group. Also a day to say goodbay, hope a see you later. Hackfest put a dot and continue. Thanks to all people who made this posibol, i think we have 73 points more in inkscape now. Bye

1 0

Improve docs for new devs
by Maren Hachmann 28 Apr '15

28 Apr '15

Hi devs, to make entering the project easy for new developers, we have a whole section of the website dedicated to development topics [1] We're looking for suggestions what to add / how to improve that section, especially the "Getting started" part [2]. It would be especially valuable if someone of the more recent new developers could make suggestions, as they've only just gone through the process themselves. I've added a link to the Doxygen pages, but there's probably more which could be useful to guide our future devs Any ideas are welcome! Regards, Maren [1] https://inkscape.org/en/develop/ [2] https://inkscape.org/en/develop/getting-started

1 0

[RFC] Plan for 0.92
by Bryce Harrington 28 Apr '15

28 Apr '15

Hi all, Last release we discussed switching to a more rapid release cycle starting with 0.92. So here's a proposal for a plan to do this. Even though it's been a short time since our last release, already we've accumulated a number of features, thanks in large part to Jabier's many LPE's: http://wiki.inkscape.org/wiki/index.php/Release_notes/0.92 Please make sure any other added features are included in the release notes soon. I'd like to propose the following release plan, which is based on the 0.91 plan, but simplified and with more focus on changes to packaging, no bug hunt, and no experimental branch. We simplify to a single Freeze phase. We cut a pre0 release before starting the build system hacking, so testers will have something to test. We move the about screen contest up so it can get done sooner, and so that we can string freeze earlier to give translators time. This should drop a number of the more time consuming bits yet keep the important steps in the checklist. Please let me know what you think, and esp. if you see some areas that need tweaking. Bryce # Period Tasks -------------------------- 1. Open development. Post inkscape-0.92-pre0.tar.gz (w/ old build sys) Start an About Screen contest Decide new unit testing system Decide new build system Implement new build system Integrate new swatch dialog Begin switching packaging to use new build system Begin tracking % translated Migrate mailing lists off sourceforge (Other bits off roadmap...) 2. Chill. Development focuses on wrapping up Disable features that aren't finished Identify 'make distcheck' issues Identify remaining writing needed for Release Notes. Identify any release blocker bugs Recruit Release Wardens for Hard Freeze 3. Frost. Only production-ready code committed to Mainline Finalize any major changes to platform packaging Inkscape must pass 'make distcheck' Ensure packaging for all platforms installs Ensure packaging for all platforms uninstalls Finalize tutorials to be shipped with release Finalize other docs included in the release Finalize about screen Finalize Release Notes except Known Issues Post additional inkscape-0.92-pre*.tar.gz releases Packagers test creating pkgs of the -pre* releases Post % translated per language for each release 4. Freeze. Stable Branch is forked from Mainline Regular development resumes on Mainline. Only Release Wardens can commit to Stable Branch Cherrypick bug fixes from Mainline to Stable Complete any late work under advisement of Wardens Focus on release-critical bug fixing. String Freeze No further string changes allowed on Stable Branch. Translators work on translations. Finalize all extensions Finalize codebase translations Finalize Known Issues section of Release Notes Finalize packaging scripts Post additional inkscape-0.92-pre*.tar.gz releases Post % translated per language for each release 5. Release. Post inkscape-0.92.tar.gz Post packages Post official announcements Plan 0.92.1+ release(s), if needed 6. Open development. As far as timing goes, I'm thinking we give a few weeks to open development (step 1), and then a week each for all the subsequent steps. This would see 0.92 released in a June/July timeframe.

3 2

Does swapping R and B bytes in colors ring any bells?
by mathog 28 Apr '15

28 Apr '15

Do any of you recall having seen code in Inkscape which swaps the bytes for colors R and B, but leaves the bytes for G and A alone? In emf-print.cpp there has long been a section with this code (sorry about the wrap): (void) RGBA_to_DIB(&px, &cbPx, &ct, &numCt, rgba_px, width, height, width * 4, colortype, 0, 1); // Not sure why the next swap is needed because the preceding does it, and the code is identical // to that in stretchdibits_set, which does not need this. swapRBinRGBA(px, width * height); A bug has turned up https://bugs.launchpad.net/inkscape/+bug/1447850 where the swap is needed for interactive work, but NOT needed for cli work. As the note indicates, I never knew why those two bytes were reversed, they should not have been, it was always a workaround for unexplained behavior. Now it seems that these bytes are not always swapped. Here is what happens: (bytes are swapped in output routine: Y/N) image fillimage gui Y Y cli Y N Fillimage refers to an image used in a fill operation, image is just the usual sort of image in the SVG drawing. The EMF input/output has no idea what mode it is operating in. The pixel array rgba_px comes from this line in emf-print.cpp: rgba_px = (char *) pixbuf->pixels(); // Do NOT free this!!! and the contents of rgba_px are not the same for the fillimage test case in gui and cli modes. pixbuf comes via a call from metafile-print.cpp: *epixbuf = ((SPImage *)parent)->pixbuf; So, as far as I can tell the R<->B swapping has occurred elsewhere in Inkscape, long before it hits the EMF output code. Any suggestions where that might be? Or why that might be? Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

3 3

better bucket tool design proposal & measurement ruler
by Jelle Mulder 27 Apr '15

27 Apr '15

Hi Todor and all, On the fill tool Being a heavy user of the current fill tool, which for creating a quick mask/clip area around bitmaps is a godsend I concur with most of the issues of the bucket tool. Nodes are placed at curious spots and spikey hair is not well addressed to say the least. What I do like about the current tool is that it is fast. So what I would propose is instead of replacing the current tool, adding a more elaborate one to the list. If possible with a method to grow and or shrink the offset much like a gradient taken from the centerpoint of the fill. I made a simple example of how I envision this to look. It would have to calculate the intersections and then take that as the vector for the amount of grow or shrink. By setting some control nodes on would be able to make the outline shrink more to the inside or grow a bit more if required and fiddle around with it. Maybe you could even give it several vectors and use a displacement map based on calculated mesh warp. I'm not sure how feasible this would be, but it sure would be cool and could lead to a whole set of tools that apply some kind of displacement map to a vector and spit out a vectorised displaced image. Thinking of text on a round surface (ball, cup, etc) or wavy flags. Ripple effects would become easy to create. You can just apply a feDisplacement in the file, but that takes quite some computation on the client side you may want to prevent. On the measurement ruler Why not make it an option to create an object with that? It is a useful tool, but would be more useful if you could create an object with the measurement results and the shapes as a permanent object. It would be even more useful if you could copy and adjust this object and get new measurements from it. Or how about a tool that lets you create an object with certain measurements, say a 20 mm line in a 32% angle and a line vertical or horizontal to that edging the bounding box with the correct measurement. Pretty sure an architect or cutter would greatly enjoy that. Sawing machines could probably use that too. Sorry for the inconvenience, Cheers, Jelle

2 1

First day!
by Jabier Arraiza 27 Apr '15

27 Apr '15

First day at HackFest. A god day. Thanks to all for his patience with my english, specialy to Krzysztof who take me away from the incomprehension. Good night to all!

1 0

Access to the wiki to add a better bucket tool design proposal
by Todor Imreorov 26 Apr '15

26 Apr '15

Hello everyone! There was a google+ discussion where I expressed thought on a better bucket tool implementation and discussed issues with the current one. https://plus.google.com/u/0/+inkscape/posts/4ZGgz6XKmGo As a result +Martin Owens <https://plus.google.com/102241005050666075649> and +Tavmjong Bah <https://plus.google.com/111969650498055377139> invited me to this mailing list to get involved in the effort to improve the bucket tool in inkscape. I need to write a proper design proposal at inkscape's wiki. In it I plan to outline the workflow issues and include examples of better bucket fill implementations from other open source software and public algorithms / research papers . How do I go about getting write access to the wiki page and where do I exactly file my proposal? Thank you in advance for the time. Best regards, Todor

6 6