The proper way to integrate self-made widgets with themes
Hello list.
I asked this question a few days ago at the generic gtk list, but
unfortunately did not get much of an answer. I'll figure I would try my
luck here instead...
In the process of making a bunch of widgets I have stumbled upon this
issue: I need to paint various parts of my widget, but I would like to
make the color of the parts controlled by the theme. I.e. the properties I
want to deal with are extra, self-invented properties besides the usual
style properties. (Note: I am using PyGTK 2.12, GTK 2.10 on Arch Linux)
I have figured out how to manually load a theme-file accompanying my
application (by setting the environment variable GTK2_RC_FILES to ./gtkrc
before initializing gtk)
However I cannot insert my own property-names in such a file. The
following gives rise to a syntax error:
# My Properties
scalartrack_segment_handle_size = 5
Besides I wouldn't know how to get those properties out again so I can use
them in an expose event
So...
I am asking for the canonical way to implement new widgets and push the
choice of color, size and pixmap-overlays to the theme-designer. The
alternative is drawing with libcairo and using hardwired style properties.
Then I answered my own question in part (but not enough) with this posting:
Possible solution: Use the pixmap engine. It seems to support the detail
parameter, so I can specify many additional sections, one for each detail.
Example:
style track
{
engine pixmap
{
image
{
function = BOX
recolorable = TRUE
detail= segment
file = Extra/track-segment-type1.png
border= { 5, 5, 5, 5 }
stretch = TRUE
orientation = HORIZONTAL
}
}
}
.. This style will draw the image Extra/track-segment-type1.png when
invoked with this command (in PyGTK):
self.styleTrack.paint_box (self.window, gtk.STATE_NORMAL,
gtk.SHADOW_IN, None, None, segment, X,Y,W,H)
But still: How *should* I draw a theme'd box (using gtk_paint_box) in
colors different from what the theme has chosen for my GtkDrawingArea? Do
I have to modify_bg before each call to paint_box, and then reset it again
afterwards?
Remember that a widget can have several details which need not be in the
same color or style. It should not be necessary to make both a Knob and
Trough widget to make a scrollbar which paint two rectangles in
different colors.
Regards,
Rene Jensen, Denmark
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
weird i18n problem on Windows XP Home
I've received a strange problem report about the win32 version of my GTK app running on XP Home in Spanish on an ACER 1691 laptop (setlocale gives Spanish_Spain.1252). Window titles are managed by gettext, as in title = g_strdup(_(gretl: command script)); gtk_window_set_title(GTK_WINDOW(foo), title); so when running in Spanish some window titles will contain accented characters. For example, the above becomes gretl: gui\'on de instrucciones (represented as TeX for email purposes). The problem is that such windows are not opening, with an error of hay una secuencia de bytes no v\'alida en la entrada de conversi\'on. Many people are running the program in Spanish without this problem; there seems to be something about this XP installation that is tricking glib. Any notions what might be wrong? -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Selecting cells in threeview
Hi, On Fri, Feb 08, 2008 at 02:28:16PM +0100, Thomas Dybdahl Ahle wrote: Is there any way to select only a cell - not a row - in a gtk-treeview No, GtkTreeView does not support selecting individual cells. Selections can only contain full rows. regards, -kris. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk-can-change-accels property absent in gtk 2.8.20?
Well, I've passed in a constant string gtk_settings_set_long_property(settings, gtk-can-change-accels, TRUE, .gtkrc:0); and the code has started working - thank you very much! Richard Shann On Fri, 2008-02-08 at 00:19 +0100, Torsten Reuss wrote: On Feb 7, 2008 10:28 PM, Richard Shann [EMAIL PROTECTED] wrote: Hi Torsten, Thanks for this - curiously I get (denemo:16377): Gtk-CRITICAL **: gtk_settings_set_long_property: assertion `origin != NULL' failed with your code. Hmm, I couldn't find out what the origin parameter was good for (documentation is blank there), so I tried NULL and never had any problems with it. My gtk versions are 2.12.0 (Linux) and 2.10.11 (windows) though. Best regards, Torsten ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Disabling automatic ESC key action for GtkDialog
You may need add GTK_RESPONSE_ACCEPT or GTK_RESPONSE_REJECT parameter when create GtkDialog using gtk_dialog_new_with_buttons (). One of them is the response id from the action of press ESC key, thus you can write your handle to it accordingly. In my case, it is GTK_RESPONSE_ACCEPT. You can test it. --- Torsten Reuss [EMAIL PROTECTED] wrote: Hi, I am porting an application from gtk 1.2 to gtk 2.0 and found that there is a different behaviour for GtkDialog windows. In GTK-2.0, dialog windows automatically are closed and destroyed when the ESC key is pressed. This behaviour is incompatible with the application as most dialogs are only hidden and not destroyed when the user presses OK or Cancel. What's the easiest way to prevent this behaviour? Do I have to capture key-press-events in the Dialog window? Thanks, Torsten ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Selecting cells in threeview
Is there any way to select only a cell - not a row - in a gtk-treeview -- Best Regards, Med Venlig Hilsen, Thomas ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
Kristian Rietveld wrote: If just saving the column widths of the tree view when the tree view is destroyed is not enough, the easiest way to do this is probably to connect to the notify::width signal on each column. Remember to keep the callback fast (do not write to files, etc) as your callback will be called a lot, especially when the user is resizing columns with the mouse. The problem with your first suggestion is that I have to hook every situation in which the tree view can be destroyed. The obvious one is when I change data sets. Exiting the program is another. There will be others when I implement more of the program. It certainly is possible to record the column widths at each of these points, but it sure is clumsy. The problem with the second suggestion is that writing a file is exactly what I need to do. The point of this exercise is to record in a file the width of each column as established by the user with the mouse so that the columns will have the same width the next time the program runs. A signal seems the ideal solution and it's the one I used previously (in wxWidgets), but any other suggestions are welcome. In the meantime, I'll work on capturing the column widths at every point where the tree view can be destroyed. Designing around the lack of a signal keeps getting harder. It is not sufficient to save the column widths everytime the treeview is destroyed. Sometimes the column widths need to be saved when the treeview becomes invisible (e.g., because it is on a different page of a notebook). There are many ways this can happen in my program. I'm running out of fingers to stick in the dike. I wonder about two things. wxWidgets provides this signal and wxWidgets runs on GTK on some platforms. So how can wxWidgets provide the signal if we GTK programmers can't get it? wxWidgets has this signal; Qt has it too. Is there an argument for excluding it from GTK? When I used wxWidgets, I frequently encountered situations where I had to design around deficiencies in the toolkit. I believe that this is the first time I have had to design around a deficiency in GTK. That's pretty good. I'm still impressed with this toolkit even as I plead for a small enhancement. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
