On Thu, 2010-08-26 at 15:13 -0500, Federico Mena Quintero wrote:
On Thu, 2010-08-26 at 12:35 -0400, Behdad Esfahbod wrote:
Just keep in mind that it's very normal for text ink to leak out of the
allocation area. So even if the draw-border property is removed, we should
eventually figure
On 08/18/10 07:58, Matthias Clasen wrote:
We are just about to remove that style property, called
GtkWidget::draw-border, since it has some overhead, and nobody ever
used it.
Just keep in mind that it's very normal for text ink to leak out of the
allocation area. So even if the draw-border
On Thu, 2010-08-26 at 12:35 -0400, Behdad Esfahbod wrote:
Just keep in mind that it's very normal for text ink to leak out of the
allocation area. So even if the draw-border property is removed, we should
eventually figure out how to handles these.
But widgets are supposed to request a size
On Sat, 2010-08-21 at 00:01 -0400, Havoc Pennington wrote:
On the Clutter front I'd still like to see the ClutterBackend
replaceable at runtime so you could basically put GTK in there or your
compositing manager in there, and avoid Clutter's attempts to do its
own Xlib things. That'd be a
Hi,
All of these changes sound really awesome.
On Sat, Aug 21, 2010 at 7:02 AM, Emmanuele Bassi eba...@gmail.com wrote:
this would actually allow a GDK backend to be easily written; then
clutter-gtk could depend on it, and embedding GTK widgets inside Clutter
would be (relatively) easier than
On Wed, 2010-08-18 at 12:10 -0400, Paul Davis wrote:
On Wed, Aug 18, 2010 at 12:06 PM, Paul Davis p...@linuxaudiosystems.com
wrote:
sometimes i hate gmail keybindings ... so, to finish what i was saying ...
in my mind, a canvas does two things:
1) composites together the result of
/unrealize implementations though.
So, imho no-window widgets removal is an obvious candidate for
simplification when we have the chance.
In my ideal world, the containers are responsible for bubbling up
drawing commands and events. For gtk_widget_draw(), this is pretty
much a requirement
On Fri, Aug 20, 2010 at 5:15 AM, Alexander Larsson al...@redhat.com wrote:
Gtk+ has always followed this model though, it just now does it more
internally where it previously relied on some support from the windowing
system.
GTK has historically not composited separately drawn surfaces
On Fri, 2010-08-20 at 09:00 -0400, Paul Davis wrote:
What
puzzles me is the mental effort that appears to go into avoiding what
to me seems like the inevitable conclusion of this evolution:
GTK-as-scene-graph. We inherited a very particular mindset from the
early X toolkits, and its taking
Alexander Larsson wrote:
On Fri, 2010-08-20 at 09:00 -0400, Paul Davis wrote:
What
puzzles me is the mental effort that appears to go into avoiding what
to me seems like the inevitable conclusion of this evolution:
GTK-as-scene-graph. We inherited a very particular mindset from the
On Fri, Aug 20, 2010 at 8:32 PM, Jose Gonzalez jose_...@juno.com wrote:
When it comes to the question of the desirability of some notion
of a canvas (or scene-graph if you like), it should be clear that
whatever such a thing might be it's best if it were a local rather
than global construct,
Hi,
On Fri, Aug 20, 2010 at 5:22 PM, Alexander Larsson al...@redhat.com wrote:
If I were to do something like that I'd keep gtk3 approximately as it
now takes shape (i.e. cleanup but mostly compatible). Then create a
completely new toolkit with a different name, based on the gtk stack
(i.e.
On Wed, 2010-08-18 at 11:13 -0500, Federico Mena Quintero wrote:
On Wed, 2010-08-18 at 09:37 +0200, Alexander Larsson wrote:
[Border around windows so you can glow around a widget]
There are all sorts of ways you can hack it into GtkButton or any
specific widget, I'm sure. However, its
does it for
windows, GTK does it for drawing on no-window widgets (with
gtk_container_propagate_expose()). GtkWindow does it for key presses.
In my ideal world, the containers are responsible for bubbling up
drawing commands and events. For gtk_widget_draw(), this is pretty
much a requirement
On Tue, 2010-08-17 at 16:04 -0500, Federico Mena Quintero wrote:
On Tue, 2010-08-17 at 21:10 +0200, Alexander Larsson wrote:
Additionally I was thinking one could specify a border on the window
such that for clipping purposes and calculation of what has to be
repainted we grow the window
On Tue, Aug 17, 2010 at 5:04 PM, Federico Mena Quintero
feder...@ximian.com wrote:
[ ... ]
its quite amusing to me how what is being described is slowly
converging on something extremely close to a canvas model in many of
its most fundamental aspects. am i the only one seeing this? does it
On Wed, Aug 18, 2010 at 3:37 AM, Alexander Larsson al...@redhat.com wrote:
There are all sorts of ways you can hack it into GtkButton or any
specific widget, I'm sure. However, its hard to do in a more generic way
for a theme. I was thinking the theme could just set a style property to
have
On Wed, 2010-08-18 at 07:56 -0400, Paul Davis wrote:
its quite amusing to me how what is being described is slowly
converging on something extremely close to a canvas model in many of
its most fundamental aspects. am i the only one seeing this? does it
matter?
In my mind a canvas does two
On Wed, Aug 18, 2010 at 11:49 AM, Federico Mena Quintero
feder...@ximian.com wrote:
On Wed, 2010-08-18 at 07:56 -0400, Paul Davis wrote:
its quite amusing to me how what is being described is slowly
converging on something extremely close to a canvas model in many of
its most fundamental
On Wed, Aug 18, 2010 at 12:06 PM, Paul Davis p...@linuxaudiosystems.com wrote:
sometimes i hate gmail keybindings ... so, to finish what i was saying ...
in my mind, a canvas does two things:
1) composites together the result of a variety of different objects
drawing themselves/ it does
On Wed, 2010-08-18 at 09:37 +0200, Alexander Larsson wrote:
[Border around windows so you can glow around a widget]
There are all sorts of ways you can hack it into GtkButton or any
specific widget, I'm sure. However, its hard to do in a more generic way
for a theme. I was thinking the theme
such as a display. Instead HippoCanvas is totally recursive -
events get to leaf items by being sent to parent items that then
forward to the leaf items, to draw the whole screen you just draw the
root item, etc. This then makes it very easy to be in that
gtk_widget_draw() type of world where you can draw
On Wed, Aug 18, 2010 at 12:27 PM, Havoc Pennington h...@pobox.com wrote:
Hi,
On Wed, Aug 18, 2010 at 7:56 AM, Paul Davis p...@linuxaudiosystems.com
wrote:
On Tue, Aug 17, 2010 at 5:04 PM, Federico Mena Quintero
feder...@ximian.com wrote:
[ ... ]
its quite amusing to me how what is
On Mon, 2010-08-16 at 21:36 -0400, Allin Cottrell wrote:
On Mon, 16 Aug 2010, Alexander Larsson wrote:
- Benjamin Otte o...@gnome.org wrote:
Here's an email detailing my thought process for what I want to do
with rendering in the master branch following the rendering-cleanup
On Thu, 2010-08-12 at 20:48 +0200, Benjamin Otte wrote:
EOG uses this to good effect, for example - scaling an image is
expensive, so it only scales the areas that absolutely need to be
repainted.
Cairo does that automatically. On the GPU, too. So I suppose EOG
doesn't yet upload the
(SOURCE)
cairo_paint()
def render_window (native_window, cr):
foreach (subwindow of native_window):
cairo_save()
cairo_clip(get_region (subwindow))
if (! everything_clipped ()):
cairo_translate(subwindow.x,subwindow.y)
gtk_widget_draw (get_widget (subwindow
(native_window, cr):
foreach (subwindow of native_window):
cairo_save()
cairo_clip(get_region (subwindow))
if (! everything_clipped ()):
cairo_translate(subwindow.x,subwindow.y)
I think you forgot a render_window() recursion here.
gtk_widget_draw (get_widget
On Tue, 2010-08-17 at 17:28 +0200, Benjamin Otte wrote:
The biggest problem for me when reading the GdkWindow code is that I
have no idea what a window is. So I have a hard time understanding the
code and if what it does is sane.
One pattern we see a lot is when widgets want to paint
On Tue, 2010-08-17 at 13:43 -0500, Federico Mena Quintero wrote:
On Tue, 2010-08-17 at 17:28 +0200, Benjamin Otte wrote:
The biggest problem for me when reading the GdkWindow code is that I
have no idea what a window is. So I have a hard time understanding the
code and if what it does is
On Tue, 2010-08-17 at 21:10 +0200, Alexander Larsson wrote:
[Widgets with an InputOnly window for events]
Yeah, they do it to avoid the window resize being asynchronous with
respect to the repainting, etc, causing ugly looking resizes.
Oh, I thought they did it to get the parent's background.
- Benjamin Otte o...@gnome.org wrote:
Hi,
Here's an email detailing my thought process for what I want to do
with rendering in the master branch following the rendering-cleanup
merge. It's mostly a brain dump, so treat it as such.
So, I read this thread and thought about it a bit
On Mon, 2010-08-09 at 02:07 +0200, Benjamin Otte wrote:
This is awesome stuff, Benjamin.
I'll start with the end goal: gtk_widget_draw(GtkWidget *widget, cairo_t *cr);
One thing I'd definitely like to have is the region-to-expose. Many
times people have started with oh, I'll just paint
() which
would return the currently invalidating GdkWindow or NULL. That would
basically replace event-window and then all you need to do is check
that the order of the draw calls is the window's stacking order and
you're all set.
If gtk_widget_draw(w, cr) really means paint thyself, then we
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
: gtk_widget_draw(GtkWidget *widget, cairo_t *cr);
That function will draw the given widget to the given cairo_t, no
matter what kind of cairo_t you hand it
I think I can subscribe to that. It sounds like a nice goal.
3) Resolution independence. A cairo_scale (cr, 2, 2) before calling
Hi,
On Sun, Aug 8, 2010 at 8:07 PM, Benjamin Otte o...@gnome.org wrote:
I'll start with the end goal: gtk_widget_draw(GtkWidget *widget, cairo_t *cr);
That function will draw the given widget to the given cairo_t, no
matter what kind of cairo_t you hand it, no matter wether it's an
actual X
On Mon, Aug 9, 2010 at 1:03 PM, Morten Welinder mort...@gnome.org wrote:
Here's an email detailing my thought process for what I want to do
with rendering in the master branch following the rendering-cleanup
merge. It's mostly a brain dump, so treat it as such.
Assuming you managed to get all
hi Havoc,
On Mon, 2010-08-09 at 12:46 -0400, Havoc Pennington 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 think we should just
Hi,
On Mon, Aug 9, 2010 at 3:57 PM, Ryan Lortie de...@desrt.ca wrote:
I think we should just fix these.
It seems like the only GtkWidgets that posess GdkWindows ought to be
toplevels (windows, popups, etc) and GtkPlug/GtkSocket.
Subwindows do have a function though (events, clipping,
yet. I want to guarantee two semantics:
1) The stuff looks correct on screen.
This one is a no-brainer. It should also be fast.
2) Calling gtk_widget_draw() draws all child widgets, even if they
have custom windows.
This is necessary, because nobody will like just getting a grey box
when
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
On Mon, Aug 9, 2010 at 10:17 PM, Havoc Pennington h...@pobox.com wrote:
GtkSourceView would be one heavily-affected codebase if there are
changes here.
I did not mention this explicitly anywhere yet, so I'll do it here:
My goal is to have all my changes minimize the effects on code that is
Hi,
Here's an email detailing my thought process for what I want to do
with rendering in the master branch following the rendering-cleanup
merge. It's mostly a brain dump, so treat it as such.
I'll start with the end goal: gtk_widget_draw(GtkWidget *widget, cairo_t *cr);
That function will draw
On Mon, 2010-08-09 at 02:07 +0200, Benjamin Otte wrote:
So, that's a rough list of ideas I have currently. I have no idea if I
get all of this done for 3.0 and in what order I'm going to tackle
these problems
It all sounds utterly brilliant.
++
Changing the object hierarchies is a bit of a
On Fri, 2009-12-04 at 15:01 -0600, Harry Coin wrote:
If there is a non-deprecated way to start a timer as soon as an image is
known to be drawn without using gtk_widget_draw I'd need to be educated
about it. If not I think there is a good argument to not deprecate
gtk_widget_draw
Il giorno Fri, 04 Dec 2009 15:01:25 -0600
Harry Coin hc...@quietfountain.com ha scritto:
The only answer I can think of to retain the ability to time most
accurately, starting the moment that the image has been drawn is to
use gtk_widget_draw right after setting the pixbuf
that the image has been drawn is to
use gtk_widget_draw right after setting the pixbuf.
If gtk_widget_draw() is working for you, why don't you pasteadapt its
code in your application? The implementation is quite trivial:
http://git.gnome.org/cgit/gtk+/tree/gtk/gtkwidget.c#n3811
Ciao
Presently the function gtk_widget_draw is deprecated in favor of
gtk_widget_queue_draw.
I need the great minds of gtk to think of a way I've missed to
accomplish a certain task, or consider un-deprecating gtk_widget_draw.
The context is a multi threaded application using gtk. In a thread
49 matches
Mail list logo
