- Inkscape Devel - Inkscape Mailman

Delay on scripting support
by David Turner 07 Sep '04

07 Sep '04

Unfortunately, I've unexpectedly had to move house, so I haven't been able to get time to adding scripting support. I had hoped to get to it before now, but I haven't. I'm leaving the country in three days for a month, and I won't have access to a compiler. I'll be unsubscribing from this mailing list after I send this message. I hope that when I get back, my life will settle down a little and I'll be able to hack on Inkscape some more. Sorry for dropping the ball here. -- -David "Novalis" Turner Stalk Me: 617 441 0668 <insert dark NIN lyrics here>

1 0

Re: [Inkscape-user] Line reported to be longer than I expected
by bulia byak 07 Sep '04

07 Sep '04

> The line is reported to be 2mm longer than I expected (402mm), even > though it touches the bottom and top of the page perfectly, the page is > reported to be exactly 400mm high. Is this a bug or a feature? It's a bug. Lines' bboxes extend beyond line ends by the line width. This is because the bbox is now calculated simply by adding half the stroke width to all 4 sides of the without-stroke bbox, but in this case (for unclosed horizontal line) it should be added only to the top and bottom. It is a very difficult bug to fix because we currently have no code to reliably determine how far the stroke of a given shape extends, which may be affected not only by stroke width but also by (as in your case) shape orientation and closeness, join and cap types, and miter limit. Anyway, I think we don't yet have this in our bug tracker, so please submit it (with my comments).

1 0

Gtkmmification
by Bryce Harrington 07 Sep '04

07 Sep '04

Hi all, We had identified the primary goal for this next release, 0.40, to be the conversion of Inkscape's user interface from Gtk+ to Gtkmm. To date we've been attacking this both from a bottom-up perspective, by working on converting individual dialogs to Gtkmm, as well as a top-down perspective, by starting from the top level Inkscape::Application object and working down. This latter top-down approach is what I've been working on the past few weeks. Here's a summary of where this work is at. The Inkscape::Application class is the top level manager of the main window. It creates and provides the callbacks for the GUI elements such as menus, toolbars, the main canvas, the statusbar, etc. One day, once this is merged into the main Inkscape codebase, it will also own things like the user preferences and the document model itself. You'll notice that the application.h file is pretty terse. This is because nearly all of the Inkscape::Application internals are hidden in a subclass called Inkscape::ApplicationImplementation. This means that the application.h is kept very lightweight, and other parts of the program can include it without including the whole world (only gtkmm/window.h). Inkscape::Dialog is a new abstract class. This provides a general purpose interface that Inkscape::Application can use for interacting with any of the dialogs. If there are stylistic or behavioral aspects that we want to apply to all dialogs in Inkscape, this is where we would do it. For instance, this class will provide common routines for saving the position and size of dialogs in the user's preferences, as well as the transient behavior. If you recall the trouble we had implementing those in each dialog independently under Gtk+, you can imagine how this will help centralize the behavior to one easily maintained place. Inkscape::DialogManager is another new class. This is basically just a container of all the dialogs in Inkscape, that allows us to construct them lazily - instead of creating them all at program startup, we construct them right before they're first used, then cache the dialog until DialogManager gets destructed. DialogManager also provides a set of signals that can be issued to all Inkscape dialogs, such as to show/hide all dialogs. DialogManager hooks these signals to each dialog as it creates them. One of the nifty things about Gtkmm is that it makes it quite easy to create new widgets, and we're taking advantage of this by creating "compound widgets" for sets of widgets that get reused throughout the application. For instance, most of our dialogs are implemented as Notebooks with pages that contain labeled frames within them and a table within that; the Inkscape::NotebookPage widget provides a convenient way to build a dialog using this scheme. LabelledSpinbutton, created by Carl, provides a combination of a label and a spinbutton entry, which is used repeatedly on the preferences dialog. ScalarWidget provides a widget for entering numbers associated with units, such as appears heavily on the transformation dialog and in general throughout the application. Using these widgets, Carl and I have roughed out much of the transformation and application preferences dialogs (although none of the widgets are hooked to anything internally yet). In general, what we can expect from Gtkmm is a) flexibility, and b) reduced linecount. It uses the exact same widgetset underneath, so by and large Inkscape will *look & feel* the same, and there's no plans to redesign the layout of anything (although we may do some small tweaks where it makes things easier). But this will let us do the same stuff in a fraction of the number of lines of code; this will make it easier to maintain and enhance Inkscape's look and feel in the future. This top-down gtkmm work is available in Inkscape's 'experimental' CVS module, in experimental/bryce/inkscape_gtkmm. A simple makefile is included if you'd like to fire it up and try it. If you're interested in working on something related to this Gtkmm work, you'll find this top-down codebase pretty easy to get up to speed on, since there's only about a dozen files of significance. There are examples of both widgets and dialogs, that you can use as guides in developing your own widgets and dialogs. Inkscape::Application has many of the stubs in place for adding menus, toolbars, the statusbar, and the canvas, so if you're interested in working on any of those, the hooks are there for it. If you've never done Gtkmm development, you'll find the tutorial at gtkmm.org to be quite handy - took me only a couple evenings to work through enough of the examples to feel comfortable with it. If you're not sure about your C++ skills, don't worry - gtkmm is designed in a way that allows this work to be done using really basic C++ features, so as long as you're familiar with inheritance, constructors/destructors, and public/protected/private, you should find it pretty clear. Knowledge of templates is helpful, since they're used in various places, but not required - you can learn as you go. There is a PLAN file with some todo's I've identified for myself to work on. At the end of that file, I've also written up some little projects (like implementing the Statusbar or developing Accelerators) that need doing. You're welcome to commit work into this package, although I appreciate hearing what you plan to work on so we can coordinate efforts. The big picture plan for this is to get the structural aspects figured out and examples put in place, then move it into the main Inkscape codebase for further development, with a cmdline flag to indicate which interface to use. I'd like to have at least two dialogs at 100% (including docs!), half a dozen compound widgets fleshed out, some of the canvas integration code stubbed out, so it'll be clear how to plug in the canvas when we get to that point. Bryce

2 1

freehand smoothing?
by bulia byak 07 Sep '04

07 Sep '04

People keep complaining about the unsmooth freehand drawing in Inkscape and point out Sodipodi's smooth drawing as its advantage over us: http://linuxfr.org/2004/07/20/16864.html (see comment "Sodipodi meilleur que Inkscape ?") I remember this problem was being attacked quite some time ago, and I was under an impression that the solution was near. Peter and Nathan were working on it, as well as the person known as paraprax on jabber. Can someone please update me on the status of that work? How far has it progressed and what is needed to finish it? I would really love to see this issue closed for the next version.

3 5

London Linux Expo 6-7 October 2004
by Plinnell 06 Sep '04

06 Sep '04

Hi all, Correction, the date is 6-7 October 2004. Cheers, Peter

1 0

London Linux Expo 6-8 October 2004
by Plinnell 06 Sep '04

06 Sep '04

Hi all, The Scribus Team has been invited by UKLinux.net again to exhibit at .Org Village as a part of LinuxWorld in London, 6-8 October 2004. Any UK or European users who are planning to attend can enter free with advance registration. If you are a user and are attending, please make your self known at the booth. For details, see: http://linuxexpo.co.uk/ I would really appreciate having one or two knowledgable users help to demo Scribus and other DTP applications. If there are Inkscapers or Scribus users who would like to help with the exhibit, please contact me off list. Cheers, Peter

1 0

possibly-obnoxious Doxygen usage: where to document structs/classes
by Peter Moulder 05 Sep '04

05 Sep '04

I've recently been playing with using doxygen for inkscape's sources. For the most part the changes are uncontraversial. In this and a future post are the couple things that I thought people may want to comment on. Moving documentation from a .h file to a .cpp file -------------------------------------------------- While updating the documentation for a member of SPCurve, I used some text that I thought might need changing [indeed it already has changed]. Sometimes people are hesitant to change documentation in a .h file, as doing so can cause lots of ~needless recompilation. As mental once mentioned, doxygen allows putting doc comments in .cpp files instead of .h files. The best example of this is documenting a non-inline function: the doc comment can precede the definition in the .cpp file instead of its declaration in the .h file. Doing so has the additional benefit that the comment is more likely to be kept up to date for changes to the definition. A more questionable possibility is to store documentation for a struct/class in a .cpp file instead of the .h file where the type is defined. I've experimentally done this for SPCurve: the .h file now has a single comment /* See end of curve.cpp for doxygen documentation. */ One reason that it's questionable to move the documentation away from the definition of the type is that doing so requires extra doxygen directives to say what the the comments pertain to. (See end of curve.cpp in CVS.) Will moving the documentation away from the definition result in people not updating the documentation for changes to the definition? The `See end of curve.cpp' comment should mitigate this problem. Also keep in mind the already-mentioned reduced disincentive to edit comments in .cpp files compared to .h files, which tends to increase accuracy of comments kept in .cpp files compared to .h files. Regarding convenience of reading the documentation: I'd guess that at some point doxygen will be the preferred way of accessing doc comments (e.g. using doxygen under emacsen; not sure about vim, but possibly one can use vim's existing tags support). When using doxygen to access documentation, it shouldn't matter whether we use the .h or .cpp file. Whereas if not using doxygen, then there's an advantage to storing in the .h file: e.g. people can use a standard tag search to get to the type's definition. Consequently one might recommend "keep the doc comment with the type definition for now, and we may move to .cpp files later. Or decide based on how widely-#included the .h file is and how often the documentation is likely to change." In any case, no doubt people's responses in this thread will influence people's case-by-case decisions as to where to put the documentation. pjrm.

2 1

possibly-obnoxious Doxygen usage: how to use mathematical notation
by Peter Moulder 05 Sep '04

05 Sep '04

I said that there were two issues with doxygen usage to be discussed, but this second one is so minor that actually I don't think we need discuss it, and I wouldn't be writing this if I hadn't said that I would :) . When documenting the requirements or guarantees of a function, or the invariants of class/struct instance variables, it's common to use operators from mathematics, whether comparison relations (>=, !=), boolean operators (and, or, not, maybe logical implication), set operators (\in, \subseteq, union, intersection), or quantifiers (forall, exists). Sometimes one would prefer to differentiate between operator!= and mathematical/abstract inequality (e.g. for NaN or for glib data structures commonly referred to with pointers). Similarly, one may wish to use the easier-to-reason-with commutative mathematical and/or operators instead of C/C++'s short-circuiting &&/|| (or `\&\&', to use doxygen quoting!). In javadoc, which I'm more accustomed to, the natural solution is to use HTML character entity references (`&and;', `∈', `≥' etc.) -- partly because HTML supports them, and partly because the alternative escaped representations (`&&', `>=') are worse. However, doxygen doesn't currently accept many of these -- see http://sourceforge.net/tracker/index.php?func=detail&aid=1018462&group_id=5… which also discusses alternatives. Unlike HTML/JavaDoc, Doxygen does allows backslash to be used for escaping, which eases things a little. Probably for the moment we'll stick with backslash escaping or keeping the words in the generated documentation rather that using symbols. Has an advantage that people are more likely to understand forall/exists/&&/|| than the corresponding symbols ∀/∃/∧/∨ (upside-down A, backwards E, upside-down v, right-way-up v). pjrm.

1 0

Snaping should be done only on bbox.
by Hans Deragon 05 Sep '04

05 Sep '04

Greetings. Newbie here. I chatted with bbyak and we found that snapping is done on both bbox and nodes by default. This gives an odd snapping behavior to path objects with large strokes, very counter intuitive, and with a perceived snapping to a grid finer than the one which is currently set. bbyak believes that snapping should be done on bbox only by default, and leave to experienced users to set snapping on both types in the preferences dialog, if he desire. So, I propose that default snapping be done only on bbox. If we agree, can someone bring the change to the code? BTW, great tool. I fell in love with it. Best regards, Hans Deragon -- Consultant en informatique/Software Consultant Deragon Informatique inc. Open source: http://www.deragon.biz http://facil.qc.ca (Promotion du libre) mailto://hans@...527... http://autopoweroff.sourceforge.net (Logiciel)

2 2

Text rendering on Win32
by Bob Jamison 04 Sep '04

04 Sep '04

Hi all, Now that the Win32 builds are working again, another problem has appeared(or disappeared) on Win32. Text rendering is not drawing the text on the screen at all. The <text> item is there, and editable, but there is no visible rendering at all. I really don't think that this has anything to do with the crashing bugs, except for the crashes preventing us from seeing the symptom for the last few weeks. (Though I may be wrong. Maybe something is missing from Pango?) Have there been any significant changes in text rendering in the last several weeks that might be causing this? The guys who work with text rendering, layout, and Pango can probably fix this one a lot better than I can. Bob

2 1