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
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
-- 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 o...@gnome.org wrote:
Hey,
Here's a problem I'm currently thinking about and would like input on. I
discussed
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!
The
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
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
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
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
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
Mike C. compmastermike at yahoo.com writes:
It is, but I'd talk more about GTK as a platform than GNOME here because I see
a lot of caution to port to this mythical GTK3 beast. XFCE and LXDE seem to
position themselves as wanting GTK3, but hesitant to grab it. SpaceFM only
recently got GTK3
On Sun, Nov 11, 2012 at 6:36 PM, Jasper St. Pierre
jstpie...@mecheye.net wrote:
I would disagree with you on backwards compatibility, slightly. I think we
shouldn't try too hard, but we also now have a clear goal for theme authors:
standard CSS. We should obey the goals of the standards, and
Michael Natterer mitch at 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
Michael Meeks michael.meeks at 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
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
Peter Hurley peter at 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.
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
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
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
Matthias Clasen matthias.clasen at 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
Ryan Lortie desrt at 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
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
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?
On Mon, Jan 9, 2012 at 5:40 PM, Tristan Van Berkom t...@gnome.org 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
On Mon, Jan 9, 2012 at 5:59 PM, Jan Jokela janjok...@gmail.com 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,
. :)
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
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
Owen Taylor otaylor at 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
On Fri, Dec 9, 2011 at 3:48 AM, Matthias Clasen
matthias.cla...@gmail.com 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.
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
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:
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
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
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
On Wed, Nov 16, 2011 at 9:37 AM, Kristian Rietveld k...@loopnest.org 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
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 for
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
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 decision is
On Sun, Oct 30, 2011 at 1:45 PM, Michal Suchanek hramr...@centrum.cz 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
On Wed, Oct 12, 2011 at 12:43 PM, Robert Bragg rob...@sixbynine.org 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.
On Sat, Oct 29, 2011 at 2:03 PM, Peter Clifton pc...@cam.ac.uk 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,
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
On Thu, Sep 29, 2011 at 6:30 PM, Johannes Schmid j...@jsschmid.de 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
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
Emmanuele Bassi ebassi at 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
Piñeiro apinheiro at 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 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
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
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
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,
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
On Fri, May 6, 2011 at 12:04 PM, Kristian Rietveld k...@gtk.org 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
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
On Thu, May 5, 2011 at 10:18 AM, Kristian Rietveld k...@gtk.org 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
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
://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 o...@gnome.org wrote:
Hey,
So this came up while discussing
https://bugzilla.gnome.org/show_bug.cgi?id=647284 and we weren't sure
what
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
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
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
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 in
On Sat, Apr 9, 2011 at 2:14 PM, Tristan Van Berkom
trista...@openismus.com 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,
On Tue, Feb 15, 2011 at 8:45 AM, Alexander Larsson al...@redhat.com 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
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
On Mon, Feb 14, 2011 at 10:28 PM, Matthias Clasen
matthias.cla...@gmail.com 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.
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()
Hans Breuer hans at 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,
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
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
with
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
Alexander Larsson alexl at 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
On Mon, Dec 6, 2010 at 7:43 PM, Alexander Larsson al...@redhat.com 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
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
Carlos Garnacho carlosg at 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+
On Wed, Oct 20, 2010 at 12:26 PM, Richard Hughes hughsi...@gmail.com 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)
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
On Tue, Sep 14, 2010 at 7:46 PM, Matthias Clasen
matthias.cla...@gmail.com 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
:42 PM, Benjamin Otte o...@gnome.org 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
do anything there.
yes, we have
On Sun, Sep 12, 2010 at 6:21 AM, Havoc Pennington h...@pobox.com 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
On Sat, Sep 11, 2010 at 6:29 PM, Havoc Pennington h...@pobox.com 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
On Sat, Sep 11, 2010 at 7:05 PM, Havoc Pennington h...@pobox.com 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
Whew, lots of things to reply to. Here we go...
On Sat, Sep 11, 2010 at 5:16 PM, Havoc Pennington h...@pobox.com wrote:
A round of rebase/squash might be nice which would make it easier to
review, for example c5c08bafb94e794a88ef5d650999f46b419429ed could
squish into
So,
I've been busy the last few days making all expose events use Cairo
contexts exclusively and while doing that had to wander into the
cobwebbed regions of Gtk code and other exciting places. While doing
that a few questions about general cleanup occured to me:
1) How to handle old-school
Havoc Pennington hp at pobox.com writes:
Hi,
I thought of another approach to this problem. Don't expose the pixbuf
format at all; keep it as-is. However, add:
gdk_pixbuf_get_cairo_surface()
gdk_pixbuf_new_from_cairo_surface(cairo_surface_t *surface);
Now, keep the cairo surface
On Mon, Aug 30, 2010 at 1:12 AM, Matthias Clasen
matthias.cla...@gmail.com wrote:
Hey Benjamin, the branch builds just fine, but I see a ton or redraw issues.
Everything basically turns black after a while...
Oh, I forgot about that:
I switched csw windows to using Cairo subsurfaces, which are
Hey everybody,
the second part of my GTK 3 rendering-cleanup work is done and is (as
always) available at
http://git.gnome.org/browse/gtk+/log/?h=rendering-cleanup Note that
after every commit the branch is fully compiling and working.
This work only touches GTK3 and will not effect GTK 2.22.
Murray Cumming murrayc at murrayc.com writes:
gdk_bitmap_create_from_data() has been removed but it's not yet
deprecated in the gtk-2-22 branch, so I can't read about what replaces
it. I see no other simple way to create a GdkBitmap.
A GdkBitmap is just a GdkPixmap with a depth of 1. Even in
On Mon, Aug 30, 2010 at 12:03 AM, Peter Clifton pc...@cam.ac.uk wrote:
Is there any plans to drop the gdk_color_parse() API? Our circuit board
design app (gEDA/PCB) uses that for processing configured colour values
to RGB values. AUUI, it can also translate X colour names into RGB
values. It
After reading this mail I think we pretty much 100% agree on the ideal
world. The hard part is just figuring out how to get there. I see 2
problems with this:
1) developer time to actually implement this for GTK3.
2) keeping the code changes for app developers small.
So if we don't manage to get
Alexander Larsson alexl at redhat.com writes:
It may seem correct and easier, and in most cases it will work. But
things like that were added for a reason. In this case it is to make
things like notification icon work, where there the parent of the window
we paint in is a foreign window (the
On Thu, Aug 19, 2010 at 10:08 AM, Alexander Larsson al...@redhat.com wrote:
The problem with no-window widgets is not really for the no-window
widget, but rather that all parents must have special expose code that
chains to the no-window widgets. If we want to clean up the drawing code
this is
On Mon, Aug 16, 2010 at 11:23 PM, Alexander Larsson al...@redhat.com wrote:
[...]
Just doing this is a great cleanup and simplification of gdk and the
backends, which is clearly a good step towards further work.
Great. This is what I've been hacking on in the rendering-cleanup
branch (yes,
On Mon, Aug 16, 2010 at 3:29 PM, Jean Brefort
jean.bref...@normalesup.org wrote:
Sorry to come late to this thread, but I'd like to know how you intend
to support things that can't be rendered using cairo? Just like a 3D
OpenGL scene. I'm not sure gtkglext would still work. I hope I'm missing
Hey,
This is a notice that I intend to drop the DirectFB backend from GDK
3. It hasn't compiled for weeks now and I haven't heard from anyone
saying he'd look at it. More than that, people I asked about it have
told me that it's basically broken since 2.18, which is almost a year
ago. So it seems
On Thu, Aug 12, 2010 at 7:27 PM, Federico Mena Quintero
feder...@ximian.com wrote:
- If you have an event signal in GdkWindow, like you proposed, then we
can make widgets responsible for connecting to their subwindows. In
theory the (client-side) window system will send those signals in Z
On Thu, Aug 12, 2010 at 7:15 PM, Federico Mena Quintero
feder...@ximian.com wrote:
One thing I'd definitely like to have is the region-to-expose. Many
times people have started with oh, I'll just paint everything every
time, only to find later that this is too slow. Then they go and make
use
On Mon, Aug 9, 2010 at 6:46 PM, Havoc Pennington h...@pobox.com wrote:
How would we handle widgets that currently have multiple windows and
draw different things to each one (i.e. the expose handler is looking
at the window in the expose event).
For example GtkTextView
I'm not entirely sure
On Mon, Aug 9, 2010 at 6:22 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
3) Resolution independence. A cairo_scale (cr, 2, 2) before calling
gtk_widget_draw() smoothly scales widgets to twice the size. Of
course, event translation and all that fun is needed, too, but the
rendering part
1 - 100 of 127 matches
Mail list logo
