Hey,
The intention is indeed to only link gdk-pixbuf-buffer-queue.c into the tga
loader, not into the main libgdkpixbuf.
GdkPixbufBufferQueue is only used by the TGA loader (so far) and as it's
utility code for the loaders, it should not be public API.
Benjamin
On Mon, Oct 19, 2015 at 8:10 AM, I
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@gnom
it much -- we should be synchronized to that in any case.
>
> I haven't investigated how much breakage something like that would cause.
>
> On Thu, Jan 29, 2015 at 11:51 PM, Benjamin Otte wrote:
>
>> Hey,
>>
>> Here's a problem I'm currently thinking a
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 inconveni
Benjamin Otte gnome.org> writes:
>
> Bastien Nocera 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
Bastien Nocera 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!
The reason i
http://i.imgur.com/GksyZ02.gif
On Thu, May 15, 2014 at 1:26 AM, Jakub Steiner wrote:
> It's early Christmas! Thanks Benjamin, especially for the spinner.
>
> On Thu, May 15, 2014 at 1:19 AM, Benjamin Otte wrote:
> > Hey,
> >
> > so I've landed the css-ico
Hey,
so I've landed the css-icons branch in git master and wanted to document
the changes we did there so people can start using them.
Icontheme
===
The icontheme now handles ltr and rtl variants of icons. GTK widgets will
do that lookup automatically based on the text direction of the widget
Hey,
As part of the installed-tests work in master I've moved all tests into a new
testsuite/
directory in the sources toplevel directory.
In particular, these directories moved:
gdk/tests => testsuite/gdk
gtk/tests => testsuite/gtk
tests/a11y => testsuite/a11y
tests/css => testsuite/cs
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
_
Yes, I've perfected the API with Tristan for a while and I'm happy
with it. From our last discussion the things we were waiting on were:
- Ryan's construct properties work
I think the conclusion here was to merge anyway and adapt gtk once the
glib work lands.
- The intltool issue
No idea, that was
Hey,
Today, in my quest to make things clearer in the GTK core, I'm
tackling GtkWidget::visible.
The flag is documented as "Whether the widget is visible."[1] or a bit
better in the documentation for gtk_widget_show() as "Any widget that
isn't shown will not appear on the screen."[2]
However, this
Hi,
Apparently GTK 3.6.3 contains a small bugfix that causes a rather
severe crasher. It happens at least whenever you try to measure the
size of a combobox, but there's probably other callers of
gtk_style_context_get_font() that fall into this particular trap. And
because a lot of applications us
Michael Natterer gimp.org> writes:
> I think my actual point here is: There are so many usecases
> and levels of complexity in peoples' workflows, and
> in the applications that can be written in GTK+, we should
> not disable useful things because they are either not in
> fashion any longer accor
On Tue, May 22, 2012 at 10:59 AM, Martyn Russell wrote:
>
> I've always believed libraries should do the job that *many* projects would
> have to re-implement. It just doesn't make sense from a maintenance and bug
> fixing point of view to have many solutions to the same problem scattered
> around
Michael Meeks suse.com> writes:
>
> The unfortunate thing about
> this design is that every toolkit user gets to re-write a bus-load of
> boiler plate stubs & skels and link them into every application. Why not
> do that, just in a better way, inside the toolkit ?
>
(Disclaimer: This is my pers
So,
there's a branch innocently named wip/cssvalue in git master that
implements what I teasered in
http://blogs.gnome.org/otte/2012/04/02/gtk-3-6/ and IMO is ready for
master (after 3.4 branched off of course).
What does this branch do? Here's the TL;DR version:
- Speed up CSS by a factor of 10
2 things:
1) You cannot force widgets smaller than their minimum size in GTK 3. This was
allowed in GTK 2. (And it crashed only sometimes!)
2) You can try to use gtk_widget_set_halign/valign() to make sure the widget
doesn't fill the space it's assigned to.
bonus:
While you look into sizing, you m
On Tue, Mar 20, 2012 at 1:01 PM, Peter Hurley wrote:
> Ok. My question was more aimed at finding out what the first steps in
> that migration might look like.
>
The first step that I want to do is redesign the way widgets draw
things. This is generally known by the term "render objects" or
"actors
Emmanuele Bassi gmail.com> writes:
> I guess we'll have to maintain the gdk_threads_set_lock_functions(),
> and internally use gdk_threads_enter()/_leave(), even if the API is
> not available in public headers.
>
No, we will not.
If you want to use GTK, you will have to ensure that all GTK func
Peter Hurley hurleysoftware.com> writes:
>
> Hi,
>
> Is there a plan for implementing the CSS box model into existing
> containers?
>
Yes, the idea is to support the full CSS box model and only the CSS box model.
Widget style properties will go away. No idea how long that will take though.
Be
Here's a heads-up on this patch: We've held up on applying this patch
to give developers a chance to get their servers fixed. But we want
this patch in 3.4, so it has now landed. So if you are running a GTK
>= 3.3.19, you need to have an up to date X server or you'll see weird
focus behavior.
A wo
So, here's few interesting things I learned in the last few days while
talking to people about touch (mostly Peter Hutterer and Chase
Douglas, more power to them for getting my X up and running with touch
events).
1) There is a huge difference between touchscreens and touchpads.
No platform exist
So from reading Matthias' mails it seems to me that this is the first
step, so we should get this right first. We should have a good idea of
where we want to go, but we don't need to merge the full multitouch
branch to get touch events. So let's start small.
Note that I do not have any touch-capabl
Ryan Lortie desrt.ca> writes:
> We need to figure out what our story is with respect to annotations.
> 'Rename to:' is an extreme example (since an entire function, as named,
> disappears) but we can easily cause problems just as serious with
> changes that look a lot more innocent (like changing
Matthias Clasen gmail.com> writes:
> - This is almost convenience api - except for the interaction with
> event capture, every widget could do this itself with a timeout and a
> handrolled animation. But having this supported consistently across
> the desktop seems well worth it. The branch add p
Matthias Clasen gmail.com> writes:
>
General questions:
- How does that integrate with EventControllers?
This is more of a "thing to think about" than a question, but I think it's
interesting that this works well in a world where we have EventController
objects and run on top of Clutter. So I g
CSS goes in, styled windows come out. You can't explain that.
And quite frankly, that sucks. So here's a high-level overview of how
the GTK CSS machinery works in master. I'll also include some mentions
of changes I expect to make in the future to improve per- and
conformance, but I'll be sure to
One thing I've been wondering about is what features GTK is missing.
This is mostly about developer-visible APIs, ie new widgets, and not
about internal changes. I have some ideas from IRC discussions, mails
and applications, but of course there might be big things I'm missing.
So personally, I co
On Mon, Jan 9, 2012 at 5:59 PM, Jan Jokela wrote:
> Hej, great read!
>
> Regarding your point on Application design & theming for different form
> factors, I think there isn't any logic in even attempting the same user
> interface design (not talking about theming here) for lets say, desktops and
On Mon, Jan 9, 2012 at 5:40 PM, Tristan Van Berkom wrote:
> I think the first thing we have to keep in mind is that while well-known
> use cases of GTK+ are in the domain of "desktop applications" there
> is a great deal of use cases that are not tied in to desktop environments
> (be they, mobile
Hey,
Here's another discussion point I want people to think about before
the hackfest. This time it's not so much about API in a direct way but
more about a guiding principles for the kinds of APIs we want to
provide. The short question is this:
Who gets to decide how an application looks?
Thi
's not on the branch
because it _really_ breaks Adwaita. :)
Benjamin
On Tue, Jan 3, 2012 at 4:31 AM, Benjamin Otte 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 th
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
I'm posting this here so that people can have a look at it and comment
o
Owen Taylor redhat.com> writes:
> My basic idea is to have a "Window Clock" object that serves as the
> central point of timing coordination for each toplevel window.
>
Why is this a property of a window? Aren't clocks specific to a screen/display?
>From the message you sent to wm-spec list it
On Fri, Dec 9, 2011 at 3:48 AM, Matthias Clasen
wrote:
> gtk_scrolled_window_add_with_viewport lets you largely get away with
> pretending you are in case C), right ?
> It just automatically inserts a GtkViewport between the
> GtkScrolledWindow and your 'large canvas' widget. Taken together
> GtkS
Hey Emmanuele,
Here's a follow up to our IRC discussion. For everyone reading along,
we discussed about
http://wiki.clutter-project.org/wiki/Clutter/Apocalypses/Apocalypse1#Actor_hierarchy
and I wanted to poke the Webkit guys to figure out how Webkit handles
children in the DOM. I wanted to figure
On Tue, Dec 6, 2011 at 6:26 AM, Benjamin Otte 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 sho
Hey,
Here's another one of those mails about stuff to think about for the
hackfest. This time I have no clue at all what I consider the solution
we should take and I've been thinking about this since at least the
last hackfest. Relevant links to this are:
https://live.gnome.org/GnomeOS/Design/Wh
I would be somewhat tempted to listen to all the stuff you're saying
below. But then I looked at the code you maintain[1], and I realized
it doesn't do anything of that. So I'm inclined to think that what
you're talking about is more about an ideal world that you wish we all
aspired to, but is not
Tristan Van Berkom gnome.org> writes:
> Yes, real-world well-written GObjects *must* not crash after being disposed,
> code that crashes because apis are called after dispose time are bugs,
> and you should fix them as specially if you have possible circular object
> references.
>
This is of cou
Hey Kris,
sorry for the late mail, I wanted to get to it earlier, but I forgot.
I blame Matthias wanting to get a release out. :)
In case you didn't notice, I did some refactoring in the treeview code
and pushed it to master. It's mainly meant for the accessibility
implementation. I'll continue d
On Wed, Nov 16, 2011 at 9:37 AM, Kristian Rietveld wrote:
> If there are multiple views, which are changed by which controller? What
> complicates thinking about this for me is that in MVC as I know it, there is
> 1 Model, 1 View and 1 Controller for each "thing".
>
I think this is where the m
So, next idea. I'm pretty sure about this one actually and have talked
to it with people on IRC a lot. Again I have no idea how it will look
in detai, but I know I want to get there.
This one is all about layouting complex widgets. It again has nothing
to do with the public API or ABI of GTK and i
On Fri, Nov 11, 2011 at 2:47 PM, Michael Natterer 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 for drawing.
Hey,
so I've been thinking about this for a bit, and I think it's a good
idea, but I wanted to see if other people have an opinion about it.
And I wanted to get it into people's minds before we sit down for a
hackfest.
So this idea is a result of the mainly the following things:
- Clutter integra
On Sun, Oct 30, 2011 at 1:45 PM, Michal Suchanek wrote:
> The question is: why should they not use OpenGL instead of Cairo?
>
> OpenGL is a defined api (although poorly in some respects) just as Cairo is.
>
OpenGL is a piece of shit API. If you can do something wrong when
designing an API, OpenGL
On Sun, Oct 30, 2011 at 8:38 AM, Kristian Rietveld wrote:
> I find this a rather weird statement. To me, GL support is an important
> requirement for a windowing toolkit. There are very valid reasons to use GL
> in GTK+ applications, such as CAD and scientific visualization, as Peter
> Clifto
> GTK+ 3 actually does work reasonably well on OS X.
>
> Whether or not you are concerned about other backends is a discussion that
> has been had before -- is GTK+ a cross-platform toolkit or should other
> backends not hold the X11 part from progressing? Perhaps it is time that a
> real decisi
On Sat, Oct 29, 2011 at 2:03 PM, Peter Clifton wrote:
> The PCB design CAD software I work (in the gEDA suite) on has this
> requirement, and currently uses GtkGlExt with GTK 2.0. Migrating to GTK
> 3.0 is of course not possible at the moment, as GtkGlExt is not ported
> to GTK 3.0, and a lot of t
On Wed, Oct 12, 2011 at 12:43 PM, Robert Bragg wrote:
>> - Make sure all native GdkWindows are valid framebuffers for Cogl
>> - Does that work today? What do we need to be careful about?
>
> One thing worth noting here is that we don't yet have proper OSX
> support in Cogl. Currently the OSX wins
After Emmanuele's mail[1] I've been wondering how to get there. In
particular, I've been wondering how to get there incrementally, so
that when we finally release a GTK 4.0, we can support a transition
that is as smooth for applications as the transition to GTK 3.0.
I think that the best first ste
On Thu, Sep 29, 2011 at 6:30 PM, Johannes Schmid wrote:
> This is a massive change to existing GtkBuilder .ui files so I would
> suggest that somebody able to do xml and/or sed/grep magic would write a
> script that just replaces GtkTable with GtkGrid in existing .ui files. If
> that is included i
Hey everyone,
So now with GNOME 3.2 out, it's time to make GTK break builds again.
So I deprecated GtkTable in GTK master[1]. GtkTable is turned more and
more problematic as GTK 3 evolves and the implementations of
height-for-width improved, which GtkTable does not support. So we were
ending up wi
Emmanuele Bassi gmail.com> writes:
>
> a) drop GTK+, move to Clutter and port the complex widges over;
> b) re-implement Clutter inside GTK+;
> c) use Clutter between GDK and GTK+;
>
I would translate that as:
a) tell GTK developers their code is crap
b) tell Clutter developers their code i
Piñeiro igalia.com> writes:
>
> On 06/07/2011 05:06 PM, Emmanuele Bassi wrote:
> >
> >> 5) figure out new interfaces for GTK to expose necessary features to
> >> a11y (and other consumers, such as IM and OSK)
> > we should probably establish some common interfaces so that Clutter can
> > expose
On Sun, May 29, 2011 at 1:06 AM, Paul Davis wrote:
> On Sat, May 28, 2011 at 5:01 PM, Benjamin Otte 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, and the
Hey,
I have a problem. I've not talked about this a lot, but it has crept
up in my work of trying to improve GTK. It's the problem with how I
see developers in GNOME currently approach developing the user
interfaces for their applications. I have a feeling it goes something
like this:
- Someone co
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 wrote:
> Hey,
&g
On Mon, May 16, 2011 at 5:12 AM, Havoc Pennington wrote:
> this should Just Work because the grid layout code should not
> work with an area exceeding the children's natural size if the grid
> isn't set to FILL and the children aren't expanding.
>
This is the only thing I'm interested in: no expan
On Fri, May 13, 2011 at 6:00 PM, Matthias Clasen
wrote:
> Given that the default value for align is FILL, I'm really tempted to reply:
> So ? If you do not want that and want your widget to expand, simply
> don't set align to a non-expanding value.
>
> Changing the semantics of align as you propos
On Fri, May 13, 2011 at 4:32 PM, Matthias Clasen
wrote:
> I would argue that if all the widgets dealing with text really have
> the same needs, they should really support the same interface in GTK+,
> and there should be no need to write n adaptors for widget-with-text
> to atktext, but instead ju
Hey,
I've had an interesting discussion that has so far involved Matthias
and Alex about align and expand flags and about GtkGrid's involvement
in it[1]. This discussion is mostly academic in that it should never
appear in the real world. People should set their expand and align
flags properly whe
Hey,
I intend to do a somewhat incompatible change to the CSS parsing
algorithms, and I'd like to announce it here. It's mostly meant
informational, but if you disagree with it, feel free to speak up, the
patch hasn't landed yet. If you don't know wtf I'm talking about, just
move along. Anyway, so
On Tue, May 10, 2011 at 10:46 PM, Brian Cameron
wrote:
>
> A main reason that there are multiple sets of interfaces is to make the
> free desktop accessibility interfaces widget-set neutral. A huge
> amount of effort has been invested over the years to make GNOME and KDE
> accessibility interoper
Hey,
So I've been thinking about accessibility in GTK for a while (since it
broke all the time during the unstable GTK 3 development to be exact).
And I've been wondering how to fix the somewhat sad state of the code
we do have. Unfortunately I have no idea how to solve it, but I have
an opinion a
On Fri, May 6, 2011 at 12:04 PM, Kristian Rietveld wrote:
> Which raises another question, would it be a good idea or make sense to merge
> the image differ into the GTK+ test utils so that other tests (e.g. the tree
> view scrolling test suite) can make use of it?
>
I did not spend any time thi
On Thu, May 5, 2011 at 10:18 AM, Kristian Rietveld wrote:
> As we've already discussed on IRC some time ago, I would really like to see
> all
> GTK+ unit tests in one single place, instead of in several different places
> in the
> source code. We really need people to run the unit tests more of
I want them to write a reftest.
Benjamin
On Tue, May 3, 2011 at 10:01 PM, Benjamin Otte 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
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 have fixed and
will continue to add tests for bugs I fix. For what the test runner
does, see the commi
http://people.freedesktop.org/~company/stuff/label-fun.out.png
6: http://people.freedesktop.org/~company/stuff/label-fun.diff.png
On Sun, Apr 10, 2011 at 12:25 AM, Benjamin Otte wrote:
> Hey,
>
> So this came up while discussing
> https://bugzilla.gnome.org/show_bug.cgi?id=647284 and we weren&
On Sat, Apr 9, 2011 at 2:14 PM, Tristan Van Berkom
wrote:
> What I should have done, as Owen pointed out back in december was to
> leave the label requests very straight-forward and require the program
> author to set an explicit minimum size of the toplevel GtkWindow,
> essentially the difference
Here's my answers (and sorry for messing up the reply of the last 2
mails, I blame gmail)
I've also attached the sources for the program I used to generate the
GTK2/3 answers I posted above. Please look at it if there's any
questions remaining after looking at that long table.
When I put "5/10" i
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
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
Hey,
So this came up while discussing
https://bugzilla.gnome.org/show_bug.cgi?id=647284 and we weren't sure
what the proper answers for all those questions were. So we were
wondering.
We are thinking about GtkLabel size reuqests, in particular about the
width. For ease of discussion, we assume tha
On Tue, Feb 15, 2011 at 8:45 AM, Alexander Larsson wrote:
> The height/width stuff makes this very much a pixel-storage-based kind
> of picture, and doesn't ideally describe a vectorized image, like say an
> svg, where there might be no "natural" size in terms of pixels.
>
> How do you intend to h
On Mon, Feb 14, 2011 at 10:28 PM, Matthias Clasen
wrote:
> - Why does this belong in gdk ?
>
It's in GDK for now because that's where gdk-pixbuf comes from. And as
I'm targetting GTK and didn't want to work on two git checkouts while
playing with it, I stuck it into gdk. Emmanuelle asked about pos
Hey,
I've pushed a new branch "picture" to the gtk repository. It contains
an implementation of an idea I've toyed with in my mind for a while.
It's of course not finished yet, but already works very well and more
importantly is the simple API that I had envisioned. So I'd like to
get it merged in
Hey,
I intend to remove the following things from GDK on my quest to get
rid of GdkNativeWindow.
structs:
- GdkEventClientMessage:
functions:
- gdk_add_client_message_filter()
- gdk_event_send_client_message()
- gdk_event_send_clientmessage_toall()
- gdk_event_send_client_message_for_display()
sig
Hans Breuer breuer.org> writes:
>
> Current master has three occurences of
>
> #ifdef GDK_WINDOWING_X11
>if (GDK_IS_X11_DISPLAY (display))
>
> followed by some
> window = gdk_x11_window_lookup_for_display (display, ...);
>
> Only one was ported to win32 and currently none for OSX, le
What I'd do is put all the headers in the same directory, but add a
#ifdef GDK_WINDOWING_X11 to the header and then put
-DGDK_WINDOWING_X11 into gtk+-3.0-x11.pc That way we avoid lots of
different include directories and IMO makes it easier to look for
header files in one's installation.
There's al
While we're talking about getting rid of stuff, I'd like to get rid of
> gdk_utf8_to_string_target
> gdk_string_to_compound_text_for_display
> gdk_utf8_to_compound_text_for_display
> gdk_free_text_list
> gdk_free_compound_text
But I lack enough clue about selections to do that. Is there anyone
wit
On Mon, Dec 6, 2010 at 7:43 PM, Alexander Larsson wrote:
> You can of course check on the type of anything, like the display or a
> window. However, sometimes there might be no display availible, like if
> its not been opened yet.
>
I think the question is if we want to support multiple different
Alexander Larsson redhat.com> writes:
> Support specifying multiple targets in --with-gdktarget, then build a
> single libgtk-3.0.so supporting all of these, switching at runtime. At
> one time i was thinking we could load the backends dynamically to avoid
> linking to all the dependencies of all
This started out as a little TODO list while I was looking into
deprecating GdkColor for GdkRGBA in Lisbon's airport (it's much nicer
than Madrid) and ended as a pretty large list of comments. The
contents are unfiltered, so don't take anything personal. It wasn't
originally meant to be public. I d
Hey everyone,
If you read this mail, it's probably because GTK made your compile
fail. Again. It might be because the final part of the GTK3 rendering
cleanup has landed. This part only touches GDK APIs, so most
applications should not be affected at all.
If your app has been affected nonetheles
On Wed, Oct 20, 2010 at 12:26 PM, Richard Hughes wrote:
> I don't think maintainers mind porting stuff, as long as:
>
> 1) it doesn't keep changing in drastic ways, cough, GtkApplication, cough
> 2) you provide a porting "how to" document with examples
>
3) There are maintainers.
4) The maintainer
Carlos Garnacho gnome.org> writes:
> 1) Keep GtkStyle in 3.0, encourage people verbally to use
> GtkStyleContext instead.
>
> 2) Keep GtkStyle, but not include in gtk.h, force people to take a
> decision between being lazy and using the brand new stuff.
>
> 3) Remove GtkStyle, port all GTK+ wid
Do you pine for the nice days of GTK 1.3, when men were men and wrote
their own widgets? Are you without a nice project and just dying to
cut your teeth on a desktop you can try to modify for your needs? Are
you finding it frustrating when everything works on GNOME 2? No more
all-nighters to get a
10 at 7:42 PM, Benjamin Otte wrote:
>> I'm actually not sure about that. First, we don't have any code that
>> defines if an allocation is valid or even defines what a "valid"
>> allocation is. Or do we? gtk_widget_get_allocation() at least doesn't
>&g
On Tue, Sep 14, 2010 at 7:46 PM, Matthias Clasen
wrote:
> What about the expose_event / gtk_widget_send_expose_event stuff ? Do
> we want to merge what you have first and figure that out afterwards ?
>
I want to figure that out afterwards. It's something I haven't figured
out completely yet. I co
I just pushed an update to rendering-cleanup and
rendering-cleanup-next that incorporates the suggestions from this
thread. In particular:
- I squelched commits
The fixes from Kris for OS X should now be in their correct position
and allow compiling random checkouts so git bisect works on OS X
(hop
On Sun, Sep 12, 2010 at 5:41 AM, Matthias Clasen
wrote:
> Benjamin, can you have a look at this ?
>
Fixed in
http://git.gnome.org/browse/gtk+/commit/?id=66e860b5d19ead7d30b13eacfbe65b22b24c9d37
Benjamin
___
gtk-devel-list mailing list
gtk-devel-list@gno
On Sun, Sep 12, 2010 at 6:21 AM, Havoc Pennington wrote:
> Something that occurred to me mid-bisect is that with Benjamin's
> draw() work, it would probably be straightforward to write the
> following test program:
>
> * instantiate every widget type in GTK (or even various modes of every
> widget
Whew, lots of things to reply to. Here we go...
On Sat, Sep 11, 2010 at 5:16 PM, Havoc Pennington wrote:
> A round of rebase/squash might be nice which would make it easier to
> review, for example c5c08bafb94e794a88ef5d650999f46b419429ed could
> squish into 9badb81a7ed62af1cdf11eb31c7e94293a6834
On Sat, Sep 11, 2010 at 7:05 PM, Havoc Pennington wrote:
> I'm looking at gtk_scale_draw for example on your branch
> http://git.gnome.org/browse/gtk+/tree/gtk/gtkscale.c?h=rendering-cleanup-next#n1159
>
gtk_scale_get_layout_offsets() returns values relative to
widget->window, so takes into accoun
On Sat, Sep 11, 2010 at 6:29 PM, Havoc Pennington wrote:
> - in many languages GtkSizeRequest::get_width() is already just
> callable as widget.get_width()
> - plain get_width() more naturally gets request, anyhow
>
Ugh, I'd always assume that widget.get_width() would give me the width
of the widg
What's you opinion on having gtk_widget_get_width() and
gtk_widget_get_height() functions? They would just return
widget->priv->allocation.width/height for now.
Such functions would address your issues and would make writing draw
functions pretty much as simple as they are now, without having to
p
On Sat, Sep 11, 2010 at 5:22 PM, Bastien Nocera wrote:
> On Sat, 2010-09-11 at 07:03 +0200, Benjamin Otte wrote:
> It's missing the symbolic icons...
>
I suppose that's because I'm on F13 and F13 oes not have symbolic
icons? At least, I don't have any icons s
1 - 100 of 145 matches
Mail list logo
