- Inkscape Devel - Inkscape Mailman

dividing the inch
by Aaron Spike 31 Dec '04

31 Dec '04

It is customary to divide inches in halves, fourths, eighths and sixteenths, right? In Inkscape dark grid lines (love that feature by the way) and ruler marks appear in halves, fifths and tenths. sp_ruler_metrics in sp-metrics.h has it all right. But sp_ruler_set_metric is only called in desktop.cpp and SP_PT is hardcoded as the metric. To make the divisions follow the document preferences the call to sp_ruler_set_metric would probably have to be moved farther down the line into sp_desktop_widget_update_rulers and some math would need to be changed. I don't know if Inkscape would want to do this. A really feature bloated app might even let you work in your prefered unit and configure you own arbitrary divisions. Then I could divide inches in thirds. I tried hacking out a change for this a while back and started to get the idea that messing with units probably wasn't appropriate for a newbie with now knowledge of C++. It seems messing with units actually means messing with the fundamental assumptions on how Inkscape should deal with units. So I don't have a question, as such, I would just like to see what others think. Aaron Spike

2 1

CFV: Gtkmm - Develop a Context Menu
by Bryce Harrington 31 Dec '04

31 Dec '04

Okay, last Call for Volunteers today, I promise! This one will be quite tricky and requires good knowledge of C++, Gtkmm, and the Inkscape codebase. The menu needs to be very dynamic and well tied in with Inkscape's internals, so if you don't already know Inkscape code thoroughly, you'll need to be prepared for a lot of digging and learning. Fortunately, you can start simple and build up as you go. :-) 7. Context Menu ================ The current context menu in Inkscape is not very powerful. We can do better. First skim through the tutorial on context menus on the gtkmm.org site: http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/ch10s03.html In the Gtk+ codebase, the context menu is implemented in the function sp_ui_context_menu, in the file interface.cpp. Review that function to see how the context menu works currently. As a general rule, there should be no more than about ten items total on the context menu. The context menu, by definition, should customize the set of items it displays to the user based on what the user has right clicked on. It should tie in with the Actions system, and should display appropriate menu items for the selected context. The context menu must check the context item against the current selection. The context item is the thing directly under the mouse cursor when the right-click action occurs. The current selection is the item or items selected by the left-click menu. Note that it's definitely possible for these to be different - the user may left click to select a circle, then right click over a rectangle to change its properties. It is also possible to have no selection, or to select multiple items. Each of these implies a different type of context, and would be handled differently. If the context item is completely different from the selection, then display only actions which don't require the object to be selected. For instance, do not display the 'Delete' action, since that will cause the _selected_ item to be deleted rather than the context item. Same thing for cut, copy, etc. Note that context commands should *not* change the selection to get around this. If the context item is the same as the selected item, then detailed operations should be shown for that item, including actions that can be performed on selections. In this case, you'd display Delete, Cut, Paste, etc. If multiple items are selected, and the context item is one of the items in the selection, then present actions that can be performed on multiple selected items. Delete, cut, copy, duplicate should act on all selected items, for instance, and commands for group, Text-on-path, booleans (Union, Difference, etc.) should be presented. If the context item is part of the chrome (i.e., a toolbar button, the status bar, etc.) then display a context menu appropriate to that item, plus some commands specific to the inkscape application itself. For instance, it should allow all of the actions available through doubleclick, shift-click, alt-click, etc. with the button, and inkscape preferences, view/hide the chrome item, etc. Think about the context menu in three sections. The top third and bottom third should have the most commonly expected commands, and the middle should have the less common commands. The top (and sometimes the bottom) will be the closest to the mouse cursor when popped up so it will be most convenient for common actions to be located there. The middle is less accessible so rarer functions should be placed there. Strive to always place the same command in the same location in the context menu. The top portion of the menu should have actions which are common, frequently used commands needed for any shape or context. The bottom portion should consist of the commands that are common for the specific shape or context selected. The middle portion should consist of commands specific to the shape or context, but less commonly used. Any action available in the context menu should also be available through other means, but you can include actions that otherwise require several clicks. For instance, in the context of a font item, you could include actions for changing the font size; this is normally available only by first opening the text and font dialog, then selecting the font size from the font size widget. To get the Gtkmm codebase: $ cvs -d:pserver:anonymous@...54...:/cvsroot/inkscape login (hit enter for password) $ cvs -z3 -d:pserver:anonymous@...54...:/cvsroot/inkscape co experimental/bryce/inkscape_gtkmm $ cd experimental/bryce/inkscape_gtkmm $ make $ ./inkscape Bryce

1 0

CFV: VDX and PDF extensions
by Bryce Harrington 31 Dec '04

31 Dec '04

For those interested in learning more about extensions, here are two that might be worth incorporating: http://vdxtosvg.sourceforge.net/ http://www.solidcode.net/pdf2svg/ Try them out - do they actually look useful and compatible with Inkscape? If so, add them to our extensions. You'll need to create a .inx file (see /usr/share/inkscape/extensions/ for examples), and test it out on a variety of files to make sure it's not too buggy. Then post a patch to the patch tracker (or report back if it looks like a no-go). Also, if you can find any other xxx2svg filter programs out there, go ahead and test out adding them too. Good places to look include svg.org and Freshmeat.net. You can also create your own filters pretty easily using packages such as perl's SVG.pm. I had good luck at hooking together SVG.pm and Perl's POD converter to create a pod2svg filter. ;-) Bryce

1 0

grid (and ruler) units
by Aaron Spike 31 Dec '04

31 Dec '04

I've seen it in my web logs a few times now. People are searching google to find out how to change the ruler units in Inkscape. I'm not surprised because that was one of my first questions. I ended up finding the answer in the release notes. If the "Document Preferences" dialog said "Grid and Ruler units" instead of just "Ruler units" the answer would be more apparent. If that isn't acceptable it could go in a FAQ. Aaron Spike

2 1

CFV: Performance measuring/testing
by Bryce Harrington 31 Dec '04

31 Dec '04

Here's a much more techie task we need done. Over the past several releases there's been some observations of slowness in the Inkscape renderer. We'd all like Inkscape to be nice and snappy, even for huge documents. However, we've not really had good, standardish ways of measuring performance. A good way of measuring it would be helpful in several ways: It'd help developers quickly see if a change improves or degrades performance; it'd enable us to track performance from release to release; and, it'd be a tool we could add new performance "Problem Cases" to as we go. The task is to create a collection of scripts that one can run on a copy of inkscape, that exercise it in some different ways and records the speed it did each thing. Right now, you can do some testing by just running Inkscape in cmdline mode on a large .svg file, and time how long it takes for Inkscape to startup, create the .png, and exit. (Later, maybe we can add some testing triggers inside the code so we can better measure performance of particular pieces (like just the startup time, just the gui init, etc.) Also, later hopefully we'll have some internal scripting or Atk support to allow further automated testing of the app. But static runs should be enough to give us some good info to start with.) It would be interesting to run this performance suite against older versions of the software, and measure how performance has changed over time. It'd be especially cool if this could produce an SVG graph. :-) Bryce

1 0

CFV: Update Roadmap
by Bryce Harrington 31 Dec '04

31 Dec '04

Here's another task... This one needs to be done fairly soon; I'm hoping to get to it later this weekend if nobody else can. We've decided to have an accelerated 0.41 release in mid to late January. This means that we need to shuffle the roadmap. Wiki skills are needed. Some knowledge of Inkscape's development activities would be helpful, but if you're good at asking questions you won't need much depth. http://inkscape.org/cgi-bin/wiki.pl?Roadmap * Tasks related to gtkmm need to be moved from Milestone 7 (0.41) to milestone 8 (0.42). * Most development tasks for 0.41 will also need to be bumped forward to 0.42 (speak with bulia, mental, etc. if you have questions - or ask them to update their tasks directly) * Most or all tasks listed for Milestone 8 (0.42) need to be bumped up one number, to Milestone 9 (0.43). Also bump all the subsequent tasks up one release number, too. * Also update the website copy of the roadmap: http://inkscape.org/roadmap.php Thanks, Bryce

1 0

Re: [Inkscape-user] proposed change to icons
by Ben Crowell 31 Dec '04

31 Dec '04

After posting on inkscape-user and increasing the sample size, it seems to me that there is a clear consensus in favor of the new style. Bulia wrote: >There's no need to argue. Ben, you can continue working on the new >icon set, and when you are ready we will ship your icons.svg alongside >the old one, so people can choose whichever they like. Trent, the same >for you: you are welcome to develop a set of icons that work best for >your black background, and we'll ship them also. When there's at least >one complete set besides the old one, we can make a preference with a >UI to choose one of them on load. The real issue is whose icons will be the defaults. Since most people seem to like mine better than yours, I think mine should be the defaults. I would like to request a clear decision on this from the core developers before I invest a lot more time on the icons.

3 3

about inkscape in FreeBSD
by Albert 31 Dec '04

31 Dec '04

Dear developers, I have found that surprigsingly the new ports tree for FreeBSD 5.3 can only install and run inkscape 0.38 The mantainer claimed that there are several memory leaks issues because of the usage of boehm-gc, as explained here : http://lists.freebsd.org/pipermail/freebsd-gnome/2004-December/ 009256.html Are the developers aware of this issue? Is there any hope to have a FreeBSD running 0.40 version any time soon? Thank you. Albert

3 2

proposed change to icons
by Ben Crowell 31 Dec '04

31 Dec '04

I've made some changes to the icons in the copy of Inkscape I have running on my own machine. If other people agree that this is an improvement, I'll do some more work in the same style. Here is a screenshot: http://www.lightandmatter.com/proposal.png The rotation and flip tools are my new versions, and next to them you can see the lower and raise icons in the original style, with the greenish-yellow color. My idea here was to tone down the colors a little, and also use transparency to create more of a visual impression of the object rotating. It's meant to look like the new Gimp 2.0 icons, which IMO are very professional looking.

7 9

Help needed with UI work in Gtkmm codebase
by Bryce Harrington 30 Dec '04

30 Dec '04

If anyone's interested in contributing some time to the new Inkscape UI work, we can use some help with setting up the menus. It's extremely straightforward work, there's just a lot of it to do. Basically, for each menu item we need to write code to establish things like handlers, signals, descriptions, etc. I've coded up a examples for several menu items, so you'd just copy and extend that for all of the menu items. If you're interested in working on this drop me a line and I'll fill you in. The task writeup is in the PLAN document in the 'experimental' module in CVS, under bryce/inkscape_gtkmm/. Bryce

1 1