recommended way to create a render loop with gtkglext
Hello, I'm writing a GLSL shader editor and I need to be able to create a loop that will force the gtkglext widget to constantly refresh at 60Hz or less if the frames take too long to render. I've tried to copy the code from the logo.cexample but it just isn't refreshing. Honestly I'd rather stay away from g_timeout for this task. I tried using threads but it became really unstable (segfaults) when calling /* Invalidate the whole window. */ gdk_window_invalidate_rect (widget-window, widget-allocation, FALSE); /* Update synchronously. */ gdk_window_process_updates (widget-window, FALSE); in the separate thread. Is there a way I could simply have the separate thread send a redraw signal to the widget, and would that event work? I'm open to just about any ideas that don't involve g_timeout. Thanks. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Extended Layout Summary
Am Donnerstag, den 20.12.2007, 11:46 -0500 schrieb Havoc Pennington:
Hi,
Mathias Hasselmann wrote:
Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington:
Then the following default implementations:
- all four of the new functions have default implementations that
invoke the current size_request and use it for both min and natural
size; so unmodified widgets still support the new interface
So you suggest, that GtkWidget implements GtkExtendedLayout?
Several factors I can think of here.
First when implementing each container, it would be nice to avoid:
if (is_extended_layout(child)) {
use new request API
} else {
use old size request API
}
One solution would be that GtkWidget automatically implements extended
layout in terms of size request. Another solution would be just a
convenience function that does the above.
Yes, it makes sense to implement GtkExtendedLayout at GtkWidget level
already. This step has quite some potential to simplify code.
I'm guessing your patch already had a solution to this, I don't remember
what it was.
Two, when implementing a widget, it would be good to avoid writing both
the old size request and the new extended layout. So, one way to do that
is that in GtkWidget there's a default implementation of size request
that invokes extended layout. This may require GtkWidget to implement
extended layout, or maybe the default impl of size request could do
GTK_IS_EXTENDED_LAYOUT(), that might be fine too. Then GtkWidget would
not have to implement extended layout.
The solution I used, was adding a flag, respectively a callback to the
old size_request method indicating the operation mode (minimum
size/natural size). My size_request implementation called that now
internal function with minimum-size arguments, the natural_size
implementation called with natural-size arguments.
Ugly, compared to the smart choice of fallback behavior you suggest.
I'll modify my patches, so that all containers directly use the extended
layout interface, without any if/else mambo for child measurement.
Third, since implementing an interface requires extra boilerplate
GObject stuff, it would be convenient for authors of a custom widget if
GtkWidget already did the boilerplate for them. Since for newly-written
custom widgets, the recommendation would be to always support extended
layout.
I don't see the boilerplate savings you talk about? As far as I
understand GObject interfaces, you always need this this single-line
boilerplate for overriding interface methods:
G_DEFINE_TYPE_WITH_CODE (MamanBar, maman, GTK_TYPE_WIDGET,
G_IMPLEMENT_INTERFACE (GTK_TYPE_IFACE, maman_bar_iface_init))
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Extended Layout and Size Groups
Seems GtkSizeGroup has to be modified to cache and modify natural sizes.
See attached picture for details.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
inline: extended-layout-and-size-groups.png#include gtk/gtk.h
#include math.h
static void
size_group_toggled_cb (GtkToggleButton *button,
GtkSizeGroup*group)
{
if (gtk_toggle_button_get_active (button))
gtk_size_group_set_mode (group, GTK_SIZE_GROUP_HORIZONTAL);
else
gtk_size_group_set_mode (group, GTK_SIZE_GROUP_NONE);
}
static void
ellipsize_toggled_cb (GtkToggleButton *button,
GtkWidget *vbox)
{
GList *rows, *cells, *iter;
PangoEllipsizeMode mode;
if (gtk_toggle_button_get_active (button))
mode = PANGO_ELLIPSIZE_END;
else
mode = PANGO_ELLIPSIZE_NONE;
rows = gtk_container_get_children (GTK_CONTAINER (vbox));
for (iter = rows; iter; iter = iter-next)
{
if (!GTK_IS_CONTAINER (iter-data))
break;
cells = gtk_container_get_children (iter-data);
if (cells GTK_IS_LABEL (cells-data))
gtk_label_set_ellipsize (cells-data, mode);
g_list_free (cells);
}
g_list_free (rows);
}
int
main (int argc,
char *argv[])
{
GtkWidget *window, *vbox, *button;
GtkSizeGroup *groups[2];
gint x, y;
gtk_init (argc, argv);
for (x = 0; x G_N_ELEMENTS (groups); ++x)
groups[x] = gtk_size_group_new (GTK_SIZE_GROUP_NONE);
vbox = gtk_vbox_new (FALSE, 6);
gtk_container_set_border_width (GTK_CONTAINER (vbox), 6);
for (y = 0; y 4; ++y)
{
GtkWidget *hbox = gtk_hbox_new (FALSE, 6);
for (x = 0; x 2; ++x)
{
gchar *text = g_strdup_printf (Label #%.0f.%d, pow(10, y), x + 1);
GtkWidget *label = gtk_label_new (text);
g_free (text);
if (!x)
gtk_label_set_ellipsize (GTK_LABEL (label), PANGO_ELLIPSIZE_END);
else
gtk_box_pack_start (GTK_BOX (hbox), gtk_vseparator_new (), FALSE, TRUE, 0);
gtk_box_pack_start (GTK_BOX (hbox), label, 1 == x, TRUE, 0);
gtk_size_group_add_widget (groups[x], label);
}
gtk_box_pack_start (GTK_BOX (vbox), hbox, FALSE, TRUE, 0);
}
gtk_box_pack_start (GTK_BOX (vbox), gtk_hseparator_new (), FALSE, TRUE, 0);
for (x = 0; x G_N_ELEMENTS (groups); ++x)
{
gchar *text = g_strdup_printf (Size Group #%d, x + 1);
button = gtk_check_button_new_with_label (text);
gtk_box_pack_start (GTK_BOX (vbox), button, FALSE, TRUE, 0);
g_free (text);
g_signal_connect (button, toggled, G_CALLBACK (size_group_toggled_cb), groups[x]);
}
button = gtk_check_button_new_with_label (Ellipsize);
gtk_box_pack_start (GTK_BOX (vbox), button, FALSE, TRUE, 0);
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (button), TRUE);
g_signal_connect (button, toggled,
G_CALLBACK (ellipsize_toggled_cb),
vbox);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_container_add (GTK_CONTAINER (window), vbox);
gtk_widget_show_all (window);
g_signal_connect (window, destroy,
G_CALLBACK (gtk_main_quit),
NULL);
gtk_main ();
return 0;
}
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington:
What if the API for GTK+ were something like the above, plus a
width-for-height variant, so rename the above two:
get_desired_width(int*,int*)
get_desired_height_for_width(int,int*,int*)
and add:
get_desired_height(int*,int*)
get_desired_width_for_height(int,int*,int*)
Then the following default implementations:
- all four of the new functions have default implementations that
invoke the current size_request and use it for both min and natural
size; so unmodified widgets still support the new interface
- the default implementation of size_request
(gtk_widget_real_size_request) is modified to do something like
You mean do_size_request() in gtksizegroup.c, don't you?
gtk_widget_real_size_request just returns cached data since size groups
were introduced.
if (widget has height-for-width feature) {
get_desired_width(widget, min_width, NULL);
get_desired_height_for_width(widget, min_width, min_height,
NULL);
This API would require to calculate the size of GtkLabel for at least
three times:
1) get_desired_width
2) get_desired_height_for_width with min_width
3a) get_desired_height_for_width with allocated width of the
parent in vertically aligned containers like GtkVBox
3b) get_desired_width_for_height with allocated height of the
parent in horizontally aligned containers like GtkHBox
Why is it sensible to calculate the size three times?
Wouldn't it be better to replace size_request with
void get_desired_size (GtkRequisition *minimum,
GtkRequisition *natural);
Your get_desired_height_for_width and get_desired_width_for_height
functions would keep the signature you suggested (expect that I'd drop
the word desired).
I cannot imagine situations, where you are without size restrictions,
but cannot trivially retrieve the other dimensions of a desired size.
So we really should calculate both dimension in one single step.
The point is, in newly-written widgets ideally there is no need to code
the now-deprecated size_request; and also for most widgets hopefully no
need to implement width-for-height since that's something of a strange case.
How to react when a library user adds a handler to size-request signal
of a modern widget? Simply ignore it? Would be quite nasty if each
implementation of get_desired_size would have to emit and handle that
signal.
That's a bit tricky for GTK since there's legacy gunk in the way, but I
think it's the ideal.
That comment was directed to the padding stuff, we do not discuss right
now. Nevertheless it's also right for the new size request. Specially
since size groups were hacked in at some point in history. That's why
I've chosen the less ambitious way of adding a simple get_natural_size
method: Less interaction with legacy code.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gfvs] cdda backend
So, I thought some more about the content type guessing. The current code allows you to read files from all sorts of backends, and enumerate the various places you can read from (volume monitor), if you add to this a content type and a way to get at the lowlevel identifiers for the volumes (so that you can optionally map them to other libraries and get more details) this is quite powerful for many apps. However, I'm not sure its the right place the actual content type guessing API. Lets take a step back and consider the whole desktop. Any time you mount something you want to guess the content on that so that you can spawn the default operation. Another user of the content type would be the f-spot photo import dialog, which would default to only show photo type devices and mounts. However, at this points its not ideal to have to start sniffing all the mounts before bringing up the dialog, as that is kinda slow. So, it seems to me, that the ideal approach is to sniff content types each time something is mounted, and to remember that for further (cross-process) use. And a good place to put the sniffing would be where the open default content action guessing happens. I'm not sure where/how to store this though, as its a per-session thing really (some mounts are session local, and session settings might affect the results), and hal is system wide. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
