On Fri, 2005-02-25 at 10:58 +, Gustavo J. A. M. Carneiro wrote:
I'm not saying libffi is bad, if we have computer generated prototype
descriptions. Manually using libffi is more of a problem due to the
human tendency to make mistakes...
Another concern about libffi is portability.
On Thu, 2005-03-17 at 16:56 +0100, Pierre Ossman wrote:
The problem here is that a 'source' that has been removed is somehow
still dispatched. When it is called here the related structures are
already freed and overwritten by other data. The callback address in the
object (a DBusTimeout
On Thu, 2005-03-24 at 22:22 +0800, KC wrote:
it's X reparent problem. I just want to know if the patch I posted worthy to
apply or does XReparentWindow() do have such problem for some window
managers.
The problem is that without XEMBED you're doing something totally
Hi,
Back in the day when I was working on the Inti C++ bindings, one of the
objectives was to clean up the cruft from the GTK+ C API. Some examples
of cleanups one might do:
- put the main loop only in the GLib layer, no gtk_main visible
- hide color allocation, just always use the GdkRGB
On Fri, 2005-03-25 at 00:45 -0500, Havoc Pennington wrote:
- put the main loop only in the GLib layer, no gtk_main visible
- hide color allocation, just always use the GdkRGB stuff
- fix some of the other examples of weird X features leaking through
- gdk_drawable_get_size() replaced
On Fri, 2005-03-25 at 13:50 +0800, KC wrote:
This I don't quite agree. Look at the function prototype, it's
void gtk_socket_add_id (GtkSocket *socket_, GdkNativeWidnow XID);
It implies all GdkNativeWindow should work ...
I prefer looking at the docs ;-)
* gtk_socket_add_id:
*
On Tue, 2005-03-29 at 15:30 +0800, James Henstridge wrote:
Is there any reason to hide destroy() though? If you hide it, you'll
need to provide some other way to destroy toplevel windows, among other
things.
I'd move it to GtkWidget I think.
I'd put this one under provide sane default
On Mon, 2005-08-15 at 20:06 +0200, Soeren Sandmann wrote:
Havoc Pennington [EMAIL PROTECTED] writes:
So random thoughts.
A few more random thoughts:
All good stuff, Piccolo and Java3D have some ideas here -
- Zooming is more than just setting a transformation matrix because
On Sun, 2005-08-21 at 14:05 +0100, Roger Leigh wrote:
One thing I (as an end developer) would like is for libgobject to be
merged with libglib
That's off the table since it would break ABI ...
I currently find the split to make some tasks impossible (for example,
I recently wrote a
On Wed, 2005-08-24 at 07:44 -0400, JP Rosevear wrote:
On Mon, 2005-08-22 at 13:37 +0200, Rodrigo Moya wrote:
what about libsoup/network library? Wouldn't it also make sense to move
it to a libgnet in glib?
I'm also for this, right now we are using multiple networking libraries
and we fix
Hi,
May also be worth pointing out that even if the WM honors the request
it's asynchronous, so you need to run the main loop to process the
changed state event before you could get_state() and see the new state.
Or if gdk_window_get_state() does a round trip, you don't need to run
the main loop
Hi,
The way I've always thought about the floating flag is that when you
create a new object, *you* don't own a reference. Instead, there's a
floating reference with no owner, and anyone is allowed to remove that
floating reference since it's community property - the if floating
exists remove it
On Tue, 2005-12-20 at 17:27 +0100, Tim Janik wrote:
GObject:
- created with ref_count=1
- not initially floating
This is the key I think. The point of my theoretical rant is that I
think it's really bad if I do:
obj = g_object_new(TYPE_WHATEVER);
and don't know whether I own a refcount or
On Tue, 2005-12-20 at 09:37 -0800, Dave Benson wrote:
why does one want GFloatingObject?
it seems like calling g_object_force_floating()
isn't too hard... and derivation is a somewhat
inflexible way to set flags (for example, it
can't be done in a subsubclass of object;
and to support N
On Thu, 2005-12-22 at 19:02 +0100, Tim Janik wrote:
in fact, there is no technical reason for this. so many people have
argued this to be better though (havoc even went so far as to argue
why this would be conceptually neccessary), that i decided to simply
sponsor an object type if that helps
On Tue, 2006-02-28 at 16:33 +, Gustavo J. A. M. Carneiro wrote:
That sounds complicated to get right in one go. Personally, I'd just
be happy to have a canvas that lets you create items, with virtualized
draw method, even at position/size statically controlled by the
programmer,
Carl Worth wrote:
A downside is that these new, inert objects are exposed to the
application and might cause unexpected side effects. (In practice, as
I've been switching various parts of cairo's internals to this scheme,
the worst side effect I've found is that switching to an inert-object
Hi,
I posted some sort of blue-sky canvas ideas a year ago:
http://mail.gnome.org/archives/gtk-devel-list/2005-August/msg00067.html
Since then I've learned HTML/CSS much more thoroughly and also used
Flash a bit. And in the last week needed to write a canvas in 2-3 days
to use for Mugshot.
Gustavo J. A. M. Carneiro wrote:
It seems this HippoCanvas has no model-view split, yet I remember you
designed GtkTextBuffer/View with model/view. Do you consider model-view
unimportant, or simply just got prioritized away?
I'm not sure, I'd have to look at GooCanvas or experiment
Tristan Van Berkom wrote:
Havoc
My opinion is that the canvas should replace the GTK core in a way,
i.e. GtkWidget
becomes a specialized thing you can embed in a canvas.
This obviously makes the canvas into a pretty big project.
Kindof disagree here - I think that in most cases a
Marco Pesenti Gritti wrote:
This seem to imply a box based layout for the canvas, similar to the gtk
one. In one of your previous canvas posts you was talking of more
powerful layout managers (to be able to layout widgets around a shape
for example). Something turned down that idea?
If
Soeren Sandmann wrote:
A much simpler approach is often to simply walk the model and draw on
a drawing area on every expose event. This gets hard for two reasons:
- you need to handle input on distinct areas corresponding to objects
in the model.
- you need to handle scrolling
Both
Soeren Sandmann wrote:
I think retained mode is interesting when the objects have two
properties:
- Does the object contain state that the application doesn't *care*
about.
- Is the object generic enough that many applications would need it
That amounts to saying does the
Hi,
Soeren Sandmann wrote:
My point is that flash/html-like custom UI is simply not convenient to
do in _any_ toolkit, extra-nifty or not
While I don't doubt something even more convenient is possible, I would
say Flash and HTML are well ahead of both GtkWidget (retained-mode) or
Soeren Sandmann wrote:
Yevgen Muntyan [EMAIL PROTECTED] writes:
Much more people would make use of simple things like draw a
rectangle and drag it around if it wasn't so hard.
The draw a rectangle and drag it around use-case is somewhat
misleading; it applies most to something like a game,
Tristan Van Berkom wrote:
I just dont think we should dive right into writing up a GtkRocketShip or
a GtkFlashScene without having paved the way with a simple GtkCanvas that
is usefull to everybody first - rocket ships and geckos might also be
considered as unneeded bloat to gtk+, and could
Hi,
Damon Chaplin wrote:
So how are we going to decide on a list of requirements for a canvas?
I think there seem to be two main use cases:
A) DTP/Graphics apps that want a canvas for the main document.
(A model/view split, device-independent layout, zooming printing
are
Tim Janik wrote:
ah, interesting. could you please explain why you consider it
such a big win?
Without it I think I usually write about 10% coverage, and imagine in my
mind that it is 50% or so ;-) I'm guessing this is pretty common.
With it, it was easy to just browse and say OK, this
Hi,
You'd probably be a lot better off just installing a global event filter
(see libwnck or metacity for an example)
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Ross Burton wrote:
I'd say thread-safety.
And the ability to not link to libX11, which is relatively huge.
It seems pretty clear that gtk-x11 has to continue to be installed -
gdkx.h is in the ABI.
That means a path forward would have to make maintaining both XCB and
libX11 GDK targets a
Ross Burton wrote:
This sounds good to me. Would deprecating gtkx.h be considered when XCB
is sufficiently deployed?
It's almost an academic question, right... it's not like anything
deprecated in 2.0.0 has been removed yet.
Havoc
___
Jamey Sharp wrote:
This approach isn't thread-safe, which is why XCB's API is designed to
discourage it. There may be various reasons why thread-safety doesn't
matter at these points in Gdk
Such as GDK is in no way threadsafe ;-)
http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html
Louis E Garcia II wrote:
I believe Yang JianJun is working on the xcb port of gtk and wanted to
know how it's coming? Their has been talk of possible abi compatibility
problems with xlib. I wonder if this would be a good time for a abi/api
break 3.0 release. Their are many performance
Hi,
David Zeuthen wrote:
Actually, as mentioned on IRC, TCP/IP transport been in D-Bus for a long
time, it's just not hooked up by default on the session bus nor
forwarded by e.g. ssh yet. You asked about how auth will work; that's a
good question... Havoc, can you shed some light on the
David Zeuthen wrote:
Writing this patch and getting it into openssh sounds like great Google
Summer of Code project for the D-Bus project.
All the changes would be to openssh though. Probably a first step is
just ask on the openssh mailing list.
[1] : such as /var/lib/dbus/machine-id - btw,
Hi,
Asbjørn wrote:
I'm tightning my code and i wonder why some of the g_slist functions don't
use
const.
Here is an old mail on the topic:
http://mail.gnome.org/archives/gtk-devel-list/2001-May/msg00485.html
Havoc
___
gtk-devel-list mailing list
Hans Petter Jansson wrote:
If it's cached, shouldn't it still be reachable?
valgrind has a (mostly useless) mode that shows reachable-but-not-freed
blocks.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
Hi,
Carlos Garnacho wrote:
First of all we need to specify the feature requirements for the
canvas.
I'd step back first and do use-cases instead, and also talk about at a
high level what the canvas is for and when it would be used, i.e.:
- when is a canvas item used vs. a widget? what
Marco Pesenti Gritti wrote:
* Key navigation (which is obviously also a prerequisite for a11y)
I'd add to this bullet anything GtkWidget has that HippoCanvasItem does
not - basically HippoCanvas is the GtkWidget/GtkContainer replacement
school of canvas thought.
* Ability to set a global
Marco Pesenti Gritti wrote:
There is something which bothers me though. Support for some units,
points for example, would require floating points measures. And I
suspect we don't want to do layout in floating point (instability
issues). Mozilla converts css units in twips (an arbitrary
Sven Herzberg wrote:
I don't think the GtkWidget API and the GtkCanvas API shouldn't be tied
together too much.
In HippoCanvas we took this to the extreme of not including gdk.h or
gtk.h in the canvas core. I happen to really like this approach, but in
general I tend to like to keep code
Michael L Torrie wrote:
On the other hand I don't often use gobjects, the event loop,
call-backs, or any other part of glib in many of these little utility
programs.
The real question of course is whether everyone's use and don't use
lists are similar or not.
It's a little bit academic,
Brandon Casey wrote:
And this has caused the dependency
requirements of glib to grow, which makes it harder to build (think non
linux platforms).
OTOH, having all the portability goo in GLib makes all the *apps* easier
to build once you get GLib done. Most of the stuff in GLib _is_ needed
by
Hi,
Federico Mena Quintero wrote:
Now for the other use-case... in GNOME we don't have much experience
with loading SVG-like things and then manipulating them (think Flash).
Maybe we can find someone with Flash experience to comment on what API
would be helpful to them?
For most Flash usage,
Hi,
Carlos Garnacho wrote:
What are we missing in the current core? What benefits would bring a new
one?
I certainly have not sat down and exhaustively tried to figure this out.
There is a fair bit of cruft in the core; if you were starting over, I'm
sure you'd want to just kill GdkWindow
Hi,
Brandon Casey wrote:
It's hard for me to think of unicode as
being low-level when it adds so much overhead to string handling.
I think many just wouldn't agree - yes it adds overhead, but without
Unicode, string handling doesn't *work* - so saving the overhead is
pretty useless unless
Hi,
I read over the GooCanvas code and wrote down everything I thought of,
some of it is half-baked or quarter-baked, but hopefully helpful in some
way.
Havoc
- GooCanvas object could have private fields, also e.g ItemSimple has
public fields... I think it's nicer to always use accessors,
Hi,
Michael Lawrence wrote:
I am wondering what is happening with GObject introspection. It seems
that it has been in the works for some time now but that development has
stalled.
Rob Taylor started working on it again, see
http://bugzilla.gnome.org/show_bug.cgi?id=363228
1) What are the
Hi,
Carl Worth wrote:
On Thu, 3 May 2007 11:11:39 +0200, Benjamin Otte wrote:
I much prefer the cairo model, where basically the
object keeps its own GError and has a function like cairo_status [3]
that gives you the last error that occured.
It's worth pointing out an
Hi,
Benjamin Otte wrote:
To bring up some examples: GdkPixbufLoaders, GKeyFile, GBookmarkFile,
GMarkup.
I'd be for that in the case that the API has a required ending call,
the equivalent of close(). Then you can force error checking on that
last call with a GError or warn_if_unused
Hi,
Havoc Pennington wrote:
In GLib/GTK it's library bugs vs. app bugs, D-Bus maintains the same
distinction for _dbus_return_if_fail vs. _dbus_assert *but* D-Bus makes
them both fatal so it doesn't matter much anyhow.
And as Benjamin pointed out, D-Bus ships with assertions disabled
Hi,
Carl Worth wrote:
Anyway, I've learned a few new things, and found the discussion very
useful. I hope you have as well.
Certainly.
By the way, is that a compile-time or a run-tim environment variable?
And what measures do you take to advertise it?
It's a run-time env variable. I think
Hi,
Vincent Untz wrote:
For example, a lot of companies do have an interest in GTK+ but are not
actively participating upstream. I've been in contact with some of them
to see if they could get some of their developers to freely work on
upstream as part of their job. People have been open
Would it be better to just support an icon inside the entry? (how many
different use cases are there really for this, maybe all of them should
just be supported directly?)
The reason for the side windows in GtkTextView is sort of different:
they scroll with the text view contents. The
Is the Hello, World simplest use case as short and simple as it possibly
could be? That's always a handy final litmus test for an API.
From the header it looks like the simplest hello, world would have to
builder_new, add_from_file, connect_signals, get_object at minimum?
Maybe there's a
Hi,
Johan Dahlin wrote:
Havoc Pennington wrote:
Is the Hello, World simplest use case as short and simple as it possibly
could be? That's always a handy final litmus test for an API.
How do you do an hello world in a ui toolkit?
Should it include signals? How many widgets
Hi,
Pascal Schoenhardt wrote:
As far as I know, the number
of screens in X is hard coded to 1, and always will be (hence
xinerama, and now RandR 1.2).
It isn't hardcoded to 1 in X, there can be multiple.
There's no real reason to have multiple and few people do it anymore,
but in the days
Hi,
Kristian Rietveld wrote:
GUnique was brought up as a possible feature for 2.14, a small discussion
about its usefulness as stand-alone feature emerged. It doesn't make all
that much sense without an application window class, subsequently an
application window class doesn't make much
Somewhat related, I was thinking if we had proper dbus usage sorted out
in gnome, a number of the nuts and bolts of this could be in the dbus
lib and gtk would mostly deal with the GdkScreen and startup
notification aspects.
background:
Hi,
What about nautilus? At what point would it be ported, and are things
going to be weird if an app is using gvfs and nautilus gnome-vfs, or
vice versa?
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
Hi,
There's a lot of code to absorb here, a minor comment, I might expect
GUnixFileInputStream/GWindowsFileInputStream rather than
GLocalFileInputStream.
I haven't found the relevant code yet to see what it does, but a nice
property would be to set close-on-exec by default for all streams.
A
Hi,
On 9/14/07, Alexander Larsson [EMAIL PROTECTED] wrote:
Well, the same class is used on both unix and windows. Its the
implementation of native files, and I don't see any need to split it
out really. What differences would there be between the two?
My impression is that ideally on Windows
Hi,
Various bits of the GNOME platform are ending up off to the side or
not integrated into gtk properly due to the dbus dependency.
(previously whining about this at
http://lists.freedesktop.org/archives/dbus/2007-August/008238.html)
Examples of features that do or could use dbus, which should
Public
* License along with this library; if not, write to the
* Free Software Foundation, Inc., 59 Temple Place - Suite 330,
*
* Author: Havoc Pennington [EMAIL PROTECTED]
*/
#ifndef __GTK_DESKTOP_H__
#define __GTK_DESKTOP_H__
#include gdk/gdk.h
G_BEGIN_DECLS
#define GTK_TYPE_DESKTOP
Hi,
I had a random thought at the summit; what if we add a new library in
the stack (perhaps shipping with GLib or GTK tarball, I don't know).
Call it libgapplication. It would contain:
- GApplication
- GSettings
- dbus main loop hooks
- ...
It would depend on GObject, dbus, gvfs,
Hi,
BJörn Lindqvist wrote:
So how about replacing gdk-pixbuf with something cairo compatible that
is also modern? 16 bits per sample is common these days. Support for
digital camera RAW images would also be nice. Is a completely new
image library worth pursuing? Are there maybe better ways to
Hi,
Alp Toker wrote:
2) GTK+ has a dependency on dbus, on X11 only, for desktop
integration features to work. (See list of examples above.) By
dependency I mean specifically:
- dbus.h is not included in gtk.h
- gtk or gdk contains interfaces such as settings, notifications,
single
Hi,
The concerns you raised are:
- multiple implementations of dbus protocol are extra overhead
- multiple connections to the bus from a single process are extra
overhead
- multiple connections may be confusing semantically
Well, there is a proposal on the table to avoid multiple
Hi,
Simon McVittie wrote:
I'm not convinced Gtk+ is the place to be experimenting with D-Bus
integration. Can't we do the experimentation in a libgdesktopbus or
libgnomebus or something, with convenience API for single-instance,
notifications, etc., that hides libdbus, and if it turns out
Hi,
Alp Toker wrote:
API goals like manage the screensaver simply fall outside of GTK+'s
job description. I don't think you understand the diversity of scenarios
GTK+ is used in.
I wrote large parts of GTK. I have been involved with it (and the gnome
libraries) since at least 1999,
Hi,
Brian J. Tarricone wrote:
As for multiple implementations, why can't gtk have a simple pluggable
IPC module, sorta like the IM modules or GtkFileSystem? I know, I know,
it's one more layer of potentially-unneeded abstraction, one more API
that needs to be carefully designed since it
Hi,
The point about toolkit vs. app framework I think is perfectly
debatable, but is best debated on its own, and considering lots of
things besides dbus, imo. I won't try to start that thread by laying out
a comprehensive position statement or anything. There is already some
stuff on Project
Hi,
It may not be clear to everyone on the list the structure of GIO and
GSettings; we had a discussion with Ryan about it on Monday. (I am not
100% sure GIO works the same as GSettings, so I'll talk about GSettings.)
Applications use GSettings, which includes an interface for storing
Hi,
While I haven't looked at the patches in detail, based on your writeup
it feels like the interfaces here will make it a little hard to
implement in widgets.
In HippoCanvas I ended up with this:
void (* get_width_request)(HippoCanvasItem *canvas_item,
Hi,
Matthias Clasen wrote:
On Nov 20, 2007 8:45 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote:
a) Maximize number of children taking their natural size.
I am not convinced this is always the best strategy. Doesn't this
encourage starving
one child in favour of the rest of the pack
Hi,
Behdad Esfahbod wrote:
The PACK_IF_FITS children are done in a second pass after other children,
the if_fits flag indicates which pass this is. If if_fits=TRUE we need
to skip if_fits children that did not fit.
Interesting. Do you think that will be useful to add to Gtk+?
I
Hi,
Mathias Hasselmann wrote:
OK, so lets six other years until we get the perfect solution Havoc
dreams of in his pipe dreams.
I think you misunderstand the intent; you said here's the proposal and
I asked some questions and said what about doing it this way
You are very welcome to say
Hi,
Mathias Hasselmann wrote:
Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington:
Then the following default implementations:
- all four of the new functions have default implementations that
invoke the current size_request and use it for both min and natural
size
Hi,
On Sun, Mar 2, 2008 at 12:44 PM, Sven Neumann [EMAIL PROTECTED] wrote:
Shouldn't GTK+ provide a really simple output widget for this use case?
I would just instantiate a GtkWidget, but GtkWidget is abstract. Am I
missing something obvious?
You could probably use GtkAlignment or
Hi,
Have posted some notes over the last couple years discussing a canvas
widget, based on working on HippoCanvas, and looking over GooCanvas.
Recently I've also been hacking on Clutter, and prototyping a
specialized compositing manager based on Clutter.
I think there's a practical, attainable,
Hi,
Some people asked about Pigment; I thought it was all in Python so had
not looked at it. But it turns out the core is in C. So, this is
something else to look at. I did not leave it out on purpose, just
didn't realize it had the C part.
Here is the home page:
Hi,
2008/5/6 Felipe Contreras [EMAIL PROTECTED]:
I noticed disable-nls wasn't available so I dug until I came with a solution.
I'm attaching a patch that makes use of autopoint and seems to work fine.
I would have created a bug report but the bug reporting form is a joke [1].
Try this
Hi,
On Tue, May 6, 2008 at 4:15 PM, Felipe Contreras
[EMAIL PROTECTED] wrote:
Is there any reason?
I don't know. If I had to guess, it probably wasn't seen as worth
maintaining. After all none of the other features of GLib have random
--disable-feature options. Searching in bugzilla might
Hi,
On Tue, May 6, 2008 at 7:54 PM, Brian J. Tarricone [EMAIL PROTECTED] wrote:
Disabling NLS support might be quite useful for people on embedded
systems and/or people who are using glib for only a part of their
application and use a different translation framework.
Right, but that
Hi,
2008/5/19 Zhe Su [EMAIL PROTECTED]:
So I'm wondering is there and method to move, resize and redraw a window
at the same time to avoid flick?
The underlying X window system doesn't support doing this, though it
may in the future as compositing managers become the norm.
The best you can
Hi,
On Sun, Jun 1, 2008 at 11:53 AM, Yevgen Muntyan [EMAIL PROTECTED] wrote:
Too bad gobject-introspection depends on python-2.5. Is
it going to be a dependency only for gobject-introspection
itself, or is it going to be a dependency for projects
which use gobject-introspection, i.e. will a
Hi,
On Fri, Jun 6, 2008 at 5:34 PM, Paul Davis [EMAIL PROTECTED] wrote:
Moreover, I think its worth noting (again) that while Clutter and the
sketch of scene graph central to GTK are both very cool (with Clutter
being here and now, and the scene graph stuff merely imagined), canvas
widgets do
Hi,
On Mon, Jun 9, 2008 at 3:52 AM, Murray Cumming [EMAIL PROTECTED] wrote:
I really like the obvious sanity of your gtk-with-scene-graph idea, but
I do wonder when it's likely to happen.
Don't get me wrong, I don't *expect* it to happen - I mean, it's
completely feasible if the right person
Hi,
On Mon, Jun 9, 2008 at 10:37 AM, Murray Cumming [EMAIL PROTECTED] wrote:
If you (and your team) are not working on it then we know that nobody is
working on it, I guess. Thanks, that's actually useful information.
Definitely not working on it.
Then there's also no need for
Hi,
2008/6/25 [EMAIL PROTECTED]:
1）I use glib's main event loop, but why glib's main event loop don't support
epoll/kqueue?
The poll/select func's efficiency is very poor.
The libevent(http://monkey.org/~provos/libevent/) use epoll/kqueue. Why glib
not?
Hi,
This is in the archives a bunch of times, for example the first google
hit I got was
http://mail.gnome.org/archives/gtk-devel-list/2001-May/msg00485.html
Whether you agree or not, the GLib types don't use const in their API,
so if you try to use const yourself on these types you're just
Hi,
On Thu, Jul 3, 2008 at 9:49 AM, Alberto Mardegan
[EMAIL PROTECTED] wrote:
If I proposed a patch which adds some const here and there, would that be
discarded a priori, or would it undergo a serious consideration?
I'm not a GTK maintainer, but one problem with this is backward
Hi,
On Wed, Jul 16, 2008 at 6:16 AM, Gwenael Casaccio [EMAIL PROTECTED] wrote:
In fact I use this function in a thread and the squeak virtual machine also
use X events
for the morphs (an old user interface). Here is the problem after some
events everything
is frozen the morphs and the gtk
Hi,
Here are some alternate ideas, just brainstorming:
1) have an iterator concept in gobject-introspection and map from
GList etc. in g-i. So g-i would allow you to invoke a method that
returns a list, and get an iterator back.
If I were doing this in gobject-introspection I'd tend to make the
Hi,
I often install most stuff from rpms instead of jhbuild, then jhbuild
buildone foo bar where foo and bar are things I am actually working
on or actually need bleeding-edge versions of. Building *everything*
with jhbuild from the ground up is just kind of annoying.
Requires some knowledge of
Hi,
On Thu, Jul 31, 2008 at 9:30 AM, Paul Davis [EMAIL PROTECTED] wrote:
i think someone commented just the other day that as of now, MS
compilers do not support stdint.h which is also a C99 feature. so its
not entirely clear that we will *know* we can rely on any particular C99
feature.
Hi,
2008/8/6 Mathias Hasselmann [EMAIL PROTECTED]:
The following mail is about using the chance of breaking API with
glib-3.0 for improving GArray and GList.
I thought 3.0 had no API breaks in it?
Havoc
___
gtk-devel-list mailing list
I'd argue mandatory init functions are more or less always wrong, they
all train-wreck in a similar way ... unfortunately every G-inspired
library seems to gratuitously have them.
If the init function has no args, then it should be possible for the
library to just deal with it and call it
Hi,
On Fri, Aug 15, 2008 at 5:55 PM, Brian J. Tarricone [EMAIL PROTECTED] wrote:
This breaks for libraries that require locking in threaded programs but
(obviously) not in non-threaded programs. You can get into a situation
where you call a lock() without threads initialised, then something
Hi,
On Fri, Aug 15, 2008 at 7:32 AM, Halton Huo [EMAIL PROTECTED] wrote:
I want to check whether action is GDK_ACTION_MOVE during drag-begin
phase, if yes, end this DnD. Unfortunately, I found that context-action
is always 0 during drag-begin even SHIFT is hold. While it will be 4
1 - 100 of 1140 matches
Mail list logo
