Re: deprecated gtk_cairo_create

[Sergei Kolomeeyets]

Hi, Emmanuele
thanks for your help in last days of last year. Well, in the
attachment there are codes of the (perhaps) simplest usage of Drawing
Area widget. It goes without gdk_window_create_similar_surface.

I'd like to summarize several ideas mentioned in "the deprecated
gtk_cairo_create()" thread.

1. On-screen drawing in Drawing Area against GTK+3 is much more easy
than in GTK+2. But this simplification has been achieved by
significant changes in API. In particular, the GtkWidget::draw signal
is quite different from GtkWidget::expose in GTK+2. GtkWidget::draw
takes a cairo_t* as the second parameter, not a GdkEventExpose like
did ::expose.  And here one can have the Cairo context required. In
other words one SHOULD DO NOTHING to create a cairo context BECAUSE IT
HAS BEEN ALREADY CREATED BEFORE A DRAW EVENT EMISSION and put by GTK+3
as the second parameter of a draw event callback function. Don't
create it, don't destroy it, just use it!

/*a standard main, except a new type of signal, "draw"*/
gint
main ()
{
   GtkWidget *window;  /* pointer to the app main window */
   GtkWidget *area;

   window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
   area = gtk_drawing_area_new();

   gtk_widget_add_events(window,...);
   gtk_widget_add_events(area,...);

   g_signal_connect(G_OBJECT(area), "draw",
 G_CALLBACK(draw_callback),
 NULL);

   g_signal_connect(G_OBJECT(area),
 "configure_event",
  G_CALLBACK(configure_callback),
  NULL);

   gtk_container_add(GTK_CONTAINER(window), area);
   gtk_widget_show_all(window);
   gtk_main();

}
/*-*/
gboolean
draw_callback (GtkWidget *widget, cairo_t *cr)
{
   GtkStyleContext *context;
   context = gtk_widget_get_style_context (widget);
// do your own drawing
}

It is sobering to be informed that the API reference is generated via
gtk-doc, which queries the type for signals and properties using the
GType API; Cairo provides GType wrappers for property and signal
marshalling, and those have CamelCase names to better fit in. This
means that a C `cairo_t` type is a `CairoContext` GType, and a
`cairo_surface_t` C type is a `CairoSurface` GType.


2. If you want to draw outside of the ::draw() handler and paint the
cached thing then, use a cairo_surface_t as the offscreen surface, and
paint on it then. You either create your own Cairo surface, or you ask
GDK to create a similar surface (or similar image surface) to the one
used by the GdkWindow that is the target of the rendering. Then, you
call 'cairo_create()` to get a Cairo context. The latter is possible
as cairo_create () is still not deprecated, but only
gtk_cairo_create() is.

GdkWindow *window = gtk_widget_get_window (widget);
cairo_surface_t *surface = gdk_window_create_similar_surface (window,
CAIRO_CONTENT_COLOR_ALPHA, width, height);

/* then create a Cairo context from it, and draw:*/

  cairo_t *cr = cairo_create (surface);
  // draw
  cairo_destroy (cr);

/* Now you can use the surface as a source on the Cairo context that
GtkWIdget::draw gives you:*/

  static gboolean
  on_draw (GtkWidget *widget, cairo_t *cr)
  {
// render your surface on the widget's context
cairo_set_source_surface (cr, surface, x, y);
cairo_paint (cr);

// do your own drawing
  }

3. But reasons (except compatibility) for such a way of drawing are
*now* a bit hazy, taking into account your comment :"creating an
intermediate surface on configure-event (something that's there only
for backward compatibility with GTK+ 1.2, and it's an X11-ism) just to
source it again is much more expensive than drawing on the provided
Cairo context".  The obvious reason was to pack all redrawing
procedures hooked to configure_event into a special drawing function
and put it into configure call-back function. Configure event happens
much less often than draw event. So there is a hope to be more
efficient...  One could find additional discussions with almost the
same context here
https://lists.cairographics.org/archives/cairo/2007-December/012211.html
and here 
https://lists.cairographics.org/archives/cairo/2007-December/012211.html.
For example, when I draw a dynamic figure with complex axes (with
sophisticated ticks' marks and other elements) why should I draw them
(axes) every time I redraw the main line? It's definitely a good idea
to gather all codes of axes drawing into special function and put it
into a configure event handler. What do you recommend that I do now
(if "off-screen' drawing is much more expensive and in general is a
very niche use cases)?

Regards,
Sergey







2016-12-30 18:15 GMT+03:00 Sergei Kolomeeyets <kolomeey...@gmail.com>:
> Hi, Emmanuele
> thanks for not leaving me alone with my first attemts to navigate through
> 'uncharted' w

deprecated gtk_cairo_create

[Sergei Kolomeeyets]

Hi, everyone
I'm struggling with migration from gtk2. Well gtk_cairo_create is
deprecated in gtk3. And it looks  the changes are very serious (or I'm sach
silly that even do not understand what should I do instead of it ). Is
there anybody who use Drawing Area in GTK3 and can explain the right way of
its cairo context creation and drawing on it to me. It would be so
appreciated.

Documentation says the following:
***gtk_cairo_create
gdk_cairo_create has been deprecated since version 3.22 and should not be
used in newly-written code. Use gdk_window_begin_draw_frame()

and gdk_drawing_context_get_cairo_context()

instead.

***gdk_window_begin_draw_frame
[bla-bla-bla...] When using GTK+, the widget system automatically places
calls to gdk_window_begin_draw_frame()

and gdk_window_end_draw_frame()

around emissions of the GtkWidget::draw signal. That is, if you’re drawing
the contents of the widget yourself, you can assume that the widget has a
cleared background, is already set as the clip region, and already has a
backing store. Therefore in most cases, application code in GTK does not
need to call gdk_window_begin_draw_frame()

explicitly.

I use GTK+, so I can forget about gdk_window_begin_draw_frame for some
time. Right?
And there is only gdk_drawing_context_get_cairo_context in the rest of
options. So I write the following:

{main}
...
/*Drawing area and text_entry at the bottom of it */
area = gtk_drawing_area_new();
text_entry = gtk_entry_new();
vbox = gtk_vbox_new (FALSE, 0);

gtk_box_pack_start(vbox, area, TRUE, TRUE, 0);
gtk_box_pack_start(vbox, text_entry,  FALSE, FALSE, 0);

gtk_container_add(GTK_CONTAINER(window), vbox);
gtk_widget_show_all(window);
gtk_main();
...

{draw_callback}

gboolean draw_callback(GtkWidget *area, GdkEventExpose *event, GArray
*ptLinePoints) {
...
cairo_t *cr = gdk_drawing_context_get_cairo_context (area);
...
}

But linker (gcc package) writes  "undefined reference to
`gdk_drawing_context_get_cairo_context"... :-(
Everything indicated that I missed several lines of code before
gdk_drawing_context_get_cairo_context. But what lines exactly? Googling
gives nothing...

Is there anybody who use Drawing Area in GTK3 and can explain the right way
of its cairo context creation and drawing on it to me. It would be so
appreciated.

Thanks in advance!

Best Regards, (and Happy New Year for everyone here!!!)
Sergey.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Interpretation of gtk warnings and errors messages

[Sergei Kolomeeyets]

Hi everyone!
Can anybody be so kind to help me with sources (docs of web) with relevant
information or any ideas concerning interpretation of gtk messages like
this:
(main_1:31671): Gtk-WARNING **:
/build/buildd-gtk+2.0_2.24.10-2-i386-Tg7Q_2/gtk+2.0-2.24.10/gtk/gtkwidget.c:5683:
widget not within a GtkWindow.

It's obvious that 5683 is a line in the source file. It was easy to check,
but comments in that file tell almost noting as usual. What about
(main_1:31671)? How can I understand what is it and where is it? Definitely
it is not the line in the source file main_1.c and it is not the line in
main_1.o

Thanks!

Sergey,
Moscow.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

key values on key pressed

[Sergei Kolomeeyets]

Hi,
to write a trivial key-press handler like the following:

static gboolean key_pressed (GtkWidget *area, GdkEventKey *event, GPtrArray
*ptLinePoints)
{
  GError *error;
  guint tt;

 if (event-keyval == GDK_Delete) {
...
  }

 if (event-keyval == GDK_Return) {
...
   }

  return FALSE;
}

one can use predefined constants from gdk/gdkkeysyms.h. Is there anybody
who could tell me what all those constants written in the file mean (except
the most explicit ones like GDK_Delete or similar)?  The question about the
possible meaning of GDK_KP_Enter, for instance, drivers me up the wall
really. I'm actually able to guess the meaning of Enter and GDK,,, But
what does that KP mean? Of course, the question is not about only one
constant, but about the whole set of names which is in the file. Who knows
it or where can I get the description for them?

In particulary, I badly need to use Alt+... and Ctrl+... combinations.
It would be very appreciated if someone throw a hint to me at least
relating to hexes for such combinations.
Tricks like
tt = event-keyval;
g_print (%h, tt);
give nothing.

Thanks!
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list