Re: gtk_widget_set_size_request delayed until next allocation change
On 04/27/13 02:35, Sandro Mani wrote:
Hello,
I have a GtkDrawingArea inside a GtkViewport, and I have a callback
connected to the size-allocate signal of the GtkViewport which resizes
the GtkDrawingArea by calling gtk_widget_set_size_request on the latter,
see sample source code below.
I however notice that the GtkDrawingArea allocates the requested size
only the _next_ time the allocation of the GtkViewport changes, and
hence the allocation of the GtkDrawingArea is the one requested for the
previous allocation of the GtkViewport.
The issue is best visible when maximizing and unmaximizing the window:
when maximizing, the size of the GtkDrawingArea is still the one for the
unmaximized state, and when unmaximizing again, the size of the
GtkDrawingArea is the one for the maximized state.
Question: Is this a mistake in my code or a Gtk bug? I'm using
gtk3-3.8.1-1.fc20.x86_64
Seems you could fix it by setting GTK_RESIZE_IMMEDIATE as resize mode on
the viewport, although it seems to be deprecated.
I'm not sure what's the proper/recommended way to go it instead, but
instead of calling gtk_widget_queue_resize() and the
gtk_main_iteration() loop in resize_drawarea() you could call
gtk_container_resize_children() (on the viewport).
Although, since it triggers a new size-allocate, it might be a good idea
to block your handler to avoid it getting triggered again.
-j
Thanks for any inputs.
Sandro
-- Sample code: --
// gcc alloc.c -o alloc $(pkg-config --cflags --libs gtk+-3.0)
#include gtk/gtk.h
#include stdio.h
void resize_drawarea (GtkWidget* viewport, GdkRectangle* rect, gpointer
data)
{
gtk_widget_set_size_request (GTK_WIDGET (data), rect-width / 2,
rect-height / 2);
gtk_widget_queue_resize (GTK_WIDGET (data));
printf(set_size_request(%d, %d)\n, rect-width /2, rect-height / 2);
// Wait for size_request
while (gtk_events_pending ()) {
gtk_main_iteration ();
}
int w = gtk_widget_get_allocated_width (GTK_WIDGET (data));
int h = gtk_widget_get_allocated_height (GTK_WIDGET (data));
printf(allocation = %d x %d\n\n, w, h);
}
int main(int argc, char* argv[])
{
gtk_init (argc, argv);
GtkWidget* window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
GtkWidget* viewport = gtk_viewport_new (NULL, NULL);
GtkWidget* drawarea = gtk_drawing_area_new ();
gtk_container_add (GTK_CONTAINER (window), viewport);
gtk_container_add (GTK_CONTAINER (viewport), drawarea);
gtk_widget_set_halign (drawarea, GTK_ALIGN_CENTER);
gtk_widget_set_valign (drawarea, GTK_ALIGN_CENTER);
GdkRGBA black = {0., 0., 0., 1.};
gtk_widget_override_background_color (drawarea, GTK_STATE_FLAG_NORMAL,
black);
gtk_window_set_default_size (GTK_WINDOW (window), 640, 480);
g_signal_connect (window, destroy, G_CALLBACK (gtk_main_quit), NULL);
g_signal_connect (viewport, size-allocate, G_CALLBACK
(resize_drawarea), drawarea);
gtk_widget_show_all (window);
gtk_main ();
return 0;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: 3.8 toplevel resize bug?
On 04/02/13 18:36, HMRG software wrote:
Hi all,
Following is demo code for the 3.8 toplevel window resize bug I described
in the previous message on this thread. If anyone sees any errors on my
part, please let me know. I will otherwise file a bug report on this shortly.
I believe there's already one:
https://bugzilla.gnome.org/show_bug.cgi?id=696882
I've also proposed a patch there, which should fix the issue.
-j
The code displays a small main window with one button. Click it. This
causes a second small window to appear, also with one button. Click that to
hide the second window (or click the latter's titlebar window manager window
delete button if any). Then re-click the button in the first window to
re-show the second window. The latter reappears, but at a munged size.
Absolutely nothing was done within my code here to the second window or
its children between the hide and the re-show. My test platform is 64-bit
CentOS 6.4, using all the latest/greatest gtk-related packages other than
pango (still at 1.32.4 because later versions do not build for me ;-( ).
The munged resize demonstrated here does not occur under 3.6.2.
Thanks!
Roger Davis
Univ. of Hawaii
/** begin code /
#include stdio.h
#include stdlib.h
#include gtk/gtk.h
GtkWidget *mainwin, *rszwin;
void
errexit(char *msg)
{
(void) fprintf(stderr, %s\n, msg);
exit(-1);
}
gboolean
windelproc(GtkWidget *w, GdkEvent *evt, gpointer gp)
{
if (w == mainwin) {
exit(0);
return TRUE;
}
else if (w == rszwin) {
gtk_widget_hide(rszwin);
return TRUE;
}
return FALSE;
}
void
mainopenproc(GtkWidget *w, gpointer gp)
{
gtk_widget_show(rszwin);
return;
}
void
rszcloseproc(GtkWidget *w, gpointer gp)
{
gtk_widget_hide(rszwin);
return;
}
void
mktoplevelwin(GtkWidget **tlwin, GtkWidget **scrwin, GtkWidget **layout)
{
GtkRequisition grq;
*tlwin= *scrwin= *layout= (GtkWidget *) 0;
if ((*tlwin= gtk_window_new(GTK_WINDOW_TOPLEVEL)) == (GtkWidget *) 0)
errexit(Toplevel window creation error.);
if ((*scrwin= gtk_scrolled_window_new(NULL, NULL)) == (GtkWidget *) 0)
errexit(Scrolled window window creation error.);
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(*scrwin),
GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC);
gtk_container_add(GTK_CONTAINER(*tlwin), *scrwin);
if ((*layout= gtk_layout_new((GtkAdjustment *) NULL, (GtkAdjustment *)
NULL)) == (GtkWidget *) 0)
errexit(Layout creation error.);
gtk_container_add(GTK_CONTAINER(*scrwin), *layout);
return;
}
void
mkbutton(GtkWidget **b, GtkRequisition *gr, GtkWidget *parent, gint x, gint
y, char *label, void (*proc)())
{
*b= (GtkWidget *) 0;
if ((*b= gtk_button_new_with_label(label)) == (GtkWidget *) 0)
errexit(Button creation error.);
g_signal_connect(*b, clicked, G_CALLBACK(proc), *b);
gtk_layout_put(GTK_LAYOUT(parent), *b, x, y);
gtk_widget_show_all(*b);
gtk_widget_get_preferred_size(*b, gr, NULL);
return;
}
gint
main(gint argc, gchar *argv[])
{
GtkWidget *sw, *lo, *b;
gint w, h;
GtkRequisition grq;
GdkGeometry geom;
if (gtk_init_check(argc, argv) == FALSE)
errexit(GTK+ initialization error.);
mktoplevelwin(mainwin, sw, lo);
g_signal_connect(mainwin, delete-event, G_CALLBACK(windelproc),
(gpointer) mainwin);
mkbutton(b, grq, lo, 100, 100, Open Resize Test Window,
mainopenproc);
w= 100+grq.width+100;
h= 100+grq.height+100;
gtk_window_set_default_size(GTK_WINDOW(mainwin), w, h);
gtk_layout_set_size(GTK_LAYOUT(lo), w, h);
geom.max_width= w;
geom.max_height= h;
gtk_window_set_geometry_hints(GTK_WINDOW(mainwin), NULL, geom,
GDK_HINT_MAX_SIZE);
gtk_widget_show_all(sw);
mktoplevelwin(rszwin, sw, lo);
g_signal_connect(rszwin, delete-event, G_CALLBACK(windelproc),
(gpointer) rszwin);
mkbutton(b, grq, lo, 100, 100, Close This Window, rszcloseproc);
w= 100+grq.width+100;
h= 100+grq.height+100;
gtk_window_set_default_size(GTK_WINDOW(rszwin), w, h);
gtk_layout_set_size(GTK_LAYOUT(lo), w, h);
geom.max_width= w;
geom.max_height= h;
gtk_window_set_geometry_hints(GTK_WINDOW(rszwin), NULL, geom,
GDK_HINT_MAX_SIZE);
gtk_widget_show_all(sw);
gtk_widget_show(mainwin);
gtk_main();
return 0;
}
/** end code /
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing
Re: multiple GTKentry inside a GTKnotebook
On 06/19/12 21:43, Rudra Banerjee wrote: Yeti, Thanks for your help. That is working now. I have one more problem. I need to take the data from the combo box. So after the combo box, I added the line: gchar *bibtype = gtk_combo_box_get_active_text(GTK_COMBO_BOX(widget)); fprintf(stdout, %s, bibtype); So, that part looks like combo = gtk_combo_box_new_text(); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), Book); gtk_combo_box_append_text(GTK_COMBO_BOX(combo), Article); gtk_box_pack_start(GTK_BOX(vbox), combo, TRUE, TRUE, 0); gtk_widget_show(combo); gchar *bibtype = gtk_combo_box_get_active_text (GTK_COMBO_BOX(widget)); it should probably be GTK_COMBO_BOX(combo), not GTK_COMBO_BOX(widget) fprintf(stdout, %s, bibtype); which is giving error. I am trying hard via tutorials in web from yesterday. Please help. On Mon, 2012-06-18 at 20:35 +0200, David Nečas wrote: On Mon, Jun 18, 2012 at 11:28:48PM +0530, Rudra Banerjee wrote: pasted is a minimal layout of my trial to create a bibliography maker. The problem is, in Authors tab inside notebook, I want to edit 3 more entry, as Editor an example. But its taking only the first entry. Please show me where I am making the error. GtkFrame is a GtkBin which means it can contain a single widget. If you want more you need to use packing container (GtkTable, GtkVBox, GtkGrid, ...), put it to the frame and then pack widgets to this contaner. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: desktop integration: program launcher entry and icon
I believe you might want to include a .desktop file (installing it in e.g. /usr/share/applications/), and it should be used by all compatible DE-s. You can use whatever files you have there as examples, and the latest specs should be these: http://standards.freedesktop.org/desktop-entry-spec/latest/ -j On 04/06/12 01:14, Christopher Howard wrote: This is not strictly speaking a gtk+ question, but I was hoping someone might help me out anyway: how do I go about integrating my application properly with the desktop, i.e., so that my program shows up with an entry and an icon in the application menu of Gnome, Xfce4, and all other compatible desktop environments? If anyone could point me to a good Web page on the subject, I would be appreciative. I can't seem to get the right search results for this question. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problem destroying selection-list window
Hi,
I'm guessing this is because you try to destroy the window while it's
still being used by GTK (to process signals, etc).
One solution could be to only hide it instead, and destroy it later on.
(For instance you could destroy it on a handler attached to unmap-event.)
-j
On 02/27/2012 10:45 AM, Evonia Perrez wrote:
hi,
i created a selection-list that pops up when a user presses a button in the
main window.
Everything works fine until i try to destroy the selection-window after the
user clicks an item from the list. If i do not try to destroy the window,
the program does not crash, but the selection-window stays up and the user
must force it closed from the window's tab [x]. i would like the
selection-list to disappear automatically after the user picks an item,
since many programs work this way.
I condensed an example in the following program:
//-
#include gtk/gtk.h
GtkWidget *outer_window, *popupselector;
int selected;
void select_item( GtkWidget *wdg, gpointer data )
{
GtkTreeIter iter;
GtkTreeModel *model;
char *text;
if (gtk_tree_selection_get_selected( (GtkTreeSelection *)wdg, model,
iter))
gtk_tree_model_get(model, iter, 0, text, -1);
else
return;
printf(User selected '%s'.\n, text );
selected++;
if (selected == 2)// Commenting out
these two lines prevents
gtk_widget_destroy( popupselector ); // program from crashing but
selection-list stays up.
}
void select_button( GtkWidget *widget, gpointer data )
{
GtkWidget *panel, *bpanel, *scroll_window, *tree;
GtkTreeStore *list;
GtkCellRenderer *renderer;
GtkTreeViewColumn *column;
GtkTreeSelection *select;
GtkTreeIter iter;
/* Create a window for the selection-list. */
popupselector = gtk_window_new( GTK_WINDOW_TOPLEVEL );
gtk_widget_set_size_request( popupselector, 200, 200 );
gtk_window_set_transient_for( GTK_WINDOW( popupselector ), GTK_WINDOW(
outer_window ) );
gtk_window_set_position( GTK_WINDOW( popupselector ),
GTK_WIN_POS_CENTER_ON_PARENT );
gtk_window_set_title( GTK_WINDOW( popupselector ), Selection Items );
panel = gtk_fixed_new();
gtk_container_add( GTK_CONTAINER( popupselector ), panel );
/* Add the list widget to the window. */
list = gtk_tree_store_new( 1, G_TYPE_STRING );
bpanel = gtk_fixed_new();
gtk_fixed_put( GTK_FIXED( panel ), bpanel, 2, 2 );
gtk_widget_set_size_request( bpanel, 150, 150 );
scroll_window = gtk_scrolled_window_new( NULL, NULL );
gtk_scrolled_window_set_policy( GTK_SCROLLED_WINDOW( scroll_window ),
GTK_POLICY_AUTOMATIC, GTK_POLICY_ALWAYS );
gtk_widget_set_size_request( scroll_window, 150, 150 );
gtk_container_add( GTK_CONTAINER( bpanel ), scroll_window );
tree = gtk_tree_view_new_with_model( GTK_TREE_MODEL( list ) );
renderer = gtk_cell_renderer_text_new();
column = gtk_tree_view_column_new_with_attributes( Selection Items,
renderer, text, 0, NULL );
gtk_tree_view_append_column( GTK_TREE_VIEW(tree), column );
gtk_container_add( GTK_CONTAINER( scroll_window ), tree );
select = gtk_tree_view_get_selection( GTK_TREE_VIEW(tree) );
gtk_tree_selection_set_mode( select, GTK_SELECTION_SINGLE );
g_signal_connect( G_OBJECT(select), changed, G_CALLBACK( select_item), 0
);
gtk_tree_store_append( list, iter, 0 ); /* Add item to the list. */
gtk_tree_store_set( list, iter, 0, Oranges, -1 );
gtk_tree_store_append( list, iter, 0 ); /* Add item to the list. */
gtk_tree_store_set( list, iter, 0, Apples, -1 );
gtk_tree_store_append( list, iter, 0 ); /* Add item to the list. */
gtk_tree_store_set( list, iter, 0, Pairs, -1 );
selected = 0;
gtk_widget_show_all( popupselector );
}
int main( int argc, char *argv[] )
{
GtkWidget *panel, *bpanel, *button;
gtk_init( argc, argv ); /* Create a window. */
outer_window = gtk_window_new( GTK_WINDOW_TOPLEVEL );
gtk_widget_set_size_request( outer_window, 150, 150 );
gtk_window_set_title( GTK_WINDOW( outer_window ), Test);
gtk_window_set_position( GTK_WINDOW( outer_window ), GTK_WIN_POS_CENTER );
panel = gtk_fixed_new();
gtk_container_add( GTK_CONTAINER( outer_window ), panel );
bpanel = gtk_fixed_new(); /* Add a button to bring up the
selection-list window. */
gtk_fixed_put( GTK_FIXED( panel ), bpanel, 20, 20 );
button = gtk_button_new_with_label( Select Items);
gtk_signal_connect( GTK_OBJECT(button), clicked, GTK_SIGNAL_FUNC(
select_button ), 0 );
gtk_container_add( GTK_CONTAINER( bpanel ), button );
gtk_widget_show_all( outer_window );
gtk_main();
return 0;
}
--
Note that I added the global counter selected so that the destroy is
attempted on the second call to the callback, since it gets called once
immediately when the list-window is created.
The second call happens when
Re: [GTK3] GtkEntry, why focus-in-event does not work ?
On 02/23/2012 02:49 PM, Gilles DOFFE wrote:
Hello,
Below a simple application with a GtkButton and a GtkEntry.
Two callbacks associated to this widgets following this rules :
1) When I click on the GtkButton, it should display the GtkEntry pointer
value.
2) When I focus on the GtkEntry, it should display the GtkButton pointer
value.
Case 1) works perfectly but case 2) always give a different value for the
GtkButton pointer ?!
Did i miss something ?
That the signature for focus-in-event isn't the same[1], and that second
parameter you use in your printf is a pointer to the GdkEvent, not your
user_data (Also, this callback should return a gboolean value).
-j
[1]
http://developer.gnome.org/gtk/stable/GtkWidget.html#GtkWidget-focus-in-event
Thanks,
Gilles
#include gtk/gtk.h
void
onEntryFocusIn(GtkWidget *entry, gpointer pData)
{
printf(pData = %p\n, (GtkWidget *)pData);
}
int main(int argc, char **argv)
{
GtkWidget *pWindow = NULL;
GtkWidget *pButton = NULL;
GtkWidget *pEntry = NULL;
GtkWidget *pHbx = NULL;
gtk_init(NULL, NULL);
pWindow = gtk_window_new(GTK_WINDOW_TOPLEVEL);
pButton = gtk_button_new();
pEntry = gtk_entry_new();
pHbx = gtk_hbox_new(FALSE, FALSE);
gtk_box_pack_start(GTK_BOX(pHbx), GTK_WIDGET(pButton), FALSE, FALSE, 0);
gtk_box_pack_start(GTK_BOX(pHbx), GTK_WIDGET(pEntry), FALSE, FALSE, 0);
gtk_container_add(pWindow, pHbx);
g_signal_connect(G_OBJECT(pWindow), destroy, (GCallback)
gtk_main_quit, NULL);
/* THIS WORKS : */
g_signal_connect(G_OBJECT(pButton), clicked, (GCallback)
onEntryFocusIn, (gpointer)pEntry);
/* THIS DOES NOT WORK : */
g_signal_connect(G_OBJECT(pEntry), focus-in-event, (GCallback)
onEntryFocusIn, (gpointer)pButton);
gtk_widget_show_all(pWindow);
printf(pEntry = %p\n, pEntry);
printf(pButton = %p\n, pButton);
gtk_main();
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to extend a widget?
Thanks. I will have a look into Vala, although for projects I have planned, I really want/need to be using C. And while GTK is oriented-object, it is written in C and, AFAIK, there are no such things as classes in C? I believe the way to create a widget based on/extending another one is how I have done so far (based on the docs /tutorials I read), only I'm not sure how to properly do things like overriding functions to change behaviors or add features. If Vala allows to do that easily and does produce C code though, I might try and see how it does/what code it produces, but I'm not sure learning a new language is something I wanna get into right now... -jacky On 12/16/2011 07:05 PM, Michael Torrie wrote: On 12/16/2011 08:16 AM, jacky wrote: As I said, I'm not sure this is the right way to do such a thing, so I would appreciate any help/information on how one would do this properly. Since GTK is object oriented, you could just create a new class that inherits from GtkCalender. However this is C we're using, so it's not quite as simple as in C++, Java, or Python. If I recall correctly, you'll end up with 3 files. 2 .C files and 1 .H One C file will contain the klass and vtable initialization stuff, one .C file of your implementation, and one .H file with your public interfaces, cast macros, and so forth. At one time GTK people were using a tool called gob to compile a single file of some object-oriented C-like syntax into these files. Seems to me, though, that you'd be well-served in doing this in Vala. Vala itself defines a C-like (more C#-like) language that compiles into C and GObject code. You can take the output of Vala and use it in your normal C development. In fact the job you describe is just what Vala was originally designed for, though Vala has gone far beyond just being a GObject compiler. Michael. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to extend a widget?
Right, thanks. Alright so using extend might not have been the right term (probably comes because I've done some PHP and have been influenced by that), sorry. Oh, and I've used the term composite widget simply because I read it here, and assumed it was how such widgets were called: http://developer.gnome.org/gtk-tutorial/stable/x2200.html Anyways, I don't have a problem with creating a new (shell/composite) widget using another one inside of it, it's actually exactly what I did in my example: created a widget JjkCalendar which contains a GtkCalendar. It's just that I felt (from tutorials and such I read) that such (composite) widgets were only using widgets they contain and combining them together, rather than modifying their behaviors. I guess my question is more: how do I affect this widget's internal behavior? how do I add a new feature (which might imply alter current way to draw the widget) ? That is, do something not really supported/planned by the widget's public API. Like I said, in the example code I posted, in order to do that, and alter GtkCalendar's behavior, I needed to redefine GtkCalendarPrivate in my widget, so that I could change values contained the GtkCalendar's private struct. Also had to copy/paste a few functions as well -- is that okay, or will it lead to problems? And if so, what's the right way to do it then? -jacky On 12/16/2011 11:03 PM, Michael Cronenworth wrote: jacky wrote: What I was looking into would be more taking an existing widget, and modifying it a little, as in changing its behavior on some aspect, or adding a feature, something like that. My question is: what would be the best/standard/recommanded way to do such a thing? Widgets are not plugins. They are whole objects. There is no extensible feature to them. You will have two choices: 1. Copy an entire GTK widget and give it a unique name. Example: GtkButton becomes GtkMyButton 2. Create a shell widget that uses existing GTK widgets inside of it to do what you want. In the event you need to touch the GTK widgets inside, you can make your new widget a simple struct and have pointers to the interior GTK widgets. I would suggest number 2, unless you are doing something very radical. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to extend a widget?
Thanks, I do need to do some more reading on the gobject docs, great stuff there. What I'm looking for is inheritance, and I see how it could be done yes. However, that would require the original widget to be done using virtual public methods, and I'm afraid this isn't the case unfortunately... -j On 12/17/2011 12:21 AM, Michael Torrie wrote: On 12/16/2011 02:52 PM, jjacky wrote: And while GTK is oriented-object, it is written in C and, AFAIK, there are no such things as classes in C? As always, read the docs. Here is the documentation describing how to create new GObjects, and inherit from existing ones, implement virtual methods, etc. So if you find that you really do need to make your own subclass of the GtkCalendar you can easily do it, though as the other poster talks about, a composite widget might be the ticket too. Just remember how relationships in OOP work: The is a relationship means inheritance. the has a relationship means composite widgets. If your widget simply has a calender, then the composite widget is the way to go. If it actually is a calendar, albeit a special one, inheritance is the way to go. http://developer.gnome.org/gobject/stable/ The GOB thing I was referring to earlier: http://www.jirka.org/gob.html a specific example of using gob to extend GtkButton: http://www.jirka.org/gtk-button-count.gob.html The GOB examples you should be able to compile to straight C and use that boilerplate to implement your own pure-C extension of GtkCalendar. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to extend a widget?
Alright, I think I'm starting to see things a little better now - thank you all. I believe, in the case of GtkCalendar, there are no virtual public methods, only static/private ones, and most of them use other such methods as well as the private structure, which is why creating a widget extending it isn't all that possible. Therefore, I think I would need to write a new widget from scratch, so based on GtkWidget and not GtkCalendar, and basically copy/paste the code from GtkCalendar into my own calendar, then applying whatever changes I want. (And I'm thinking accessing the private structure the way I did in my example is just a bad idea, which will lead to troubles as soon as the private struct changes...?) So I guess I'm gonna have to go ahead and write my own calendar widget, but inheriting from GtkWidget this time. Also means it won't be castable as GtkCalendar, but I guess that's due to how it was implemented, which unfortunately doesn't allow for it. -jacky On 12/17/2011 12:47 AM, David Nečas wrote: On Fri, Dec 16, 2011 at 04:09:54PM -0700, Michael Torrie wrote: 1. Copy an entire GTK widget and give it a unique name. Example: GtkButton becomes GtkMyButton You really could Create a GtkMyButton by inheriting from GtkButton and adding your own code. However, just as in C++, the ability to override specific methods depends on whether they were made as virtual or static methods. static methods can't be overridden, but you could just shadow them with your own methods and use them instead. I wish it was so. What invariably happens in practice is this: (a) You find that the widget implementation either provides some library-level-private _gtk_button_foo() methods or depends on such methods. This is the absolutely worst case because it can easily prevent even copying the code and creating a similarly behaving widget if it needs to use these functions. Unfortunately quite common. (b) Other code in Gtk+ calls the static methods. This means that you cannot substitute your derived widget for the base class if you need different behaviour (but you can happily use the derived widget in your own code). Apparently quite rare, possibly because the devs usually convert this to (a) by making the static method library-private. (c) To extend the virtual methods you would need to access parent widget state which is private. So you need to copy the implementation. If you do not run in to (a) or (b) then consider yourself lucky. Note I do not talk about trivial extensions such as those you posted. Could you write GtkToggleButton derived from GtkButton if it did not exist? Nope. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
