- Inkscape Devel - Inkscape Mailman

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

w32 status ... (was: Another attempt at boehm on w32)
by Sudhan 04 Sep '04

04 Sep '04

vellum wrote: > Bob Jamison wrote > > " A test build using this new package > >>of libs is: >> > > http://troi.hous.es3.titan.com/~rjamison/inkscape/builds/Inkscape0409021512…" > > I tested it this morning and it works for w2k. Will not be able to really > play for a few days but certainly it opened and drew some scribs and the > buttons that I tried worked. Great news. > > vellum > I am on w2k, and when I tried the build, I still have the issue of invisible text elements. They are there all right. I can select them and change properties etc., just not visible. Am I the only one facing this issue. NOTE: This is the case with my self builds as well as the one building by Bob. Sudhan

3 6

Re: [Clipart] Logo vote
by Jon Phillips 04 Sep '04

04 Sep '04

I'm tallying up now, if you are trying to get a vote in, then get it in within the next few minutes!!! Jon On Sat, 2004-09-04 at 05:27, Alberto Simões wrote: > How are we on votes? Too far from a winner? > > Cheers, > ALb > > > On Fri, 3 Sep 2004 21:12:02 +0200, bvirlet <bvirlet@...400...> wrote: > > Hello, here is my vote : > > > > http://openclipart.org/clipart//OCALLogos/ocal_logo_0.5_01.svg > > without the little problems in the text (i don't know, maybe is it my viewer) > > > > Bruno > > _______________________________________________ > > clipart mailing list > > clipart@...330... > > http://freedesktop.org/mailman/listinfo/clipart > > -- Jon Phillips KOREA.PH.010.3140.7483 USA.PH.858.361.2811 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu/) Scale Journal (http://scale.ucsd.edu/)

1 0

Re: [Inkscape-devel] Re: Select Under
by Alan Horkan 04 Sep '04

04 Sep '04

On Thu, 2 Sep 2004, bulia byak wrote: > Date: Thu, 2 Sep 2004 13:21:32 -0300 > From: bulia byak <buliabyak@...400...> > To: Alan Horkan <horkana@...44...> > Subject: Re: [Inkscape-devel] Re: Select Under > > On Thu, 2 Sep 2004 14:22:52 +0100 (BST), Alan Horkan > <horkana@...44...> wrote: > > Presumably Metacity is not one of those Window managers (and hopefully not > > the default KDE window manager either). > > Dunno about Metacity, but KDE does steal alt+click. I had to > reconfigure it (it was easy). Of course forcing people to do WM > configuration is not the best thing possible, but there's simply no > other modifier I could use for this. And besides, alt+click and > alt+drag are not core capabilities, so casual users can do without > them. (logged into a Linux machine to check) Metacity use Alt+Click(and Hold) to allow users to drag a window but I cannot come up with a better suggestion and you are right, select under is not a vital feature so for now it is a reasonable compromise. >From trying to make changes in other projects my worry (paranoia almost) is that users will become too accustomed to all the little compromises that have to be made. That in the future when people want to change things for the better users will resist, or even worse developers will have moved on and the new developers will also resist changes failing to understand the compromises that were made. We are not yet even at 1.0 so there is room to change things, and the attitude of the communinity is good so I expect the current developers wont be leaving anytime soon. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/

4 4

inkscape:groupmode reintroduced
by MenTaLguY 03 Sep '04

03 Sep '04

Just a quick note that I've reintroduced inkscape:groupmode, so all that's needed to make a layer is to make a group and then set its inkscape:groupmode attribute to "layer" from the XML editor. The "Active Group" selector (secretly the "Layer Selector") doesn't update when layers are made/unmade yet (the reason I removed inkscape:groupmode for the 0.39 release), but other than that the non-widget portions of layers are done. [ we do also need to establish which layer to start in when a document is loaded; currently we still start out with the root as the current layer ] -mental

3 2

Re: [Inkscape-user] print to ps: transparency and gradients
by Ted Gould 03 Sep '04

03 Sep '04

On Fri, 2004-09-03 at 06:13, Aewyn wrote: > It seems to me, inkscape print to ps doesnot > handle transparency and gradients. > > Can I make it work? Sure! I think to get transparency to work properly you're going to have to use Postscript Level 3 -- which, to my understanding, is the first version to support alpha. The thought in the back of my head for doing this would be to steal the Postscript/PDF engine from Scribus and plug it in to Inkscape. It would be really cool if you did this. If you have questions about where to put stuff or what you can do feel free to ask. --Ted PS - I cc'd the devel list because this discussion should probably be moved there.

1 0

Another attempt at boehm on w32
by Bob Jamison 03 Sep '04

03 Sep '04

Whilst talking to Mental, I noticed one thing about the Boehm-GC libs that might be a problem on Win32. gc6.2 and gc6.3 have similarly-named .h files in their include directory, but they are in -different places-. This means that an upgrade from 6.2 to 6.3 will not overwrite the .h files, and a mismatch between the .h definitions, and the actual object in libgc.a, is very possible. To reduce the number of candidate sources of bugs in GC by one more, I have repackaged gtk24.zip to contain only the .h files supplied by gc6.3. The cleaned-up gtk24.zip is here: http://troi.hous.es3.titan.com/~rjamison/inkscape/gtk24.zip ...and a complete rebuild of Inkscape is here: http://troi.hous.es3.titan.com/~rjamison/inkscape/builds/Inkscape0409010635… Again, I am not saying that this is going to fix the problems, but as Forrest Gump would say, "that's one less thing." Bob

6 11

end of code freeze
by MenTaLguY 03 Sep '04

03 Sep '04

I guess now that Win32's struggling back to its feet we can lift the code freeze and carry on. Any objections? -mental

1 0

Scribus Nominated As A Finalist For Linux Format Awards 2004
by Plinnell 02 Sep '04

02 Sep '04

Hi all, Issue 58 Sept 2004 of Linux Format UK has chosen Scribus as one of four finalists for Best Office Software. >From the article, "In spite of four hundred nominations in this category, most of them were for the same select group of software, resulting in a pretty short list. Newcomer Scribus is a welcome addition". Scribus users are encouraged to vote for their favorites at: http://www.linuxformat.co.uk/awards And they based this on 1.2 cvs, not the final version :) Cheers, Peter

1 0

unsuscribe
by unknown＠example.com 02 Sep '04

02 Sep '04

1 0

Inkscape Status 2004-09-01
by Bryce Harrington 02 Sep '04

02 Sep '04

I notice that the daily downloads of Inkscape have started equalling that of Sodipodi. This is one of the few remaining statistics that Sodipodi has surpassed Inkscape at, so is interesting to see this now changing. Beyond that, things appear to be fairly level right now; hopefully we'll see accelerated growth as we move into the fall. Statistics Nov 15 May 15 Jun 15 Jul 15 Aug 15 Sep 1 ========== ====== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 1028 928 845 774 777 (68.5%) (92.7%) (93.4%) (94.0%) (94.6%) (94.5%) Max Week's Rank on SourceForge: 62 36 41 33 53 79 (99.6%) (99.8%) (99.8%) (99.8%) (99.7%) (99.6%) Total SF Page Views * 475,000 616,263 741,681 900,566 954,864 Total SF Downloads * 27,400 34,015 39,359 47,278 50,672 Total Freshmeat URL Hits 746 * 7,333 7,946 9,382 9,811 Total Freshmeat Subscriptions 16 74 87 93 114 115 Lines of Code in src/: 115,901 189,116 280,263 264,418 276,437 294,072 Code lines 147,471 210,119 192,240 200,684 210,979 Comment line 16,757 40,620 41,926 43,558 50,014 Blank 25,886 34,677 35,422 37,425 39,531 Lines of Docs in doc/: 1,135 4,544 15,170 15,217 16,358 16,769 Lines of content in website: 1,173 6,008 6,372 6,784 7,106 7,391 Size of the Inkscape wiki: 3,700 18,638 17,176 17,854 19,665 19,921 Minutes since last ChangeLog mod: 360 * * 54 * 2733 Bugs open/total: 9/15 57/365 63/401 73/496 110/568 120/592 Features open/total: 18/18 183/238 210/285 242/331 266/361 267/369 Patches open/total: 1/ 6 4/ 83 5/ 88 8/110 5/120 5/122 CVS Commits (as per inkscape-cvs): 481 3391 5549 6314 6,822 7,083 Inkscape-devel membership: 49 78 84 95 104 108 Inkscape-announce membership: 9 43 53 60 74 77 Inkscape-user membership: 71 76 90 109 112 Num Translations : 32 33 33 Ave Translation Ratio: 40.5% 44.9% 45.0% * - Statistics unavailable

1 0

Select Under
by bulia byak 02 Sep '04

02 Sep '04

On Thu, 26 Aug 2004 01:35:54 +0200, Aewyn <aewyn@...523...> wrote: > Working with lot's of semi transparent objects I ran a serious problem. > I can't select an object underlaying objects, bacause at this moment the > object upper is selected. > > I can use tab to switch objects, but working with 100 object, it is > impossible. > > So it would be nice a view "wireframe", with possibility border selecting. Wireframe view is in our plans, but not in the short term. Instead I just did what I wanted to do for a long time, hopefully it will help: * Select Under: in Selector, clicking with Alt selects the object at cursor which is below (in z-order) the currently selected object at cursor; if the bottom object is selected, Alt+click again selects the top object. Thus, several Alt+clicks will cycle selection through the z-order stack at the click point. Combining Alt with Ctrl and Shift works, too. Note that on Linux, some window managers steal Alt+click, but Ctrl+Alt+click ("select under in groups") and Shift+Alt+click ("select under, add to selection") will still work. And also as a helpful reminder, * Pressing Alt, Ctrl, or Shift displays the function of these modifiers in the statusbar (only in Selector so far). This is in CVS now.

2 4

logo vote for OCAL
by Jon Phillips 01 Sep '04

01 Sep '04

Hello Inkscapers, We are voting on the OCAL logo right now. Please submit your top 3 logo choices from here: http://www.openclipart.org/cgi-bin/navigate/OCALLogos to the Open Clip Art Library list. We need more eyes on the logos and have had few votes. The vote cutoff time is FRIDAY afternoon 5 PM PST. If you are not on the mailing list, then now is a good time to jump on the project and pick up a shovel by voting and submitting your metadata rich graphics! Jon PS: You can also submit your logo votes to my email address... -- Jon Phillips KOREA.PH.010.3140.7483 USA.PH.858.361.2811 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu/) Scale Journal (http://scale.ucsd.edu/)

1 0

[Fwd: [Inkscape-user] moving forward (Was: Re: cause of crashes)]
by MenTaLguY 31 Aug '04

31 Aug '04

Whoops, meant to send this to the development list.. -----Forwarded Message----- From: MenTaLguY <mental@...3...> To: Inkscape Users List <inkscape-user(a)lists.sourceforge.net> Subject: [Inkscape-user] moving forward (Was: Re: cause of crashes) Date: Sun, 29 Aug 2004 13:01:02 -0400 Ok, so it appears we're currently waiting on someone to test with a build of libgc that we know to have been compiled with the appropriate options (this means C++ support, but nothing else -- particularly no malloc replacement). So, is someone willing to assume responsibility for making a new build of libgc to test with, and documenting what steps they took when building it? -mental

2 1

refcount rules
by MenTaLguY 31 Aug '04

31 Aug '04

On Mon, 2004-08-30 at 00:59, bulia byak wrote: > Mental, please check out the patch in this bug: > > https://sourceforge.net/tracker/index.php?func=detail&aid=1012874&group_id=… > > and apply if ok. It fixes a bad memory usage crash in deleteObject. Unfortunately sourceforge is currently in "read-only" mode, so I cannot comment in the bug itself. The patch hides the problem without really fixing it, though (and sort of breaks the intended semantics I had for successors, albeit not in a way that matters too much). The bug is not in deleteObject, but rather that deleteObject's caller is not retaining a reference to it (by increasing the reference count) while deleteObject() does its work. The general rule is always, always, always make sure that you have claimed a refcounted object before calling a nontrivial function (especially one that modifies the object). This holds not just for deleteObject(), or SPObjects in Inkscape, but for any software with simple refcounted objects. [ The garbage collector relaxes this requirement slightly, but only for classes which are managed by it, which SPObject is not yet. ] The correct fix is to modify the portion of sp_marker_prev_new(): SPObject *oldmarker = sandbox->getObjectById("sample"); if (oldmarker) oldmarker->deleteObject(false); thusly: SPObject *oldmarker = sandbox->getObjectById("sample"); if (oldmarker) { sp_object_ref(oldmarker, NULL); oldmarker->deleteObject(false); sp_object_unref(oldmarker, NULL); } Probably simliar mistakes are made in other places as well (and with other functions beyond just deleteObject() -- deleteObject() is simply more likely than most to remove the remaining external refcounts on the object). -mental

2 3

libgc on Win32
by MenTaLguY 30 Aug '04

30 Aug '04

Talking to Simarilius, it looks like the version of libgc we've been using on Win32 has been built to replace the standard malloc. This should in principle be harmless (except that the collector will be scanning a lot of memory it does not need to, and might mistake e.g. bitmap data for pointers), but Could someone try a version of libgc that has been built without the malloc-replacement option and report back? A different problem may be that Win9x and WinNT/2k/XP could require different builds of libgc. -mental

6 14

GC_no_dls
by MenTaLguY 30 Aug '04

30 Aug '04

I'm going to make one small adjustment to the GC code now: adding GC_no_dls = 1 to the GC intialization code. This will prevent libgc from scanning the static data areas of dynamic libraries, which seems to cause problems on FC2, and in any case is unnecessary. Ideally we want the most conservative gc configuration that is reasonably possible; this should bring us a step closer. -mental

3 3

switch + documentation translations
by bulia byak 30 Aug '04

30 Aug '04

With the number of documentation translations growing, the current system becomes less and less sustainable: if I now update an English tutorial, translators will have lots of trouble spotting the changes and updating their translations accordingly. It basically amounts to manual comparisons, which means the translations are likely to almost always be out of sync with the original. How to fix this? I thought about the switch element: http://www.w3.org/TR/SVG11/struct.html#SwitchElement Inkscape needs to support it (it doesn't yet) at least for the systemLanguage attribute. Then, all translations of a tutorial can be stored in one file. A translator would select each text obejct (they will need to be converted to flowed text objects, by the way) and use a command to add an alternative for his language, then type the translation. Illustrations would be shared across all languages. This way, if a new section is added but not translated yet, users of a non-English language will still see this section in English, which is better than not seeing it at all. Inkscape could provide additional help by storing the last-edited timestamps in switch'ed objects, so that a translator could find sections where the original is more recent than a translation. What do you think of this idea?

7 8

resurrecting Win32 builds
by Bob Jamison 30 Aug '04

30 Aug '04

Hi all. Just thought I'd update everyone on the Win32 situation. Re: win32 startup crashes =================== For the entire summer, I have been without a Win32 box on which to do native builds or test Inkscape. All I can do is make cross-compiled builds and depend on other people to test and debug Win32 factors. Simarilius and others have been researching many possible reasons for the crashing bugs, and trying to alleviate them. malloc/free and null pointers seem to be prime suspects. One possibility occurred to me yesterday. The GCC3.4.1 compiler we have been using for cross-compiling was a CVS HEAD version, and not the final 3.4.1 release. It was possible that MinGW patches might insufficiently apply to this code. It is thus possible that the objects created from C++ might be buggy. So I rebuilt the cross-compiler and all of the C++ libs in our gtk24.zip collection, and put these new builds on the web site. Anyone building Win32 Inkscape should get a fresh copy of these. The same links as before have the new items. I built Inkscape with these libs yesterday, put them on the server. Bulia said it works; Simarilius says there are still some problems. So -at least- we are making some progress. One possible problem area to investigate is MSVCRT's RtlFreeHeap() seeing different address spaces in the .exe and .dlls. Allocating memory in one, and freeing in the other would cause a fault in WinNT and above (not 9x). Re: server =================== After more than a week of downtime, my little development server is partially back online. The current location is now: http://troi.hous.es3.titan.com/~rjamison/inkscape By 'partially,' I mean that it can be accessed via http, but the admin has not fixed the routers to allow the machine to see the Net. So it cannot do a cvs checkout, thus cannot do an autobuild. The admin is a good guy, so this condition is certainly temporary. Because of this, I did a manual build, and put a copy in the /builds subfolder (link at the top of the page). I will do this occasionally until things are fixed. InkscapeLatest.zip points to it. Bob

3 5

evil_malloc
by MenTaLguY 30 Aug '04

30 Aug '04

Since I was asked about evil_malloc() -- the main reason I introduced it was that malloc debuggers (e.g. Electric Fence) don't like malloc(0), and I wanted to be able to use them. The reason is that malloc(0) is not required to return NULL; all that is required is that it return a pointer which can be free()d -- this can introduce some subtle bugs depending on the platform and libc versions. [ regrettably, realloc(p, 0) is not guaranteed to return NULL either, though it is more likely to :/ ] While I don't see any harm to livarot specifically resulting from differing malloc(0) behaviors, there is far too much code in there that is "wrong, but harmless". I want rid of it; subtle bugs cropping up in livarot is sapping far too much of my development time. So, anyway, the proper resolution to the evil_malloc() business is to replace the calls to evil_malloc() with an explicit check of the allocation size (really, nrPt or whatever the size is computed from). I will do that myself eventually, but it's a simple enough task that anyone can do it if they are so inclined. -mental References: http://sources.redhat.com/ml/libc-hacker/1998-06/msg00001.html http://users.bestweb.net/~ctips/tip028.html http://lists.freebsd.org/pipermail/freebsd-standards/2004-February/000395.h… http://www.ussg.iu.edu/hypermail/linux/kernel/0011.0/1122.html http://www.uclibc.org/downloads/Glibc_vs_uClibc_Differences.txt (item #4)

1 1