- Inkscape Devel - Inkscape Mailman

Inkscape Status May 15, 2004
by Bryce Harrington 17 May '04

17 May '04

Project Status Saturday, May 15, 2004< Much development has been under way over the past month. Markers have been fully implemented and can be applied to start, end, and mid nodes of lines; there's still a bit of work left to iron out little gliches, but the feature is fully usable at this point. A number of bugs related to localization, file saving/loading, markers, and more have been fixed; 21 bugs have been closed in the past 2 weeks. A number of new preferences have been added, including a wide range of paper sizes. It'll be great to get all these new capabilities out to users but the focus we determined for this next release is switching of the underlying font renderer from libnrtype to Pango. Mental has recently initiated work on this with the conversion of libnrtype to a C++ style of interface. Hopefully enough of us can contribute spare cycles into this effort that it can be completed quickly. Once that architectural conversion is complete we can turn attention to finalizing the 0.39 release. Aside from code development, work is being done to assist in promotion of the tool. Artemio has contributed screenshots of a couple of his websites to provide an <a href="/screenshots/examples/">example</a> of how Inkscape is being used for real work. We need additional examples of other types of usage, such as making icons, logos, posters, vectoralization of raster images, and etc. LWN has recently published a review of various Open Source diagramming tools, including a brief mention of Inkscape. Bryce is working to get an article about Inkscape published. Inkscape is being presented at events such as the "FLOSS In Design" seminar in Rotterdam. Statistics Nov 15 Jan 15 Mar 15 Apr 15 May 15 ========== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 1928 * 1164 1028 (68.5%) (86.1%) * (91.7%) (92.7%) Max Week's Rank on SourceForge: 62 321 90 31 36 (99.6%) (97.5%) * (99.8%) (99.8%) Total SF Page Views * 126,500 * 330,000 475,000 Total SF Downloads * 5,735 * 17,250 27,400 Total Freshmeat URL Hits 746 2,958 4,670 6,000 7,500 Total Freshmeat Subscriptions 16 33 50 70 74 Lines of Code in src/: 115,901 166,914 177,286 183,694 189,116 Code lines 133,150 138,457 143,662 147,471 Comment line 12,468 15,584 16,041 16,757 Blank 21,929 24,061 24,931 25,886 Lines of Docs in doc/: 1,135 3,000 4,434 4,540 4,544 Lines of content in website: 1,173 2,885 5,087 5,414 6,008 Size of the Inkscape wiki: 3,700 11,284 14,840 15,461 18,638 Minutes since last ChangeLog mod: 360 6 0 11 1 Bugs open/total: 9/15 74/160 43/244 47/322 57/365 Features open/total: 18/18 104/120 151/184 173/213 183/238 Patches open/total: 1/ 6 4/32 6/ 45 5/ 72 4/ 83 CVS Commits (as per inkscape-cvs): 481 * 3070 3710 3391 Inkscape-devel membership: 49 64 75 77 78 Inkscape-announce membership: 9 22 35 41 43 Inkscape-user membership: 71 * - Statistics unavailable

1 0

windows builds (src/libnrtype/nr-type-w32.*)
by MenTaLguY 17 May '04

17 May '04

I've been poking at the Win32 bits of libnrtype today; hopefully the build is no longer broken, but could someone on Win32 please verify? -mental

1 0

pangoification
by MenTaLguY 16 May '04

16 May '04

Just a quick note that I've started further C++ifying libnrtype; it's about time we got this pango ball rolling. -mental

4 3

Re: [Inkscape-devel] pangoification
by bulia byak 16 May '04

16 May '04

>On another note, BULIA, do you have any great thoughts about icons for >the new CLONE commands? Yes, JON, I do have great thoughts about those and many other icons :) but this will need to wait until closer to the release. For now I only cleaned up the Fill & Stroke icons a bit. _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: [Inkscape-devel] Inkscape review
by bulia byak 16 May '04

16 May '04

>Okay, cool. I'll start implementing a whole series of item-only verbs. As I said, don't make item-oriented variants for _all_ commands, but only for those that make little or no sense for a selection of multiple objects of different types. >I, too, think it should item-oriented. This may complicate the usage of >verbs. Perhaps I will invent a "right-clicked" item in SPDesktop or >SPView, similar to the "selection" stuff. That way once the verb gets >called, it'll know what to take action on. Is there a better way to >handle this? I think the verbs should just take an optional SPItem* attribute, which if set will make them act on that item. That item is easy to figure out by sp_item_at_point, which depending on an argument returns an item with or without going into groups. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN Premium http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

Re: [Inkscape-devel] Inkscape review
by bulia byak 15 May '04

15 May '04

>Is there a simple command that will tell me what "sort" of object the >mouse is on? No signle command, but there are macros SP_IS_RECTANGLE, SP_IS_USE, SP_IS_PATH and so on. >- what "mode" the mouse is in (selector, rectangle, text, etc) I think there's a function for that in tools-switch.cpp >- what object is under the mouse. (and notice "multiple selections") The number of selected items is easy to get from SPSelection. >Is there an enum of object types anywhere? At least the sense of object >vs stroke? What do you mean by "object vs stroke"? Maybe a shape (rect, star, etc) vs. arbitrary path? >Also, should the menu be long or deep? Use your judgement. The menu cannot be too short, Inkscape is a complex program. I think using submenus is OK - after all, this is what people have always done in Sodipodi, and some of them even like it, who'd-a-thought... >For example, if multiple items >are selected, the set of boolean operations should be included, but that >would make the top-level menu very long. A different way would be to >make a separate "boolean" submenu... thoughts? Yes, booleans in a submenu sounds good to me. But again, I never use that menu, so cannot really judge its usability. _________________________________________________________________ STOP MORE SPAM with the MSN Premium and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

Re: [Inkscape-devel] Inkscape review
by bulia byak 15 May '04

15 May '04

One more idea: for item-oriented commands, it would be nice if the command name reflected the type of the object, e.g. "Select Rect", "Select Rect in Group" etc. _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: [Inkscape-devel] Inkscape review
by bulia byak 15 May '04

15 May '04

>Basically, the question is: should the right-click context menu be >selection-oriented or item-oriented? Currently it is item-oriented, >where the rest of the application is selection-oriented. Now that I think of it, item-oriented menu makes a lot of sense. It's a way to do something to one object only, without changing the selection. For example, it would be useful to have commands like: - Select/Deselect: Object (would work the same as shift-click, command name depends on whether the clicked object is selected or not) - Select/Deselect: Object in Group (same as shift-ctrl-click) - Object: Properties (applied to clicked object regardless of selection) - Object in Group: Properties - The most useful commands specific to the object type, such as Object to Path for non-paths, Stroke to Path for objects with visible stroke, Not Rounded for rects, Make Whole for ellipses (if applicable), Unlink/Select Original for clones, etc. Also: Remove Stroke, Remove Fill (useful but not yet implemented as a separate command) etc. However selection-oriented commands also need to be present, but in a section of their own after a separator. These may include relevant dialog openers: Text and Font if only text object(s) selected, Fill&Stroke for everything except clones, etc. These need to be selection-oriented because the corresponding dialogs are selection-oriented. When more than one object selected, this section would also contain group/ungroup, booleans, combine/break apart. Commands that may be applicable to both separate objects and selection (such as Copy) should also be here and work on selection, otherwise it may become confusing. As for Undo/Redo, I don't think these are appropriate for the context menu at all. Any commands that are not directly applicable to an object or selection should be removed from the context menu. So, overall, lots of useful logic may be implemented in this menu, so that opening it will at once give you lots of useful information on what's under mouse and what's selected, even if you do not call any of its commands. Most of this logic is already implemented around the codebase, you just need to gather it all in one place. _________________________________________________________________ MSN Premium includes powerful parental controls and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

Re: [Inkscape-devel] Inkscape review
by bulia byak 15 May '04

15 May '04

>Oh, right. :P I've changed the text slightly to make it clearer for >me: > >Open a new window with the same document view > ^^^^ I don't like this change. "Same document view" to me sounds like the new view will be in sync with the old one, e.g. zoom in when I zoom in the other window, etc. _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

Re: [Inkscape-devel] Inkscape review
by bulia byak 15 May '04

15 May '04

>When I was doing icon/verb work, I had suggested "Duplicate Window", >which to me says I'm going to get another window, and it's going to be >the same as what I have right now. However, this may not indicate to >other people that it will contain a independently-controlled view of the >same data. (Although I think "Duplicate Window" is more informative >than "New Window" or "New View", it is probably still incomplete.) I cannot think up a way in which a new window would not be an "independently-controlled view of the same data", so I think "Duplicate Window" is perfectly adequate. >Perhaps "Duplicate View Window"? Or "Duplicate Window View"? Ew :) >(Can't we >have menu-based tool tips?) We do. Watch your statusbar as you walk through the menu. _________________________________________________________________ STOP MORE SPAM with the MSN Premium and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1