I'm not a Gtk+ developer, but I think one of the criteria for being
considered is: doesn't introduce a new library dependency, or maybe it
can, if it really makes sense. Gtk+ depending on a spell checking
library hardly makes sense, however.
On Fri, 26 Aug 2005, Mike Hearn wrote:
Yes, it's yet
Il giorno dom, 21/08/2005 alle 00.50 -0400, Jonathan Blandford ha
scritto:
Now that GTK+-2.8.0 is out, the GTK+ team would like to announce Project
Ridley.
GOALS:
The primary goal of Project Ridley is to cut down on the number of
problem libraries that are part of the GNOME platform. We
On 8/27/05, Chipzz [EMAIL PROTECTED] wrote:
I'm not a Gtk+ developer, but I think one of the criteria for being
considered is: doesn't introduce a new library dependency, or maybe it
can, if it really makes sense. Gtk+ depending on a spell checking
library hardly makes sense, however.
I would
On 1/19/06, Matthias Clasen [EMAIL PROTECTED] wrote:
On 8/27/05, Chipzz [EMAIL PROTECTED] wrote:
I'm not a Gtk+ developer, but I think one of the criteria for being
considered is: doesn't introduce a new library dependency, or maybe it
can, if it really makes sense. Gtk+ depending on a
Hi folks,
GtkSpell lacks some features and I've been aware of the lack for years
-- even since the GTK 2 days. I haven't had the time to work on
GtkSpell and so finally, rather than stifling it by hanging on too
tightly, I found a new maintainer, who has done a great job of making
incremental
* Matthias Clasen [EMAIL PROTECTED] schrieb:
snip
Maybe just moving deprecated widgets to a separate library, like
libgtk2.0-compat.la, would be a better solution? We'd get well
maintained applications to avoid linking to this library, while at the
same time keeping it around for
* Banginwar, Rajesh [EMAIL PROTECTED] schrieb:
I am really glad to see the intention of keeping the ABI same even with
3.0 release.
I'm not.
Binary compatibiliy prevents us from changes in the library structures,
ie. which widgets belong into which lib.
Normally a new major release
* Rob Adams [EMAIL PROTECTED] schrieb:
snip
I don't really see much reason ever to break ABI for the forseeable
future. There's essentially nothing stopping us from simply leaving
deprecated functions in there indefinitely, other than a fairly minor
Very *bad* idea.
This breaks many
* Philippe De Swert [EMAIL PROTECTED] schrieb:
snip
This is an issue for embedded systems using gtk (like for example GPE).
Maybe a --disable-deprecated flag could do the trick?
Nice idea.
BUT: it as to be absolutely clear what exactly this means. Just
calling it obsolete is not enough.
So
* Florian Boor [EMAIL PROTECTED] schrieb:
snip
I'm working on the GPE project (http://gpe.handhelds.org, a software framework
for mobile devices like PDAs) which is using GTK.
Moving more features into GTK will make application development easier for us
in
a software environment of limited
On Fri, 2005-08-26 at 07:53 +0200, Murray Cumming wrote:
But being as part of the official library pack makes them be official,
and avoid people using different solutions for the same problem.
That's the idea of being in the GNOME Development Platform. I don't see
how putting the whole
On Wed, Sep 14, 2005 at 12:02:46PM -0400, JP Rosevear wrote:
Its a fine line, but I can't see how network connections don't fit in as
an acceptable low level operation when we have the following in glib:
1) lexical scanner
2) xml subset parser
3) IO Channels
Even if not in glib we
JP Rosevear writes:
Even if not in glib we should be creating an official solution that
hooks nicely in to the mainloop rather than neon/curl/soup.
There is also linc2 (in ORBit2) and gnet.
--tml
___
gtk-devel-list mailing list
On Mon, 2005-08-22 at 12:23 -0400, Jonathan Blandford wrote:
Rodrigo Moya [EMAIL PROTECTED] writes:
what about libsoup/network library? Wouldn't it also make sense to move
it to a libgnet in glib?
I don't know of any plans for this. I don't think networking makes a
whole lot of sense
I am entering into the discussion thread without reading any other email
than this one, but... as for XML we should not create the wheel again.
That leads to libxml2 or expat. In my case, I prefer libxml2. Being part
of w3c development maybe helps me choosing it. Well, having work with
expat
Hello all,
I don't really see much reason ever to break ABI for the forseeable
future. There's essentially nothing stopping us from simply leaving
deprecated functions in there indefinitely, other than a fairly minor
memory footprint increase which will never be paged in anyway.
This is an
Jonathan Blandford wrote:
The primary goal of Project Ridley is to cut down on the number of
problem libraries that are part of the GNOME platform. We propose to do
this by moving functionality into GTK+, wherever it makes sense.
What about EggRegex?
--
Marco Barisione
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 the same bugs in multiple places. I think its odd as a
JP Rosevear [EMAIL PROTECTED] writes:
I'm also for this, right now we are using multiple networking libraries
and we fix the same bugs in multiple places. I think its odd as a
platform we have no official way to great an http/network connection
(yes libsoup is in the platform for evolution,
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
What about XML support ? Now we have:
- basic XML subset in GLib
- libxml2
- expat
Moving all XML features to GLib doesn't look good, neither looks good
having three separate libraries with the same functionality.
Olexiy
___
gtk-devel-list
Hello all,
Jonathan Blandford wrote:
The primary goal of Project Ridley is to cut down on the number of
problem libraries that are part of the GNOME platform. We propose to do
this by moving functionality into GTK+, wherever it makes sense. These
libraries are generally small,
Am Montag, den 22.08.2005, 13:37 +0200 schrieb Rodrigo Moya:
there is no reason to force us to do GNOME 3.0, but since many GNOME
libraries will be disappearing with Ridley, we might want to call it
3.0, so that we don't have to maintain the old libraries around.
Also, as we deprecate most
Gustavo J. A. M. Carneiro wrote:
On Mon, 2005-08-22 at 16:10 +0200, Christian Neumair wrote:
Am Montag, den 22.08.2005, 13:37 +0200 schrieb Rodrigo Moya:
there is no reason to force us to do GNOME 3.0, but since many GNOME
libraries will be disappearing with Ridley, we might want to call it
On Mon, 2005-08-22 at 17:43 +0300, Olexiy Avramchenko wrote:
Maybe just moving deprecated widgets to a separate library, like
libgtk2.0-compat.la, would be a better solution? We'd get well
maintained applications to avoid linking to this library, while at the
same time keeping it
On Sun, 2005-08-21 at 12:31 -0400, Havoc Pennington wrote:
Another thing I would be interested as an extension to the above is
specialisation (or rather, restriction) of containers to particular
GTypes. If for example, we had a call such as
GType
g_type_specialise(GType type, ...)
Gustavo J. A. M. Carneiro wrote:
On Mon, 2005-08-22 at 16:10 +0200, Christian Neumair wrote:
Am Montag, den 22.08.2005, 13:37 +0200 schrieb Rodrigo Moya:
there is no reason to force us to do GNOME 3.0, but since many GNOME
libraries will be disappearing with Ridley, we might want to
Jeff Waugh [EMAIL PROTECTED] writes:
Probably worth putting some of the ABI/API answers on the ProjectRidley
page, just so it's absolutely clear. I would do it, but I don't really want
to miscommunicate the goals. :-)
Good point. Done.
Thanks,
-Jonathan
Seems great goals !
Have some questions:
1) Is GTK+-3.0 scheduled ? Or is it a long long time work which will be
released when it's ready. Will be a GTK+-2.10 version ? Or 3.0 is the
next version ?
2) If GTK+-3.0 is released, will it lead automatically to gnome-3.0 ? So
is it the right moment
Hi Xavier,
I can't answer all the questions. Just one, in fact :-)
Le dimanche 21 août 2005 à 14:00 +0200, Claessens Xavier a écrit :
2) If GTK+-3.0 is released, will it lead automatically to gnome-3.0 ? So
is it the right moment (not now, but when GTK3 will be released) to do
API/ABI
On Sun, 2005-08-21 at 14:00 +0200, Claessens Xavier wrote:
Seems great goals !
Have some questions:
1) Is GTK+-3.0 scheduled ? Or is it a long long time work which will be
released when it's ready. Will be a GTK+-2.10 version ? Or 3.0 is the
next version ?
2) If GTK+-3.0 is released, will
Oki thanks, its more clear for me now :-)
signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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
33 matches
Mail list logo
