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 in
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-sh
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 ti
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
To: gtk-app-devel-list@gnome.org
Subject: Re: Fwd: Gtk3 M
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
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
y 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 mutt
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
qui
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 environme
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
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, w
ents/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
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=,
file=, other_file=, type=optimized out>, model=0x22b4d80) at gtkfilesystemmodel.c:1912
#10 gtk_file_system_model_monitor_change (monito
ilure.
Any 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_*_r
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.
Thank
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/l
sh 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
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 downgrad
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-deve
hink 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
ng 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
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 e
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
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
unm
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 remaini
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, bu
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 .t
$ 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
ation 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
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
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 thi
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 interpr
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 wi
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
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
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
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 f
nformation 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
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 somewha
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
Hi John,
Thanks for your thoughts as always. I think there may be some significant
differences between gtk2 and gtk3 on these points, although this guess is
based almost exclusively on reading documentation at this point as opposed
to actual experience, of which I have about zero. Given the m
ea 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
___
sage: 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
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
To: Lance D
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
n 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@gnom
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.
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
st
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
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
em 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 env
s? 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
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 ref
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
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-l
Lucky you! ;-> )
Thanks again!
Roger
On Wed, 29 Feb 2012, Dov Grobgeld wrote:
On Wed, Feb 29, 2012 at 01:17, Roger Davis wrote:
[stuff deleted]
Does Cairo have a way
of mimicking an X11 XOR-op GC for doing low-overhead ephemeral
drawing ops
of rubberband-l
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 mai
57 matches
Mail list logo
