Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #85079 > unrolled thread

Is there a cairo like surface for the screen without the window hassle

Back to article view | Back to comp.lang.python

Contents

  Is there a cairo like surface for the screen without the window hassle Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-02-02 14:20 +0100
    Re: Is there a cairo like surface for the screen without the window hassle Paul Rubin <no.email@nospam.invalid> - 2015-02-02 08:54 -0800
    Re: Is there a cairo like surface for the screen without the window hassle Nobody <nobody@nowhere.invalid> - 2015-02-03 12:17 +0000
      Re: Is there a cairo like surface for the screen without the window hassle Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-02-03 16:46 +0100

#85079 — Is there a cairo like surface for the screen without the window hassle

I need to have a program construct a number of designs. Of course I can directly
use a pfd surface and later use a pdf viewer to check. But that becomes rather
cumbersome fast. But if I use a cairo-surface for on the screen I suddenly have
to cope with expose events and all such things I am not really interested in.

So does someone know of a package that provides a cairo like surface but that
would take care of the events in a rather straight forward matter, so that my
program could make it's design in a window on the screen just as if it is
designing it in a pdf file.

-- 
Antoon Pardon

[toc] | [next] | [standalone]

#85095

Antoon Pardon <antoon.pardon@rece.vub.ac.be> writes:
> So does someone know of a package that provides a cairo like surface

Not sure what a cairo like surface is, but maybe you want HTML5 Canvas
that's built into recent browsers.  So you'd just embed a web server
in your application and interact with it through a browser.

[toc] | [prev] | [next] | [standalone]

#85143

On Mon, 02 Feb 2015 14:20:56 +0100, Antoon Pardon wrote:

> I need to have a program construct a number of designs. Of course I can
> directly use a pfd surface and later use a pdf viewer to check. But that
> becomes rather cumbersome fast. But if I use a cairo-surface for on the
> screen I suddenly have to cope with expose events and all such things I
> am not really interested in.

If you're writing a GUI application, something has to deal with those
events regardless of which rendering API you use.

> So does someone know of a package that provides a cairo like surface but
> that would take care of the events in a rather straight forward matter,
> so that my program could make it's design in a window on the screen just
> as if it is designing it in a pdf file.

What exactly is the issue here? That you want to be able to construct a
graphical representation then discard the data used to construct it,
rather than having to keep it around in order to handle subsequent expose
events?

If that's the case, the simplest solution is probably to render to an
image surface then handle expose events by drawing the image onto the
screen (or handing the image to some kind of "widget" which does this for
you).

Or, if you want to support dynamic scaling, you can "render" to an SVG
surface instead, but widgets which can display SVG aren't as common as
those which deal with raster formats.

Another solution is to render to a recording surface. This can then be
used as a source surface, so handling expose events boils down to a single
cairo_paint() operation with the recording surface as the source surface
and the window as the destination surface. Maybe there's even a widget
somewhere which does this, but I don't know of one.

[toc] | [prev] | [next] | [standalone]

#85157

Op 03-02-15 om 13:17 schreef Nobody:
> On Mon, 02 Feb 2015 14:20:56 +0100, Antoon Pardon wrote:
>
>> I need to have a program construct a number of designs. Of course I can
>> directly use a pfd surface and later use a pdf viewer to check. But that
>> becomes rather cumbersome fast. But if I use a cairo-surface for on the
>> screen I suddenly have to cope with expose events and all such things I
>> am not really interested in.
>
> If you're writing a GUI application, something has to deal with those
> events regardless of which rendering API you use.

Sure but from my point of view I am not writing a GUI. I just have a function
that takes a cairo context and draws an image on it. That works all very fine
if it is a postscript of pdf or an image but gives trouble when the context
is associated with a window on the screen.

>> So does someone know of a package that provides a cairo like surface but
>> that would take care of the events in a rather straight forward matter,
>> so that my program could make it's design in a window on the screen just
>> as if it is designing it in a pdf file.
>
> What exactly is the issue here? That you want to be able to construct a
> graphical representation then discard the data used to construct it,
> rather than having to keep it around in order to handle subsequent expose
> events?

I want those expose events handled for me, so I don't have to care for them,
so that I can just use a context that will render the drawing in a window
on the screen without me having to wonder about any event.

> If that's the case, the simplest solution is probably to render to an
> image surface then handle expose events by drawing the image onto the
> screen (or handing the image to some kind of "widget" which does this for
> you).
>
> Another solution is to render to a recording surface. This can then be
> used as a source surface, so handling expose events boils down to a single
> cairo_paint() operation with the recording surface as the source surface
> and the window as the destination surface. Maybe there's even a widget
> somewhere which does this, but I don't know of one.

Yes I had written something like this for pygtk. The module provided an
initiator which you called with a function. This would then start the gtk.main
loop and start the function in a thread. The module provided also a class
similar to a cairo context, which would create a windon and draw into it, it
was implemented more or less as you describe above. The main advantage was that
the function that made the design didn't need to care about being used in a GUI.

Problem is I don't succeed in getting it to work with the new introspective
gtk framework. But since this seems something usefull I thought I ask about
maybe someone else already having written something similar before I sink
more of my own time into it.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web