Re: gtk_widget_set_size_request stopped working with GTK3
Hi Tristan!
I suggest you start by filing an enhancement bug against GtkImage for this.
Yes, I can do that. Just to make sure, I file a new bug for component gtk,
severity set to enhancement, and put somethign like Size request of GtkImage
into the title. Is this correct?
If you have a patch to propose, here would be a good place to discuss
the proposed new apis.
I might also be able to work on this and provide a patch. Before starting on
this, how about the following changes:
Regarding size request:
We add a new property of type boolean to GtkImage. If it is set (default), the
size request for GtkImage will be the size of the underlying image (or the
pixel-size), i.e. the exact same behaviour as it is now. If it is set to FALSE
then the minimum size will be (1, 1) and an application can use width-request
and height-request for making the widget size larger. I am not sure what a
good name for this new property would be, but maybe you have a suggestion?.
Something like min-size-is-image-size would probably make the property
self-explanatory but is obviously too long compared to other existing property
names. Maybe full-image or image-size-request?
Regading placement:
In GTK2, GtkImage cropped the image such that only the center is shown, i.e. it
took off an equal amount of image content on the left and right, and top and
bottom. It probably just sets the right clipping mask when drawing the image
for achieving this. We could simply use the same policy, or we modify the
usage of GtkWidget's halign and valign properties. Currently the docs
reads:
halign GtkAlign : Read / Write
How to distribute horizontal space if widget gets extra space, see GtkAlign
enum GtkAlign
typedef enum { GTK_ALIGN_FILL, GTK_ALIGN_START, GTK_ALIGN_END, GTK_ALIGN_CENTER
} GtkAlign;
Controls how a widget deals with extra space in a single (x or y)
dimension.
Alignment only matters if the widget receives a too large allocation,
for example if you packed the widget with the expand flag inside a GtkBox,
then the widget might get extra space. If
you have for example a 16x16 icon inside a 32x32 space, the icon
could be scaled and stretched, it could be centered, or it could be
positioned to one side of the space.
Note that in horizontal context GTK_ALIGN_START and GTK_ALIGN_END are
interpreted relative to text direction.
GTK_ALIGN_FILL stretch to fill all space if possible, center if no meaningful
way to stretch
GTK_ALIGN_START snap to left or top side, leaving space on right or bottom
GTK_ALIGN_END snap to right or bottom side, leaving space on left or top
GTK_ALIGN_CENTER center natural width of widget inside the allocation
My suggestion is to make halign and valign also deal with the case where the
content of the widget is larger than the allocated space. The modified docs
would then read:
halign GtkAlign : Read / Write
How to distribute horizontal space, see GtkAlign
enum GtkAlign
typedef enum { GTK_ALIGN_FILL, GTK_ALIGN_START, GTK_ALIGN_END, GTK_ALIGN_CENTER
} GtkAlign;
Controls how a widget deals with space in a single (x or y)
dimension.
Alignment only matters if the widget receives a too large or too small
allocation,
for example if you packed the widget with the expand flag inside a GtkBox,
then the widget might get extra space. If
you have for example a 16x16 icon inside a 32x32 space, the icon
could be scaled and stretched, it could be centered, or it could be
positioned to one side of the space. Likewise, if you have a 100x100 image
inside a 20x20 space
then the image could be scaled down, only the center part of the image be
shown, or it could
be cropped to the top left or bottom right part.
Note that in horizontal context GTK_ALIGN_START and GTK_ALIGN_END are
interpreted relative to text direction.
GTK_ALIGN_FILL stretch or shrink to fill all space if possible, or center if no
meaningful way to scale
GTK_ALIGN_START snap to left or top side, leaving space or cropping widget
content on right or bottom
GTK_ALIGN_END snap to right or bottom side, leaving space or cropping widget
content on left or top
GTK_ALIGN_CENTER center widget inside the allocation
Steffen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
Hi Tristan! Lets not go around the merry-go-round one more time. In GTK+3, widgets receive *at least* what they requested in the size requesting phase. User facing apis cannot undermine the minimal requirements for the geometry which a widget has requested. User facing apis can however, enforce a minimum size (i.e. the widget will be at least this big) or they can configure a widget in such a way that it will require less size. Ok, I accept this statement. Will the docs of gtk_widget_set_size_request be updated accordingly? For GtkImage though, I think we need some way to specify the minimum size when a GdkPixbuf is used. The pixel-size thing not working for pixbufs could be considered an enhancement request bug for GtkImage. i.e. it should support clipping of pixbufs (and then, it should also need some alignment parameters to decide which portion of the input image should be clipped, also pixel-size does not really imply clipping directly, the user might very well expect the image to scale to the desired size). The docs for gtk_image_set_pixel size says: Sets the pixel size to use for named icons. If the pixel size is set to a value != -1, it is used instead of the icon size set by gtk_image_set_from_icon_name(). This is not really clear to me. Does it scale the image to the desired pixel size, or center or crop them? This should be specified in the docs. Also for a GtkImage based on a GdkPixbuf, don't we want to support different values for width and height? The pixel size only specifies one dimension. Are the icons always of a squared size? Maybe two new properties in GtkImage would do the job, say pixbuf-width-request and pixbuf-height-request. They would do the same thing as width-request and height-request in GTK2. Or, say we allow shrinking of the size in width-request and height-request but only if an additional new property size-request-enforce (boolean, default is FALSE) is set to TRUE. Regarding alignment, the halign and valign properties in GtkWidget may be useful. Although they currently are only meaningful when there is extra space, not when the content of the Widget is larger than the allocated space. a.) Create a GtkDrawingArea b.) Connect to draw signal c.) Use this code: gdk_cairo_set_source_pixbuf (cr, pixbuf, x, y); cairo_paint (cr); (borrowed directly from: Yes, that works. Thanks! Steffen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
Hi Tristan I must admit the docs are incorrect about this, it says: Sets the minimum size of a widget; that is, the widget's size request will be width by height. You can use this function to force a widget to be either larger or smaller than it normally would be. But what it should say: Sets the minimum size of a widget; that is, the widget's size request will be width by height. You can use this function to force a widget to be larger than it normally would be. Thanks for the clarification. Although, I am not convinced that restricting it to only allow enlarging the min size is desirable. If an application really wants to make a widget smaller and accepts that content may get clipped, why not allowing gtk_widget_set_size_request setting a smaller size, like it was in GTK2? In other words, as Cosimo already mentioned in the report, a widget can never be smaller than the minimum size reported by the implementation. He also mentioned that you can configure that particular widget to actually be smaller. The suggested solution was using the pixel-size property which does not do anything when using a GdkPixBuf as image. The min size of the GtkImage will be the size of the GdkPixBuf. If that one is large, so will be the GtkImage. If an application accepts image filenames typed in by a user, and thus does not know a-priori the size of an image, the GtkImage might spawn a size larger than the screen. Two other options are: o If you cant display the whole widget, put it in a scrolled window I tried that as well. When using the GTK_POLICY_NEVER scrollbar policy, the min size of the GtkScrolledWindow becomes the min size of the GtkImage. o Use clutter-gtk library to put the GtkWidget one a stage and then scale it and transform it to the desired size ;-) I would prefer not using additonal libs and don't need any scaling or transformations, just clipping and centering. Here is what I am trying to do. I have an image. The center part of the image contains a logo that I want to display to the user. Around the center part there is little extra content that is not important but nice to have. With GTK2 I set the min size (properties with-request and height-request) to just about the size of the logo, place the GtkImage into a GtkWindow, set the default size of the GtkWindow to slightly larger than the min size but smaller than the fulll size of the image, make the window resizable, and show it to the user. GtkImage in GTK2 automatically clipped the image and centered it. The user can enlarge the window and see more of the image, or shrink it down to the min size where only the logo stays visible. I have not found a way yet to achive the same with GTK3. Steffen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk_widget_set_size_request stopped working with GTK3
Hi, with GTK2 some applications used to set the minimum size of some widgets using gtk_widget_set_size_request. E.g. the min size of a GtkImage. This no longer works with GTK3 and the min size of the GtkImage is that of the underlying image, e.g. a GdkPixbuf. There is also a bug report here: https://bugzilla.gnome.org/show_bug.cgi?id=670068 Is gtk_widget_set_size_request broken? Or how is an application supposed to set (or override if the app knows better) the min size? Steffen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk_text_buffer_set_text and remember cursor/adjustments
Hi! Is there a way to set the text of a GtkTextView but also keep the cursor location and adjustments of a GtkScrolledWindow where the text view resides? I am trying to do it using the attached code but there are two problems: 1. When you scroll down, set the cursor and then press 'Reload' there is a lot of visual flickering (scrollbar and text view). 2. The adjustment is changed such that the cursor is on the last line. Any idea about how to do this properly, e.g. without any noticeable visual effect? Usecase: syntax checking/auto-correct in a programming environment (replace 'Reload' by 'Compile and update' and you get the idea). Best regards, Steffen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_text_buffer_set_text and remember cursor/adjustments
It seems the attachment got lost so I put it here in plain text:
-- Steffen
/*
** gcc -o textview textview.c -Wall `pkg-config gtk+-2.0 --cflags --libs`
*/
#include string.h
#include gtk/gtk.h
static void reload(GtkWidget *tv)
{
static char text[20];
char *s = text;
int i;
for(i=0; i 5000; i++) {
sprintf(s, %*sLine %d\n, i%20, , i);
s += strlen(s);
}
GtkTextBuffer *buffer = gtk_text_view_get_buffer(GTK_TEXT_VIEW(tv));
GtkTextMark *cursor = gtk_text_buffer_get_insert(buffer);
GtkTextIter iter;
gint offset;
gtk_text_buffer_get_iter_at_mark(buffer, iter, cursor);
offset = gtk_text_iter_get_offset(iter);
gtk_text_buffer_set_text(buffer, text, -1);
gtk_text_buffer_get_iter_at_offset(buffer, iter, offset);
gtk_text_buffer_place_cursor(buffer, iter);
gtk_text_view_scroll_mark_onscreen(GTK_TEXT_VIEW(tv),
gtk_text_buffer_get_insert(buffer));
}
int main(int argc, char **argv)
{
gtk_init(argc, argv);
GtkWidget *window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_default_size(GTK_WINDOW(window), 500, 500);
g_signal_connect(window, destroy, gtk_main_quit, NULL);
GtkWidget *vbox = gtk_vbox_new(FALSE, 0);
gtk_container_add(GTK_CONTAINER(window), vbox);
GtkWidget *sw = gtk_scrolled_window_new(NULL, NULL);
gtk_box_pack_start(GTK_BOX(vbox), sw, TRUE, TRUE, 5);
GtkWidget *tv = gtk_text_view_new();
gtk_container_add(GTK_CONTAINER(sw), tv);
GtkWidget *button = gtk_button_new_with_label(Reload);
gtk_box_pack_start(GTK_BOX(vbox), button, FALSE, TRUE, 5);
GTK_WIDGET_UNSET_FLAGS(button, GTK_CAN_FOCUS);
g_signal_connect_swapped(button, clicked, G_CALLBACK(reload), tv);
reload(tv);
gtk_widget_show_all(window);
gtk_main();
return 0;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Telling a widget not to be in the focus chain
--- [EMAIL PROTECTED] wrote: On 10/31/07, Steffen Gutmann [EMAIL PROTECTED] wrote: So, anybody has an idea what the correct way of leaving a widget out of the focus chain is? I use gtk_container_set_focus_chain() to set an exact list of widgets for a section of the focus chain. Thanks for your answer. The word 'section' in your answer gave me the right idea: I placed the widget that I want to be out of the focus chain in its own container widget and called gtk_container_set_focus_chain with NULL as second argument. This gives the desired result. Very simple and quite trivial once you find out... Cheers, Steffen __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Telling a widget not to be in the focus chain
Hi!
I would like to tell a widget to not be part of Gtk's focus chain. I
know there is gtk_container_set_focus_chain, however, I would like to
keep Gtk's default focus chain logic and just would like to have one or
two widgets not being part of it. The widget could be a GtkButton,
GtkEntry, GtkTreeView or GtkTextView, or any other user interface
element.
I tried to unset the GTK_CAN_FOCUS flag. This works nicely e.g. for
GtkButton (pressing tab jumps over the button) but when doing this on a
GtkEntry or GtkTextView it means that the widget also doesn't grab the
focus when clicking on it, thus no text input is possible any more.
I tried g_signal_connect(widget, focus, G_CALLBACK(noFocus), NULL)
where the callback is defined as:
static gboolean noFocus(GtkWidget *widget)
{
g_signal_stop_emission_by_name(widget, focus);
return FALSE;
}
This works well for GtkButtons and GtkEntries but has a small glitch
for GtkTextView and GtkTreeView. There is no focus drawn but still the
focus is 'somehow on the widget'. Pressing the tab key again then
moves on to the next widget. Not perfect.
So, anybody has an idea what the correct way of leaving a widget out of
the focus chain is?
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Programming with GTK
Consider the following macros:
#define WindowObject gtk_widget_new(GTK_TYPE_WINDOW
#define VBoxObject gtk_widget_new(GTK_TYPE_VBOX
#define HBoxObject gtk_widget_new(GTK_TYPE_HBOX
#define LabelObject gtk_widget_new(GTK_TYPE_LABEL
#define ButtonObject gtk_widget_new(GTK_TYPE_BUTTON
... // add one for each widget type
#define End NULL)
... allows to write code like this:
GtkWidget *win, *label, *ok, *cancel;
win = WindowObject,
child, VBoxObject,
child, label = LabelObject,
label, _(Hello world!),
wrap, FALSE.
End,
child, HBoxObject,
child, ok = ButtonObject,
label, _(_Ok),
use-underline, TRUE,
End,
child, cancel = ButtonObject,
label, _(_Cancel),
use-underline, TRUE,
End,
End,
End
End;
The same code, using traditional gtk coding would be:
GtkWidget *win, *label, *ok, *cancel;
GtkWidget *top, *buttons;
ok = gtk_button_new();
gtk_button_set_label(GTK_BUTTON(ok), _(_Ok));
gtk_button_set_use_underline((GTK_BUTTON(ok), TRUE);
cancel = gtk_button_new();
gtk_button_set_label(GTK_BUTTON(cancel), _(_Cancel));
gtk_button_set_use_underline(GTK_BUTTON(cancel), TRUE);
buttons = gtk_hox_new();
gtk_container_add(GTK_CONTAINER(buttons), ok);
gtk_container_add(GTK_CONTAINER(buttons), cancel);
label = gtk_label_new(_(Hello world!);
gtk_label_set_wrap(GTK_LABEL(label), FALSE);
top = gtk_vbox_new();
gtk_container_add(GTK_CONTAINER(top), label);
gtk_container_add(GTK_CONTAINER(top), buttons);
win = gtk_window_new();
gtk_container_add(GTK_CONTAINER(win), top);
What do people think about this style of writing GTK programs?
Obviously there are pros and cons. I start with the latter
- no type checking. Since the whole creation of the object tree is one
nested function call with variable number of arguments, the compiler
cannot check the types of arguments. I actually had a crash once when
I forgot to place a comma between two string constants, an attribute
followed by its value. I am wondering if there any extensions in
current C compilers that would enable type checking on vargars calls
(similar to how printf format strings and arguments are type-checked
nowadays)?
- no syntax checking of attributes. Since the code uses strings like
label there is no check (at compile-time) possible when one
accidentally misspells an attribute. A solution would be to use
defines (e.g. GTKA_LABEL instead of label).
- formatting of the calling tree has to be done by manually. In case
the structure changes, e.g. inserting another VBox somewhere, other
lines might have to be indented accordingly.
And the pros:
+ reads much better (in my opinion)
+ source code looks more compact
+ it is possible to use attributes that are not present in all versions
of GTK. E.g. xalign for GtkEntry was introduced in 2.4, thus by
checking the version of GTK at runtime, one can use or not use this
attribute:
if (gtk_minor_version = 4) {
gtk_widget_set(entry, xalign, 0.5); // center text
}
I believe that this programming style would make GTK more attractive
for developers as it looks very simple and straight forward, without
the need for various casts (GTK_WHATEVER(widget)) as in the
traditional version. However, the current implementation does not
support it really. For example if one also wants to specify packing
attributes (e.g. make the label expandable but not the button box) then
this is not currently possible. It could be done by adding new
attributes to the Box widget API though (actually I did this by writing
my own GtkGroup class).
Well, just some thoughts. I have coded a major application using this
technique and simply wanted to share my experience with you.
Best,
Steffen
PS: if this sounds familiar to you, I first saw this idea proposed in
the MUI programming toolkit in the early 90's. SunOS's OpenWindows
also had a similar approach).
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: modality, hinting to the WM, and GtkWindowGroup
Hi,I haven't followed the full discussion on this thread nor have I viewed at any of the bugs mentioned. Thus, my comment might nor be fully qualified. But, I also would like to have a dialog being modal to some but not all windows. The use case is where like in Gimp there are several top level windows, each holding an image (or more general, a project). Then, a dialog such as 'Do you really want to close this project without saving? Yes/No' should only block (be modal to) one of the top level windows.Actually I found a way to this myself by implementing the concept of 'sleep' for a GtkWindow. If a window is set to sleep it means that it shows a busy cursor when the mouse is over the window and that it does not react on any user input. This is a bit different from having a modal dialog grabbing all user input, but it comes very close. The application programmer of course has to keep track of which windows he puts to sleep
and sets back to non-sleep but with proper programming it should be straight forward. So, how about supporting a 'sleep' option for GtkWindow (gtk_window_set_sleep(GtkWindow *, gboolean sleep)).Here is a code fragment that I am using in my implementation (with slightly different function names and prototypes)// gtk_window_set_sleepstatic void guiSetWindowSleep(GtkWidget *w, bool sleep){ if (GTK_IS_WINDOW(w)) { GdkWindow *win = w-window; if (win) { guint count = GPOINTER_TO_UINT( g_object_get_data(G_OBJECT(win), "sleep")); if (sleep)
{ if (count++ == 0) { guiSetBusyCursor(win); } } else if (count != 0) { if (--count == 0) { guiClearBusyCursor(win); } } g_object_set_data(G_OBJECT(win), "sleep",
GUINT_TO_POINTER(count)); } }}static void guiSetBusyCursor(GdkWindow *win){ GdkWindow *busy = (GdkWindow *)g_object_get_data(G_OBJECT(win), "busy"); if (!busy) { // we place an input-only window over the whole top-level window // and set a busy pointer GdkWindowAttr attr; attr.event_mask = GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK | GDK_KEY_PRESS_MASK | GDK_KEY_RELEASE_MASK | GDK_ALL_EVENTS_MASK; attr.x = 0; attr.y = 0; attr.width =
G_MAXINT; attr.height = G_MAXINT; attr.wclass = GDK_INPUT_ONLY; attr.window_type = GDK_WINDOW_CHILD; attr.cursor = busyCursor; busy = gdk_window_new(win, attr, GDK_WA_X | GDK_WA_Y | GDK_WA_CURSOR); gdk_window_set_keep_above(busy, true); g_object_set_data_full(G_OBJECT(win), "busy", busy, (GDestroyNotify)gdk_window_destroy); } gdk_window_show(busy); // gdk_window_set_accept_focus(win, false);}static void guiClearBusyCursor(GdkWindow *win){ GdkWindow
*busy = (GdkWindow *)g_object_get_data(G_OBJECT(win), "busy"); if (busy) { gdk_window_hide(busy); // gdk_window_set_accept_focus(win, true); }}The variable busyCursor was set in the main function to something like this: busyCursor = gdk_cursor_new(GDK_WATCH);Unfortunately, there are some events I still have to block manually. For this I install my own event handler, so somewhere in the main function, I have this line: gdk_event_handler_set((GdkEventFunc)GuiDoEvent, 0, 0);and the event handler is here:static void GuiDoEvent(GdkEvent *event){ switch (event-type) { case GDK_DELETE: case
GDK_KEY_PRESS: case GDK_KEY_RELEASE: if (GPOINTER_TO_UINT(g_object_get_data( G_OBJECT(event-any.window), "sleep")) == 0) { gtk_main_do_event(event); } break; case GDK_CONFIGURE: case GDK_EXPOSE: gtk_main_do_event(event); if
(GPOINTER_TO_UINT(g_object_get_data( G_OBJECT(event-any.window), "sleep")) != 0) { GdkWindow *busy = (GdkWindow *)g_object_get_data( G_OBJECT(event-any.window), "busy"); if (busy) { gdk_window_raise(busy); // make sure we are on top
} } break; default: gtk_main_do_event(event); break; }}This implementation of the sleep concept is a bit of a hack but should show the idea. If something like this (in a clean way) could be made part of gtk then the application programmer could easily implement his own modal dialogs in any way he thinks is useful for his application.Regards, Steffen
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
