On 26 Jun 2010, at 19:17, John Coppens wrote:
Did you read this article? It seems to sum up the issue quite nicely:
http://lwn.net/Articles/188693/
The discussions are interesting too.
Thanks John. That article is definitely an interesting read and I'm glad you
recommended it. I
I very much doubt if anybody who actually is doing the work, i.e.
maintaining the gtk+ stack, has any interest at all in switching to
CMake. So this discussion is mostly pointless. (And anyway, this
discussion is on the wrong mailing list; gtk-devel-list would have
been the relevant one.)
Yes, I can quite understand why a potential move to cmake might not be high on
the priority list! Out of curiosity though... what do you use to produce the
vcproj files for glib and gtk+? Is it a utility or a script of some sort?
I do think it's a shame that Pango, Cairo and ATK haven't
From my own experience trying to have Libgda use CMake to compile,
CMake still lacks/badly supports some features which are available
using the autotools, such as:
* convenience libraries
* pkg-config support
For Libgda, this means I would have to reorganize much of my code,
which is a very
Am Fri, 25 Jun 2010 14:12:00 -0400
schrieb Colin Walters walt...@verbum.org:
On Fri, Jun 25, 2010 at 12:50 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
Sure, we could continue to shoehorn features in to 2.x and it will
increasingly get harder, and the bugs will increasingly get
Hello GLib devs,
I upgraded to latest glib, and I discover that GCompletion is now
deprecated. Empathy was using it to complete the nickname when hitting
TAB in chatrooms.
I see nothing to replace that API... am I supposed to copy/paste its
code inside Empathy?!?
Is there a good reason to
On Mon, 2010-06-28 at 15:26 +0200, Xavier Claessens wrote:
1) I can think a bazillion of UIs that do/should have completion.
the fact that nobody implemented them using GCompletion should give a
hint that: a) this is not a shared opinion and b) it probably wasn't
possible with GCompletion.
On Mon, 2010-06-28 at 14:49 +0100, Emmanuele Bassi wrote:
On Mon, 2010-06-28 at 15:26 +0200, Xavier Claessens wrote:
1) I can think a bazillion of UIs that do/should have completion.
the fact that nobody implemented them using GCompletion should give a
hint that: a) this is not a shared
On Mon, 28 Jun 2010 14:49:48 +0100
Emmanuele Bassi eba...@gmail.com wrote:
the fact that nobody implemented them using GCompletion should give a
hint that: a) this is not a shared opinion and b) it probably wasn't
possible with GCompletion.
That's not quite true, several applications use
On Mon, 2010-06-28 at 17:58 +0200, Salvatore De Paolis wrote:
On Mon, 28 Jun 2010 14:49:48 +0100
Emmanuele Bassi eba...@gmail.com wrote:
the fact that nobody implemented them using GCompletion should give a
hint that: a) this is not a shared opinion and b) it probably wasn't
possible
Am Mon, 28 Jun 2010 17:28:47 +0100
schrieb Emmanuele Bassi eba...@gmail.com:
On Mon, 2010-06-28 at 17:58 +0200, Salvatore De Paolis wrote:
On Mon, 28 Jun 2010 14:49:48 +0100
Emmanuele Bassi eba...@gmail.com wrote:
The issue isn't really about deprecating some code but instead not
On Mon, 2010-06-28 at 16:24 +0100, Martyn Russell wrote:
On Mon, 2010-06-28 at 14:49 +0100, Emmanuele Bassi wrote:
On Mon, 2010-06-28 at 15:26 +0200, Xavier Claessens wrote:
1) I can think a bazillion of UIs that do/should have completion.
the fact that nobody implemented them using
On Mon, 28 Jun 2010 15:26:47 +0200 Xavier Claessens wrote:
1) I can think a bazillion of UIs that do/should have completion.
Personally, I'd find GNOME-Do style completion totally awesome [1]. I
don't know if it's feasible to have something like that at a low level
in the stack, but the thought
On Mon, 2010-06-28 at 18:43 +0200, Christian Dywan wrote:
and, again, there is this false impression that deprecation is akin to
removal.
[...]
you can either #undef G_DISABLE_DEPRECATED for the files that use
these particular data structures, or copy gcompletion.[ch] in your
From and outsiders perspective
I too would absolutely LOVE this feature. Not just in GTK, but in OS X as well.
the OS X NSSearchField however (to my shock!) does not implement this
functionality either.
Apple has exposed this in the NSTextView (with spell check et al...) which is
akin to
Le 28/06/10 15:48, Bastien Nocera a écrit :
On Mon, 2010-06-28 at 15:26 +0200, Xavier Claessens wrote:
2) If all unmaintained code should be deprecated with no replacement,
what do we have left in glib/gtk? Probably not that much...
That sort of comments has no place here, and hardly helps
Le 28/06/10 15:49, Emmanuele Bassi a écrit :
On Mon, 2010-06-28 at 15:26 +0200, Xavier Claessens wrote:
1) I can think a bazillion of UIs that do/should have completion.
the fact that nobody implemented them using GCompletion should give a
hint that: a) this is not a shared opinion and b)
Le lundi 28 juin 2010 à 21:25 +0200, Xavier Claessens a écrit :
How could I come up with a better API if:
1) You don't tell what's wrong with current?
2) You keep repeating completion is not used by app, and barely used
code shouldn't be included in GLib? If that was true, even a better API
Le 28/06/10 18:46, Emmanuele Bassi a écrit :
a 2 minutes API review of GCompletion:
• g_completion_new(): not bindable; requires at least a new version
with a GDestroyNotify function for language bindings.
• the GCompletionFunc doesn't have a data parameter, making it
unbindable.
•
Hi.
I was reading the documentation of the GtkFontSelectionDialog and see
that it implements own methods to set and get the GtkFontSelection
properties. Why it is at this way? Isn't more correct and standard use
methods of GtkFontSelection just casting with GTK_FONT_SELECTION() the
font
010/6/29 Tadej Borovšak tadeb...@gmail.com:
There has been some work going on to bring font chooser widgets into
21st century, but nothing has come out of that yet (and I lost the
link to the page with some mockups).
This is the link: [1]
[1]
21 matches
Mail list logo
