Re: Gtk3 MacOS (OSX) context menu issues

2015-03-20 Thread Roger Davis


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')

2015-03-16 Thread Roger Davis


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')

2015-03-15 Thread Roger Davis


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')

2015-03-15 Thread Roger Davis


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

2015-03-06 Thread Roger Davis


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

2015-03-06 Thread Roger Davis


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

2015-03-04 Thread Roger Davis

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

2015-02-28 Thread Roger Davis


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

2015-02-25 Thread Roger Davis


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

2015-02-25 Thread Roger Davis


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

2015-02-25 Thread Roger Davis


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

2015-02-24 Thread Roger Davis

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?)

2014-03-18 Thread Roger Davis
 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?)

2014-03-18 Thread Roger Davis


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 toplevel resize bug?

2013-03-30 Thread Roger Davis

Hi all,

I have some questions about gtk+ window manager interaction relating to
what appears to me to be a bug in the latest 3.8 release. The reference
manual for 3.8, under the description of the gtk_window_set_default_size()
routine, states that

   The default size of a window only affects the first time a window is
   shown; if a window is hidden and re-shown, it will remember the size
   it had prior to hiding, rather than using the default size. 

The latter half of the above sentence no longer appears to hold true for
many of my apps after switching from 3.6.2 to 3.8 -- when I do a
gtk_widget_hide() on a toplevel window and subsequently do a
gtk_widget_show(), the window does not reappear at the same size it had
just before it was hidden. Instead, it reappears at a postage-stamp size
that is just large enough to display the window manager control buttons in
the titlebar added by the window manager. I am quite certain that I am
doing nothing to these windows myself between the hide and show calls.
Under 3.6.2, all of my apps perfectly conformed to the behavior described
by the documentation, and they are now universally broken in this regard.
This is happening under CentOS 6.4, with all gtk-related packages except
pango (still at 1.32.4 due to the configure problems mentioned elsewhere
on this list) upgraded to current revisions.

This may have something to do with the particular nature of my toplevel
windows, as I can't believe that general behavior like this would have gone
unnoticed in the 3.8 release development process. My typical toplevel window
contains a GtkScrolledWindow (using GTK_POLICY_AUTOMATIC) as its only direct
child, which in turn contains a GtkLayout as its only direct child. The
latter will contain many different children of various types depending upon
its purpose. Before I first map the toplevel, I calculate the minimum size
(w, h) needed to show everything contained within the GtkLayout, and that
size is used as follows:

gtk_window_set_default_size(GTK_WINDOW(toplevel), w, h);
gtk_layout_set_size(GTK_LAYOUT(layout), w, h);
geom.max_width= w;
geom.max_height= h;
gtk_window_set_geometry_hints(GTK_WINDOW(toplevel), NULL, geom, 
GDK_HINT_MAX_SIZE);

When the toplevel is initially mapped with gtk_widget_show() it appears
at the correct size, with no scrollbars visible. The user cannot enlarge the
window because of the GDK_HINT_MAX_SIZE setting, but can make it smaller, in
which case the scrollbars appear. All of this still happens properly in 3.8.
My problem is that when the window is hidden and reshown, under 3.8 it now
does not reappear at the same size it was before unmapping, but rather at
the ridiculously small size noted above (although the user can still enlarge
it up to GDK_HINT_MAX_SIZE).

So, my questions are as follows:

(1) Is it still policy that any toplevel window which is hidden and reshown
should reappear at its last visible size if the application does nothing
between the hide and show to alter its size? The manual still says so,
and I should think that from the user standpoint this would still be
the expected reasonable behavior.

(2) If the answer to #1 is yes, then does anyone see anything in the
foregoing description of my toplevel window details that would contribute
to breaking that policy?

I have tested a workaround that seems good so far (maintaining my own memory
of window sizes through configure event handling, then manually resizing the
windows to those sizes just before remapping), but it seems awfully kludgy
and a lot of work as I have lots of windows in my apps to patch up. If this
is truly a 3.8 bug, I would greatly prefer to just see that bug get fixed!
I can work up sample demo code as necessary to demonstrate this behavior,
but before I do so I just wanted to see if anyone had any observations on
the above.

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


3.8 invisible widget change breaks my app

2013-03-28 Thread Roger Davis

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: 3.8 invisible widget change breaks my app

2013-03-28 Thread Roger Davis

Nevermind!! gtk_widget_show_all(w) fixes all. I thought by 'visible'
the change notes meant 'really truly visible on the screen'.

Sorry to bother everyone.
___
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

2013-03-27 Thread Roger Davis

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

2013-03-26 Thread Roger Davis

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

2013-03-26 Thread Roger Davis

[ 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

2013-03-26 Thread Roger Davis

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

2012-11-25 Thread Roger Davis

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

2012-10-22 Thread Roger Davis




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

2012-10-21 Thread Roger Davis

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

2012-10-21 Thread Roger Davis

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

2012-10-21 Thread Roger Davis



$ 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

2012-10-21 Thread Roger Davis



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

2012-10-21 Thread Roger Davis



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

2012-10-21 Thread Roger Davis


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

2012-10-21 Thread Roger Davis


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

2012-10-01 Thread Roger Davis

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

2012-09-30 Thread Roger Davis


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

2012-09-30 Thread Roger Davis

Thanks, Nicola.


AFAIK GtkRBTree (hence _gtk_rbtree_insert_after) is
used extensively by GtkTreeView


I was wondering about that, but unfortunately my code does not explicitly 
use any GtkTree* objects! Is there any way to search the documentation 
efficiently to determine which object types are inheriting from 
GtkTreeView? I have begun searching on my objects one by one (e.g., 
GtkMenu, etc.), but I am not finding any that appear to inherit from 
GtkTree*. Of course my app uses dozens of different object types and it 
will be quite a chore to exhaustively search the documentation of each one 
to examine its object hierarchy graph. I suspect that in the end I will 
come up empty, as I have already looked at the objects I am using which, 
by their appearance, look the most related to a GtkTreeView, e.g., menus, 
file chooser dialogs, etc.


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

2012-09-30 Thread Roger Davis


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

2012-09-30 Thread Roger Davis



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

2012-08-31 Thread Roger Davis

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

2012-04-12 Thread Roger Davis



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

2012-04-12 Thread Roger Davis


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

2012-04-12 Thread Roger Davis


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

2012-04-06 Thread Roger Davis
 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

2012-04-06 Thread Roger Davis

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

2012-03-29 Thread Roger Davis

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?

2012-03-08 Thread Roger Davis
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?

2012-03-07 Thread Roger Davis

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?

2012-03-07 Thread Roger Davis



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

2012-03-04 Thread Roger Davis



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

2012-03-03 Thread Roger Davis

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

2012-03-03 Thread Roger Davis


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

2012-03-03 Thread Roger Davis

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

2012-03-02 Thread Roger Davis

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

2012-03-02 Thread Roger Davis

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+

2012-02-29 Thread Roger Davis

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+

2012-02-29 Thread Roger Davis

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+

2012-02-29 Thread Roger Davis


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+

2012-02-29 Thread Roger Davis



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+

2012-02-28 Thread Roger Davis
, 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