headers
Bryce Harrington | 1 Dec 2004 01:37

Re: [Clipart] Announcing Inkscape 0.40 Release (fwd)


---------- Forwarded message ----------
Date: Tue, 30 Nov 2004 19:01:37 -0500
From: Jonadab the Unsightly One <jonadab@...>
To: clipart@...
Subject: Re: [Clipart] Announcing Inkscape 0.40 Release

Bryce Harrington <bryce@...> writes:

> user's may encounter more trouble getting Inkscape installed on some
> platforms than in previous releases.  To help those who run into
> this issue, we're also providing 'Static Binary' packages that
> include these new libraries inside the package, and thus, the static
> releases are very large.

Very large?  8 Megs hasn't been a large size for an application
download in *years*.  There are *plugins* nearly twice that large.
(For example, I've got a copy of j2re-1_4_2_05-linux-i586.rpm sitting
around in my downloads directory weighing in at 14MB, and nobody
apologised for that being large.)

Honestly, I wish more applications would realease statically linked
binaries like this.

<rant intensity="50%">
  However, I still have to chase down a dependency: gtk2.  I have
  gtk2, of course, but apparently it's not the latest and greatest
  version.  So I downloaded that, but now I need other stuff...

  error: Failed dependencies:
(Continue reading)

Permalink | Reply | 704 comments |
headers
bulia byak | 1 Dec 2004 02:22
Picon

Re: Re: [Clipart] Announcing Inkscape 0.40 Release (fwd)

> The take-home message is this:  Static linking is GOOD, and the world
> needs more of it.

Amen.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
Permalink | Reply | 0 comments |
headers
MenTaLguY | 1 Dec 2004 05:34
Favicon
Gravatar

Re: Re: C-based garbage collection for Inkscape

On Tue, 30 Nov 2004, Keith Packard wrote:
> >
> > I've been using a garbage collector in C for about twenty years which is
> > different from the Boehm system.

It looks really interesting to me.  I'm not sure it would address the
general problems we've had with garbage collection[1], nor that it
offers everything we need for C++.

> > advantages:
> >
> >  1)	Completely portable -- no machine dependent code at all

I have to say I find the use of a "reference stack" in avoiding the need
to examine the stack or registers to be very elegant.

> >  2)	Integrates with malloc/free using code

Hmm.  We haven't really had many integration problems with the boehm
collector.  About 1/4 of our codebase uses the collector, and the
remainder uses the system allocator (generally via glib).

The one issue that does come to mind is the problem of storing
references to collector-managed objects in malloc-managed memory.

In Inkscape's case we have some collector-managed classes which have
supplementary refcounts.  Objects of these hybrid classes are pinned
while they have a nonzero refcount, and can safely be referenced from
untraced memory if refcounts are managed appropriately.
(Continue reading)

Permalink | Reply | 3 comments |
headers
MenTaLguY | 1 Dec 2004 05:38
Favicon
Gravatar

Re: layer commands we need

On Mon, 2004-11-29 at 15:24, bulia byak wrote:
> Group to Layer      // convert group to layer
> Layer to Group

Hmm, I'm not entirely sure either of these is really necessary.  

Certainly "Group to Layer" would be handled by the hypothetical "from
selection" option in the "New Layer" dialog.

Not sure about how much or if at all "Layer to Group" would be needed. 
Can you provide a use case?

-mental
Permalink | Reply | 1 comment |
headers
bulia byak | 1 Dec 2004 05:57
Picon

Re: layer commands we need

> Certainly "Group to Layer" would be handled by the hypothetical "from
> selection" option in the "New Layer" dialog.
> 
> Not sure about how much or if at all "Layer to Group" would be needed.
> Can you provide a use case?

Just convenience - when you work inside some group it's convenient to
have it as layer, so as not to have to "enter" it all the time. When
you're done working inside it and want to position or transform it,
you need it to be a group again.

In old files, people may have used groups instead of unavailable
layers as a way to organize stuff. It would be nice to allow them to
convert these to proper layers easily. Making a layer with selected
group and then ungrouping it is not too elegant, and as we now know
ungrouping may not preserve appearance for textpaths.

Also there's a slight didactic value in these commands: they emphasize
the relation between groups and layers which is an important thing to
understand.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
Permalink | Reply | 0 comments |
headers
Keith Packard | 1 Dec 2004 07:07
Favicon
Gravatar

Re: Re: C-based garbage collection for Inkscape


Around 23 o'clock on Nov 30, MenTaLguY wrote:

> It looks really interesting to me.  I'm not sure it would address the
> general problems we've had with garbage collection[1], nor that it
> offers everything we need for C++.

I don't know that it is a good solution, I've just heard from other people 
using the Boehm collector that it had "issues" which my little GC system 
appears to solve and was wondering if it might be of interest to you as 
well.

> I have to say I find the use of a "reference stack" in avoiding the need
> to examine the stack or registers to be very elegant.

I was much more interested in portability than transparent use, and with 
some practice, it's not that hard to use the macros.  One nice thing is 
that forgettin to use the macros causes no harm, it just delays the 
collection of garbage collected below the function failing to invoke the 
macros.

> The one issue that does come to mind is the problem of storing
> references to collector-managed objects in malloc-managed memory.

And this is easy enough with the nickle collector -- you create a 
synthetic object and add it as another root in the system.  The 'mark' 
function then walks the malloced memory to reference the gc'able objects.
The malloc'ed storage need never know that it's being used in this fashion.

> Is there any alternate way the nickle collector could assist us in
(Continue reading)

Permalink | Reply | 2 comments |
headers
Lucas Vieites | 1 Dec 2004 09:38

Re: Inkscape slides in spanish

El mar, 30-11-2004 a las 19:10 +0000, Alan Horkan escribió:
> On Tue, 30 Nov 2004, Lucas Vieites wrote:
> 
[...]
> >   Hi,
> >   A few months ago there was a presentation of Inkscape at the
> > University of A Coruña. Now the slides used at that presentation have
> > been made available. The slides are made in inkscape in order to provide
> > a useable space on the right to do some demos as you speak.
> >   Find them at:
> 
> http://www.gauss-fic.udc.es/Members/moebius/tutoriales/inkscape/inkscape-slides.tar.bz2
> 
> >   And «kudos to the author»: Adrián Perez de Castro
> >
> >   If an english translation is needed I'll be glad to provide one.
> 
> If there was some way you could put the slides one the web in HTML (or
> even plain text) format so that we can use automated online translation
> tools that would be great (and hopefully much easier than a full
> translation).

  I'll try and find a way. The problem is that the author converted all
text to strokes so there would be no font issues. I'll ask for the
originals.

  Cheers,
--

-- 
Lucas Vieites Fariña
Dept. Desarrollo <lucas@...>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Jamison | 1 Dec 2004 17:21

Query: I/O cleanup, reorganization?

Hi all,

I am back from holidays today, and have been catching up on my email.

I was wondering: would a good task for this cycle be a reorganization
of our set of scattered, disparate I/O classes into a nice, clean heirarchy
of its own, such as   /src/io    and the namespace Inkscape::IO?
We have been talking about moving from filenames to URIs for months
now,  and changing slowly from FILE * to iostreams.  Maybe now at
the beginning of a release cycle would be a good time to bite the bullet.
This would not be a roadmap thing, but a nice clean top-to-bottom
refactoring that would finally take care of our recurring migraines with
files and paths and localization.  Consider it to be a big bugfix.

If we could upgrade from
char * ---to--->FILE *

to a much cleaner
URI ---to--->istream
and
URI ---to--->ostream

...with built-in support for localization, it would make things a LOT 
easier.

I have been looking around the net a lot, and there already exists a 
wonderful
'gzstreams' lib for supporting .svgz without pipes.  I experimented with
it by recoding my copy of repr-io.cpp to use iostreams instead of FILE 
*, and
(Continue reading)

Permalink | Reply | 15 comments |
headers
Bob Jamison | 1 Dec 2004 17:45

Scene interpretation mentioned on Slashdot

There is an article on Slashdot that mentions a
"new photographic technique" with some concepts strikingly
similar to how the Tracer works:

http://science.slashdot.org/article.pl?sid=04/12/01/0238222&tid=152&tid=126&tid=14

this is the quoted article:

http://www.photo.net/learn/technology/mflash/merl-non-photo.html

Notice the mention of a "canny edge detector."  ;-)

One thing that someone showed me, is how tracing the same
image multiple times with different algorithms and/or parameters, and
recombining the results, can often produce a fairly good rendition
of the original.  Here is a trivial example of the raytracer doing it
with merely 3 different levels of brighness threshold:

http://troi.hous.es3.titan.com/~rjamison/inkscape/files/clemens-traced.png

So, hey, we are ahead of the curve on this one!  ^^

Bob

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kees Cook | 1 Dec 2004 18:01
Favicon

Re: Re: [Clipart] Announcing Inkscape 0.40 Release (fwd)

On Tue, Nov 30, 2004 at 04:37:57PM -0800, Bryce Harrington wrote:
> ---------- Forwarded message ----------
> <rant intensity="50%">
>   However, I still have to chase down a dependency: gtk2.  I have
>   gtk2, of course, but apparently it's not the latest and greatest
>   version.  So I downloaded that, but now I need other stuff...
> 
>   error: Failed dependencies:
>         libglib2.0 >= 2.4.0 is needed by libgtk+2.0_0-2.4.9-9mdk
>         libpango1.0 >= 1.4.0 is needed by libgtk+2.0_0-2.4.9-9mdk
>         libgtk+-x11-2.0_0 = 2.4.9-9mdk is needed by libgtk+2.0_0-2.4.9-9mdk
> [snip]
> 
>   Not only is GTK quite pointlessly dynamically linked against libglib
>   and pango, but it *itself* is subdivided into two packages, for
>   absolutely no good reason.

I think the RPM deps for pango are not detected correctly.  I did the
final bits of work on making the static inkscape package, and originally
I wanted to do GTK statically, but it turned out to be very difficult.  
Anyway, as an explaination for you as to why GTK wasn't linked 
dynamically, here's my email.  :)  If you have any solutions, I'm all 
ears, since I'd like to see Inkscape running on my old redhat 7.2 box.  
:)

It seems Pango (which uses all the Glib data types, which translates 
into the libs libgobject, libgmodule, etc) cannot operate when compiled 
statically.  Now, I could have easily missed something, but I had 
already spent about 20 hours endlessly recompiling things as I 
discovered more deps.  I could not get pango operational unless it was
(Continue reading)

Permalink | Reply | 0 comments |

Gmane