Using SVG for icons (and scaling)

I'm currently developing an application (using the Gtk 3.x series). I've got some icons I'd like to use (for buttons n' stuff) and they are in SVG format. It's pretty trivial to turn these into a PNG, and then into my .glade file. But I'm a bit concerned about how much smaller bitmap images

GLib may busy loop on invalid file descriptors

TRUE from g_io_unix_check by always checking for the errors * Test again in g_io_unix_dispatch but log an error and return FALSE if none of the requested conditions match. Thoughts? Benjamin PS: https://github.com/abrt/abrt/issues/1280 has some info on the specific issue. signature.asc

Re: GTK menus on Ubuntu

On Wed, 5 Oct 2016 21:11:41 -0400 (EDT) Allin Cottrell wrote: > I'm wondering if anyone knows the machanism whereby Ubuntu > "commandeers" the main menu system of a GTK application and sticks > it into the global top-of-screen menu bar, or combines it with the >

Re: Unicode normalization and text display differences

On 01/06, Behdad Esfahbod wrote: > Hi Ben, > > You at least need to tell us on what platform you are testing this and with > what fonts. Sorry, I'm running on Debian testing (libpango-1.0 package version 1.36.8-3) and using it through GObject introspection from python (although that's probably

Re: Unicode normalization and text display differences

On 01/06, Behdad Esfahbod wrote: > On 16-01-06 02:55 PM, Benjamin Kiessling wrote: > > On 01/06, Behdad Esfahbod wrote: > >> Hi Ben, > >> > >> You at least need to tell us on what platform you are testing this and with > >> what fonts. > > >

GUADEC meetup

Here's a FYI for all interested GUADEC attendees: We scheduled our yearly informal GUADEC GTK meetup on Monday morning. Details are on https://2015.guadec.org/bofs-and-hackfests/ See you then, Benjamin ___ gtk-devel-list mailing list gtk-devel-list

gtk_style_context_get()

Hey, Here's a problem I'm currently thinking about and would like input on. I discussed it with Matthias on #gtk+ today and he suggested I'd reach out to more people. I've included the log below and formatted it for clarity so that it reads like a QA-style interview. I hope it is not too

Re: gtk_style_context_get()

(so it should be fine to make them slow or weird if we have to), we should nonetheless make them possible. And we should make them possible in the way that people expect them to work. Benjamin On Fri, Jan 30, 2015 at 6:01 AM, Jasper St. Pierre jstpie...@mecheye.net wrote: This is a pipe dream, I

Re: State of gdk-pixbuf

Bastien Nocera hadess at hadess.net writes: I'm particularly interested to know what cairo, pixman and other image manipulation libraries can do for us. Benjamin surely has comments[2] :) I think gdk-pixbuf should just die already, but it won't. And now you're resurrecting it, dammit

Re: State of gdk-pixbuf

Benjamin Otte otte at gnome.org writes: Bastien Nocera hadess at hadess.net writes: Benjamin surely has comments[2] :) [2]: https://bugzilla.gnome.org/show_bug.cgi?id=491507#c13 I think gdk-pixbuf should just die already, but it won't. And now you're resurrecting it, dammit! 3

Re: Label with fixed size

, what your problem is about having the Fixed widget taking as much space as possible. The Gtk Philosophie is not always beautiful, but there are many different Gtk containers, thought for many possible designs. Sunny days, Benjamin On 18:06 Fri 29 Aug , rastersoft wrote: Hi! Well

Re: Label with fixed size

Ah wait, let me have a guess: You are drawing something and You want to have the ellipsized text inside the drawing? In this case: Why don't You just put the drawing area inside the Gtk::Fixed, maximizing it to the dimension of the Fixed and then putting the Label just above. On 18:06 Fri 29 Aug

Problems Sending Input/Focus to Plug Window - Solution

not follow the xembed protocoll correctly. Be wild and genius, Benjamin ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Problems Sending Input/Focus to Plug Window

/f179ff891f7c8029faf8 or clone it via: git clone https://gist.github.com/f179ff891f7c8029faf8.git Benjamin For reference, here is the code from the gist: Makefile: sockfoc: sockfoc.cc window_ext.h g++ -ggdb sockfoc.cc -o sockfoc `pkg-config gtkmm-3.0 --cflags --libs` -lX11 sockfoc.cc #include gtkmm.h

New icons features

' Try to draw a regular icon, i.e. try to not draw a symbolic icon. If no regular icon can be found looking at all possible icon names, fall back to the requested name As always: Comments, questions to me! Benjamin 1: http://dev.w3.org/csswg/css-images-3/#image-values 2: http://dev.w3.org/csswg

Re: New icons features

http://i.imgur.com/GksyZ02.gif On Thu, May 15, 2014 at 1:26 AM, Jakub Steiner jim...@gmail.com wrote: It's early Christmas! Thanks Benjamin, especially for the spinner. On Thu, May 15, 2014 at 1:19 AM, Benjamin Otte o...@gnome.org wrote: Hey, so I've landed the css-icons branch in git

_gtk_quartz_framework_init

Hey, I recently found this magic call to _gtk_quartz_framework_init() in the Quartz initialization code and after asking people on IRC it seems it's no longer used by anyone (was it ever?). So in my pursuit of code clarity I was wondering if I can just remove it. Can I? Benjamin

Re: Composite GtkBuilder template

, that was yours and Tristan's territory, I'm happy not to be involved in build issues. Other than that, I think it's ready to merge and let early adopters go and find bugs. Benjamin On Mon, Apr 8, 2013 at 1:30 PM, Matthias Clasen matthias.cla...@gmail.com wrote: Are we about ready to move forward

GtkWidget::visible

a chance to stop us before we release this as GTK 3.8. Benjamin 1: http://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget--visible 2: http://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-show 3: http://git.gnome.org/browse/gtk+/commit/?id

Rather evil crasher in 3.6.3

these don't get noticed. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Bug 687752 - work with theme authors

quickly anymore. And so far, that's what we want. Backwards compatibility is a huge time sink. Benjamin ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Bug 687752 - work with theme authors

and be styled using CSS properties. The behavior of these properties is specified in the CSS specifications and conforms to what browsers do for all the standard CSS properties that we do support. We are not there yet, but we know where we are going. Benjamin

Re: runtime accel changes

of unmaintained code, even if the cost to that is features. And if it turns out those features were great, hopefully someone will volunteer to add them back later. I'm pointing this out because I don't like the way of reasoning here. I have no real opinion on editability of keybindings. Benjamin

Re: gdk threads ...

for Mozilla.) Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

all about animations

to make things exciting for a while. So that's all for now. If there's questions, you know how to ask. :) Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: How to make a progress-bar thinner?

might also want to look into gtk_widget_set_hexpand/vexpand(). Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: CSS box model-gtk containers integration

. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+ 3.3.7+ bugfix will BREAK Xorg (before 1.12) unless patch is applied

. A workaround exists: If you export GDK_CORE_DEVICE_EVENTS=1, GDK will stop using XInput and use old-school X11 events, and that code path in the X server doesn't have that bug. Benjamin On Mon, Jan 9, 2012 at 8:11 PM, Olav Vitters o...@vitters.nl wrote: Company found a bug in the XI2 handling of GTK

Re: touch events

because of client-side windows. And the X server wouldn't know which event to send. So how do we fix this? I have no idea, but I suppose it'll cause lots of madness. That's it for today's episode of lots of fun with X Benjamin ___ gtk-devel-list mailing list

touch events

to a patchset based on these ideas: - Qt has device type TouchScreen vs TouchPad. Should we have that? - I suppose just having a GDK_TOUCH_MASK is enough? Does this look sane? Or are there any platform issues? Did I miss anything? Benjamin ___ gtk-devel-list

Re: Multitouch review 1: event capture

? Because grabbing inside a ScrolledWindow might get funny effects that you wouldn't expect when you grabbed stuff because the ScrolledWindow captures your events away from you? Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http

Re: gir stability

distcheck. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

How GTK styling works

. Benjamin 1: This even means you could reasonably attempt to try to use the GTK CSS machinery for styling other things (like librsvg or even ST/MX) if you wanted. Though that has certainly never been a design goal. 2: In fact, almost all the public API introduced for CSS with GTK 3.0 is already

RFC: new features

. However, a well-done maps widget would - just like a plot widget, improve visuals in a lot of places. That said, I have no idea if it is too specific a widget for GTK. So there you go. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http

RFC: UI design

, so they're equally unhappy. But I'd like that to change in the future. Benjamin 1: http://en.wikipedia.org/wiki/Graphic_design 2: http://en.wikipedia.org/wiki/Interaction_design 3: Hi Xan! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http

Re: RFC: UI design

guarantee that this function works well (as pointed out above) if it has to work with a light theme, a dark theme or any random theme downloaded from the internet, because - for a start - I don't even know which foreground color will be used. Benjamin ___ gtk

Re: RFC: UI design

of GTK would be way harder to change, because application would start to depend on the fact that treeview headers are white (and not light gray or greenishly tinted) because that would break their design. And we would need to change our themes with way more care. Benjamin

Re: wip/css

. :) Benjamin On Tue, Jan 3, 2012 at 4:31 AM, Benjamin Otte o...@gnome.org wrote: Happy new year everyone I spent too much of the holidays redoing the CSS infrastructure yet again. The result can be seen in the wip/css branch, or for the lazy, by clicking on http://git.gnome.org/browse/gtk+/log/?h

wip/css

while still maintaining a public API that says G_TYPE_INT. Thanks to Lap, Cosimo, Paolo and Zeeshan for reviewing the code while I was writing it instead of playing with fireworks. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http

Re: Modernizing the display loop [try 2]

it into the current mess we have in GTK. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: scrolling

this detail. I think the scrollables themselves - at least the ones inside GTK - don't need a lot of code to work without a bin window as we tend to call it. But that is just my very unscientific look at the code, not something I tried. Benjamin ___ gtk-devel

Re: RFC: scrolling (typo)

On Tue, Dec 6, 2011 at 6:26 AM, Benjamin Otte o...@gnome.org wrote: - viewport This is the widget that is actually managing the scrolling by drawing scrollbars, reacting to scroll events and such. This is roughly equivalent to GtkViewport from the GTK side. typo: This should read

RFC: scrolling

design the new scrolling. Easy: A So, if you followed along up to here, you'll surely have an opinion. So please go ahead. Ideally, you'd propose an API that solves all these issues and make me stop thinking about it. Benjamin ___ gtk-devel-list mailing

Re: GObjectClass.dispose and bringing objects back to life

to, but is not in any way related to how people write code in the real world. Benjamin 1: http://git.gnome.org/browse/gnumeric/tree/gnumeric.doap On Sun, Dec 4, 2011 at 3:15 PM, Morten Welinder mort...@gnome.org wrote: What we probably also should do is deprecate one of the two virtual functions, so people

GtkTreeView changes

running. /usr/bin = 12s vs 53s $HOME (4200 files) = 24s vs 63s Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

RFC: boxes

with an interface that is easy to export as public API so other people can tune these widgets or write their own easily. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: Model-View-Controller

a treeview. That's indeed kinda very useless. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: Model-View-Controller

On Fri, Nov 11, 2011 at 2:47 PM, Michael Natterer mi...@gimp.org wrote: Hi Benjamin, [snip typical German ecouragement talk] please give a small example. (disclaimer: just to illustrate the idea, might change a lot) So, a GtkButton is kinda complex from the input perspective, but simple

RFC: Model-View-Controller

and possibly IPC interact with it. Sounds like a plan? Benjamin 1: http://en.wikipedia.org/wiki/Cyclomatic_complexity 2: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http

Re: Patch for updating gtk over wayland interface

For review its always better to git send-email, and since this is wayland related it should be fine to send gdk-wayland patches to the wayland-list, maybe with a gtk prefix. To comment on the patch i'll copy the relevant parts for now. -  wl_display_sync_callback(display_wayland-wl_display,

Re: cross-platformness (was: GTK + Clutter next step(s))

configure switch for the time being. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK + Clutter next step(s)

nobody else wants to use it. Compared to the hell that is OpenGL, Cairo is like floating through the clouds with Megan Fox on your left and Emma Watson to your right while a choir of angels sings in the background. Benjamin ___ gtk-devel-list mailing

Re: GTK + Clutter next step(s)

to test with. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK + Clutter next step(s)

I want to have OpenGL usage in the possible realm, but I want to keep it away from the easy realm, so that nobody goes oh, that is easy, I'll just write my widget using OpenGL, because that would be wrong. You want to use GTK/Clutter mechanisms there. Benjamin

GTK + Clutter next step(s)

this is a rather important thing, because there is probably nobody with enough of a clue on how the end result should look. Certainly not me. Comments? Benjamin 1: http://mail.gnome.org/archives/gtk-devel-list/2011-August/msg00058.html 2: http://wiki.clutter-project.org/wiki/CoglDesign

Re: GtkTable is deprecated

warnings during compilation. So unless you have code that live-edits tables, your code will still continue to compile and run fine for the time being. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk

GtkTable is deprecated

expand and fill child properties. As always, should you have any questions, don't hesitate to ask. Happy hacking, Benjamin 1: http://git.gnome.org/browse/gtk+/commit/?id=08d578dfcbbbc4769d8c26de4ea0de4f76e1b2de 2: http://developer.gnome.org/gtk3/unstable/GtkWidget.html#gtk-widget-set-hexpand 3

Re: GTK+ 4.0 and Clutter 2.0: rainbows and unicorns

or not to continue using GObject properties. I'd like some elaboration on the pros and cons here, too. But I can get that using beers at the Summit, too. :) Benjamin 1: http://git.gnome.org/browse/gtk+/tree/gtk/gtkentry.c#n3456 2: http://rapicorn.testbit.eu/rapicorn.html

Re: Gail next steps (was Re: GTK and ATK)

docs, which they are a lot more likely to do than reading ATK docs. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: I have a problem

On Sun, May 29, 2011 at 1:06 AM, Paul Davis p...@linuxaudiosystems.com wrote: On Sat, May 28, 2011 at 5:01 PM, Benjamin Otte o...@gnome.org wrote: this is a cart vs. horse problem. i think you're absolutely correct that functionally, this is identical to a notebook. but there's function

I have a problem

the HIGs that we have, design beautiful interfaces by default and have them work hard should they insist on something ugly. But that requires me knowing what I need to look for. Thanks, Benjamin 1: https://bugzilla.gnome.org/show_bug.cgi?id=646841 2: https://bugzilla.gnome.org/show_bug.cgi?id

Re: [pygtk] reserve screen space / prevent overlapping

On 27 May 2011 01:28, John Stowers john.stowers.li...@gmail.com wrote: On Wed, 2011-05-25 at 22:50 +0200, Benjamin Trias wrote: Hi list, I am trying to port from Gtk+2 to Gtk+3 using Python (PyGobject Introspection) I am trying to find the equivalent of: gtk.Window.get_toplevel

reserve screen space / prevent overlapping

window properties with PyGI to reserve screen space? Could a binding be missing? Or do i miss some library? Anyone has an idea? Thanks. Benjamin ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list

Reserving screen space / preventing overlap

is very much lacking, I'm struggling on each line to find out the syntax. Is there any plan to document this better? I have started a modest blog where I plan to put all my findings as I go, if you want to participate let me know, (http://gtk3lab.blogspot.com/). Regards, Benjamin

Re: CSS type selector specificity

The parser branch has landed in git master now after Cosimo and me grinded on it for a while. If you notice something not looking right after updating gtk _and_ gnome-themes-standard, please complain to one of us. Benjamin On Thu, May 12, 2011 at 1:23 PM, Benjamin Otte o...@gnome.org wrote

CSS type selector specificity

their own fault, they should be using * (which has a lower specificity). Benjamin 1: specificity for regular CSS is explained at http://www.w3.org/TR/CSS21/cascade.html#specificity ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http

align vs expand vs grid

this and because I wasn't involved in the original design discussion and might be missing something, I'd welcome some more input on this. Benjamin 1: If I were ranting, this would include something about people adding functionality to GTK without actually porting at least a few applications

GtkButton vs. GtkLabel font relief: how to customise one or the other?

this problem on StackOverflow with screenshots: http://stackoverflow.com/questions/5924037/gtkbutton-vs-gtklabel-font-relief-how-to-customise-one-or-the-other Thanks for your help. Benjamin ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org

Re: reftests

either way. I guess Matthias is the one that gets to decide here. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: reftests

to write a reftest. Benjamin On Tue, May 3, 2011 at 10:01 PM, Benjamin Otte o...@gnome.org wrote: Hey, with the latest commits[1] I have added reftests to GTK. Reftests are my approach at getting layout and rendering behavior of gtk tested. I've added a bunch of tests already for the things I

Re: reftests

first need to have a use for these test paths. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

reftests

useful outputs. In particular, it should be easy to skip it. So, this got longer than I expected it to get. So I better close now. Questions? Benjamin PS: Credit for this test runner goes to David Baron, Robert O'Callahan, Carl Worth, Sandro Santilli who inspired me to spend more time on testing

Re: Please fill out the GtkLabel questionnaire

rendering.) Benjamin 1: http://people.freedesktop.org/~company/stuff/label-fun.ui 2: http://people.freedesktop.org/~company/stuff/label-fun.ref.ui 3: http://people.freedesktop.org/~company/stuff/label-fun.ref.png 4: http://people.freedesktop.org/~company/stuff/label-fun.org.png 5: http

Please fill out the GtkLabel questionnaire

for some weird corner case. Enjoy, Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK2

This is what GTK2 thinks (note that minimum == natural because size requests weren't that smart in GTK2 land) properties characters requested wrapellipsize width_chars max_width_chars minimum natural false false -1 -1

Re: GTK3

Here's the answers of GTK3: properties characters requested wrapellipsize width_chars max_width_chars minimum natural false false -1 -1 10 10 truefalse -1 -1 10

Re: Please fill out the GtkLabel questionnaire

-width-chars is set, reduce the natural size to this many characters. 3) Ensure the natural size is at least as big as the minimum size. This is the algorithm I'll try to implement if nothing better comes up. Benjamin #include gtk/gtk.h static void check_width (GtkWidget *label

Re: Please fill out the GtkLabel questionnaire

width of the text is bigger than any of those properties, that size will be used instead, but the natural width of the text is ignored if the max-width-chars property is set. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http

Re: pictures

% would not make sense in GTK for example.) Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

pictures

this is the state that I'd like to talk about. Comments? Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: pictures

into an iconview without blocking. (I suspect they'd use webkit for that today?) Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

3.0: remove client messages

of this mail: Is there an actual user of this? Cheers to Xan[1], Benjamin 1: http://twitter.com/xanlpz/status/31394054252003329 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Bad portability by foreign_new_for_display

API ready for multi-backend GTK. They need to be changed before we can ship GTK 3.0. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building multiple backends on on same system

way better (because you don't have missing function definition complaints from gcc, but useful output). I vote or the second btw. Benjamin On Mon, Dec 13, 2010 at 4:03 AM, Matthias Clasen matthias.cla...@gmail.com wrote: On Sun, Dec 12, 2010 at 1:37 PM, Alexander Larsson al...@redhat.com wrote

Re: Building multiple backends on on same system

code should take care of them. But the current situation is that even people who worked on the DND code have no idea what it's for. (I asked in #gtk+ and nobody had any clue.) Benjamin On Fri, Dec 10, 2010 at 6:22 PM, Matthias Clasen matthias.cla...@gmail.com wrote: I have mostly taken care

Some comments on the StyleContext stuff

GtkStyle, please? And deal with the fallout? It's not like people don't have to rewrite their draw functions anyway for GTK2 = GTK3 ... Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building multiple backends on on same system

this for 3.0? Because I don't think it's doable in an API-stable way during 3.x? Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building multiple backends on on same system

fields, removing outdated APIs that do stupid things (like gdk_utf8_to_string_target) and things like that. Not the actual implementation of the idea. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman

More GTK breakage

gdk_window_foo(). Most prominently gdk_x11_drawable_get_xid() is now called gdk_x11_window_get_xid(). As always, if you have any issues, feel free to poke me. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman

Re: Docs for the gtk-style-context branch changes

mean you get to do more work, probably a lot more work. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Docs for the gtk-style-context branch changes

of the port. Examples: gnome-desktop, evolution, gnome-panel, gnome-utils You will usually get called to help the second set of projects. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

gtk-style-context notes

will probably start to commit some more intrusive changes to gtk-style-context (or if preferred a new branch). Benjamin signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http

Re: GtkSpreadTable ('spread-table' branch)

On Thu, 7 Oct 2010, Tristan Van Berkom wrote: Some technical caveats: - When there are over ~12 columns the whole thing slows down significantly. The reason for this being, the algorithm in place starts by lining up all the widgets in the first column and then evening them

Re: rendering-cleanup-next

details that we might want to change later (like background handling), but we can do that after rendering-leanup-next hit master. So I consider it ready to merge. Comments? Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http

Re: rendering-cleanup-next

with. ;) Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: rendering-cleanup-next

Fixed in http://git.gnome.org/browse/gtk+/commit/?h=rendering-cleanup-nextid=99f0da58168e3db6cdf8c27c4239afc600bef058 Thanks for pointing out that flag, I never realized it exists. Benjamin On Wed, Sep 15, 2010 at 2:36 AM, Havoc Pennington h...@pobox.com wrote: Hi, On Tue, Sep 14, 2010 at 7

Re: padding cleanup

to Linux or even from Cairo's image surface to X. So I'd strongly recommend not comparing to reference images if you can avoid it. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: rendering-cleanup-next

where the origin of the cairo_t is. You'll notice in all the Port to draw vfunc patches that I removed allocation.x/y from the x/y parameters. The original paint functions that took a GdkWindow were window-relative so had to take into account allocation.x/y. Benjamin

Re: rendering-cleanup-next

the windows). And I think it's best to rely on allocation.x/y, even if all the other events don't. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: rendering-cleanup-next

from a widget currently seems to be to require that it is drawable. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

  1   2   >