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
On Fri, 2010-08-20 at 03:09 +0200, Benjamin Otte wrote:
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
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
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 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
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 being described is slowly
converging on something extremely close to a canvas
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
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 Tue, 2010-08-17 at 17:28 +0200, Benjamin Otte wrote:
On Mon, Aug 16, 2010 at 11:23 PM, Alexander Larsson al...@redhat.com wrote:
[...]
However, the next step, getting rid of the wrappers/impls and
restructuring the window class hierarchy is not really right
imho. Having impls be a
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
On Tue, 2010-08-10 at 01:59 +0200, Benjamin Otte wrote:
[Widgets that own multiple windows]
My current idea on how to implement it is to give the widgets a hint
as to wether they are repainting a window or wether they are painting
to something else. Something like
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 Sun, Aug 8, 2010 at 8:07 PM, 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.
I'll start with the end goal:
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,
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
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
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
44 matches
Mail list logo
