- Inkscape Devel - Inkscape Mailman

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