- Inkscape Devel - Inkscape Mailman

Getting menu items from class Desktop
by Irfan Hamid 27 Feb '07

27 Feb '07

Hi, Newbie question follows: I'm trying to fix bug #1664790 ("Display mode toggle doesn't update radio button"). Today's the first time I have delved into the Inkscape sources. I've got the hang of how the menu UI portion is generated automatically and how verbs work (more or less). I've also been able to trace my way to the Desktop class's setDisplayModeNormal( ) and setDisplayModeOutline( ) functions which is where I should implement logic to toggle the radio button change for it to happen. Question is, how to get the GTK widget handle for the main menu bar? I couldn't find any helper functions in Desktop nor any in events.cpp TIA, Irfan.

2 1

A Reminder : A Survey on Defect Management Practices in Free/Open Source Software
by Anu Gupta DCSA 27 Feb '07

27 Feb '07

Sir/Madam I seek help from designers, developers, testers,defect fixers,project managers or playing any other key role in Free/Open Source software development or maintenence in carrying out a study to identify practices and problems of defect management in various Free/Open Source Software projects. The insights gained from the study can further help us to extract publicly accessible defect data and determine impact of defect management practices on software quality. Please spend a few minutes of your precious time to fill up the Questionnaire. The most of the questions follow multiple choice formats and are quite easy to answer. To have the Online Questionnaire, please visit: http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey (You can also copy and paste this link into your browser, and hit the 'Return' key.) I hope you will find all the questions interesting and thought-provoking. Your answers will be kept anonymous.The data thus collected will only be used for research purpose.It would be nice if you may further refer this mail to others actively engaged with Free/Open Source Software development. If you have any query or suggestions then feel free to contact. Thank You With regards, Anu Gupta Senior Lecturer Department of Computer Science and Applications, Panjab University, Chandigarh. INDIA In case of any problem in accessing/using the above mentioned link please contact: E-mail: anugupta@...1665... anugupta98@...400...

1 0

Re: [Inkscape-devel] NEW: flood fill
by Joshua Facemyer / Impressus Art 27 Feb '07

27 Feb '07

These work? > - we need a better icon for it - icon artists anyone? > > - we need a matching b/w mouse cursor for the tool

2 5

git on win32
by Aaron Spike 27 Feb '07

27 Feb '07

The recent morbid talk of creating a branch for cairo conversion work makes me think, wouldn't an SCM like git be a huge facilitator for such work? In my mind the one thing that makes branching such a negative is SVN. IMHO SVN is branch possible but not branch friendly. I've only used git for a few small (and mostly linear) projects at work. So I don't have a huge base of knowledge to speak from. I know mental has been doing quite a bit of research into the workflow for using git locally in combination with a central SVN repo. He would be much more capable to comment on its suitability for Inkscape. (Hopefully he will summarize his for the rest of us sometime.) One apparent downer is git's level of support for win32. So I thought I'd take a chance to mention a couple of the options in case anyone wants to check them out. 1) git via cygwin. Two major complaints I've heard are: a) that git is slower on cygwin than it is on native unix. Well, of course it is but rarely do you see a comparison with SVN on windows. I did just recently run across the following quote: "Note: At the time of writing, GIT does not run natively on MSWindows platforms. Several projects are underway to port GIT to Windows but they are not complete yet. It is possible to use git on Win32 via Cygwin, but with slightly worse performance (note: v1.4.5 has several performance enhancements on Cygwin) though even on Cygwin GIT is much faster than CVS or SVN." -- http://docs.moodle.org/en/Tracking_Moodle_CVS_with_git b) installing cygwin is complex. Perhaps we could lessen this perceived complexity for our devs by providing a unified package as we do for libraries. I recall seeing a few packages that distribute portions of cygwin like this. In case anyone wants to try, the most detailed description of running git on cygwin that I have found is at http://git.or.cz/gitwiki/WindowsInstall?action=show . 2) mingw git fork. Apparently there is a usable fork of git built with mingw. Info at http://repo.or.cz/w/git/mingw.git . So maybe win32 won't keep us from git forever. Aaron Spike

3 2

Idea for shape generation and morphing
by Jemima Bond 26 Feb '07

26 Feb '07

Hello. I have an idea for generating and morphing vector shapes using bezier curves and a turtle drawing routines. You can view this as an applet here: http://myweb.tiscali.co.uk/oaktree/jcb/applets/polymorphapplet.html You will have to play around with the various sliders, combo boxes etc to get a feel of how the thing works. Un-check the "Skeleton" and "Control Point" boxes to see the bezier curve only. Just thought I'd throw it into the inkscape pot. Thanks for your time. JB -- ***************************************************************** This email and its attachments are confidential and intended for the exclusive use of the addressee(s). It must not be edited or reposted. This email and its attachments may also be privileged or protected by legal rules. If you have received this email by mistake please let me know by reply immediately and destroy this email and its attachments. You should not disclose, edit, copy or forward any of its contents. *****************************************************************

5 7

Announce: Scribus 1.3.3.8 Release
by Plinnell 26 Feb '07

26 Feb '07

The Scribus Team is pleased to announce the release of Scribus 1.3.3.8 This release is purely a further bug fix release to the recently released 1.3.3.7. This release adds more translation updates, some bugs were found and fixed, many improvements to the SVG importer, Open Document Draw importer and improvements to PDF forms. With 1.3.3.7 we announced the availability of a new OpenSuse rpm download repository for all Suse versions 9.3+, including SLED 10. To download add: http://software.opensuse.org/download/home:/mrdocs/ to your yast/apt/smart source list for the corresponding Suse version. We have now added Fedora 5/6 rpms as well. We hope have this for Mandriva in the next release. Downloads: Source and some rpms: http://sourceforge.net/project/showfiles.php?group_id=125235 Upstream Debian/Ubuntu repo: http://debian.scribus.net Ubuntu users are advised to see: http://wiki.scribus.net/index.php/Getting_Scribus_on_Ubuntu/Kubuntu_up_and_… Fedora 5/6 RPMS: http://software.opensuse.org/download/home:/mrdocs/Fedora_Extras_6/repodata/ http://software.opensuse.org/download/home:/mrdocs/Fedora_Extras_5/repodata/ MacOSX: http://aqua.acribus.net The Scribus Team would also like to thank - Anduin.net/Øverby Consulting and Cardia AS for their continued hosting of all of the Scribus websites. The Scribus Team would also like to thank the many end users, translators, testers and contributors who helped us with this release. About Scribus Scribus is a cross-platform open source page layout application with a focus on high quality commercial grade PDF and postscript export. Originally developed on Linux, Scribus now runs natively on MacOSX, OS/2, many forms of Unix and Windows 2000/XP. Underneath the modern and user friendly interface, Scribus supports professional publishing features, such as CMYK color, spot colors, separations, ICC color management and versatile PDF creation. Scribus was the first page layout application on the planet to directly support PDF/X-3 output, a rigorous ISO standard. Scribus did so by almost a year. The Scribus Team is made up of a diverse group of developers with significant experience in pre-press and newspaper publishing. Commercial support for Scribus is available for companies and institutions for implementation, training and migration.

1 0

Two different Inkscape SVN freezes
by Joshua A. Andler 26 Feb '07

26 Feb '07

Ok, there are two recent freezes that I've witnessed (one pointed out by Johan). Both occur with current SVN. First, I've got a file (our icons) that with a particular object selected, if you switch tools inkscape freezes up. I will file a bug report and attach file shortly so others can check it out. Johan's is also easy to reproduce. Run Inkscape in GDB on win32 (both of us tested on XP specifically) and select a file from the "open recent" list. It doesn't freeze outside of gdb and doesn't freeze in gdb on linux. So it seems a little strange. Anyone have any thoughts? (other than filing both bugs formally) -Josh

1 0

NEW: smoother panning and scrolling
by bulia byak 26 Feb '07

26 Feb '07

Several improvements make canvas panning and scrolling smoother and more interactive in complex slow-rendering documents: * When panning by the middle mouse button, Inkscape no longer attempts to redraw the canvas while your mouse button is pressed. Any redrawing only happens after you release the mouse. As a result, the newly revealed parts of the canvas are somewhat more "dirty" but the panning is smoother than before, with few if any "hiccups". * Previously, if you start panning with middle button while Inkscape is still redrawing screen in a complex drawing, panning sometimes completely failed or moved canvas just a little step. Now it is guaranteed to pan the canvas all the way from mouse-press point to mouse-release point in any case, even if sometimes it fails to show the intermediate positions. * When pressing and holding Ctrl+arrows to scroll canvas, Inkscape normally accelerates scrolling so that each next scrolling step is bigger than the previous. Previously, in complex drawings this acceleration sometimes got interrupted, which made scrolling annoyingly bumpy and slow. Now this is fixed so that scrolling is smoothly accelerated even in a slow-rendering document. * The default starting speed and acceleration of Ctrl+arrows scrolling are slightly increased. (They are both settable in Preferences.) -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 2

Fwd: [cairo] Re: NEW: cairo rendering in outline mode
by bulia byak 25 Feb '07

25 Feb '07

Here's a message from a cairo developer - not sure if it reached our list, so I'm forwarding it. It confirms that my initial description was indeed incorrect: Inkscape uses fixed order, while Cairo's order depends on platform. Sorry for the confusion (though it amounts to the same thing from compatibility viewpoint). ---------- Forwarded message ---------- From: Jeff Muizelaar <jeff@...1669...> Date: Feb 25, 2007 5:15 PM Subject: Re: [cairo] Re: [Inkscape-devel] NEW: cairo rendering in outline mode To: bulia byak <buliabyak@...400...> Cc: jiho <jo.irisson@...400...>, cairo@...278..., inkscape List Devel <inkscape-devel(a)lists.sourceforge.net> On Sun, Feb 25, 2007 at 11:10:16AM -0500, bulia byak wrote: > Last night, with the help of Carl Worth, the issue of cairo/inkscape > not working on mac was more or less clarified. Here's how I understand > it. > > When drawing into a memory buffer, cairo uses a fixed byte order of > the R, G, B, A bytes regardless of the platform. This is incorrect. Cairo's byte order depends on the platform. See, for example, pixman/src/fbpict.c:fbOver(): static CARD32 fbOver (CARD32 x, CARD32 y) { CARD16 a = ~x >> 24; CARD16 t; CARD32 m,n,o,p; m = FbOverU(x,y,0,a,t); n = FbOverU(x,y,8,a,t); o = FbOverU(x,y,16,a,t); p = FbOverU(x,y,24,a,t); return m|n|o|p; } As is shown, the alpha component is always in the most significant byte. So byte 0 on big endian and byte 3 on little endian. However, Inkscape's code assumes a fixed byte order (see below). i.e R is byte 0, G is byte 1 etc. void nr_R8G8B8A8_N_EMPTY_A8_RGBA32 (unsigned char *px, int w, int h, int rs, const unsigned char *mpx, int mrs, unsigned long rgba) { unsigned int r, g, b, a; unsigned int x, y; r = NR_RGBA32_R (rgba); g = NR_RGBA32_G (rgba); b = NR_RGBA32_B (rgba); a = NR_RGBA32_A (rgba); for (y = h; y > 0; y--) { if (a == 0) { memset(px, 0, w*4); } else { unsigned char *d = px; const unsigned char *m = mpx; for (x = w; x > 0; x--) { d[0] = r; d[1] = g; d[2] = b; d[3] = NR_PREMUL_111 (m[0], a); d += 4; m += 1; } } px += rs; mpx += mrs; } } > > Inkscape and GDK (which is used by Inkscape for drawing to screen), > however, both use system-dependent byte order, i.e. the order of R, G, > B, A is determined by the hardware and is different on PC and Mac > platforms. > > And it so happens that the fixed order of cairo coincides with the > hardware order on PC but not on Mac. Hence, painting by cairo directly > into Inkscape/GDK buffers worked on PC but on Mac, all colors are > wrong and (in case of outline) black color gets zero opacity, i.e. > becomes invisible. > > Essentially, this means that Inkscape and cairo are not compatible as > is, and that a gradual switching of parts of our display engine to > cairo is not possible. (Unless we ditch Macs, of course.) > > Even if we switch our screen output from using GDK to cairo (which is > relatively easy), this won't help - it will just break rendering on > PCs too. Inkscape has a lot (and I do mean A LOT) of code that assumes > system-dependent byte order. Composers, decomposers, premultipliers, > unpremultipliers, blitters and blotters of all sizes and colors > permeate the codebase. Most of them come all the way from Sodipodi. Fortunately, cairo has a lot of equivalent code that matches cairo's byte order. It also looks like alot of inkscape's compositing code, like cairo's, isn't particularily fast either. > > Now, of course, it's possible to create "adapters" for cairo bits. > That is, every time we use cairo, instead of drawing directly into > Inkscape buffer, we can draw into a temporary buffer instead, > rearrange the bytes in that buffer, and then compose that into the > main buffer. But that is certain to more than negate the feeble speed > gains we're seeing from cairo's image backend rendering. > > Or, we can attempt a much more drastic rearchitecturing, by changing > our functions so they pass around cairo contexts instead of Inkscape > buffers. With this approach, byte reordering will be needed less > frequently, and eventually eliminated completely. But this is not only > much more work, it will also mean a lot more bugs and regressions and > quite some time before Inkscape is usable again. > > So, it looks like due to this stupid byte-order issue, cairo for us is > practically an all-or-nothing proposition - and much more hassle than > I expected. I'm not saying it's impossible but it is quite a major > project that cannot be done gradually. > > Unless, of course, cairo gets so in love with Inkscape as to provide > us with a new image surface with system-dependent byte order... This is painful as well. All of cairo's software compositing routines use the cairo byte order, and likewise X assumes this byte order as well. -Jeff -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 1

Fwd: [cairo] Re: NEW: cairo rendering in outline mode
by jiho 25 Feb '07

25 Feb '07

Forward of a message by Jeff Muizelaar who is probably someone at Cairo and could not post this to the list because he is not subscribed. Begin forwarded message: > From: Jeff Muizelaar <jeff@...1669...> > Date: 2007 February 25 22:15:09 CEST > To: bulia byak <buliabyak@...400...> > Cc: jiho <jo.irisson@...400...>, cairo@...278..., inkscape > List Devel <inkscape-devel(a)lists.sourceforge.net> > Subject: Re: [cairo] Re: [Inkscape-devel] NEW: cairo rendering in > outline mode > > On Sun, Feb 25, 2007 at 11:10:16AM -0500, bulia byak wrote: >> Last night, with the help of Carl Worth, the issue of cairo/inkscape >> not working on mac was more or less clarified. Here's how I >> understand >> it. >> >> When drawing into a memory buffer, cairo uses a fixed byte order of >> the R, G, B, A bytes regardless of the platform. > > This is incorrect. Cairo's byte order depends on the platform. See, > for > example, pixman/src/fbpict.c:fbOver(): > > static CARD32 > fbOver (CARD32 x, CARD32 y) > { > CARD16 a = ~x >> 24; > CARD16 t; > CARD32 m,n,o,p; > > m = FbOverU(x,y,0,a,t); > n = FbOverU(x,y,8,a,t); > o = FbOverU(x,y,16,a,t); > p = FbOverU(x,y,24,a,t); > return m|n|o|p; > } > > As is shown, the alpha component is always in the most significant > byte. So > byte 0 on big endian and byte 3 on little endian. > > However, Inkscape's code assumes a fixed byte order (see below). > i.e R is byte > 0, G is byte 1 etc. > > void > nr_R8G8B8A8_N_EMPTY_A8_RGBA32 (unsigned char *px, int w, int h, int > rs, const unsigned char *mpx, int mrs, unsigned long rgba) > { > unsigned int r, g, b, a; > unsigned int x, y; > > r = NR_RGBA32_R (rgba); > g = NR_RGBA32_G (rgba); > b = NR_RGBA32_B (rgba); > a = NR_RGBA32_A (rgba); > > for (y = h; y > 0; y--) { > if (a == 0) { > memset(px, 0, w*4); > } else { > unsigned char *d = px; > const unsigned char *m = mpx; > for (x = w; x > 0; x--) { > d[0] = r; > d[1] = g; > d[2] = b; > d[3] = NR_PREMUL_111 (m[0], a); > d += 4; > m += 1; > } > } > px += rs; > mpx += mrs; > } > } > >> >> Inkscape and GDK (which is used by Inkscape for drawing to screen), >> however, both use system-dependent byte order, i.e. the order of >> R, G, >> B, A is determined by the hardware and is different on PC and Mac >> platforms. >> >> And it so happens that the fixed order of cairo coincides with the >> hardware order on PC but not on Mac. Hence, painting by cairo >> directly >> into Inkscape/GDK buffers worked on PC but on Mac, all colors are >> wrong and (in case of outline) black color gets zero opacity, i.e. >> becomes invisible. >> >> Essentially, this means that Inkscape and cairo are not compatible as >> is, and that a gradual switching of parts of our display engine to >> cairo is not possible. (Unless we ditch Macs, of course.) >> >> Even if we switch our screen output from using GDK to cairo (which is >> relatively easy), this won't help - it will just break rendering on >> PCs too. Inkscape has a lot (and I do mean A LOT) of code that >> assumes >> system-dependent byte order. Composers, decomposers, premultipliers, >> unpremultipliers, blitters and blotters of all sizes and colors >> permeate the codebase. Most of them come all the way from Sodipodi. > > Fortunately, cairo has a lot of equivalent code that matches > cairo's byte > order. It also looks like alot of inkscape's compositing code, like > cairo's, > isn't particularily fast either. > >> >> Now, of course, it's possible to create "adapters" for cairo bits. >> That is, every time we use cairo, instead of drawing directly into >> Inkscape buffer, we can draw into a temporary buffer instead, >> rearrange the bytes in that buffer, and then compose that into the >> main buffer. But that is certain to more than negate the feeble speed >> gains we're seeing from cairo's image backend rendering. >> >> Or, we can attempt a much more drastic rearchitecturing, by changing >> our functions so they pass around cairo contexts instead of Inkscape >> buffers. With this approach, byte reordering will be needed less >> frequently, and eventually eliminated completely. But this is not >> only >> much more work, it will also mean a lot more bugs and regressions and >> quite some time before Inkscape is usable again. >> >> So, it looks like due to this stupid byte-order issue, cairo for >> us is >> practically an all-or-nothing proposition - and much more hassle than >> I expected. I'm not saying it's impossible but it is quite a major >> project that cannot be done gradually. >> >> Unless, of course, cairo gets so in love with Inkscape as to provide >> us with a new image surface with system-dependent byte order... > > This is painful as well. All of cairo's software compositing > routines use the > cairo byte order, and likewise X assumes this byte order as well. JiHO --- http://jo.irisson.free.fr/

1 0