GtkTreeView save/resotre expanded state
Hello All GtkTreeView expanded state for all rows saved to file. Next time when appilcation start expanded state restored using gtk_tree_view_expand_row function. But there a problem: this function works only for first row, other rows not expanded. When I add some time wait function (i use g_debug) - all works fine. Whats a problem? Thanks! Sorry for my bad English -- Dubravin Andrey ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
problem related to _gtk_marshal_BOOLEAN__BOXED
hi Actually this is a apps related query but if you will see the attachment i think here is the place to ask here is a snapshot of gdb http://www.nabble.com/file/p12438057/snap1.jpg snap1.jpg i have written a simple gtk application which only loads a webpage. I have used following widgets GtkWindow-GtkVBox GtkVbox contains Gtk Entry for url display and GtkNotebook for webpage display. while the webpage is loading and i press down arrow the application terminates. please help -- View this message in context: http://www.nabble.com/problem-related-to--_gtk_marshal_BOOLEAN__BOXED-tf4363786.html#a12438057 Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
On Fri, 2007-31-08 at 13:26 +0200, Lieven van der Heide wrote:
As for the general rendering of widgets, I think the current way of
letting the widget itself do the drawing, using a bunch of primitives
(ie. boxes, frames, etc.), and then letting the theme engines theme
just those primitives, instead of the whole widget, has shown to not
really work. What most theme engines seem to be doing now, is kind of
reverse engeneer those draw calls, and then render the theming in
their own way, which often is quite different from what the widget
actually thought is was drawing.
Most of the time these are special cases as for example making certain
corners rounded, but true.
I think it would be better if each widget just has it's own, specific
rendering class, which has a single function that should render the
complete widget at once. (this way, you kind of get a model/view
seperation inside controls). Themes can then override this rendering
class, and have complete freedom inside the render function of that
rendering class.
This sounds a lot like how QT works (I have not had a very deep look
though). However I don't think that any system should require build time
linking. As desktop environments (GNOME, maemo) and/or applications will
need custom widgets.
This is a general problem that I have not brought up earlier. But I
wonder how to handle one widget that may have two different modes. An
example that is annoying me right now is the radiobutton. It can not
only be a drawn as normal radio button with an indicator, but also as a
button without an indicator (in eg. GtkRadioToolButton).
In the two different cases you may not only want to have some different
style for the radiobutton, but also for the widgets (label) inside. I
think that we either need to remove any case like this, have the
possibility to style widgets (and their children) based on properties or
need a second independent representation of the UI for theming.
Hm, I don't see a way right now to handle the connected buttons in a
button box with this approach nicely.
http://futurepast.free.fr/buttonbox.png
Each renderer should also have a default implementation, which renders
the widget in a default way, using lower level rendering classes,
which render things like edges and boxes. If a theme engine doesn't
implement a specific widget's rendering class, but it did implement
the lower level ones, then it will still be rendered using something
that fits your theme (basically in the same way it's supposed to work
now).
It should also be possible for a renderer to use the renderer of
another (more basic) widget ,for example, a treeview could use the
button renderer as the default renderer for it's column headers.
pseudo code for the default renderer of a checkbox:
class CheckBoxRenderer
{
struct Params_s
{
int state;
string label;
}
virtual void render(GdkDrawable target,Params_s params)
{
// default implementation that uses the generic renderer
GenericRenderer generic_renderer = get_renderer(GENERIC_RENDERER);
generic_renderer.render_box(target,Rect(0,0,16,16));
if(params.state)
{
generic_renderer.draw_check(target,Rect(0,0,16,16));
}
generic_renderer.draw_text(target,Point(24,0),params.label);
}
}
In this example, overriding the generic renderer class will let you do
theming in the way it's done right now, overriding the
CheckBoxRenderer will give you complete freedom over the way you want
to render the checkbox
To still be able to set up some generic theming things, that will be used by
Something missing here?
Benjamin
signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
Why not use the most obvious solution for the problem: Keep the theming engine as is, but instead of using one single theming detail string, let's attach a theming class property in the spirit of CSS class names to widgets: const gchar** gtk_widget_get_style_classes (GtkWidget *widget); gboolean gtk_widget_has_style_class (GtkWidget *widget, const gchar *class_name); Well, or for optimal speed let's use GQuarks instead: const GQuark* gtk_widget_get_style_classes (GtkWidget *widget); gboolean gtk_widget_has_style_class (GtkWidget *widget, GQuark class_name); Now let's add the rule, that widgets have to provide a macro for each style class they define, and we even get some easy way to document style classes: #define GTK_STYLE_CLASS_TREE_VIEW_COLUMN_BUTTON \ gtk_style_class_tree_view_column_button_get_quark () You might argue defining quarks for this purpose is quite some effort, but Bugzilla and libegg contain the implementation of a G_DEFINE_QUARK, respectively EGG_DEFINE_QUARK marco declaring *_get_quark functions: G_DEFINE_QUARK (GtkStyleClassTreeViewColumnButton, gtk_style_class_tree_view_column_button); This approach might not be a big and final solution, but its an approach that can be implemented right now without breaking much stuff. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] 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: GTK+ Theming improvements
On Sat, 2007-01-09 at 16:32 +0200, Mathias Hasselmann wrote: Why not use the most obvious solution for the problem: Keep the theming engine as is, but instead of using one single theming detail string, let's attach a theming class property in the spirit of CSS class names to widgets: const gchar** gtk_widget_get_style_classes (GtkWidget *widget); gboolean gtk_widget_has_style_class (GtkWidget *widget, const gchar *class_name); Well, or for optimal speed let's use GQuarks instead: const GQuark* gtk_widget_get_style_classes (GtkWidget *widget); gboolean gtk_widget_has_style_class (GtkWidget *widget, GQuark class_name); Now let's add the rule, that widgets have to provide a macro for each style class they define, and we even get some easy way to document style classes: #define GTK_STYLE_CLASS_TREE_VIEW_COLUMN_BUTTON \ gtk_style_class_tree_view_column_button_get_quark () You might argue defining quarks for this purpose is quite some effort, but Bugzilla and libegg contain the implementation of a G_DEFINE_QUARK, respectively EGG_DEFINE_QUARK marco declaring *_get_quark functions: G_DEFINE_QUARK (GtkStyleClassTreeViewColumnButton, gtk_style_class_tree_view_column_button); This approach might not be a big and final solution, but its an approach that can be implemented right now without breaking much stuff. OK, this might solve some of the problems. But I see it much more important to have the possibility of matching against these classes in the gtkrc instead of an API for the engine to query them. Also I think that applications need to be able to add attach their own classes to a widget or removing ones that area already there. This is useful in server cases: * GtkComboBox can modify its classes to show if it is in appears-as-list mode (it could be using an comboboxentry class because it has a visible entry then). * Custom widgets may want to look like eg. comboboxes, or fake treeview headers. Adding classes is important for this. In my opinion it is very important that any implementation like this would right away have a complete set of classes. This is important as theming is already a complex issue with a large set of special cases and quirks, and adding more API will not make this better in the long run. This of course does not (and cannot) address issues like: * More complex layout support (eg. in the sugar theme widgets should be aligned to a 15px grid most of the time.) * Resolution independence * For example notebook corner rounding (bug #457087). (Corners should be rounded depending on the position of tabs) Btw. I don't only want to discuss what can we do now to improve the current situation in the 2.x cycle, but also how should theming could look like in GTK+ 3.x. Both discussions are important though. Benjamin signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: problem related to _gtk_marshal_BOOLEAN__BOXED
On Sep 1, 2007, at 3:17 AM, varun_shrivastava wrote: Actually this is a apps related query but if you will see the attachment i think here is the place to ask Please go to gtk-app-devel-list. This list is for development of gtk itself. here is a snapshot of gdb http://www.nabble.com/file/p12438057/snap1.jpg snap1.jpg HTTP ERROR: 410 This file has been deleted. -- One, two, free, four, five, six, sebben, eight, nine, ten, elebben, twull, fourteen, sickteen, sebbenteen, eightteen, elebbenteen, fiffeen, elebbenteen! -- Zella, aged three, counting to twenty. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
New style tooltips - persistance
Hi list I've noticed that one of the differences between the old- and new-style tooltips is that the new ones don't disappear as soon as you move the mouse - they hang around for as long as your mouse stays in the widget's area. I think for large widgets this really causes a problem, as the only way to get them to disappear is by touching them with your mouse. It feels like a game of Whac-a-mole sometimes! Is this by design? I'm not sure if I find it annoying or not. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
