Re: Gtk3 MacOS (OSX) context menu issues
Hi Jim Konstantin, I can now add another data point on this topic. My boss bought me a nice new iMac 27 Retina which arrived a couple days ago (yayy boss!!), so I decided to do my first ever X11-free quartz-only gtk3 MacPorts install (agh gtk3-on-quartz!!). I am now seeing your menu insensitivity bug, another bug as well, and all my hard-won tweaks to get gtk3 looking nice re: font and theme issues under XQuartz have gone down the toilet and I'm back at square one. On to the details ... (1) I had a bit of installation difficulty with MacPorts. For my previous XQuartz gtk3 installs I always just did port install gtk3 but to do this quartz-only install I followed some other instructions and did port install cairo +quartz -x11 port install pango +quartz -x11 port install gtk3 +quartz -x11 The last command failed because it dragged in the gtk2 port which wanted a pango with X11, so I started over: port install cairo +quartz port install pango +quartz port install gtk3 +quartz -x11 That worked. (2) My gtk3 app runs basically OK (and is not starting X11), but now shows the message *** WARNING: Method userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead. every time I start it. Naturally, my own code knows userSpaceScaleFactor from nothing, so it must be getting called somewhere within gtk3/whatever. There are other reports of this on the web (some of which state that it has led to fatal errors!!) but I have not yet seen any detailed explanation. Obviously it still afflicts gtk 3.14.9 and friends on quartz-only. (3) Now, the context menu issue ... I am basically seeing the same problem you are (although I have *never* seen it under my XQuartz installs), but have some additional observations to add. First, my popup menus (both those which I directly display within my own code as well as those displayed indirectly by GtkComboBoxText widgets) initially display with a transparent 6-ish-pixel-wide border the first time they are shown, but on subsequent displays show no border at all (but still suffer from the insensitivity bug). Weird. Second, I can avoid triggering the bug if I initiate the menu display with a quick click-and-release. If on the other hand I trigger the menu with a depress-only mouse event, I see the bug as you have described. On my own direct popups, the menu displays to the lower right of the mouse cursor position. If I depress-only and move the mouse directly to the lower right the items are sensitive until I move the mouse out of the menu, but if I first move the mouse to the upper left and then into the menu, the items are never sensitive. Jim, I don't see how this could have anything to do with X11 because (1) the latter is not running on my quartz-only install where the bug appears, and (2) the bug *never* appears on my XQuartz platforms. Hope this helps, Roger Jim Charlton wrote: I certainly should have mentioned that my observations were made under the MAC OS X 10.10 (Yosemite) operating system. I too have not been able to observe this problem under Linux (Ubuntu). As Konstantin has pointed out, it does not seem possible to add a margin to the popup menuitem box in Linux to test if the problem would arise. I will try to determine if the problem arises in the XQuartz X11 libraries or in the GTK3 libraries. But the incorrect motion event data seems to point to the X11 libraries on the MAC. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: borderless MacOS menus (was 'Gtk3 MacOS (OSX) context menu issues')
On Mon, 16 Mar 2016, Jim Charlton wrote:
.menubar {
border-width: 6px;
background-color: red;
border-color: black;
border-style: solid;
}
Thanks Jim, that tip led to this good-enough-for-now solution:
GtkMenu {
border-width: 1px;
border-color: #cc;
border-style: solid;
box-shadow: inset -1px -1px 2px #77;
}
GtkMenu is equivalent to .menu as far as I can tell, and both worked for
me -- can anyone comment? The .menubar style class does not work as these
are popup menus, not menubars. (Curiously, .popup does not work, which
would seem to apply according to the GtkStyleContext man page.)
My earlier attempt with
* {
did not work because I wasn't specifying the correct property entries.
(border-width and border-style are key, I was incorrectly using margin
before.)
Box shadows seem totally unattainable on my MacOS system if I do not use
the optional (!?!) 'inset' specifier. I actually do not want an inset
shadow (I want outset?) but the above specification creates a shadow
that's subtle enough that you can't easily tell the difference.
Many minor gtk3 style inconsistencies remain between my MacOS and CentOS 7
boxes, but I think for now I've whacked all that exceed my personal
hideousity threshold.
Thanks!
Roger
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
borderless MacOS menus (was 'Gtk3 MacOS (OSX) context menu issues')
Hi all,
Thanks to Jim Charlton for the nice fix (or workaround) on the context
menu problem! I've had a MacOS menu problem for some time which may be
related to this, but as it's a bit off-topic re: the context menu thread
I've started a new thread here.
My MacOS gtk3 menus have no borders whatsoever, a rather annoying graphics
glitch. This includes menus built-in to gtk3 widgets (e.g., made from
gtk_combo_box_text_new()) as well as those made directly by me via
gtk_menu_new(). The same menus look fine under CentOS.
I'm using a perhaps unusual gtk3 setup under MacOS (although it does seem
like many folks' MacOS gtk3 installs are unique). I am running the XQuartz
backend with a very minimal gnome environment. I set XDG_CONFIG_HOME to
reference my own private settings.ini file with the contents
[Settings]
gtk-application-prefer-dark-theme = false
gtk-theme-name = Adwaita
gtk-icon-theme-name = Adwaita
gtk-font-name = Cantarell 12
This at least solved a recent font problem of mine (see the Feb. 2015
'gtk3 (GtkTextView) and MacOS' thread), so it seems to be doing something
useful, and my shadowless menu issue pre-dates use of this file so it's
not the source of the current problem. However, I'm not sure how to make
any use of Jim's shadow-removing workaround to *add* shadows to my menus,
since:
(1) It seems that shadowed menus are supposed to be default bahavior, but
I'm not getting shadows despite having done nothing to disable them.
(2) My /opt/local/share/themes/Adwaita/gtk-3.0/gtk.css contains only the
comment line
/* Adwaita is the default theme of GTK+ 3, this file is not used */
implying there's nothing I can add there that will make the slightest bit
of difference anyway.
Of course, probably I should just be grateful that I don't suffer from the
MacOS context menu sensitivity problem and leave well enough alone!
Does anyone have any ideas? Thanks!
Roger Davis
Univ. of Hawaii
From: Jim Charlton char...@gmail.com
To: gtk-app-devel-list@gnome.org
Subject: Re: Fwd: Gtk3 MacOS (OSX) context menu issues
To answer part of my own question I am using my own gtk3 theme
rather than the compiled Adwaita theme that comes with Gtk3. I set the
environment variable XDG_CONFIG_HOME (export
XDG_CONFIG_HOME=/opt/local/share/themes/Adwaita/gtk-3.0), edited
/opt/local/share/themes/Adwaita/gtk-3.0/gtk.css to @import
url(gtk-main.css); and then edit
/opt/local/share/themes/Adwaita/gtk-3.0/gtk-main.css to customize the
theme. (careful... your theme directory may be elsewhere, depending on
how you installed Gtk3).
To cure the context menu problem, I eliminated the margin on popup
windows by adding
|.window-frame,
.window-frame:backdrop {
box-shadow: none;
margin: 0;}
to the end of the gtk.css file. Without the margin box the selection
problem seems to go away.
This is not a cure... but perhaps a useful work-around! The inspiration
for this idea comes from https://forum.xfce.org/viewtopic.php?pid=36005.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: borderless MacOS menus (was 'Gtk3 MacOS (OSX) context menu issues')
Thanks for the suggestion, Jim, but no luck so far in getting any change
to my menu borders via
.window-frame, .window-frame:backdrop {
box-shadow: 6px 6px;
margin: 6px;
}
which I added to a new $XDG_CONFIG_HOME/gtk-3.0/gtk.css file. This file is
definitely being parsed at app startup time, because if I change
.window-frame, .window-frame:backdrop {
to instead read
* {
I get the most hideous GUI imaginable, i.e., big ugly shadow borders
around almost everything *except* my menus, which are still completely
borderless! It just seems like my system is flat-out never drawing any
menu borders no matter what.
Roger
On Sun, 15 Mar 2015, Jim Charlton wrote:
My experience has been that I can set the XDG_CONFIG_HOME environment
variable to the path to the gtk-3.0 directory (eg.
/opt/local/share/themes/Default) and then put both the gtk.css and the
settings.ini file in the /opt/local/share/themes/Default/gtk-3.0/ directory.
When a gtk3 application is run, both files will be processed. You can put
css into the gtk.css file and it seems to override the in-line (compiled?)
theme data. If you do figure out how to put shadowed margins on the menus,
let us know if it brings back the item selection problem.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 toplevel windows incorrectly maximized under gnome3
On Fri, 6 Mar 2015, Emmanuele Bassi wrote: GNOME Shell *is* Mutter. The shell uses libmutter which provides ... Thanks, Emmanuele. I assumed there was some type of subterfuge in effect here. Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 toplevel windows incorrectly maximized under gnome3
I finally ran this down. The mutter window manager does indeed by default auto-maximize any newly mapped window larger than 0.8 of the 'usable screen area'. I think the latter means the space between gnome-shell's upper and lower toolbars, as I could never get anything more than about 0.75 of the total X11 display area. I still can't absolutely confirm that I'm actually running mutter because it does not appear in my system process list, and wmctrl says my WM is 'GNOME Shell'. However, the behavior I am experiencing is exactly as described within the mutter source code, and you can actually disable it via gsettings set org.gnome.mutter auto-maximize false I have to confess to enjoying some of the comments in bug reports filed on this behavior that led to the above gsettings workaround. Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk3 toplevel windows incorrectly maximized under gnome3
Hi all, I have been using several of my gtk3 apps on CentOS 6.x for a couple of years with no problem, but am now testing them under CentOS 7 (which uses gnome3's desktop, window manager, etc., instead of gnome2's) and have encountered a new difficulty with a window manager issue at app startup time. Some of these apps' toplevel windows are now consistently being initially and incorrectly displayed in a maximized state, meaning that they (together with their window-manager-attached titlebar) completely fill all available space on the gnome3 display between the top and bottom gnome-shell control (or whatever) bars. This happens every time these particular windows are first displayed. Other toplevel windows, however, never exhibit this problem despite the fact that they are being created by exactly the same code. All of my toplevels are explicitly size-initialized via the same calls to gtk_window_set_geometry_hints() and gtk_window_set_default_size(), setting the maximum size within the former equal to the default size of the latter. After much experimentation I've determined that the problematic windows are all those which are close to, although not exceptionally close to, the display size. On an X11 display size of 1891x1110 pixels (this is within a VMWare Fusion VM), I can correctly initialize a 1763x900 window, for example, but not a 1763x901 or 1764x900 window. The limitations do not seem to be strictly about width or height, however, but rather about total area, as I can also correctly initialize a 1700x933 window but not a 1701x933 or 1700x934 window. None of these sizes actually come within a couple dozen pixels of the edge of the usable display, so I have no idea why the window manager (if that is indeed the problem as I suspect) is deciding that it needs to maximize the window. These windows all function as large image/plot areas consisting of a GtkDrawingArea (explicitly sized via gtk_widget_set_size_request() to the precise dimensions required by the app) within a GtkLayout within a GtkScrolledWindow within the toplevel window. I do not want the user to ever resize the toplevel to be larger than the GtkDrawingArea because it would expose undrawn pixels along the right and bottom edges, so the GtkDrawingArea size is passed to gtk_window_set_geometry_hints() as the maximum size. It's OK for the user to resize the toplevel window smaller than this size because of the available scrollbars, but in most cases the user will want the toplevel window to be exactly the same size as the drawing area so as to expose exactly the entirety of the latter and nothing more -- hence, I also pass the GtkDrawingArea size to gtk_window_set_default_size(). I have tried various things with gtk_window_set_geometry_hints() to try to give myself the maximum possible freedom when it comes to specifying a large and precise default window size, e.g., geom.max_width= drawwidth; geom.max_height= drawheight; geom.width_inc= 1; geom.height_inc= 1; geom.min_aspect= 0.0001; geom.max_aspect= 1.; gtk_window_set_geometry_hints(GTK_WINDOW(win), NULL, geom, GDK_HINT_MAX_SIZE | GDK_HINT_RESIZE_INC | GDK_HINT_ASPECT); gtk_window_set_default_size(GTK_WINDOW(win), drawwidth, drawheight); but nothing seems to help once drawwidth*drawheight begins to approach about 75% of the total screen area. The above code works perfectly well up to that point under CentOS 7, and has always worked at any size up to the full display size under CentOS 6 as well as MacOS/XQuartz. How can I fix this? Thanks! Roger Davis Univ. of Hawaii PS: I'm not even sure where to look for info on gnome3 window manager (WM) bugs because I cannot figure out what WM is running under CentOS 7. Various web resources say it's mutter, but that's not in my system process list (although its RPM is installed), nor is anything else that looks like a WM (except perhaps gnome-shell itself). For whatever it's worth, I appear to be running in classic mode via 'gnome-session --session gnome-classic'. On systems where I do not have this problem, the running WMs are metacity (CentOS 6) and quartz-wm (MacOS/XQuartz). Information on this point of confusion would also be most welcome. PPS: I have kludged a workaround with gtk_window_unmaximize() called from within a window-state-event signal handler, but would prefer to not use it as wrestling with a WM is nearly always a bad idea. gtk_window_unmaximize() does not seem to work for me if it is called before the window is mapped and a window-state-event signal is received. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 (GtkTextView) and MacOS
Hi Jim, I suspect this may have something to do with how gtk3/gnome3 is built and/or configured on the Mac. I have no experience with the jhbuild environment and have always used the MacPorts packages, but have never made any attempt to dig into how the latter are built. As I said, I was quite startled to find that my apps were somehow getting their fonts out of the MacOS font system rather than the fontconfig stuff used by most X11 servers. Perhaps gtk3 has some backdoor directly into the MacOS fonts that was enabled by the MacPorts build, or maybe somehow my XQuartz (2.7.7, xorg-server 1.15.2) has been built to use those fonts. Might be an interesting experiment to play with a non-gtk X11 client's fonts and see what happens. As far as my use of $XDG_CONFIG_HOME/gtk-3.0/settings.ini, I based this strategy on https://developer.gnome.org/gtk3/stable/GtkSettings.html which reads GtkSettings provide a mechanism to share global settings between applications. On the X window system, this sharing is realized by an XSettings manager that is usually part of the desktop environment, along with utilities that let the user change these settings. In the absence of an Xsettings manager, GTK+ reads default values for settings from settings.ini files in /etc/gtk-3.0, $XDG_CONFIG_DIRS/gtk-3.0 and $XDG_CONFIG_HOME/gtk-3.0. These files must be valid key files (see GKeyFile), and have a section called Settings. ... Maybe the key phrase here is In the absence of an Xsettings manager, i.e., you have one and I don't? Also of interest might be On the X window system, implying that if someone used the direct-to-Quartz gtk backend this would not work then, either? It would certainly be nice to discover a strategy that worked under all these circumstances. I think that at this point I don't actually need my settings.ini file to get proper functionality with the default theme (now that my fonts are being correctly accessed), but I'm keeping it around mostly so users can alter the fontsize since I'm not running full-on gnome3 and there's no tweak-tool, etc., available. (I still can't install many of the gnome3 MacPorts packages because of a MacPorts package bug, and am at any rate not enthusiastic about loading up the system with all that weight just to run my own gtk app suite.) You might try changing your font size value in settings.ini just to confirm whether that file is being read at all. That had an effect for me even when I could not get the font to change (before discovering I was trying to use the wrong fonts). This is a murky swamp indeed! Roger From: Jim Charlton char...@gmail.com I tried your font changing solution to alter the font for my gtk3 application. I was unable to change the font by putting gtk-font-name in settings.ini regardless of where I put that file or the value of the environment variable XDG_CONFIG_HOME... or the actual font name. I found this to be true on both MAC OS X (Yosemite 1010, Gtk3 and Gtkmm3 built with jhbuild) and on my Linux Ubuntu box. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 (GtkTextView) and MacOS
Wow, here's a shocker, to my own stupid self at least -- it appears that gtk3 is tied into the native MacOS font system! Thanks for the tip on fontconfig/fc-cache, Allin. Once I looked into this it became apparent that fontconfig had known all along about all kinds of fonts, but none of the ones listed by fc-list which I had already tried were usable from my settings.ini file. Eventually, however, I tried 'Courier' which worked to my great surprise. I then tried to figure out what was special about Courier, and having noticed that the system process list showed 1330 9108 1 0 9:12AM ?? 0:06.92 /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Support/fontd I opened up my MacOS Terminal preferences on a lark to see what fonts MacOS was making available. Courier, check. Copperplate, Monaco, check. And they all work in my settings.ini. Youse all have to try this just to see a gtk3 dialog panel overflowing with Copperplate. Or not. It does seem a bit contradictory to me that gtk3 (at least as packaged by MacPorts) calls up XQuartz, but then completely ignores the X11 font support and goes direct to MacOS. Not a crazy idea, I suppose, but a bit surprising, and also not likely to make available all the gtk-related fonts you're used to having. I'd be less surprised to see a direct gtk-on-Quartz implementation do this. OK, now to figure out how to add the font I want to MacOS -- how hard could that possibly be? ;- Thanks for your followup, Jim, and for your comments as well, Daniel! Regarding the latter, I'd have to say that for what is supposed to be a cross-platform GUI, gtk3/gnome3 is abysmally supported on MacOS, which is a major platform. I won't say that's anybody's fault, but if the philosophy here is that gtk doesn't need to work well on boxes that aren't running full-on gnome3, I think that's a prescription for its ultimate demise -- a disturbing thought given that I've recently spent almost a year porting two decades' worth of Motif code into it. Thanks all! (And back here in ten minutes after I'm whipped by the MacOS font system.) Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 (GtkTextView) and MacOS
Thanks, Jim, your hint on setting XDG_CONFIG_HOME led me to a bunch of other useful info on the web that I have been slogging through all morning now. I have had some success but am still far from the finish line. On my Mac, if I set XDG_CONFIG_HOME to /opt/local/share/themes/HighContrast, which is where MacPorts dumped the HighContrast theme, and which contains a gtk-3.0 subdirectory with the files gtk.css, gtk.gresource and settings.ini, my app successfully loads the HighContrast theme, although I still have the same font problems within my GtkTextView windows. Similarly, I can make my own settings.ini file in ~/gtksettings/gtk-3.0, set XDG_CONFIG_HOME to ~/gtksettings, and my app processes that file, but again with the same font issues. That file contains a line of the form gtk-font-name = fontname fontsize e.g., gtk-font-name = Sans 10 and I can tweak the fontsize value and successfully get the altered font size in my app. However, absolutely nothing that I do to the fontname results in the use of a different font. In fact, gtk-font-name = FontConfusion 10 still loads exactly the same font! So, I am now convinced this is some kind of font installation or configuration problem. I am guessing that my MacOS gtk3 can't find any fonts whatsoever except for this exceptionally unintelligent fallback font it seems to be using. Does anyone know where gtk3 is looking for its fonts? I've spent quite a while looking for font files on my CentOS 7 system where I'm not having font problems, and actually can't find many there anywhere! Can anyone give me a reference to some decent documentation on where gtk3 font management that describes how to name fonts with the gtk-font-name property and how that name is associated with an actual font file? I sure have not been able to find any on my own! Thanks again, Roger I found (eventually) that I could do the same on the Mac if I set the environment variable XDG_CONFIG_HOME=/path/to/theme/gtk-3.0/ (I am not sure where your themes are installed using MacPorts. Perhaps /usr/share/themes/Ambiance or whatever). prior to executing the program. The selected (and perhaps edited) theme is then used over the embedded default. If memory serves me correctly... I was able to copy themes from Linux to the Mac and use them. jim... JIm Charlton ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 (GtkTextView) and MacOS
Hi all, So I finally have my problem fully solved for now, and here is a summary of the pertinent points. Beware that some of this may only apply to the MacPorts install of gtk3, I have no experience with any other type of gtk3 install on MacOS. (1) I had to set my XDG_CONFIG_HOME environment variable to a directory of my own creation containing the file gtk-3.0/settings.ini. The contents of the latter are [Settings] gtk-application-prefer-dark-theme = false gtk-theme-name = Adwaita gtk-icon-theme-name = Adwaita gtk-font-name = Cantarell 12 Use the gtk-font-name to specify a font name and size of your choice, but the named font must be MacOS-managed, not X11/fontconfig-managed! Meaning, if you were to open up the MacOS FontBook app you should see it listed there. You may be able to set XDG_CONFIG_HOME to any gtk3-installed theme directory, e.g., /opt/local/share/themes/HighContrast, but whatever font is being used by that theme (or by default) must be similarly MacOS-managed. (2) If you want to use a font that is not already managed by MacOS (e.g., Cantarell or any other gtk-ish font not already available in native MacOS), you must install it in one of two ways. You can use FontBook as recommended by many web sources, but I could not find any way to install my fonts in that manner so as to be visible to all userIDs. To do the latter I had to manually use the Finder to drag the desired .ttf file(s) into /Library/Fonts. See http://support.apple.com/en-us/HT201722 for more information. (3 -- Free Bonus!) Unless you are using a direct gtk-on-Quartz implementation (in which case, please tell me if that's working well and, if so, how you made it so), you will very likely be using the XQuartz X11 server. I have been having intermittent problems with XQuartz startup when invoking various X11 clients, the problem being that occasionally X11 windows are mapped to the display in an unmanaged state (meaning without the MacOS window titlebar and its close/iconify/etc. buttons and with no way to move the window anywhere else on the display). This does not happen often but it's far from rare. When it does happen, it takes XQuartz a *very* long time to start (tens of seconds). This problem has been reported by other users but I have never seen any clear fix, and I have seen one fix that did not work for me at all (changing a Mission Control setting). In my case (and probably all the others), the quartz-wm window manager either died or was just never started. Fortunately for me at least, however, I have so far been able to fix this problem just by manually (re?)starting the window manager with % quartz-wm May my luck continue and yours be as good, because this is a truly annoying problem! I hope others find these tips helpful, and thanks again to the list members who helped me grope my way to these solutions! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk3 (GtkTextView) and MacOS
Hi all, I have an application suite built on gtk3 which is targeted at both Linux (specifically CentOS 6 and 7) and MacOS X (Yosemite). Although the software is usable under MacOS I am having an ugly cosmetic problem there with my GtkTextView widgets, and other visual details are also not consistent with CentOS Linux. I suspect this is due to an incomplete or misconfigured gnome3 theme/font installation under Yosemite. (I am using the MacPorts gtk3/gnome packages.) I am hoping that someone here can give some advice on what gnome3 packages I need to install and configure to at least solve my GtkTextView problem. Under Linux my GtkTextView widgets display text nicely with consistent and adequate spacing between successive lines of text. There appears to be a very consistent 2 or 3 pixels of white space between the lowest descenders of line N and the highest ascenders of line N+1. Under MacOS, however, the descenders from line N actually touch the ascenders of line N+1 and the text is thus hard to read. Furthermore, line spacing is not always consistent -- lines with the unicode sequence \342\206\222 (right-arrow) have 2 or 3 pixels of additional inter-line spacing after the preceding line. (That spacing is actually perfect, but I want it for *every* line.) There appear to be no relevant gtk_text_view_XXX() functions controlling inter-line spacing, so I assume this problem is all about something that is broken with my gnome3 theme and/or font installation under MacOS. Does anyone have any idea of what this might be? I would very much prefer to configure a gnome3 installation under MacOS that is as lightweight as possible. No gtk3 apps other than my own are running, and I don't want to force users to have to cope with the gnome3 UI any more than is necessary, although if there was a way for them to select their own theme (especially with regard to font sizing within GtkTextView and other dialog panel widgets) that would be a big plus. Another reason for a lightweight gnome3 environment is that I've so far been unable to even install the full MacPorts gnome3 package set (due to a problem with the mojs17 port which seems to be a required dependency for many of the gnome3 packages), and I've read that many people who did manage to install a full-featured gnome3 under MacOS never got it to operate. Following is a list of gtk3- and gnome-related MacPorts packages which are now installed on my system, and which are clearly sufficient to build my software and run it, albeit with these annoying cosmetic issues: port list installed | grep gnome adwaita-icon-theme @3.14.1 gnome/adwaita-icon-theme at-spi2-atk@2.14.1 gnome/at-spi2-atk at-spi2-core @2.14.1 gnome/at-spi2-core gnome-backgrounds @3.14.1 gnome/gnome-backgrounds gnome-icon-theme @3.12.0 gnome/gnome-icon-theme gnome-themes-standard @3.14.0 gnome/gnome-themes-standard gobject-introspection @1.42.0 gnome/gobject-introspection gtk2 @2.24.25gnome/gtk2 gtk3 @3.14.5 gnome/gtk3 hicolor-icon-theme @0.14 gnome/hicolor-icon-theme icon-naming-utils @0.8.90 gnome/icon-naming-utils libcroco @0.6.8 gnome/libcroco Can anyone recommend any other packages which are necessary to get my GtkTextView objects to display better-looking text? Is there any necessary user-environment configuration, e.g., environment variables or config files stashed in ~ or elsewhere? (I did try copying the ~/.config directory from a CentOS 7 system with a functional full-blown gnome3 environment, but that didn't make any difference.) Are there any gnome3-related system processes which must be running before I start a gtk3 app if I want the latter to conform to any particular theme, etc.? I am starting my apps simply by invoking them directly from a MacOS Terminal, which then implicitly starts XQuartz (2.7.7). I've made no effort to specifically launch any gnome3-related system process other than the following commands which were recommended by the MacPorts installation chatter at gtk3 package installation time: % sudo launchctl load -w /Library/LaunchDaemons/org.freedesktop.dbus-system.plist % launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist Any ideas? Thanks! Roger Davis Univ. of Hawaii ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Gtk-CRITICAL assertion failed (file dialogs?)
suggestions on how to fix this incredibly frustrating problem would be most gratefully welcomed! Roger Davis Univ. of Hawaii PS: Stack backtrace follows. This is typical, although not always the same, for this problem. There is pretty much always a call to some kind of gtk_tree_*_row_deleted() function somewhere on the stack. Here it is: #0 0x7f07545c1a0b in find_root (seq=0x2201480) at gsequence.c:1570 #1 node_get_length (seq=0x2201480) at gsequence.c:1791 #2 g_sequence_get_length (seq=0x2201480) at gsequence.c:1256 #3 0x7f0756130d73 in gtk_tree_model_filter_row_deleted (c_model=value optimized out, c_path=0x2201480, data=0x7f07340034b0) at gtktreemodelfilter.c:2592 #4 0x7f075489bdc2 in g_closure_invoke (closure=0x237ee60, return_value=0x0, n_param_values=2, param_values=0x7fffb5a1eca0, invocation_hint=value optimized out) at gclosure.c:777 #5 0x7f07548b2341 in signal_emit_unlocked_R (node=value optimized out, detail=0, instance=0x22b4d80, emission_return=0x0, instance_and_params=0x7fffb5a1eca0) at gsignal.c:3586 #6 0x7f07548b38df in g_signal_emit_valist (instance=value optimized out, signal_id=value optimized out, detail=0, var_args=value optimized out) at gsignal.c:3330 #7 0x7f07548b3ce3 in g_signal_emit (instance=value optimized out, signal_id=value optimized out, detail=value optimized out) at gsignal.c:3386 #8 0x7f0755fe1c6d in emit_row_deleted_for_row (model=0x22b4d80, row=value optimized out) at gtkfilesystemmodel.c:331 #9 0x7f0755fe3df5 in remove_file (monitor=value optimized out, file=value optimized out, other_file=value optimized out, type=value optimized out, model=0x22b4d80) at gtkfilesystemmodel.c:1912 #10 gtk_file_system_model_monitor_change (monitor=value optimized out, file=value optimized out, other_file=value optimized out, type=value optimized out, model=0x22b4d80) at gtkfilesystemmodel.c:1257 #11 0x7f0752d7d45c in ffi_call_unix64 () at ../src/x86/unix64.S:75 #12 0x7f0752d7cbf3 in ffi_call (cif=value optimized out, fn=0x7f0755fe3bf0 gtk_file_system_model_monitor_change, rvalue=value optimized out, avalue=0x7fffb5a1f1b0) at ../src/x86/ffi64.c:492 #13 0x7f0754899d48 in g_cclosure_marshal_generic_va (closure=0x23393d0, return_value=0x0, instance=0x2355a00, args_list=value optimized out, marshal_data=0x7f0755fe3bf0, n_params=3, param_types=0xcc5f70) at gclosure.c:1550 #14 0x7f075489bc0a in _g_closure_invoke_va (closure=0x23393d0, return_value=0x0, instance=0x2355a00, args=0x7fffb5a1f610, n_params=3, param_types=value optimized out) at gclosure.c:840 #15 0x7f07548b2f2d in g_signal_emit_valist (instance=value optimized out, signal_id=value optimized out, detail=0, var_args=value optimized out) at gsignal.c:3238 #16 0x7f07548b3ce3 in g_signal_emit (instance=value optimized out, signal_id=value optimized out, detail=value optimized out) at gsignal.c:3386 #17 0x7f07556b15d1 in emit_cb (data=0x2355a00) at gfilemonitor.c:392 #18 0x7f07545a9593 in g_main_dispatch (context=0x9e14c0) at gmain.c:3066 #19 g_main_context_dispatch (context=0x9e14c0) at gmain.c:3642 #20 0x7f07545ab5f8 in g_main_context_iterate (context=0x9e14c0, block=1, dispatch=1, self=value optimized out) at gmain.c:3713 #21 0x7f07545ac625 in g_main_loop_run (loop=0x20107a0) at gmain.c:3907 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk-CRITICAL assertion failed (file dialogs?)
Hi all, Looking at my stack backtraces a little closer I'm pretty convinced this is a file dialog problem: #9 0x7f0755fe3df5 in remove_file (monitor=value optimized out, file=value optimized out, other_file=value optimized out, type=value optimized out, model=0x22b4d80) at gtkfilesystemmodel.c:1912 #10 gtk_file_system_model_monitor_change (monitor=value optimized out, file=value optimized out, other_file=value optimized out, type=value optimized out, model=0x22b4d80) at gtkfilesystemmodel.c:1257 Looks like maybe something in gtk+ has detected a change in the file system and is trying to remove an entry from the file dialog's list, completely unaware that the dialog is no longer displayed? I've recoded to fully implement the create-run-destroy cycle whenever I use a file dialog and am now testing. If my app doesn't crash over the next week I will assume this is fixed (and will file a bug report against the gtk+ docs as I don't think this rather important point is ever mentioned anywhere). Does anyone know if other gtk+ dialogs do this sort of spontaneous background self-reorganization? I use the simpler dialogs created by gtk_dialog_new() in the same manner as I was using file choosers, i.e., create once and use/re-use repeatedly. Is this likely to cause trouble? I believe that so far it's not, but I wonder what might happen several gtk+ releases into the future? Thanks, Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
3.8 invisible widget change breaks my app
Hi all, I just upgraded to gtk+ 3.8 and am now being thwarted by one of the new design changes. From the 'What's New in 3.8' notes: Invisible widgets now return a size of 0x0. This is an experimental change that makes GtkWidget::visible essentially behave the same way that display: none does in CSS. If you want the effect of CSS's visibility: hidden, you can use a GtkNotebook with an empty page I am trying to predetermine some sizes of label widgets without actually displaying anything on the screen: GtkWidget *w; GtkRequisition grq; if ((w= gtk_label_new(my test string)) == (GtkWidget *) 0) return -1; gtk_widget_get_preferred_size(w, grq, NULL); This worked just fine in 3.6 but is now broken, as grq.width and grq.height are returned as 0. How can I accomplish this now? If the answer is you can't, then please consider this a request to disable this 'experimental change'. ;- Thanks! Roger Davis ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: CentOS 6.4 gtk+-3.6.2 build failure
OK, I think I've figured out what's going on and fixed it. (I now know a lot more about autoconf than I ever wanted to. ;- ). The xorg* downgrade that was required to get my X server working again introduced an incompatibility between the xorg-x11-proto-devel and libXi-* packages. After downgrading the latter to the CentOS 6.3 version the gtk+3 configure script worked properly and things compiled OK. (Haven't tested my actual app yet as I am at a remote site, but it's probably all right.) This CentOS 6.4 Xorg ABI mess is truly something special -- I expect it will be the gift that keeps on giving. Beware!! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
CentOS 6.4 upgrade breaks gtk+-3.6.2 build
Hi all, I just upgraded several CentOS 6.3 systems to 6.4 and have been rebuilding gtk+-3.6.2 (and all its dependencies, e.g., glib, gdk-pixbuf, etc.) on all of them. This has gone fine except for 2 problem systems subject to the new Xorg 1.13 ABI bug because of their particular graphics hardware. To get those particular systems to properly upgrade to 6.4 yet still be able to run Xorg, I had to add exclude all xorg* package updates via the line exclude=xorg* appended to /etc/yum.conf before doing the 6.4 update. On one of those systems, I did the normal full upgrade first, then discovered my system suffered from the Xorg bug and had to do a yum downgrade back to the 6.3 packages. These systems now run Xorg 1.10.6. On these two problem systems, my build of gtk3+ fails here very close to the beginning of the make: make[4]: Entering directory `/opt/gtk3/gtk+-3.6.2/gdk/x11' CC gdkapplaunchcontext-x11.lo CC gdkasync.lo CC gdkcursor-x11.lo CC gdkdevice-core-x11.lo CC gdkdevice-xi2.lo gdkdevice-xi2.c: In function '_gdk_x11_device_xi2_translate_event_mask': gdkdevice-xi2.c:723: error: 'XI_TouchBegin' undeclared (first use in this function) gdkdevice-xi2.c:723: error: (Each undeclared identifier is reported only once gdkdevice-xi2.c:723: error: for each function it appears in.) gdkdevice-xi2.c:724: error: 'XI_TouchUpdate' undeclared (first use in this function) gdkdevice-xi2.c:725: error: 'XI_TouchEnd' undeclared (first use in this function) Looking at my ./configure output from just prior to the make, I see this possibly relevant info: ... checking if X11/extensions/XIproto.h is needed for xReply... no checking for XkbQueryExtension... yes checking for XShapeCombineMask... yes checking for XSyncQueryExtension... yes checking for X11/extensions/sync.h... yes checking for Xinerama packages... yes checking for XGetEventData... yes checking X11/extensions/XInput2.h usability... yes checking X11/extensions/XInput2.h presence... yes checking for X11/extensions/XInput2.h... yes checking for XIAllowTouchEvents... yes checking for XIScrollClassInfo.number... yes ... I'm guessing that whatever package contains the XI_Touch* functions is not fully present on the system although perhaps configure seems to think that it is. Any idea how to fix this? Thanks! Roger Davis Univ. of Hawaii PS: I do not need any touchscreen functionality, if that's what this stuff is about. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
CentOS 6.4 gtk+-3.6.2 build failure
[ Apologies if this is a needless repost -- I tried to mail this earlier but am pretty certain the mail never left my system. ] Hi all, I just upgraded several CentOS 6.3 systems to 6.4 and have been rebuilding gtk+-3.6.2 (and all its dependencies, e.g., glib, gdk-pixbuf, etc.) on all of them. This has gone fine except for 2 problem systems subject to the new Xorg 1.13 ABI bug because of their particular graphics hardware. To get those particular systems to properly upgrade to 6.4 yet still be able to run Xorg, I had to add exclude all xorg* package updates via the line exclude=xorg* appended to /etc/yum.conf before doing the 6.4 update. On one of those systems, I did the normal full upgrade first, then discovered my system suffered from this bug and had to do a yum downgrade back to the 6.3 packages. On these two problem systems, my build of gtk3+ fails here very close to the beginning of the make: make[4]: Entering directory `/opt/gtk3/gtk+-3.6.2/gdk/x11' CC gdkapplaunchcontext-x11.lo CC gdkasync.lo CC gdkcursor-x11.lo CC gdkdevice-core-x11.lo CC gdkdevice-xi2.lo gdkdevice-xi2.c: In function '_gdk_x11_device_xi2_translate_event_mask': gdkdevice-xi2.c:723: error: 'XI_TouchBegin' undeclared (first use in this function) gdkdevice-xi2.c:723: error: (Each undeclared identifier is reported only once gdkdevice-xi2.c:723: error: for each function it appears in.) gdkdevice-xi2.c:724: error: 'XI_TouchUpdate' undeclared (first use in this function) gdkdevice-xi2.c:725: error: 'XI_TouchEnd' undeclared (first use in this function) Looking at my ./configure output from just prior to the make, I see this possibly relevant info: ... checking if X11/extensions/XIproto.h is needed for xReply... no checking for XkbQueryExtension... yes checking for XShapeCombineMask... yes checking for XSyncQueryExtension... yes checking for X11/extensions/sync.h... yes checking for Xinerama packages... yes checking for XGetEventData... yes checking X11/extensions/XInput2.h usability... yes checking X11/extensions/XInput2.h presence... yes checking for X11/extensions/XInput2.h... yes checking for XIAllowTouchEvents... yes checking for XIScrollClassInfo.number... yes ... I'm guessing that whatever package contains the XI_Touch* functions is not fully present on the system although perhaps configure seems to think that it is. Any idea how to fix this? Thanks! Roger Davis Univ. of Hawaii PS: I have no need of touchscreen functionality if that's what this is about. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: CentOS 6.4 gtk+-3.6.2 build failure
Sorry, apparently my original post *did* get through, oops! Anyway, I have tracked this down a little further but am unsure on how to proceed. The error is due to an incorrect version of XI2.h installed in /usr/include/X11/extensions. The newer release of the relevant package (xorg-x11-proto-devel-7.6-25.el6.noarch) has the required #defines, but the older release (xorg-x11-proto-devel-7.6-13.el6.noarch) doesn't. Apparently there is some confusion in my package system or elsewhere due to the CentOS 6.4 upgrade that was performed while excluding newer Xorg package updates. I have not yet tried upgrading this single package, I suspect that if I do the gtk3 build (or my own app builds) will just fail later on when code is linked to whatever X11 library is supposed to include these functions. I also suspect if I try to install the newerr libraries I will get a big dependency mess related to other new xorg packages that are missing. Like I said, if this is just about touchscreen stuff I don't need it, so if anyone knows how to fully degrade my system so that the gtk3+ configure will believe I have the older release, that would be fine. Any suggestions? Thanks! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk+ 3.6.2 menu problems
Hi all, I am getting some visually unpleasing results with the gtk+ 3.6.2 menu functions. In fact, menu appearance seems to have been getting steadily worse since gtk+ 2. ;-( I am using a CentOS 6.3 platform with all of the latest gtk+3-related packages installed (e.g., atk 2.6, cairo 1.12.8, gdk-pixbuf 2.26.5, glib 2.34.2, pango 1.32.3, pixman 0.28). There are two issues: first, pullright menus (i.e., submenus attached to some menu item within a parent menu) are being rendered with no highlight or shadow around the perimeter of the menu, and second, when I desensitize a menu item to user input via gtk_widget_set_sensitive(), in addition to that menu item's text label being grayed out, I'm also getting an unsightly lighter gray rectangular shape (but darker than the menu background) being drawn beneath the menu item's text label. I don't think I am doing anything unusual in the creation or use of these menus, and can find no documentation which describes any stylistic properties or whatnot that would seem to dictate these behaviors. The item labels are all simple text strings. Menus (and submenus) are created with code such as menu= gtk_menu_new(); Menu items are created and attached to a menu with menuitem= gtk_menu_item_new_with_label(textstring); gtk_menu_shell_append(GTK_MENU_SHELL(menu), menuitem); gtk_widget_show(menuitem); If a submenu is involved it is attached to the menu item in question with gtk_menu_item_set_submenu(GTK_MENU_ITEM(menuitem), submenu); I display my top-level popup menus in response to a button-press event with gtk_menu_popup(GTK_MENU(menu), NULL, NULL, NULL, NULL, bpevt-button, bpevt-time); According to the documentation the NULL args in the above call are typical usage. I first noticed the pullright menu border problem when switching from gtk+ 2 to gtk+ 3.4, I believe. The top-level popup menu is correctly drawn with a light-colored highlight along its left and top edges, and a dark shadow along its right and lower edges. Both highlight and shadow appear to be about 2 pixels wide. If there is a submenu attached to an item in this menu and I activate that item by mousing over it, the submenu which is then popped up is drawn with no highlighted or shadowed edges. This used to be correctly drawn in my very brief experience with gtk+ 2 before I switched over to gtk+ 3.4, but since then I have never been able to get a submenu to render with a proper border. This is pretty ugly as I am typically popping these menus up over a drawing area widget that has the same background color as the menus, so the submenu's item text labels appear to be just floating in space uncontained by anything. Yesterday I just switched over from 3.4 to 3.6.2 and now I have the new problem with desensitized menu item label rendering as described above, i.e., the menu item text is grayed out as expected but there is also an ugly dark rectangle drawn beneath that text that was not there in 3.4 or before. Can anyone shed any light on these issues? Thanks! Roger Davis Univ. of Hawaii PS: As noted above I am running on CentOS 6.3 (gtk+ 2 default environment) with gtk+ 3 packages separately installed. I have always gotten the following annoying environmental messages displayed at program startup, I don't think these have anything to do with my menu problems, but here they are just for completeness: Gtk-Message: Failed to load module canberra-gtk-module Gtk-Message: Failed to load module pk-gtk-module GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. If anyone has any hints on making the above crap go away they would of course be appreciated. Several months ago I tried in vain to get rid of the canberra problem but was unable to find the right combination of packages that would properly configure and install. Sadly, I suppose it's going to be at least CentOS (RedHatEnterprise) 7 before gtk+ 3 becomes the default environment, if then! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+3 fonts
Or request it everywhere. Not a bad idea, Liam, I'll probably do that. Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+3 fonts
Hi all, I have been developing some GTK+3/Cairo apps under CentOS 6, and am now trying to get them running under MacOS (Mountain Lion). I am using Cairo's text drawing functions to render simple strings into a GtkDrawingArea and am partial to the Sans font for various reasons. This does not seem to be properly installed on my Mac and I am trying to figure out how to correct the problem. I have installed the MacPorts gtk3 package, and subsequently built the gsettings-desktop-schemas-3.6.0 to get my apps up and running. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+3 fonts
Hi Liam, Thanks for explaining the Sans alias. I was wondering about that, as looking around on my CentOS 6 system I was able to find most of the Gnome fonts in /usr/share/fonts (including the DejaVu fonts), but was not able to find the Sans font anywhere. Playing around with the gnome-terminal profiles font selection dialog, it appears that Sans is an alias for DejaVu Sans Book. Digging a little deeper, I am noticing a number of bewildering differences between my CentOS 6 and Mac systems with regard to this font problem, however, and it's not at all clear why the differences exist, partly because (i) my CentOS system is basically a Gnome 2 environment to which I have added GTK+3 and related (i.e., up-to-date glib, cairo, etc.) libraries, and (ii) although I don't think that my Mac is similarly polluted with any Gnome 2 packages (as I only installed the MacPorts gtk3 atop the base MacOS), it probably does not have anywhere close to a full set of Gnome fonts of any vintage. I have a test drawing program (that calls the Cairo font selection and text drawing routines) which allows me to specify a font and fontsize and some arbitrary text. On CentOS, when I use DejaVu Sans and gradually decrement the size from about 24 down to 14, for instance, the rendered text all looks basically the same, just smaller as one would expect. Running the same test code on the Mac, however, when I move from 17 to 16 using DejaVu Sans, the text actually changes markedly in appearance to something that looks more like DejaVu Sans ExtraLight at the smaller size. Also, a certain UTF-8 character (\342\206\220, a left arrow) that renders just fine on CentOS with DejaVu Sans does not render at all on Mac OS, even at the larger font sizes which look more similar to the CentOS DejaVu Sans. (This character instead renders as a small boxed rectangle around a blank space, which I interpret to mean that the font does not support that particular UTF-8 value.) Finally, I can't seem to locate the Gnome fonts anywhere on my Mac, although when I use my test program to draw with certain fonts (Courier 10 Pitch, Nimbus Mono L) cairo seems to find something reasonable. Under CentOS they are in /usr/share/fonts (although this is probably their Gnome 2 location, I have no idea where a full Gnome 3 installation would put them). On my Mac, however, I did a find (Unix shell command) search and the only DejaVu files I could locate were in /Applications/OpenOffice.org.app/Contents/basis-link/share/fonts/truetype/DejaVuSans.ttf which seem to be part of the OpenOffice package and not part of any installed Gnome fonts. Any explanation for these mysteries, or any pointers to some decent documentation on Gnome 2/3 font configuration and installation? Thanks! Roger On Sun, 21 Oct 2012, Liam R E Quin wrote: On Sat, 2012-10-20 at 20:23 -1000, Roger Davis wrote: Hi all, I [...] am partial to the Sans font for various reasons. On most linux systems this is actually an alias, not a font name. Here, it's DejaVu Sans Book: $ fc-match Sans DejaVuSans.ttf: DejaVu Sans Book $ so, add DejaVuSans.ttf to your Mac. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+3 fonts
$ fc-match Sans DejaVuSans.ttf: DejaVu Sans Book Aargh, I'm stupid, Liam! Somehow I managed to skip over the key piece of information you supplied in your brief response. Here's what I get on my Mac: % fc-match Sans Vera.ttf: Bitstream Vera Sans Roman Obviously this explains a lot. Looking around on the Mac I was able to 'find' these: % sudo find / -name '*Vera*' -print /opt/X11/share/fonts/TTF/Vera.ttf /opt/X11/share/fonts/TTF/VeraBd.ttf ... lots more Vera*.ttf files in /opt/X11/share/fonts/TTF ... ... but also a bunch of other stuff here: /System/Library/PrivateFrameworks/CorePDF.framework/Versions/A/Resources/FontInfo/BitstreamVeraSans-Bold.fontinfo /System/Library/PrivateFrameworks/CorePDF.framework/Versions/A/Resources/FontInfo/BitstreamVeraSans-BoldOblique.fontinfo ... I suspect, but can't be sure, that the latter files were part of the MacOS install. The ttf files in /opt/X11/share/fonts/TTF almost certainly came from either a MacPorts package install (which could have been either from the gtk3 package or any one of a number of X11-related packages) or from an XQuartz install (Mountain Lion no longer has integrated X11, you must install XQuartz separately), and I have no idea which. Anyway, I tar'd up all the DejaVu*ttf files from /usr/share/fonts on my CentOS 6 machine and dumped them into /opt/X11/share/fonts on the Mac, but my app does not seem able to find them there, and fc-match still says that Sans is aliased to the Bitstream Vera font. It would seem that there is still some other piece of font lookup information that is missing. Any idea on what that might be? Thanks! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+3 fonts
Thanks, Michael. My MacOS GTK+3 install is using the X11 backend, or so I assume given that when my apps appear they have a small X icon embedded into each window titlebar. You said that in this case font usage is controlled by freetype. How would I (re)configure freetype to recognize new .ttf files that I have manually copied into /opt/X11/share/fonts? Thanks! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+3 fonts
How would I (re)configure freetype to recognize new .ttf files that I have manually copied into /opt/X11/share/fonts? Sorry, that should have been /opt/X11/share/fonts/TTF, where I stuck all the DejaVu*.ttf files copied from my CentOS machine. fc-list at least is able to find these now, but my own apps don't: % fc-list | grep Deja /usr/X11/lib/X11/fonts/TTF/DejaVuSansCondensed-Oblique.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Oblique,Oblique /usr/X11/lib/X11/fonts/TTF/DejaVuSansMono-BoldOblique.ttf: DejaVu Sans Mono:style=Bold Oblique /usr/X11/lib/X11/fonts/TTF/DejaVuSans.ttf: DejaVu Sans:style=Book ... etc. /usr/X11/lib/X11/fonts is a symbolic link to /opt/X11/share/fonts. Thanks, Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+3 fonts
Hi all, OK, I've made some progress based on everyone's suggestions, and focused my questions a bit more, I think. Copying the Deja*.ttf files into /opt/X11/share/fonts/TTF *did* make a difference, and they are now seen by my apps, but this fact was momentarily obscured by one of my remaining problems, namely that when I downsize my font display to smaller sizes (anything 16 or below), the font weight appears to make a dramatic shift from Book to ExtraLight. This happens on the Mac but not on CentOS. Anyone know why this is happening and if there is a way to prevent it? Second, at some point during my fiddling around this morning, the following files magically appeared in /opt/X11/share/fonts/TTF: % ls -l fo* 120 -rw-r--r-- 1 root wheel 57364 Oct 21 06:52 fonts.dir 8 -rw-r--r-- 1 root wheel 1962 Oct 21 06:51 fonts.list 120 -rw-r--r-- 1 root wheel 57364 Oct 21 06:51 fonts.scale I don't believe I did anything other than copy some ttf files into this directory and run fc-match and fc-list a few times. Does anyone know how these get created, and is their presence critical to anything, particularly any kind of font lookup procedure? It's quite possible that they were there before I started tweaking things, but their modification times have clearly been updated, and the fonts.list file now contains references to the new DejaVuSans fonts. Finally, I did some experimenting with removing ttf files from /opt/X11/share/fonts/TTF. I found that if I got rid of the Vera*ttf files, then this happened: % fc-match Sans DejaVuSans.ttf: DejaVu Sans Book And if I put them back, things are restored as before: % fc-match Sans Vera.ttf: Bitstream Vera Sans Roman Can anyone explain how this works? Is there some complicated font parameter examination taking place here, or is it as simple, at least in some cases, as a single defined fallback font for everything when a specified font cannot be located? Curiously, this test returns the same fallback font: % fc-match yuk-yuk Vera.ttf: Bitstream Vera Sans Roman I suppose what I would like to do on my Mac is have it use DejaVu Sans to satisfy a Sans request (because DejaVu has the UTF-8 characters I need and Vera does not), but without having to delete the Vera fonts from my system, which might break God-knows-what-all. Is there a way to do this? Thanks! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+3 fonts
Thanks for all the followup, Liam Michael! By default I believe the mac changes antialiasing and hinting strategies (is this 16pt or 16px?) I'm using the simple Cairo text drawing functions here. Size is being set as Cairo user space units, which should be just pixels as I'm using the unmodified coordinate space. Thanks to both of you for pointing out all of the config stuff in /etc/fonts (/opt/local/etc/fonts on MacOS with MacPorts). I believe I have found the config file there which is aliasing Sans to the Vera font. In 60-latin.conf: ... alias familysans-serif/family prefer familyBitstream Vera Sans/family familyDejaVu Sans/family Looks like a list of fonts that are aliased as substitutes for sans-serif, with Vera at the top of the list. I suspect if I re-ordered the list I could get things the way I wanted. I'm thinking that my better strategy at this point is to just #ifdef my app code to specifically request DejaVu Sans on the Mac, rather than having to tweak these fontconfig files on each Mac in addition to hand-installing DejaVu. Anyway, you guys have given me plenty of things to look into, thanks very much! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkrbtree core dump
Hello Emmanuele, Thank you for your suggestions! the RBTree is a private data structure used internally by gtk+. Some people here have suggested that this rbtree code is used by GtkTreeView objects, so I have been focusing my attention on parts of my code which might be referencing such things indirectly. I do not use any GtkTreeView objects directly in my code. Are you saying that this rbtree code is also used by other parts of GTK that have nothing to do with GtkTreeView objects? use gdb and gather a stack trace of the assertion failure. you'll see the call stack, so you'll be able to figure out what's calling that function with a empty RBTree. I am hoping to do this, unfortunately these failures are pretty rare and I cannot cause one on demand. My reading of the code, however, indicates that the g_assert fails because tree-root is *not* nil: g_assert (_gtk_rbtree_is_nil (tree-root)); I am trying to understand what happens inside g_assert. The glib documentation says it should dump core inside the assert *unless* the g_assert macro has been turned off, and then implies that the macro is probably turned off in a final code release, which should mean that the core dump is actually happening later on, perhaps in a very different stack backtrace. Do you know anything about this? Is there a way I can examine the code build configuration to determine whether the assert core dump is enabled or disabled? I suppose that ideally I would like the core dump to occur in the assertion so I can better locate the source of the failure. Thanks! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtkrbtree core dump
Hello all, I am encountering an infrequent but serious bug which is causing core dumps in one or more of my GTK3+ apps. At the time my code dumps core I see the message Gtk:ERROR:gtkrbtree.c:465:_gtk_rbtree_insert_after: assertion failed: (_gtk_rbtree_is_nil (tree-root)) The last time this happened a few days ago my app was actually in a quiescent state in terms of GUI events -- it just up and core dumped even though no user interactivity (and resulting callbacks) had taken place for a minute or two. There was a work procedure (registered via g_idle_add_full) being called periodically to check for external file input data, but that input was also quiescent, and in any case the work procedure makes no changes to any GTK objects. In my development and testing I see this occur once every couple of weeks, and I believe that I have seen it in multiple apps although it happens so rarely that I am not certain about that. It is impossible to duplicate. Unfortunately some of my apps are intended to run for weeks at a time, having them crash is a very bad thing, and the likelihood of this occurring at least once during such a time period is unacceptably high. Has anyone else ever seen this (I found only a couple not especially helpful references on the web), and/or does anyone know what is calling _gtk_rbtree_insert_after()? It isn't me, at least not directly, and I can find no reference to it in the GTK+3 docs. What kind of programming error on my part might lead to such an outcome? Thanks! Roger Davis Univ. of Hawaii ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkrbtree core dump
Hi Tadej, I am looking at the docs but not seeing what you are describing. IF you want to see which widgets are derived from GtkTreeView, simply open GtkTreeView API docs and check Object Hierarchy section. Direct descendants will be listed here (if there are any). There is no stock gtk widget that would be derived from GtkTreeView. The object hierarchy graph at http://developer.gnome.org/gtk3/stable/GtkTreeView.html shows only the ancestors of GtkTreeView: GObject +---GInitiallyUnowned +---GtkWidget +---GtkContainer +---GtkTreeView Am I looking at the wrong graph? File chooser dialogs use GtkTreeView to display files/folders and as far as I can tell from your description, this is the only place where tree view is used in your app. Maybe file system changes cause tree view to update itself in a bad way? (I'm mostly guessing here after a quick git grep through sources.) I could believe that file chooser dialogs are somehow related to GtkTreeView, but this is not shown in the object hierarchy graph at http://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.html: GObject +---GInitiallyUnowned +---GtkWidget +---GtkContainer +---GtkBin +---GtkWindow +---GtkDialog +---GtkFileChooserDialog Again, am I looking in the wrong place? Can you refer me to the GTK+3 documentation page which shows the connection between file chooser dialogs and GtkTreeView? There do seem to be a few cases in the GTK+3 documentation pages where a particular object's hierarchy graph does show at least immediate descendants as well as ancestors (e.g., GtkContainer, GtkDialog), but this does not seem to be the case in general. Thanks! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkrbtree core dump
There are much more to explore. The most effective way I found to approach this kind of issues is grepping inside the source tree: $ grep -rl gtk_tree_view *.c gtkappchooserwidget.c ... Thanks for the suggestion, Nicola. After looking at gtkfilechooserdefault.c a bit, I guess I would interpret that code as showing that while a file chooser dialog is not a descendant of a GtkTreeView, it uses some private internal data strutures which are in fact GtkTreeView (or related) objects. I guess the same would apply to other object types which make some private use of a hidden GtkTreeView object while not being directly related themselves to GtkTreeView. Thanks! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkDrawingArea cursor flicker
Hi all,
I am experiencing some very annoying mouse cursor flicker on a particular
computer system which does not occur on any other machine. I am using a
GTK+3 GtkDrawingArea widget, and am listening for GDK_POINTER_MOTION_MASK
events on that widget. When I get such an event, I do some redrawing to
a private Cairo surface based on the current cursor location, then
queue an expose event with gtk_widget_queue_draw_area(drawarea, ...).
When my GtkDrawingArea widget receives the 'draw' signal it copies the
redrawn area of interest from my private Cairo surface using this draw
handler:
gboolean
canvasdrawevt(GtkWidget *w, cairo_t *cr, gpointer gp)
{
MyCairoCanvas *c;
c= (MyCairoCanvas *) gp;
cairo_set_source_surface(cr, c-surface, 0, 0);
cairo_rectangle(cr, 0, 0, (double) c-width, (double) c-height);
cairo_fill(cr);
return TRUE;
}
After my redraw is done, on the problematic machine the mouse cursor
actually disappears from view completely. If I move the mouse around
quickly, generating lots of these redraws, I can see the cursor flickering
until I stop moving it, after which it again disappears. There are certain
areas of the widget where I do *not* handle these motion events and thus
there is no redrawing done -- in these areas the mouse cursor behaves
normally and is always visible.
This is happening on a CentOS 6 system that is several (maybe about 8)
years old. This problem does not occur on any of the other CentOS 6 systems
I have which are newer hardware. It also does not occur on the older system
if I run my app remotely via a VNC server, displaying on newer hardware.
Any idea on what is causing this or how I might work around it? Unfortunately
I really do need to run this app on the old machine. I have looked around
GDK for some type of cursor flush/redraw routine but can't seem to find
any such thing. If there was a way to force a cursor redraw I might be able
to work around this, although I'm not sure how I could guarantee that the
cursor redraw would happen after the expose event is actually handled by
my draw handler.
Thanks!
Roger Davis
Univ. of Hawaii
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: problems understanding gtk3/gdk/cairo interaction
Hi John and Simon, OK, experiment complete. Performance for me is very clearly not as good as Xlib-style XOR when drawing rubberband lines which span a screen-sized window (which is more or less typical for my apps, unfortunately), but on the other hand it's not unusable either, just somewhat annoyingly jerky. With smaller drawing areas (e.g., 300x300) the rubberbanding is perfectly smooth. Playing around with motion hint events might clean this up a little more. I'm basically doing a cairo_rectangle()/cairo_fill() from my entire off-screen surface to the GtkDrawingArea after every MotionNotify event. There are special cases, e.g., small rectangular rubberband boxes, where this is horrific overkill, but I also have cases where I need to rubberband larger collections of unpredictably-oriented line segments which span the full window, so I think my worst-case scenario experimental implementation has been a reasonable test. The outcome could have been worse, and I was expecting that it would be! For now I'll tell my users to wait 5 years and then buy new hardware. ;- Thanks for all your suggestions! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk3 display/windowmgr interaction
Hi all, I have two questions with regard to gtk3 and its interaction with the window manager and X11 (or other) display. (1) Is there a way to precisely position (or at least request such a position for) a toplevel window? gtk_window_set_postion() seems to provide only very limited positioning ability (e.g., centering). My app has multiple toplevel windows and I would like to arrange them very precisely for minimal overlap (without user interaction if possible). I see other apps doing this (gimp, I think) so there must be a way, but I have not been able to crack the code myself. (2) Is there a way to get information about your display environment, e.g., screen dimensions and pixel sizes, without actually creating any widgets? Right now I'm getting this info by making (but not mapping) a toplevel window, then calling gtk_window_get_screen(), gdk_screen_get...(), etc., and then destroying the window. Seems like a waste as I would assume that gtk_init() is actually opening the display and hence this info should be available immediately after it's called. Not a major roadblock here, but it does seem a bit kludgy. I would ideally like to have this information before creating any toplevel windows (or widgets) at all. Thanks, Roger Davis Univ. of Hawaii ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: problems understanding gtk3/gdk/cairo interaction
On Thu, 12 Apr 2012, Simon Feltman wrote: You should be able to just fill the delta regions between the cursor position changes right? Basically a backwards L shape if you're dragging upper-left to lower-right. You would need to do two rect copies (or two calls to gtk_widget_queue_draw_area for each part of the L) as opposed to one. If items have a visible selected state that changes as you drag, then the regions for those items should simply be invalidated (but only if their state changes) along with the rubber band regions using gtk_widget_queue_draw_area. If I was only drawing a rubberbanding rectangle or a single line, yes. But sometimes I'm doing something much more complicated, like dragging an entire spiderweb of lines (which often spans virtually all of the visible window) across the top of a full-screen image -- in this case the damaged rect is virtually always the entire window, or near enough to it to make practically no difference. Xlib's bitwise-XOR was really nice for this, as I could individually redraw each overlaid line, probably a maximum of a few thousand pixels all together, instead of having to restore a full megapixel+, for each motion notify. cairo does have an XOR operator but it's not bitwise (rather some kind of Porter-Duff XOR which I don't exactly understand but which I am told is definitely not bitwise), hence of no use for this kind of thing as far as I can make out. Thanks, Roger___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
problems understanding gtk3/gdk/cairo interaction
to my surprise that when
I resize my toplevel window, monkey with the scrollbars, map/unmap the
window, etc., when draw() is called its cairo_t context argument is always
the same, but when I look at the underlying cairo_surface_t referenced by
that context it changes from time to time (especially in reponse to
scrollbar activity), even though the GdkWindow belonging to the
GtkDrawingArea also seems, like the cairo_t context argument, to never
change:
draw(GtkWidget *w, cairo_t *cr, gpointer gp)
{
GdkWindow *win;
cairo_surface_t *surf;
win= gtk_widget_get_window(w);
surf= cairo_get_target(cr);
printf(cr=%1x win=%1x surf=%1x\n, (unsigned long) cr,
(unsigned long) win, (unsigned long) surf);
...
}
Here is sample output from the above, generated by messing with the
toplevel window and scrollbars as described:
cr=2714640 win=2573d80 surf=2726620
cr=2714640 win=2573d80 surf=2727140
cr=2714640 win=2573d80 surf=2726620
cr=2714640 win=2573d80 surf=2724350
This behavior does not make me hopeful that I can find some way to create
a permanent cairo reference into my GtkDrawingArea widget that I can use
outside of draw() (or at least derive a usable reference at any time that
I desire outside of that callback). Although draw()'s cairo_t context
argument does appear to never change, the fact that the underlying surface
seems to change makes me very nervous that unpredictable circumstances
which I simply have not yet encountered through my as-yet-limited
experiments might in fact cause the context to change as well at some
point, since this behavior does not appear to be defined by the
documentation.
Experimenting further with GtkDrawingArea's realize() method, I tried
this:
static GdkWindow drawareawin;
static cairo_t drawareawincr;
realize(GtkWidget *w, gpointer gp)
{
drawareawin= gtk_widget_get_window(w);
drawareawincr= gdk_cairo_create(drawareawin);
...
}
This code does in fact correctly return the same GdkWindow which I can
derive via the above draw() callback's call to gtk_widget_get_window(),
but if I then attempt to draw using the cairo context returned by the
above call to gdk_cairo_create() on that very same GdkWindow from within
the draw() callback, nothing appears on-screen. (And not surprisingly,
cairo_get_target() shows a different underlying cairo surface for the
context made by gdk_cairo_create() vs. the surface which underlies the
context passed in as an argument to draw().)
There is another piece to this puzzle which I also do not understand,
namely that GTK widgets are supposed to be double-buffered by default, and
presumably this includes the GtkDrawingArea widget as well. If there is
documentation on exactly how this double-buffering works with regard to
GtkDrawingArea I would be greatly interested in seeing it to figure out if
there is some way I can make use of it. In particular, exactly when does
either of the two buffers get written, when and how does material get
transferred from one buffer (presumably the backing store buffer?) to the
other buffer (presumably the visible on-screen buffer?) and how can I
directly control such transfers and/or write directly myself via cairo
functions into either of the buffers, either from within a draw() callback
or at any other time?
So, what can I do about all of the above? Any insights into the apparently
strange behavior I am observing or suggestions as to what I should be
doing instead? I suspect there is much here that I may be
misunderstanding, but I'm not getting very far on my own, so pointers to
more detailed documentation would be greatly appreciated. Am I completely
barking up the wrong tree with GtkDrawingArea/GtkScrolledWindow, should I
be using something else? Is there no way to do what I need to do, i.e.,
get a scrollable drawing area which I can render either from within or
without a draw() callback? Should I give up and annoy the people on the
KDE/Qt mailing lists for a while? ;-
Thanks for your incredible patience in making it to the end of this
long-winded query!
Roger Davis
Univ. of Hawaii
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: problems understanding gtk3/gdk/cairo interaction
Hi Simon, Thanks for your thoughts, I read them after responding to John. Sounds like my wild guesses about the differences between gtk2 and gtk3 here are not too horribly wrong. I will read the docs you pointed to and take a look at the Clutter stuff, after I get some time to do the required experimenting and figure out if the performance is as bad as I am worried that it might be. Thanks again! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk2 - gtk3 minor visual issues
Hi all,
I am porting some code from gtk2 to gtk3 and am having some minor issues
with respect to visual appearance of various widgets. This is on a CentOS
6.2 Linux platform with CentOS-installed gtk2 and a self-installed gtk3
which I downloaded from gnome.org and installed into /usr/local.
AFAIK I'm using the latest of everything: gtk+-3.4.0, glib-2.32.0,
gdk-pixbuf-2.26.0, cairo-1.12.0, pixman-0.24.4, atk-2.4.0.
First, I have some code that creates and displays popup menus. Some items
in the popup menu trigger a pullright menu when selected. The popup menu
is being created with recursive code that looks roughly like this
(in crudely abbreviated pseudo-code):
GtkWidget *
make_menu(... menu item description arguments ...)
{
GtkWidget *m, *mi, *sm;
m= gtk_menu_new();
for each item in menu {
mi= gtk_menu_item_new_with_label(itemlabel);
if (submenu on this item) {
sm= make_menu(... submenu item description arguments
...);
gtk_menu_item_set_submenu(GTK_MENU_ITEM(mi), sm);
}
gtk_menu_shell_append(GTK_MENU_SHELL(m), mi);
}
}
The popup is then displayed with gtk_menu_popup( ... ).
This all works fine from a functional standpoint in both gtk2 and gtk3,
but in gtk3 the submenus attached to items of the top-level popup menu
are being drawn with no borders of any kind. Any idea why this is and how
I can fix it?
Second, all of my widgets appear to be getting drawn with a different
theme, e.g., the button and scrollbar styles, etc., look different. I am
using the Crux theme in my user environment.
Finally, when I run the application I get these messages:
Gtk-Message: Failed to load module pk-gtk-module
Gtk-Message: Failed to load module canberra-gtk-module
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not
be saved or shared with other applications.
Any idea how to fix any or all of these things?
Thanks!
Roger Davis
Univ. of Hawaii
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: modifiable dialog button labels?
Thanks, Lance! That looks promising, I'll try those (preferentially your
second method, I think, as you suggested.
Roger
On Thu, 8 Mar 2012, Lance Dillon wrote:
__
From: Roger Davis r...@soest.hawaii.edu
To: Lance Dillon riffraff...@yahoo.com
Cc: gtk-app-devel-list@gnome.org gtk-app-devel-list@gnome.org
Sent: Thursday, March 8, 2012 2:07 AM
Subject: Re: modifiable dialog button labels?
On Wed, 7 Mar 2012, Lance Dillon wrote:
you can use gtk_get_action_area() to get the GtkBox that that is the
action
area, that itself contains the buttons. I believe you can then get
all the
child widgets, which would be the GtkButtons.
The docs for GtkDialog describes it some, but doesn't talk about
getting the
buttons. I think you would have to go to the page for GtkBox for how
to get
the children.
Hi Lance,
The GtkDialog documentation tells only how to access the action area,
not its children. Searching around I see a gtk_container_get_children()
which presumably returns a list of GtkWidget pointers. Is there a way I
can look at a widget pointer and detrmine the widget's type, i.e.,
figure out whether or not it's a button? I see references to a
gtk_widget_get_type() on the web, but no good examples of how it's used,
and it appears to be not present at all in my own GTK release's
GtkWidget documentation. There also seem to be some related type
discovery functions in the gobject library such as g_type(), etc., but
so far I have not found any useful examples of how I might use them to
figure out if any particular widget pointer is a button or not.
Thanks,
Roger
You would then use g_type_is_a() (possibly), perhaps with G_TYPE_FROM_INSTANCE
and g_type_from_name():
GList *g,*g1;
g1=g=gtk_container_get_children(GTK_CONTAINER(gtk_dialog_get_action_area(dial
ogbox)));
while(g1);
if (g_type_is_a(G_TYPE_FROM_INSTANCE(g1-data),g_type_from_name(GtkButton)))
{
/* do something with button */
g1=g_list_next(g1);
}
g_list_free(g);
You can of course create the dialog without buttons with gtk_dialog_new(),
then add buttons manually with gtk_dialog_add_button(), and save the return
value which is the widget, then change the labels on the buttons when you
need to. That may be easier than the above:
GtkWidget *d;
d=gtk_dialog_new();
GtkButton *b1,*b2;
b1=gtk_dialog_add_button(GTK_DIALOG(d),Wine,1);
b2=gtk_dialog_add_button(GTK_DIALOG(d),Beer,2);
Then do your gtk_dialog_run() later. Then when you need to change the values,
you can just do gtk_button_set_label(b1,Dog);
gtk_button_set_label(b2,Cat), then reshow your dialog and gtk_dialog_run()
again.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
modifiable dialog button labels?
Hi all, I am trying to code some reusable GtkDialogs (i.e., create them only once, then hide and reuse them later as necessary rather than destroying and recreating every time). I need numerous dialogs which ask a simple question and then have two buttons for the user to choose between, e.g., Favorite drink? Wine/Beer Which way? North/South (Poor examples maybe, but you get the idea.) Seems like a waste to create a bunch of different dialogs that are all using the same basic structure, I would prefer to just create one and then modify its elements as needed. I can see how to change a text label inserted into the dialog's content area to alter my question text, but so far have discovered no way to alter the text labels used in the buttons which I supply at creation time to gtk_dialog_new_with_buttons(). Seems like this ought to be an easy thing to do, but I can see no way to retrieve any pointer to the dialog's button objects nor any way to explicitly set their labels after the dialog has been created. Any ideas? Thanks! Roger Davis ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: modifiable dialog button labels?
On Wed, 7 Mar 2012, Lance Dillon wrote: you can use gtk_get_action_area() to get the GtkBox that that is the action area, that itself contains the buttons. I believe you can then get all the child widgets, which would be the GtkButtons. The docs for GtkDialog describes it some, but doesn't talk about getting the buttons. I think you would have to go to the page for GtkBox for how to get the children. Hi Lance, The GtkDialog documentation tells only how to access the action area, not its children. Searching around I see a gtk_container_get_children() which presumably returns a list of GtkWidget pointers. Is there a way I can look at a widget pointer and detrmine the widget's type, i.e., figure out whether or not it's a button? I see references to a gtk_widget_get_type() on the web, but no good examples of how it's used, and it appears to be not present at all in my own GTK release's GtkWidget documentation. There also seem to be some related type discovery functions in the gobject library such as g_type(), etc., but so far I have not found any useful examples of how I might use them to figure out if any particular widget pointer is a button or not. Thanks, Roger___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk+ 2.24 installation problems
On Sun, 4 Mar 2012, jcup...@gmail.com wrote: Oh dear, I think you may have broken your system. You've overwritten files which were being run by your package manager with your own copies. This will break updates and may well cause other programs you haveinstalled to start crashing mysteriously. I think you probably need to wipe your computer and reinstall. Hi John, Nothing odd has happened yet, I'm keeping my fingers crossed! If anything does I'll probably just restore the original CentOS glib/gdk-pixbuf packages before doing anything more drastic. It's only a VM on my laptop so at least no one else will suffer from my stupidity (except the readers of this list, of course ;- ). Thanks for the warning, Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk+ 2.24 installation problems
Thanks, Allin. For one thing, you need to ensure that you're building 64-bit versions of the libraries if you want to overwrite the distro-supplied versions. I'm not familiar with CentOS but presumably this should be documented. It's building 64-bit versions all right, the problem seems to be putting them in the right place. Secondly, there's no point in building/installing obsolete unstable versions of the libraries in question (e.g. glib 2.27.93): use current stable versions, which for glib means 2.28.7 or 2.30.2. I picked 2.27.93 because the gtk+ 2.24 configure told me I needed glib 2.27 or greater. I figured getting the latest sub-release of 2.27 would (1) get me the most stable 2.27 and (ii) avoid any larger inconsistencies with the rest of CentOS that might be introduced by a much more recent version. At one point in my numerous experiments yesterday I did try to build the very latest 2.30 (I think 2.30.2) and the glib configure complained about yet more missing dependencies. Not needing an even greater headache I quickly abandoned that effort. Are you aware of something about 2.27.93 that makes it a particularly poor choice, or that makes 2.28.7 a particularly good one? I would definitely prefer to get myself as minimally far in front of the rest of CentOS as possible. Third, consider the environment variable PKG_CONFIG_PATH. Sleeping on things overnight I'm thinking the best option may be to go back to the default configure options, let all the new packages dump their stuff in /usr/local, and adjust my environment as necessary to pick up those libraries, etc., in advance of the CentOS-included ones, which would include adjusting PKG_CONFIG_PATH as you've advised. Hopefully if I do this then the pkg-config call that's used to set my compile flags and library directories will get me all the right stuff? Thanks! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk+ 2.24 installation problems
Hi all, After deciding to just let all of the gtk+ and related packages install themselves into /usr/local and resetting PKG_CONFIG_PATH things went much better. There was still one hiccup, however -- when I built gtk+ the make complained about not being able to find the file /usr/lib64/gdk-pixbuf/2.10.0/loaders.cache, even though PKG_CONFIG_PATH had /usr/local before /usr/lib64. I manually symlinked from /usr/lib64 to the right place and then the rest of the build proceeded OK. Did I need to do something else during the configure step, etc., to make things work the first time around without making this symlink? Thanks! Roger Davis ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk+ 2.24 installation problems
Thanks, Allin! I'll give that a try. Roger On Sat, 3 Mar 2012, Allin Cottrell wrote: On Sat, 3 Mar 2012, Roger Davis wrote: Secondly, there's no point in building/installing obsolete unstable versions of the libraries in question (e.g. glib 2.27.93): use current stable versions, which for glib means 2.28.7 or 2.30.2. I picked 2.27.93 because the gtk+ 2.24 configure told me I needed glib 2.27 or greater. I figured getting the latest sub-release of 2.27 would (1) get me the most stable 2.27 [...] In the GTK world, odd minor version numbers (such as 27 in this context) indicate unstable development releases. Thus the 2.27 development phase led to the stable release of glib 2.28, and the most recent bug-fix variant of glib-2.28 is 2.28.7, so that would be the version of choice -- if you want to avoid possible dependency issues in updating to the current stable version, 2.30. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk+ 2.24 installation problems
Hello all, I am trying to install the latest version of GTK+ v2 on my CentOS 6.2 system. The CentOS 6.2 install gave me v2.18, but I need some features that the GTK+ 2 reference manual says are available only in 2.20 or later. I downloaded the v2.24 source tarball from gtk.org, but when I did a './configure' it told me I needed to install newer versions of glib (= 2.27.3), atk (= 1.29.2) and gdk-pixbuf (= 2.21.0). I then downloaded those sources and first built glib 2.27.93 with a simple './configure --prefix=/usr; make; make install;'. That went fine, but when I went on to the gdk-pixbuf build it seemed to think I still had my original glib package rather than the updated version which I had just built and installed. Investigating further I found that gdk-pixbuf's configure script is calling pkg-config to look for these dependencies. Strangely, however, the file /usr/lib/pkgconfig/glib-2.0.pc which it supposedly examines to figure this out is a brand new file just dumped there by my recent glib 2.27.93 install, and that file's contents correctly state the new version number as 2.27.93. Does anybody know what's up with this? Alternatively, is there a reliable set of x86_64 binary RPMs for CentOS 6 that I can just grab from somewhere? I was not able to find any myself. Thanks! Roger Davis ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk+ 2.24 installation problems
Hello all, I've figured out a bit more with my installation issues but am still stuck. There are actually a number of pkgconfig directories on my CentOS 6.2 system. There's a whole scad of .pc files in /usr/lib64/pkgconfig, including glib-2.0.pc, so that would seem to be where CentOS originally put all of them. (I should note if I haven't already that this is an x86_64 system.) My recent glib install dumped the new .pc file into /lib64/pkgconfig, however -- /lib64 is the original CentOS location of libglib-2.0.so.0.2200.5, so I eventually re-ran my own glib configure to dump the new libglib-2.0.so.0.2793.0 into the same directory, i.e., I did './configure --prefix=/usr --libdir=/lib64'. The glib install wasn't entirely happy with this, however: Making install in gthread make[1]: Entering directory `/export/ctrobotv0d/glib-2.27.93/gthread' Making install in . make[2]: Entering directory `/export/ctrobotv0d/glib-2.27.93/gthread' make[3]: Entering directory `/export/ctrobotv0d/glib-2.27.93/gthread' test -z /lib64 || /bin/mkdir -p /lib64 /bin/sh ../libtool --mode=install /usr/bin/install -c libgthread-2.0.la '/lib64' libtool: install: error: cannot install `libgthread-2.0.la' to a directory not ending in /usr/lib make[3]: *** [install-libLTLIBRARIES] Error 1 make[3]: Leaving directory `/export/ctrobotv0d/glib-2.27.93/gthread' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/export/ctrobotv0d/glib-2.27.93/gthread' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/export/ctrobotv0d/glib-2.27.93/gthread' make: *** [install-recursive] Error 1 It otherwise seemed to complete OK, however, so after I manually copied my new glib-2.0.pc into /usr/lib64/pkgconfig where pkg-config wanted to find it, I got my gdk-pixbuf configure to complete without complaining that there was an outdated glib installed. Unfortunately the gdk-pixbuf build did not go so well: mv -f .deps/gdk-pixbuf-csource.Tpo .deps/gdk-pixbuf-csource.Po /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -DGDK_PIXBUF_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -g -O2 -Wall -o gdk-pixbuf-csource gdk-pixbuf-csource.o libgdk_pixbuf-2.0.la -L/lib64 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lpng12 -lm libtool: link: gcc -std=gnu99 -DGDK_PIXBUF_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -g -O2 -Wall -o .libs/gdk-pixbuf-csource gdk-pixbuf-csource.o ./.libs/libgdk_pixbuf-2.0.so -L/lib64 -lgio-2.0 -lgobject-2.0 /lib64/libgmodule-2.0.so -ldl /usr/lib/libglib-2.0.so -lrt -lpng12 -lm ./.libs/libgdk_pixbuf-2.0.so: undefined reference to `g_simple_async_result_take_error' collect2: ld returned 1 exit status make[4]: *** [gdk-pixbuf-csource] Error 1 Does anyone know what's up with g_simple_async_result_take_error? I found a few of reports of similar errors on the web but nothing that has led me to a solution so far. My problems seem to be rooted in the multiplicity of library directories on my CentOS x86_64 system (/lib, /lib64, /usr, /usr/lib64) and the related configure/pkg-config/libtool confusion. Can anyone with any experience with this point me to a path out of this swamp before I corrupt my whole GTK+ compilation environment, new or old? Thanks! Roger Davis ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: porting Xlib/Motif apps to GTK+
Hi Dov, Thanks very much for that interesting code example. I built it and it seems to work fine, so there is apparently a solution to my problem, however complicated it may turn out to be. I assume since no one has given me a short 'yes' answer to my question of whether you can easily do an XOR line draw in Cairo that the answer is in fact 'no'. That's really too bad, XOR is such a nice, easy solution to quickly drawing a visible overlay line (when one is not particular about its actual color) and then rapidly restoring the original underlying drawing with an XOR erase. A few of my rubberbanding operations are unfortunately a lot more complicated than just a single line or box. I will definitely save this very useful demo code, and probably bug you about it sometime in the future when I get to the point of rewriting all of my Xlib drawing ops. (Lucky you! ;- ) Thanks again! Roger On Wed, 29 Feb 2012, Dov Grobgeld wrote: On Wed, Feb 29, 2012 at 01:17, Roger Davis r...@soest.hawaii.edu wrote: [stuff deleted] Does Cairo have a way of mimicking an X11 XOR-op GC for doing low-overhead ephemeral drawing ops of rubberband-lines, etc.? I have over the years been intrigued of how to do flicker free rubberband selection with gtk/cairo. My current solution may be seen here: https://github.com/dov/dovtk-lasso Feel free to poke me if you need more explanations and more documentation of how it works. Regards, Dov ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: porting Xlib/Motif apps to GTK+
Hi Bernhard, Thanks for your thoughts! I will look further at GooCanvas and COGL to see what's there, although my existing app set doesn't really require any explicit object-oriented support. Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: porting Xlib/Motif apps to GTK+
Hi John, thanks for your comments! As you say, gdk_ is a thin layer over the X11 drawing system, so converting that is pretty easy. Gdk has quite a few helpers too, eg. stuff for rendering a 24-bit image to whatever visual the server has, so you can save some code there. It shouldn't be a huge effort to port. Too bad all of the GDK Xlib wrapper functions appear to be completely removed from GTK 3, it would have been a much easier port! Oh well. Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: porting Xlib/Motif apps to GTK+
On Wed, 29 Feb 2012, jcup...@gmail.com wrote: You need a compositing model instead. Your draw window should be a stack of 2D layers. In your expose callback, paint that part of the window back to front. Do rubberbanding by creating a temporary top layer with the rubber band in and queueing refresh events for the pixels it touches as it moves. Very simple, reasonably efficient, easy to make flicker-free with gtk's automatic double-buffering. Hi John, thanks for the followup. Excuse my deep ignorance on the topic but I'm just beginning to look into GTK/GDK/Cairo. Does the v2 release of this whole bundle include explicit support for the layering approach you describe, or are you talking about my code having to maintain this knowledge on its own (presumably by maintaining two separate drawing surfaces, with the primary image in one and my quasi-rubberband overlays in another), and explicitly overlaying them myself? What about the v3 release? Thanks! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
porting Xlib/Motif apps to GTK+
, at least until I retire (another 15 years or so) and this becomes somebody else's nightmare? ;- (7) If I decide to go this route, I need to have a stable GTK+/GDK v3 environment. This appears to not yet be available within CentOS 6, and I'm guessing it might not appear before CentOS 7. Any thoughts here? Is it possible for v3 and v2 to safely co-exist on my CentOS 6 system along with any other essential stuff (glib?)? Is there any documentation available on doing such a dual-version installation? Thanks a million for any thoughts or observations on the above! Roger Davis ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
