Hi Carlos,
>moving this thread to geda-dev with a better subject...
>
Yes, a discussion of the geda-user vs geda-dev mailing lists
did come up at the last freedog. Thanks for moving this over to geda-dev
where it really belongs.
[snip]
>I got pixmaps from GtkWidget *window and backingstore, but they are only
>pixmaps of the same area displayed in the gschem's window (which is not
>right if you are only displaying a small area of the schematic)... and I
>got best results from backingstore (I mean other visible windows in the
>desktop can affect the png output when using GtkWidget *window, I
>think). Is backingstore cleaner than GtkWidget *window?
Yeah, backingstore is as close as it gets to the actually rendered
objects since it is used to handle the expose events.
>Is there any other variable storing the full gschem's window? If not, I
Not that I'm aware of.
>guess I need to do a 'zoom extents' before getting the pixmap, get the
>pixmap, and then restore the previous zoom factor (without the user
>noticing all these, of course)...
Yeah, this is sort of what the existing code does. The coupling
between the current rendering code and the png output exists because
I wanted to reuse all the world -> screen mappings. This is why you
see that annoying flash when you pick a large png width and height and
write to png.
>
>> I think that getting rid of libgdgeda is a great idea, but if we are going
>> to do that, we have to make sure we can do all the rendering without creatin
>g
>> a gui window etc... otherwise we are no better than the (my) existing (lame)
>
>> implementation for creating pngs.
>
>I think it's not so simple. I will get picture png support working
>first...
Agreed.
>
>The problem is that, for example, you need a visible window before
>setting the gc of the window, which is done when initializing the main
>window...
Yuck. Hmmm, is this restriction still true if you want to
render into a gdk pixmap?
>I think we need to split non-gui functions and gui functions,
>and call the latter only when needed.
That is what libgdgeda was supposed to provide (a split
between the gui and non-gui since libgdgeda is writing to a png and
really shouldn't need anything else), however somewhere in the original
png support I got a little lost and ended up coupling the png output to
the main render window. And there are way too much gui dependancies in
libgeda. Oops. Hardly the smartest things I've ever done.
-Ales
