it's possible something in here is useful:
http://mail.gnome.org/archives/gtk-devel-list/2010-October/msg4.html
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Hi,
On Tue, May 31, 2011 at 5:47 AM, Christian Dywan christ...@lanedo.com wrote:
This is a great argument. There was a mistake. It made you notice the API is
inconsistent, so you suddenly insist that GLib can't be improved further
without rewriting all the functions
It didn't make me
Hi,
On Mon, May 30, 2011 at 8:17 PM, Morten Welinder mort...@gnome.org wrote:
Doing a g_return_val_if_fail is fine here. That will give the user a
chance of saving his work. This is in contrast to g_error which is a
sure way of eating data.
If that's the argument it's fine. I treat
Hi,
Man, how many times has this thread happened? At least fifty.
On Fri, May 27, 2011 at 10:57 AM, Shaun McCance sha...@gnome.org wrote:
try:
load_some_extension()
except:
warn(This extension sucks. I'm disabling it and moving on.)
Of course, GLib is C. We don't have exceptions. We
Hi,
On Fri, May 13, 2011 at 12:00 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
Second, if children should never get
assigned extra space, why do we have the ALIGN_FILL parameter?
expand is about whether you _want_ the child to receive extra space.
align=fill is about how the child
Hi,
On Thu, May 12, 2011 at 9:53 PM, Benjamin Otte o...@gnome.org wrote:
Don't assign any extra space to children, use it as space on the
right/bottom side. (This is the current behavior)
This seems screwy, unless the grid has left/top alignment set. I would
expect the grid to position the
czk, another thing you'll need to do to get useful results is run a
lot of iterations. If you get this all going in a loop then you can
run sysprof for a while to get enough data. I would try to keep
running for 20-30 seconds.
To see one-time startup initialization, your loop will have to keep
Hi,
On Thu, Feb 24, 2011 at 8:51 PM, Wen-Yen Chuang ca...@calno.com wrote:
a.) restart dbus daemon (and keep everything communicating to dbus
still working) is not supported by upstream in a sensible way.
[1][2][3][4]
upstream doesn't support this because it isn't a dbus issue. The
Hi,
On Fri, Feb 25, 2011 at 9:13 PM, Wen-Yen Chuang ca...@calno.com wrote:
I suppose GtkApplication users do not need to handle dbus directly.
So if GtkApplication can handle dbus restart / dbus crash, I may also
consider using GtkApplication for single instance app.
However, the whole
Hi,
It seems like the following would work but maybe I'm missing the obvious
* have the video request natural size = its natural unscaled size, and
min size of whatever lowest scale factor you want to allow
* to snap to natural size, just size request the entire toplevel to
get the natural
This document may help you:
http://git.gnome.org/browse/gtk+/tree/docs/text_widget_internals.txt
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Hi,
On Mon, Nov 1, 2010 at 12:06 PM, Ryan Lortie de...@desrt.ca wrote:
The conclusion of all of this is one point: barring substantial
complaints, the be-all and end-all of time in glib is going to be
microseconds stored in a gint64.
Your arguments sound right and a nice upgrade over current
Hi,
On Mon, Nov 1, 2010 at 1:06 PM, John Ralls jra...@ceridwen.us wrote:
I don't see any reason to have a replacement for GDate.
fwiw, the original (and possibly only) use of GDate was for security
price data (Open/High/Low/Close), which has only a day, not a time or
timezone. This is also why
Hi,
On Mon, Nov 1, 2010 at 2:10 PM, Peter Clifton pc...@cam.ac.uk wrote:
Maybe add G_USEC_PER_MSEC so it's easy to write milliseconds code.
Much as I am a fan of self-documenting code.. isn't * 1000 much
shorter and easier?
Well there's already G_USEC_PER_SEC but I guess it's saving typing
Hi,
On Mon, Nov 1, 2010 at 2:25 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
In fact, here it is:
http://library.gnome.org/devel/gio/2.27/GApplication.html#gapplication-example-actions
Was a bit confused reading this example, what are the hold/release in
the action callbacks about?
Hi,
On Sat, Oct 23, 2010 at 3:37 PM, Owen Taylor otay...@redhat.com wrote:
- We should not start painting the next frame until we are notified
the last frame is complete.
Does frame-complete arrive when we just did the vsync i.e. last
frame is just now on the screen?
We can dispatch other
Hi,
On Fri, Oct 22, 2010 at 10:24 AM, Owen Taylor otay...@redhat.com wrote:
Is painting well behaved? Inherently - no. We can easily get in
situations where we can spend all our time painting and no time doing
anything else.
That's the point of the up-to-5ms-of-dispatch thing (or the
Hi,
On Fri, Oct 22, 2010 at 10:28 AM, David Zeuthen zeut...@gmail.com wrote:
If you believe that the GUI thread should never perform blocking IO
(such as reading from disk or IPC) or never perform CPU-intensive
tasks (such as image- or video-decoding) then... then all that your
code in the
Hi,
On Fri, Oct 22, 2010 at 5:06 PM, Paul Davis p...@linuxaudiosystems.com wrote:
starting from scratch, and thinking about the parallels with a
pull-model realtime audio design, it seems to me that if you were
designing this entirely from scratch you wouldn't serialize painting
and other
Hi,
On Fri, Oct 22, 2010 at 4:48 PM, Owen Taylor otay...@redhat.com wrote:
I think we're largely agreeing on the big picture here - that priorities
don't work so there has to be arbitration between painting and certain
types of processing.
Right, good. The rest is really just details - there
Hi,
On Fri, Oct 22, 2010 at 9:56 PM, Paul Davis p...@linuxaudiosystems.com wrote:
you guys are working out an incredibly complex and potentially baroque
solution when the elegant and arguably correct one has already been
implemented several times in different contexts. what's the point?
Another issue, seems like the ticker needs to be per-native-window:
* the GL context is per-window so the vsync mechanism also is
* we ought to shut down the ticker on windows that aren't visible
* each screen has its own vsync and the window is the normal
convention to imply a screen
* the
Hi,
On Thu, Oct 21, 2010 at 4:26 AM, Emmanuele Bassi eba...@gmail.com wrote:
no, the GL context should *not* be per window. multiple GL contexts
usually pose more problems than they solve, in synchronization and
context switching, on basically all drivers - except maybe on nvidia[0].
Fair
Hi,
On Thu, Oct 21, 2010 at 5:46 AM, Ryan Lortie de...@desrt.ca wrote:
What about non-input events, though? Like, if some download is
happening and packets are coming in and causing dispatches from the
mainloop that we do not have control over.
I brought this up a bit in the earlier thread.
Hi,
I guess a frame-complete signal (or timer) acts like the 5ms to create
a window for other event sources to run? So painting should not starve
other stuff, the mainloop could dispatch other stuff while the frame
is being completed. Given a gap waiting for frame-completed you don't
need a
Hi,
On Thu, Oct 21, 2010 at 5:47 PM, David Zeuthen zeut...@gmail.com wrote:
Note that with GDBus the resulting GDBusMessage is actually being
built in a separate (and private) thread - so in practice there is
zero overhead in the GUI thread - in particular it doesn't depend on
what kind of
Hi,
On Tue, Oct 19, 2010 at 7:49 AM, Carlos Garnacho carl...@gnome.org wrote:
* There is no intuitive replacement for gtk_widget_modify_*(). If we are
to drop GtkStyle, I think that 3rd party libraries and apps implementing
widgets could define regions and attach a GtkStyleProvider with the
Hi,
I would think of it like this maybe
real_adjust_request(orientation, request_data)
{
adjust_request_by_adding_margin(orientation, request_data)
/* alignment does not affect request */
}
real_adjust_allocation(orientation, allocation_data)
{
Hi,
On Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berkom
trista...@openismus.com wrote:
What happens when another subclass wants to use
-adjust_size_allocation() to realign itself further ? how
can it cooperate with GtkWidgetClass and not cause bad side
effects ?
In the patch I posted
Hi,
On Fri, Oct 15, 2010 at 8:55 AM, Tristan Van Berkom
trista...@openismus.com wrote:
The for_size fed to widget implementations additionally needs to
strip the added padding that can happen in -adjust_size_request()
Right, adjust_size_allocation should basically invert anything
Hi,
On Fri, Oct 15, 2010 at 9:55 AM, Havoc Pennington h...@pobox.com wrote:
I think you should just call the request methods again. (Not the
wrappers of course, the vfuncs directly.) Instead of passing in a
natural size.
I guess this doesn't work when chaining up and down
Havoc
Hi,
I think I get what you're saying. If not I'll probably understand it
reading your code.
btw things are looking kind of messed up to me in the current code in
gtkwidget.c ... this:
gtk_widget_get_preferred_width (widget, NULL, natural_width);
get_span_inside_border_horizontal
In sounds like in short the for_size somehow needs to be adjusted
(strip out the pixels that adjust_size_request added). (If I'm
understanding properly.) Of course that's what adjust_size_allocation
does, except it's both dimensions. for_size is after all the proposed
allocation size in one
Hi,
On Tue, Oct 12, 2010 at 2:44 AM, Tristan Van Berkom
trista...@openismus.com wrote:
On Mon, 2010-10-11 at 15:30 -0400, Owen Taylor wrote:
On Mon, 2010-10-11 at 14:45 -0400, Havoc Pennington wrote:
Agreed, GtkLabel needs to report min size = true min sane size and
natural size = either
I guess to me it's much better to have one hack in GtkWindow globally
(GtkWindow is already a giant special case) than to leak the hack into
all widgets that actually do h-for-w. Just a separation of concerns
thing. It doesn't make sense for N child widgets inside a window to
all be trying to
Hi,
On Tue, Oct 12, 2010 at 11:20 AM, Tristan Van Berkom
trista...@openismus.com wrote:
I'm not sure what exactly you are talking about here, the only guess
a label currently makes is for a reasonable width-chars, i.e. limiting
a wrapping label to a reasonably large minimum width. This is to
Hi,
On Tue, Oct 12, 2010 at 11:40 AM, Tristan Van Berkom
trista...@openismus.com wrote:
And currently the min useful is just not defined as
a single word width.
Understood, I think we basically agree.
Havoc
___
gtk-devel-list mailing list
Hi,
On Tue, Oct 12, 2010 at 12:09 PM, Owen Taylor otay...@redhat.com wrote:
I think you need to think very carefully about how natural width is
explained and documented, since it seems to be neither exactly:
- the maximum useful width
- a good width for the widget
I get the impression
Hi,
On Tue, Oct 12, 2010 at 12:38 PM, Havoc Pennington h...@pobox.com wrote:
d) max size widget can do something useful with
e) size at which widget acts like expand=false (this is what I'd call
max size and I think it's a feature GTK doesn't have right now)
Trying to think about how
constrain the default size to nice aspect ratio somehow, solving
globally for the window instead of per-label.
Havoc
From 7ddeb49f1643799794bdc7d96a55fe9a885cd39f Mon Sep 17 00:00:00 2001
From: Havoc Pennington h...@pobox.com
Date: Mon, 6 Sep 2010 11:18:35 -0400
Subject: [PATCH] Make GtkWindow default
Hi,
On Mon, Oct 11, 2010 at 3:30 PM, Owen Taylor otay...@redhat.com wrote:
Setting the hints dynamically based on the current width can work, if
we're willing to say screw wireframe resizing (wireframe resizing
doesn't completely *not* work, you just have to release and retry
a few times to
Hi,
On Sun, Oct 10, 2010 at 6:36 AM, Tristan Van Berkom
trista...@openismus.com wrote:
bottom or right size of the Grid. (if the user wants the
grid children not to expand at all, they should only have
to pack the whole grid into another container and say that
the grid does not expand).
Or
Hi,
On Sun, Oct 10, 2010 at 4:57 PM, Alexander Larsson al...@redhat.com wrote:
First of all, what happened to Bug 628902 Add expand flags to
GtkWidget. It seems to have stalled. This would be very useful.
The latest code is on widget-expand-3 branch, fwiw.
todo items are:
* magic
Hi,
Oh, I see now it's a WrapBox replacement I guess (reading threads out of order)
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
I think a picture would be helpful ;-)
Are we sure this is of general interest? It seems like something only
a few percent of apps would end up using.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
Oh, another thing to have is probably h-spacing and v-spacing for the
grid-wide space between rows and columns. For per-column or per-row
spacing you could use a margin or a spacer widget placed on that row
(?)
If not clear the idea of the exercise I was doing is to figure out how
you'd naturally
Hi,
On Thu, Oct 7, 2010 at 10:48 AM, Tristan Van Berkom
trista...@openismus.com wrote:
However I would really appreciate it if a widget's placement
inside a container can still be clearly introspected and defined
with container child properties (in other words I think the widget
should be
Hi,
On Thu, Oct 7, 2010 at 1:18 PM, Federico Mena Quintero
feder...@ximian.com wrote:
However, who writes UIs by hand these days? Doesn't everyone just use
Glade?
It's a valid point, but I don't know that Glade is always easiest. I
don't think it's a good excuse for making the actual API
Hi,
Maybe the very very simple first step that punts on all the hard stuff
is to do a queue-redraw virtualization like this:
http://git.clutter-project.org/clutter/commit/?id=961aac3fb36f73d4a48720d93b8928a3e24b5b84
The default implementation of this in GtkWidget would invalidate on
GdkWindow,
Hi,
2010/9/26 Javier Jardón jjar...@gnome.org:
It returns a pointer to a GObject now
Shouldn't it just return a GtkAdjustment* ? returning GtkObject was
some weird legacy thing.
Also, isn't gtkobject still there in master?
http://git.gnome.org/browse/gtk+/tree/gtk/gtkobject.h
Havoc
Hi,
I've been exploring how widgets with no GdkWindow could receive
events. Here are some notes so far in case people have thoughts.
Event Types
===
Events separate very cleanly into weird lowlevel stuff only matters
for GdkWindow and things widgets in general including no-window
widgets care
Hi,
On Wed, Sep 22, 2010 at 8:55 AM, Paul Davis p...@linuxaudiosystems.com wrote:
i think you might want to consider MAP and UNMAP
I was thinking the vfuncs (already called on no-window) and map/unmap
signals would be fine. i.e. I agree map is interesting for no-window,
but I don't think
Hi,
On Wed, Sep 22, 2010 at 10:28 AM, Matthias Clasen
matthias.cla...@gmail.com wrote:
Isn't that handled by containers simply not calling draw on covered up
or hidden children ?
yeah, quite possibly. Especially if we move animations into a magic
master clock that would also be stopped.
Hi,
On Thu, Sep 16, 2010 at 6:36 AM, Andrew Cowie
and...@operationaldynamics.com wrote:
On Sun, 2010-09-12 at 11:23 -0400, Matthias Clasen wrote:
Anyhow, sure, if GTK has no policy that's fine. I assumed it had a
sensible policy...
We don't have a written-down policy, beyond 'fit in
Hi,
On Tue, Sep 14, 2010 at 7: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.
Hi,
On Tue, Sep 14, 2010 at 7:42 PM, Benjamin Otte o...@gnome.org wrote:
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
+ g_return_if_fail (GTK_WIDGET_ALLOC_NEEDED (widget));
g_return_if_fail( ! GTK_WIDGET_ALLOC_NEEDED (widget));
right?
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Hi,
On Mon, Sep 13, 2010 at 7:06 AM, Tristan Van Berkom
trista...@openismus.com wrote:
Heh, do you mean GtkWindow widgets or GtkWidgets that have their own
GdkWindow ?
Widgets that have their own GdkWindow
i.e. I was proposing that when adjusting a size request,
if
Hi,
On Mon, Sep 13, 2010 at 4:26 AM, Alexander Larsson al...@redhat.com wrote:
I'm personally a tiny bit uneasy about dropping bg None, as in some
cases its really required to do flicker-free stuff in X. However, with a
modern Gtk+ these situations are quite rare, and I don't think any of
Hi,
On Sun, Sep 12, 2010 at 1:33 AM, Tristan Van Berkom
trista...@openismus.com wrote:
Ok I see, so we end up with:
- set_size_request() Can be used to increase the minimum request
I was thinking this should stay backward compatible and allow lowering
it, fwiw. Though I can't actually come up
Hi,
On Sun, Sep 12, 2010 at 6:44 AM, Benjamin Otte o...@gnome.org wrote:
Uh, you've found out about one of my secret projects. Actually, what
I'm aiming at is reftests (see
http://weblogs.mozillazine.org/roc/archives/2008/12/reftests.html for
a description). They are independant of font
Hi,
On Sun, Sep 12, 2010 at 5:05 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
Also, the idea to separate the translation and the size in
size_allocate is intriguing.
A prior art thing I thought of that's relevant, Clutter has the
translation transform *and* the allocation origin.
The
not do this?
Havoc
From 218ab01aa87e9344f6708ae32d74503014508905 Mon Sep 17 00:00:00 2001
From: Havoc Pennington h...@pobox.com
Date: Sun, 12 Sep 2010 21:43:39 -0400
Subject: [PATCH] Add documentation on adjust_size_request adjust_size_allocation
Also note in the docs for various other functions
Awesome! Some stuff I noticed looking through the branch:
*
A round of rebase/squash might be nice which would make it easier to
review, for example c5c08bafb94e794a88ef5d650999f46b419429ed could
squish into 9badb81a7ed62af1cdf11eb31c7e94293a683429 (I was pretty
confused by the None there at
Hi,
On Sat, Sep 11, 2010 at 11:16 AM, Havoc Pennington h...@pobox.com wrote:
I still think passing width, height to draw() is weird.
btw, I guess the argument here (per IRC) is that people might be
confused by allocation.x,y. But this is a really weak band-aid fix for
that, which will be wrong
Hi,
On Sat, Sep 11, 2010 at 12:15 PM, Benjamin Otte o...@gnome.org wrote:
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
Hi,
On Sat, Sep 11, 2010 at 12:57 PM, Benjamin Otte o...@gnome.org wrote:
gtk_paint_*() does - at least in my branch - draw relative to the
passed in cairo_t. As almost all the paint functions take
x,y,width,height anyway it doesn't really matter where the origin of
the cairo_t is. You'll
Hi,
On Sat, Sep 11, 2010 at 1:11 PM, Benjamin Otte o...@gnome.org wrote:
This is actually a rather ugly situation right now: Everything in the
widget but the draw function (key press events etc) uses coordinates
relative to the GdkWindow, only the draw function doesn't. So when
calling
Hi,
On Sat, Sep 11, 2010 at 11:46 AM, Havoc Pennington h...@pobox.com wrote:
* size_allocate vfunc and wrapper change to (* size_allocate)
(GtkWidget, int w, int h)
Another possible addition here, which is in both Clutter and
HippoCanvas, would be an ORIGIN_CHANGED flag. (Clutter uses a flags
Hi,
On Sat, Sep 11, 2010 at 11:41 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
Turns out this is unrelated to your branch. I've bisected this to
Oops, I just burnt a hole in my lap bisecting this too. At least _one_
of those checkouts could have managed not to rebuild the whole tree...
also.
btw along these lines, I can't remember if I filed the attached patch.
Natural size much less useful without it.
Havoc
From 7ddeb49f1643799794bdc7d96a55fe9a885cd39f Mon Sep 17 00:00:00 2001
From: Havoc Pennington h...@pobox.com
Date: Mon, 6 Sep 2010 11:18:35 -0400
Subject: [PATCH] Make
Cool. So I'm inclined to search-and-replace the patch and make the properties:
margin-left
margin-right
margin-top
margin-bottom
margin /* sets all four at once */
I'll give it a couple more days though in case this turns out to be
controversial so I don't do too much busywork ;-)
Havoc
Hi,
On Tue, Sep 7, 2010 at 3:49 AM, Tristan Van Berkom
trista...@openismus.com wrote:
What is the use-case for forcing a widget to request something smaller
than it's content ?
I think the use-cases are mostly caused by the old limited layout
system. For example, to get a label to ellipsize,
Hi,
On Tue, Sep 7, 2010 at 7:25 PM, Emmanuele Bassi eba...@gmail.com wrote:
- possible addition pre-3.0: surface ↔ pixbuf conversion functions in gdk
Incidentally, these should probably be in gdk-pixbuf (to avoid cairo
dep they could just go to guint8*). The main use I guess is say in
Clutter
Hi,
On Tue, Sep 7, 2010 at 7:25 PM, Emmanuele Bassi eba...@gmail.com wrote:
- branches for alignment and margin for review
widget-padding and widget-expand branches pushed, widget-expand
includes widget-padding
Pending changes not in the branches yet include:
- rename padding to margin
- some
Hi,
On Mon, Sep 6, 2010 at 10:06 AM, Emmanuele Bassi eba...@gmail.com wrote:
‣ undo combobox / option menu mix ?
what is the argument on this? sounds like going in circles ;-)
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
Hi,
This is a major enough change it should probably hit the list and not
just bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=628902
The patch needs finishing as noted in the bug but you can already play
with it, it just is missing some production details.
Havoc
With
https://bugzilla.gnome.org/show_bug.cgi?id=628828
and
https://bugzilla.gnome.org/show_bug.cgi?id=628902
Box and Table are pretty much all messed-up. They have a bunch of
redundant flags to specify, and their redundant fill flag is a problem
because it has the wrong default (must always be
Hi,
On Mon, Sep 6, 2010 at 8:18 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
In particular the automatic window resizability will be nice.
Unfortunately this part is scary ;-) a whole lot of the gtkwindow.c
code related to this was last touched by me in 2001, some was last
touched even
I forgot that GtkWidget::parent already works:
g_object_new (TYPE_FOO, parent, box, blah, 42, NULL)
This is a pretty nice solution I think. You don't even have to save a
pointer to the new object if you aren't doing anything other than
adding it to parent and setting a couple of props.
Havoc
https://bugzilla.gnome.org/show_bug.cgi?id=628828
has a patch ready for review.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
I'd say a useful emphasis is to focus on enabling deprecation by
adding the new way, rather than on actually removing the old way.
e.g. on my pixbuf patch, the changes allow dropping any actual use of
the old format. But going on a compile with
GDK_PIXBUF_DISABLE_DEPRECATED spree just in pixbuf
Hi,
several questions looking at this code,
1. I may be nuts but I really thought set_size_request() could reduce
a size request below the widget's normal request, back in the day.
However, won't this code allow set_size_request to *increase* min size
only?
Also,
4. AuxInfo still contains x,y, x_set, y_set and code reads them, but
commit 0d322676dcb06be62329a7d4373c497993509fbd removed set_uposition
and now there is no way to set these - so they should die, right?
Havoc
___
gtk-devel-list mailing list
Bugzilla is down, so here's a patch for another problem
Havoc
From d8b6eb473b0eb13b9540f91516f2f60df2d5f1a7 Mon Sep 17 00:00:00 2001
From: Havoc Pennington h...@pobox.com
Date: Sun, 5 Sep 2010 01:42:14 -0400
Subject: [PATCH] default impls of width_for_height,hfw should chain directly not use
Hi,
On Fri, Sep 3, 2010 at 4:05 AM, Andrew Cowie
and...@operationaldynamics.com wrote:
We can kiss gdk_pixbuf_get_pixels() goodbye, no problem, but I'm just
curious what someone would replace it with... draw to a Cairo image
surface, save that to a PNG and then load it and... oh wait. :)
The
Hi,
On Fri, Sep 3, 2010 at 4:17 AM, Benjamin Otte o...@gnome.org wrote:
- I'm not sure where to store contents
Naïvely, it doesn't make a lot of sense to store images that are only used on
the X server in client memory and upload them every time we need them. But
then,
closing a connection
Hi,
On Fri, Sep 3, 2010 at 11:35 AM, Shawn Bakhtiar shashan...@hotmail.com wrote:
Sorry this may be a very inept question:
How will this effect integration with OpenGL. I know we use a lot of
get/sets on pixels buffers; off screen rendering, textured (especial
animated) and tricks. You want
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 internally, strong-ref'd by the pixbuf.
The pixbuf
Hi,
On Thu, Sep 2, 2010 at 6:14 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
Of course, this only handles the size_request side of things.
It would be up to individual containers to respect the h/v-align in
their size_allocate (basically replacing their current child
properties),
Hi,
On Thu, Sep 2, 2010 at 11:21 PM, Andrew Cowie
and...@operationaldynamics.com wrote:
Are you thinking of the loaders populating an image surface (and thus
being in application memory) or populating an xlib surface (and thus
being in X server memory?)
I'm not proposing any change here.
Hi,
On Wed, Sep 1, 2010 at 6:37 AM, Tristan Van Berkom
trista...@openismus.com wrote:
SPREAD_EVEN is exactly that.. adding extra space between the children as
spacing, and there is SPREAD_EXPAND for the other (not sure if that
could be better explained).
that's what I was saying, just that
Hi,
On Wed, Sep 1, 2010 at 12:24 PM, Shaun McCance sha...@gnome.org wrote:
Would it be better to have padding-start and padding-end,
rather than -left and -right, and have it do the right
thing in RTL locales? I've often wished CSS did it that
way, and GTK+ does do most things with start and
Hi,
On Wed, Sep 1, 2010 at 2:03 PM, Shaun McCance sha...@gnome.org wrote:
Well, all of the packing functions use start and end, but I
guess that's just to make the term orientation-neutral.
Looking through the docs, I do see properties like left-attach,
left-margin, and left-padding. So it
Hi,
On Mon, Aug 30, 2010 at 9:51 PM, Havoc Pennington h...@pobox.com wrote:
With my proposed padding cleanup though that issue goes away:
child = g_object_new(TYPE_MYCHILD, padding, 5, h-align,
GTK_ALIGN_FILL_HORIZONTAL, NULL);
insert_child(layout, child, 2, GTK_WRAP_BOX_PACK_Y_EXPAND
Hi,
On Mon, Aug 30, 2010 at 4:22 AM, Steve Frécinaux nudr...@gmail.com wrote:
When the said window is not maximized, the scrollbar is often not on the
edge of the window, because it can be in a notebook for instance (as it is
the case in gedit) or have margins, but when the window is
Hi,
On Sun, Aug 29, 2010 at 7:02 PM, Havoc Pennington h...@pobox.com wrote:
2. supporting superclasses deriving from GtkWidget that want to add
more padding area stuff to their subclasses on top of what GtkWidget
already does. GtkMisc would be an example - maybe the only example?
I forgot
Looking at ClutterBoxLayout, they separate x and y fill, which may be
worth adding here.
void clutter_box_layout_pack
(ClutterBoxLayout*layout,
ClutterActor*actor,
gboolean
expand,
Hi,
On Mon, Aug 30, 2010 at 1:26 PM, Behdad Esfahbod beh...@behdad.org wrote:
On 08/29/10 19:02, Havoc Pennington wrote:
- is it called padding or border (border is nice perhaps since it
contrasts with all the existing stuff called padding)
Why not copy the CSS box model to the extent
Hi,
On Mon, Aug 30, 2010 at 5:00 PM, Behdad Esfahbod beh...@behdad.org wrote:
Well, I was implicitly suggesting that we take all of CSS margin, border,
padding and then some.
I see. Yeah, that could be cool. I thought about it a little but you
have to figure out what background and border
1 - 100 of 1140 matches
Mail list logo
