Previous thread on this for reference spans three months:
http://mail.gnome.org/archives/gtk-devel-list/2007-July/msg00046.html
http://mail.gnome.org/archives/gtk-devel-list/2007-August/msg00086.html
http://mail.gnome.org/archives/gtk-devel-list/2007-September/msg00088.html
(save everyone else
Hi,
On Wed, Aug 20, 2008 at 3:10 PM, Yu Feng [EMAIL PROTECTED] wrote:
Is there any particular reason that GLib doesn't provide a ref-counted
string and a ref-counted array type? Lacking them in GLib makes the VALA
language a real pain.
I think you would have to explain more why this is an
Hi,
On Wed, Aug 20, 2008 at 9:31 PM, Jamie McCracken
[EMAIL PROTECTED] wrote:
Its GString and not char * which needs the ref counting
That seems fine. But GString is just a temporary buffer (it's like
StringBuffer/Builder in Java, not like String in Java). It's virtually
never passed around in
Hi,
On Sat, Aug 23, 2008 at 8:29 AM, Freddie Unpenstein
[EMAIL PROTECTED] wrote:
This issue comes up repeatedly, and each time the response is to ask for
proof that it would make things better.
How about the opposite, where's the proof that it would make things worse?
In software, everything
Hi,
On Mon, Sep 8, 2008 at 12:07 PM, Mike Kestner [EMAIL PROTECTED] wrote:
If either attribute is unspecified, it's assumed to be false.
Kind of a detail, but with the scanner setup in g-i, I think it would
be good to require manual specification of ownership for all allocated
types.
Hi,
On Sat, Sep 13, 2008 at 1:38 PM, Colin Walters [EMAIL PROTECTED] wrote:
Actually I just had a random thought - what about putting this code
into pangocairo? All of Gtk+, GooCanvas, HippoCanvas and Clutter
depend on Pango, and Pango depends on both cairo and gobject. It's a
bit of an odd
Hi,
Johan suggested on IRC that the patch to cairo could be changed to use
dlopen to grab the copy/free functions lazily, to avoid a compile-time
dependency on glib (and also avoid a runtime dependency, if running in
an app that doesn't link to glib). It's still a hack, but a working
and
Hi,
On Sun, Sep 14, 2008 at 7:37 AM, Luke Kenneth Casson Leighton
[EMAIL PROTECTED] wrote:
i'm looking for advice on memory return result conventions - who is
responsible for maintaining andd/or freeing memory, in particular
strings, as return results from pproperrty getting for example. the
Hi,
On Sun, Sep 14, 2008 at 9:45 PM, Vladimir Vukicevic [EMAIL PROTECTED] wrote:
I don't understand the concern about doesn't mess up the dependency graph
-- there are already a dozen libraries that get linked to any glib-using app
-- why does one more hurt, especially when it would be a
Hi,
On Mon, Sep 15, 2008 at 7:46 AM, Alexander Larsson [EMAIL PROTECTED] wrote:
If you dlopen cairo-glib and use RTLD_LOCAL I think you avoid the symbol
lookup overhead. Maybe this is useful?
It breaks to RTLD_LOCAL something that's also linked to, since you get
two copies of the lib (two
Hi,
On Thu, Sep 25, 2008 at 1:06 PM, Matthias Clasen
[EMAIL PROTECTED] wrote:
The important part of the assert semantics are: if the assertion
fails, the program aborts.
If you are using assertions in a way that make it important where or
how the message is reported, I suggest that you are
Even though the update to each line may be trivial, I would say that
if a deprecation touches a lot of lines in every app, it really has to
meet a high bar for worthwhile-ness, or we're just wasting a whole lot
of people's time.
Deprecation should not be about aesthetics, or second-guessing the
Hi,
Porting a large app written on gobject-introspection from old
gobject-introspection to the latest, I have a number of add-on custom
functions that have to be replaced or kept.
In the long term, we can probably remove the need for any custom
functions, but in the short term we have the idea
Hi,
Thanks for the inject feature, I think that will solve the problem, or
at least some twist on it will ... I'll dig into it. Will also follow
up in a sec on ffi.
I do want to defend gir-repository though - I think it's extremely
necessary to make bindings practical and successful, and get the
Hi,
On Sat, Sep 27, 2008 at 5:05 PM, Colin Walters [EMAIL PROTECTED] wrote:
Well...this needs to be weighed against the other option, which is
having the overrides mechanism be entirely contained within the
bindings.
Right, that's what I started trying to do as I mentioned. However, the
issue
Hi,
On Sat, Sep 27, 2008 at 6:41 PM, Colin Walters [EMAIL PROTECTED] wrote:
Using jhbuild doesn't imply bleeding edge (trunk/HEAD).
But using jhbuild with needed upstream fixes to support bindings
*does* imply bleeding edge ;-)
Bleeding edge is only half the problem, the other half is that
Hi,
On Sun, Sep 28, 2008 at 2:17 AM, Colin Walters [EMAIL PROTECTED] wrote:
They probably do belong in glib proper, not gobject-introspection.
That would create a circular dependency.
I didn't mean the flavors taking a GIFieldInfo etc., I meant a
lower-level API that contained all the
Hi,
On Sun, Sep 28, 2008 at 2:17 AM, Colin Walters [EMAIL PROTECTED] wrote:
I think the injection and the custom .so should be in gir-repository,
and that the custom .so should be per-typelib to avoid extra
dependencies. (i.e. the custom .so for GLib should not drag in GTK)
Ok. I guess this
Hi,
On Mon, Oct 6, 2008 at 4:42 PM, coda [EMAIL PROTECTED] wrote:
As a result of all
this, gedit's inability to edit binary files is simply an inability to edit
a
file with a NUL byte in it.
That doesn't seem true; a binary file could be invalid UTF-8 (or
whatever encoding) in thousands of
Hi,
On Tue, Oct 7, 2008 at 5:50 PM, Brian J. Tarricone [EMAIL PROTECTED] wrote:
I think what he really meant (or if not, here's my take on it) was that NUL
bytes aren't *printable* text... like you'd say of low-value ASCII data.
Sure, it's technically text, but most of it isn't something you
Hi,
On Wed, Oct 8, 2008 at 11:00 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote:
Lemme pull a real-world example: Last year I had to fix a bug in Firefox where
a page with a nul byte crashed the browser.
What I don't see is how a nul byte is in any way different from an
invalid sequence, other
Hi,
On Thu, Oct 9, 2008 at 8:46 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote:
nul is invalid *just* because you declared it so.
I guess my whole claim is that it's useful/better to declare it
invalid in contexts where you really want text, as opposed to an
arbitrary binary stream. I don't see
Hi,
On Sat, Oct 25, 2008 at 6:32 PM, Matt Bucknall [EMAIL PROTECTED] wrote:
'gtk_box_forall' passing gtk_widget_destroy as the callback to destroy all
the container's child widgets. What I cannot see is how, in the latter case,
all the GtkBoxChild objects associated with the child widgets are
Hi,
2009/1/14 Pietro Battiston too...@email.it:
the documentation for gtk_widget_size_request () says:
Also remember that the size request is not necessarily the size a
widget will actually be allocated.
While there may be a lot of reasons why a widget doesn't get the area
requested, I
GDK only exposes stuff that's useful for writing a normal-ish
application; it won't expose things you might want if you're writing
one of the various sorts of manager like a window manager,
compositing manager, system tray manager, etc. But it has everything
GTK uses and GTK is sufficient to write
Hi,
On Wed, Feb 11, 2009 at 1:07 AM, Matthias Clasen
matthias.cla...@gmail.com wrote:
There is also some work by Ryan Lortie on a Glib-compatible Dbus api
called gbus. It is lower-level than EggDbus, and might be suitable as a
replacement for libdbus. While I have no clear idea yet how EggDbus
Hi,
On Fri, Feb 13, 2009 at 10:35 AM, Matthias Clasen
matthias.cla...@gmail.com wrote:
Not sure what that 'something else' would be on win32 or os x. Anyway,
dbus works fine on os x, as far as I know. And I think there is a
working win32 port around (even if it hasn't been merged back into
Hi,
I sent an earlier draft of these notes to davidz, but I think would be
useful for other binding authors and for the glib team when looking at
eggdbus, so cleaned it up a bit for this mail. A lot of this is not
specific to glib binding and would apply to any binding.
Some biases I have in
Hi,
A followup on the gjs binding API, because I think it shows how a
dynamic binding is quite different from C, and also just how small the
API really needs to be.
The dbus js module has two items in it, the session and system
objects; these are pretty much DBusConnection wrappers.
Interface
Hi,
Finally, maybe it's useful to go more concrete looking at eggdbus and
mentioning some of the specific stuff in there. I know it's a lot of
comments but I'm just giving my opinion, take it for whatever it's
worth.
General stuff
===
* Maybe this should have some use of gobject-introspection.
Hi,
On Tue, Feb 24, 2009 at 9:03 PM, Havoc Pennington h...@pobox.com wrote:
eggdbusnametracker
Another thing I just noticed in here, it looks like when the initial
GetNameOwner returns then you aren't emitting the
bus-name-gained-owner signal. I'd suggest that bus-name-gained-owner
reflect
Hi,
On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman
mark.doff...@codethink.co.uk wrote:
Both the throws and reply clauses are optional, but if a method does not
have a reply it should not have a throws clause.
This is perhaps a misunderstanding. All methods have replies (in the
wire protocol).
Hi,
On Tue, Mar 3, 2009 at 6:03 AM, Mikkel Kamstrup Erlandsen
mikkel.kamst...@gmail.com wrote:
2009/3/2 Havoc Pennington havoc.penning...@gmail.com
Anyway, I think there is no difference between method calls and
message passing. The only difference is in whether the client side API
is made
Hi,
On Tue, Mar 3, 2009 at 1:19 PM, David Zeuthen da...@fubar.dk wrote:
So, to sum up, the main suggestions you are making are
- Rework low-level bits of EggDBus so it's like dbus-hippo-helper
- Don't try to hide libdbus in the low-level bits
(but do hide it from the high-level bits)
Hi,
On Tue, Mar 3, 2009 at 2:12 PM, Ville M. Vainio vivai...@gmail.com wrote:
I'm not saying dbus-glib is inherently harder than the raw bindings -
perhaps the documentation just fails to make the point why it would be
easier ;-).
I do think it's only sometimes easier. For me the iterator
Hi,
On Tue, Mar 3, 2009 at 1:19 PM, David Zeuthen da...@fubar.dk wrote:
So I think maybe we want
GBusLowlevelConnection
that is useful for all languages and then
GBusConnection
for the C/GObject binding. But that's ugly. Ideas?
Maybe there's a ProxyManager or something which is higher
Hi,
On Mon, Mar 16, 2009 at 12:45 PM, IdaRub ida...@gmail.com wrote:
After reading the gobject code a bit more, it seems that weak
references are fired on dispose, not finalize:
Right, that's correct.
All of the documentation I could find states that it happens during
finalization, but it
Hi,
On Thu, Apr 2, 2009 at 7:05 PM, Ryan Lortie de...@desrt.ca wrote:
- How does it fit with gobject-introspection?
- Do we need code generation?
I'm on the same page with you here, but I think the fix is to split
the object mapping from the other pieces (as outlined in my long
manifesto
Hi,
On Fri, Apr 3, 2009 at 2:56 PM, Will Thompson
will.thomp...@collabora.co.uk wrote:
I don't think that relying on having correct introspection data to
marshall messages is a sound idea for a DBus binding.
There's no way you can marshal a message without the introspection data.
It can be
Hi,
On Sat, Apr 11, 2009 at 11:06 AM, Matthias Clasen
matthias.cla...@gmail.com wrote:
What David is saying (and I'm sure you understood) is that glib
already comes with a type system, namely GType. Adding a completely
separate one next to it in the same module is problematic, even if it
is
Hi,
On Thu, Apr 9, 2009 at 11:38 AM, Dan Winship d...@gnome.org wrote:
So, my feedback is, if the type system is explicitly just D-Bus and
nothing else, shouldn't it be called GDBusType or something? (I'm not
saying it's *bad* that it's D-Bus-specific, just that it should be more
explicit
Hi,
On Sun, Apr 12, 2009 at 9:14 AM, Christian Dywan christ...@imendio.com wrote:
You are asserting that something like a gint or guint is not
something that can be saved to disk.
I'm not saying that; I'm saying they can only be saved to disk by
converting them to a fixed-size integer.
int is
Hi,
On Sun, Apr 12, 2009 at 9:14 AM, Christian Dywan christ...@imendio.com wrote:
Using G_TYPE_FOO in the API is imho a lot more agreeable than any new
string signature. Sure it's more to type, but at the same time it's
more comprehensible. :)
I don't disagree for C. One thing to note
Hi,
On Thu, Apr 9, 2009 at 11:38 AM, Dan Winship d...@gnome.org wrote:
So, my feedback is, if the type system is explicitly just D-Bus and
nothing else, shouldn't it be called GDBusType or something? (I'm not
saying it's *bad* that it's D-Bus-specific, just that it should be more
explicit
Hi,
On Mon, Apr 13, 2009 at 7:45 AM, Mikkel Kamstrup Erlandsen
mikkel.kamst...@gmail.com wrote:
* I really hope there is room in GVariant for NULL values in some way
or other. Without a NULL it is hard to map stuff from an SQL DB
directly to the serialization format without nasty hacks. This
Hi,
On Mon, Apr 13, 2009 at 3:00 PM, Ryan Lortie de...@desrt.ca wrote:
GVariant has nullable (maybe) types which were a proposed extension to
DBus some time ago but never materialised. iirc, Havoc, you had a
favourable opinion of this extension but wasn't sure exactly how we'd handle
the
Hi,
On Mon, Apr 13, 2009 at 3:00 PM, Ryan Lortie de...@desrt.ca wrote:
- dictionary entries in GVariant can stand freely (ie: they are not
restricted to being contained in an array).
What does it mean if you have a free-floating dict entry? Are you
supposed to treat as a dict with one
Hi,
On Mon, Apr 13, 2009 at 4:32 PM, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
On Mon, 13 Apr 2009 at 15:56:36 -0400, Havoc Pennington wrote:
It looked like you might allow non-string dict keys, was one I noticed.
Er, so does D-Bus... Telepathy uses a{uu} in at least one place.
I
Hi,
On Fri, Apr 17, 2009 at 9:38 PM, Brian J. Tarricone bj...@cornell.edu wrote:
I assume the issue was with returning a non-primitive type by-value and not
as a pointer.
Right. The normal way in glib/gtk would definitely be as you say.
void
gtk_widget_get_allocation (GtkWidget *widget,
Hi,
On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller t@zen.co.uk wrote:
You tell people not to worry. But many people clearly do seem to worry.
Well, why don't these many people post a rational response to my
points? I have not seen a rebuttal to
Hi,
On Sun, Apr 19, 2009 at 8:05 PM, Allin Cottrell cottr...@wfu.edu wrote:
Havoc may well be right with regard to libdbus, but IMO the burden
of proof rests the other way; that is, if code that is not under
*GPL is to be made part of glib, the onus is on those who would
make the addition to
Hi,
On Mon, Apr 20, 2009 at 10:31 PM, Allin Cottrell cottr...@wfu.edu wrote:
On Sun, 19 Apr 2009, Havoc Pennington wrote:
The license was written by a lawyer and is perfectly sane.
Sane and written by a lawyer are surely orthogonal to
desirability from the point of view of free software
Hi,
On Fri, Apr 24, 2009 at 6:56 AM, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
As mentioned above, dropping my use of libdbus' helpful object path mapping
and just using a filter function was a net code reduction.
Getting pretty off-topic, but the object path mapping in
Hi,
On Mon, Apr 27, 2009 at 10:40 AM, Behdad Esfahbod beh...@behdad.org wrote:
There is a lot of G_UNLIKELY() calls in places that really are not in
any way performance sensitive. I'm not sure I like this, since it makes
the code harder to read for very little gain. Like, it probably makes
Hi,
On Mon, Apr 27, 2009 at 1:20 PM, John McCutchan j...@johnmccutchan.com wrote:
It's good practice to avoid using hints unless you have a firm grasp
on the odds of the branch being taken.
The thing I find kind of intractable, is that you have to not only
know the odds, but think your grasp
Hi,
On Sat, May 2, 2009 at 1:02 PM, David Zeuthen da...@fubar.dk wrote:
o It seems like you (or Simon or both) expect GVariant to be the only
container type in town for C bindings for D-Bus (as per the D-Bus
library bug report). E.g. you expect the C programmers to deal with
a{ss} as a
Hi,
On Tue, Jun 8, 2010 at 7:06 PM, Emilio Pozuelo Monfort
poch...@gmail.com wrote:
Hi,
On 09/06/10 00:49, Emmanuele Bassi wrote:
• how to deal with gtk-requiring libraries, with regards to the API/ABI break
- libraries will have to do an ABI bump to match the ABI bump in gtk
- we need to
Hi,
On Fri, Jun 4, 2010 at 12:50 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
app = g_object_new (GTK_TYPE_APPLICATION, appid, appid, NULL);
g_application_register (app, argc, argv, gtk_application_get_platform_data
());
A convenience API that took the likely parameters and
Hi,
On Fri, Jun 25, 2010 at 10:11 AM, Stuart Axon stua...@yahoo.com wrote:
I was reading about XCB and trawled through the gtk list archives noticed
there was some discussion, but that deprecating gtkx.h seemed to stall things.
Maybe now that gtk3 is coming up it would be the time to consider
Hi,
On Mon, Aug 2, 2010 at 9:21 PM, Yasushi SHOJI ya...@atmark-techno.com wrote:
what am I missing? or what should I do to port a RGB565 application to
new 3.0 platform?
What are you doing with the RGB565 data? GdkImage only has three
operations really: get from drawable, draw to drawable,
Hi,
On Tue, Aug 3, 2010 at 5:14 AM, Yasushi SHOJI ya...@atmark-techno.com wrote:
I assume I can't do the following:
pixbuf = gdk_pixbuf_get_from_drawable(NULL,window,NULL, ...);
Oh, this is really not what you want to do at all - getting an image
or pixbuf from drawable is actually
Hi,
On Wed, Aug 4, 2010 at 2:57 PM, Daniel Macks dma...@netspace.org wrote:
Well, it's fine if you don't intend to test it on those systems, but others
certainly are. For example, I manage the gnome suite for Fink, where our
users can run a fullish gnome desktop environment (I think similar
Hi,
On Wed, Aug 4, 2010 at 5:08 PM, Behdad Esfahbod beh...@behdad.org wrote:
On 08/04/10 16:33, Havoc Pennington wrote:
I have a personal project where I'm not using convenience libraries
for files that are part of a half-dozen executables because it's
faster to compile files 6 times than
Hi,
On Wed, Aug 4, 2010 at 4:46 PM, Sven Neumann s...@gimp.org wrote:
What about http://dolt.freedesktop.org/ ? The approach taken here sounds
quite reasonable and has the potential to cut down compile time
significantly while keeping the portability of libtool without having to
reimplement
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
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,
Hi,
On Wed, Aug 11, 2010 at 10:02 PM, cee1 fykc...@gmail.com wrote:
So if I have a IOChannel watch source with a high priority, and then attach
an idle source, the idle source will have no change to be scheduled?
An idle source will never be scheduled while any higher-priority
source is ready.
Hi,
On Sat, Aug 14, 2010 at 9:57 AM, cee1 fykc...@gmail.com wrote:
I've written a test program, which creating watches for two GIOChannels: one
for stdin with a low priority, and the other for a named pipe with a high
priority. Then ran the program with no data written to the named pipe, it
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
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.
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
Hi,
Is this more achievable if you start with Alex's step 3) Change the
event model instead of starting by removing widget-window?
I wonder if stuff would break much if you made one basic change: add
capturing. i.e. send events down from the window-owning widget through
all children that are at
It might be worth thinking about a gradual path to first allowing new
code to be written with only code to create static typelibs (runtime
registration stuff would be autogenerated), and then in glib/gtk 4.x,
the idea would be to drop the runtime-registration-based introspection
features from
Hi,
Matthias's mention of padding props got me thinking about how this
could be mopped up (based shamelessly on what we did in HippoCanvas
and then BigBox)
I'm attaching a patch that I haven't even tried to compile (my jhbuild
setup is kinda hosed, don't ask) illustrating what I might like to
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
it'd be great to avoid the GtkBox stuff I was whining about in the
padding thread, e.g.
void egg_wrap_box_insert_child (EggWrapBox
*layout,
GtkWidget
*widget,
Hi,
On Mon, Aug 30, 2010 at 9:51 PM, Havoc Pennington h...@pobox.com wrote:
I think guint here is just misleading; it's not like you can use
UINT_MAX, GTK uses signed int for most layout internally to avoid
screwy bugs caused by subtraction ending up 0.
Also public API like set_size_request
While I'm making trivial comments about wrap box - there's START/END
in several other enums, rather than BEGIN/END (just look through
gtkenums.h, wrap box is the only BEGIN)
@GTK_WRAP_BOX_SPREAD_EVEN description says evenly distributed between
children which I think means as spacing between
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 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,
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 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
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
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
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
101 - 200 of 1140 matches
Mail list logo
