On Wed, 2008-06-04 at 07:35 -0400, Paul Davis wrote:
> > Basically, something like this:
> >
> > http://doc.trolltech.com/4.4/properties.html
> >
> > When reading this and other Qt documents, one realizes that a large
> > technological gap separates GLib/GTK+ and Qt.
>
> I don't want to st
Morten Welinder wrote:
>> (things that developers of client code
>> have been wanting for years, such as the removal of deprecated code or
>> the mangling of fields),
>
> As an application developer I can assure you that we as a group are
> not actively looking for ways to break our applications.
On Wed, Jun 04, 2008 at 11:03:09PM +0200, Jean-Yves Lefort wrote:
> is worth it or not. If the GLib/GTK+ maintainers believe that selling
> an ABI breakage and a major release with just "we've mangled fields;
> we've removed deprecated cruft" is ambitious enough, then who am I
> oppose.
Please cut
Hi,
On Wed, Jun 4, 2008 at 2:37 PM, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> Regardless, gtk+ 3.0 is a long-term project, probably with a first
> release sometime in 2010 or so. Embedded developers wont want to pick
> it up before 2012.
AIUI this is NOT the case. My understanding of the Imend
On Wed, 2008-06-04 at 19:59 +0200, Jean-Yves Lefort wrote:
> > I fail to see how any of this discussion should change your
> perception
> > of GObject. This is a discussion about GTK's usage of GObject, but
> your
> > own objects can continue to use it in whatever way makes the most
> sense
> > to
On Wed, 04 Jun 2008 12:50:48 -0700
"Brian J. Tarricone" <[EMAIL PROTECTED]> wrote:
> Jean-Yves Lefort wrote:
> > On Wed, 04 Jun 2008 15:18:45 -0400
> > Paul Davis <[EMAIL PROTECTED]> wrote:
> >
> >> On Wed, 2008-06-04 at 20:57 +0200, Jean-Yves Lefort wrote:
> >>
> >>> Rather than calling my sugge
> Hi all,
>
> As most of you already know, we have presented our vision of a GTK+ 3.0 at
> the hackfest in Berlin last March. In the weeks that followed we have
> received and seen a lot of positive reactions and we feel that the
> community mainly agrees with our plans and goals. We won't repea
Hi,
This is not relevant to getting GTK 3.0 off the ground. Please start a
new thread if you want to discuss property systems.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Jean-Yves Lefort wrote:
> On Wed, 04 Jun 2008 15:18:45 -0400
> Paul Davis <[EMAIL PROTECTED]> wrote:
>
>> On Wed, 2008-06-04 at 20:57 +0200, Jean-Yves Lefort wrote:
>>
>>> Rather than calling my suggestions silly, why don't you actually try
>>> to explain how the non-preprocessed, dynamic-only GLi
On Wed, 04 Jun 2008 15:18:45 -0400
Paul Davis <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-06-04 at 20:57 +0200, Jean-Yves Lefort wrote:
>
> > Rather than calling my suggestions silly, why don't you actually try
> > to explain how the non-preprocessed, dynamic-only GLib property design
> > is superi
On Wed, 2008-06-04 at 20:57 +0200, Jean-Yves Lefort wrote:
> Rather than calling my suggestions silly, why don't you actually try
> to explain how the non-preprocessed, dynamic-only GLib property design
> is superior to the Qt design (or at least not inferior), or describe
> these specific reason
On Wed, 2008-06-04 at 21:50 +0300, Stefan Kost wrote:
> Felipe Contreras schrieb:
> > So how should people create extra functionality? For example, I
> > extended GHashTable creating a g_hash_table_peek_first function, for
> > which I needed the private fields.
No you don't.
gboolean
true_predic
On Wed, 04 Jun 2008 14:35:47 -0400
Paul Davis <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-06-04 at 20:30 +0200, Jean-Yves Lefort wrote:
> > On Wed, 04 Jun 2008 18:51:18 +0100
> > Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, 2008-06-04 at 19:44 +0200, Jean-Yves Lefort wrote:
> > >
hi,
Felipe Contreras schrieb:
> On Tue, Jun 3, 2008 at 3:23 PM, Tim Janik <[EMAIL PROTECTED]> wrote:
>> On Tue, 3 Jun 2008, Alberto Mardegan wrote:
>>
>>> ext Kristian Rietveld wrote:
10. Remove all structure fields from the public API. There are two ways
this can be done:
a) Mov
On Wed, 2008-06-04 at 19:59 +0200, Jean-Yves Lefort wrote:
>
> Tim Janik argued that the bad performance of the property system is
> not an issue in GTK+. I pointed out that in my understanding, the
> GObject framework is supposed to be a client-agnostic object
> system. As such, its performance i
You are right. Do you know on which system configurations on which it
is hard to install a gcc version with c99 Support?
Does anyone know how widespread the lack of c99-able compilers are?
Regardless, gtk+ 3.0 is a long-term project, probably with a first
release sometime in 2010 or so. Embedde
On Wed, 2008-06-04 at 20:30 +0200, Jean-Yves Lefort wrote:
> On Wed, 04 Jun 2008 18:51:18 +0100
> Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2008-06-04 at 19:44 +0200, Jean-Yves Lefort wrote:
> >
> > > > I don't want to start a flame war over old hat, but statements like this
> >
On Wed, 04 Jun 2008 18:51:18 +0100
Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-06-04 at 19:44 +0200, Jean-Yves Lefort wrote:
>
> > > I don't want to start a flame war over old hat, but statements like this
> > > shouldn't go unchallenged. GLib/GTK+ chose a different technology as a
On Wed, 04 Jun 2008 12:39:33 -0500
Cody Russell <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-06-04 at 19:15 +0200, Jean-Yves Lefort wrote:
> > I thought that GObject was meant as a general-purpose object system
> > for C, rather than as a GTK+-specific utility library. I suppose I
> > misunderstood.
On Wed, 2008-06-04 at 19:44 +0200, Jean-Yves Lefort wrote:
> > I don't want to start a flame war over old hat, but statements like this
> > shouldn't go unchallenged. GLib/GTK+ chose a different technology as a
> > base than Qt did (C vs. C++, and no pre-processing source versus
> > preprocessing
On Wed, 04 Jun 2008 07:35:41 -0400
Paul Davis <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-06-04 at 07:40 +0200, Jean-Yves Lefort wrote:
>
> >
> > Basically, something like this:
> >
> > http://doc.trolltech.com/4.4/properties.html
> >
> > When reading this and other Qt documents, one realize
On Wed, 2008-06-04 at 19:15 +0200, Jean-Yves Lefort wrote:
> I thought that GObject was meant as a general-purpose object system
> for C, rather than as a GTK+-specific utility library. I suppose I
> misunderstood.
I fail to see how any of this discussion should change your perception
of GObject.
On Wed, 4 Jun 2008 10:56:56 +0200 (CEST)
Tim Janik <[EMAIL PROTECTED]> wrote:
> On Tue, 3 Jun 2008, Jean-Yves Lefort wrote:
>
> > On Tue, 3 Jun 2008 13:34:13 +0200
> > Kristian Rietveld <[EMAIL PROTECTED]> wrote:
> >
> >> 4. We will completely lose all means to simply access fields by just
> >> d
On Tue, Jun 3, 2008 at 7:34 AM, Kristian Rietveld <[EMAIL PROTECTED]> wrote:
>
> Our repository
> --
>
> We have a git repository at git.imendio.com:
>
> git://git.imendio.com/projects/gtk+.git
>
> In this repository, the master branch tracks upstream. The sealing happens
> in the GS
Hi,
4 jun 2008 kl. 15.11 skrev Morten Welinder:
>> (things that developers of client code
>> have been wanting for years, such as the removal of deprecated code
>> or
>> the mangling of fields),
>
> As an application developer I can assure you that we as a group are
> not actively looking for w
> (things that developers of client code
> have been wanting for years, such as the removal of deprecated code or
> the mangling of fields),
As an application developer I can assure you that we as a group are
not actively looking for ways to break our applications. If the urge
should arise then w
On Wed, 2008-06-04 at 07:40 +0200, Jean-Yves Lefort wrote:
>
> Basically, something like this:
>
> http://doc.trolltech.com/4.4/properties.html
>
> When reading this and other Qt documents, one realizes that a large
> technological gap separates GLib/GTK+ and Qt.
I don't want to start a
On Wed, Jun 4, 2008 at 1:38 PM, sparkymat <[EMAIL PROTECTED]> wrote:
>>> You're assuming GCC/Linux/x86 environments, there are other environments,
>>> such as embeded devices with optimized compilers for their architecture or
>>> non Linux operating systems for non x86 architectures where getting l
>> You're assuming GCC/Linux/x86 environments, there are other environments,
>> such as embeded devices with optimized compilers for their architecture or
>> non Linux operating systems for non x86 architectures where getting latest
>> GCC is not as easy.
>>
>> As Gtk is targetting to the mobile sp
On Tue, Jun 3, 2008 at 3:23 PM, Tim Janik <[EMAIL PROTECTED]> wrote:
> On Tue, 3 Jun 2008, Alberto Mardegan wrote:
>
>> ext Kristian Rietveld wrote:
>>> 10. Remove all structure fields from the public API. There are two ways
>>> this can be done:
>>> a) Move object structures to private headers.
2008/6/3 Alberto Ruiz <[EMAIL PROTECTED]>:
>
>
> 2008/6/3 BJörn Lindqvist <[EMAIL PROTECTED]>:
>>
>>
>> Here is an overview:
>> http://www.kuro5hin.org/story/2001/2/23/194544/139. Merely the
>> initialization inside the for loop feature is a huge improvement. But
>> I never understood why someone n
On Tue, 3 Jun 2008, Jean-Yves Lefort wrote:
> On Tue, 3 Jun 2008 13:34:13 +0200
> Kristian Rietveld <[EMAIL PROTECTED]> wrote:
>
>> 4. We will completely lose all means to simply access fields by just
>> dereferencing the structure. Instead, we will start to use GObject
>> properties to access th
32 matches
Mail list logo
