On 08/19/2014 03:24 PM, Alexander Larsson wrote:
> On mån, 2014-08-18 at 18:09 +0200, Sébastien Wilmet wrote:
>> On Mon, 2014-08-18 at 10:01 -0400, Jasper St. Pierre wrote:
>>> Because every time we try to clean up GtkTreeView, we break some random
>>> application. It's a widget that has twenty th
On mån, 2014-08-18 at 18:09 +0200, Sébastien Wilmet wrote:
> On Mon, 2014-08-18 at 10:01 -0400, Jasper St. Pierre wrote:
> > Because every time we try to clean up GtkTreeView, we break some random
> > application. It's a widget that has twenty three gazillion use cases, and
> > so we have to keep i
On Mon, 2014-08-18 at 10:01 -0400, Jasper St. Pierre wrote:
> Because every time we try to clean up GtkTreeView, we break some random
> application. It's a widget that has twenty three gazillion use cases, and
> so we have to keep it a mess, because removing the mess means removing one
> use case,
On Mon, Aug 18, 2014 at 9:50 AM, Sébastien Wilmet wrote:
> On Mon, 2014-08-18 at 10:00 +0100, Emmanuele Bassi wrote:
> > On 16 August 2014 16:23, Sébastien Wilmet wrote:
> >
> > > With GskLayerContent, will it be possible to unify cell renderer and
> > > widget drawing models? To simplify signif
On Mon, 2014-08-18 at 10:00 +0100, Emmanuele Bassi wrote:
> On 16 August 2014 16:23, Sébastien Wilmet wrote:
>
> > With GskLayerContent, will it be possible to unify cell renderer and
> > widget drawing models? To simplify significantly the GtkTreeView
> > implementation, for example, and be able
On Wed, May 12, 2010 at 4:24 PM, Shaun McCance wrote:
> On Wed, 2010-05-12 at 09:29 +0200, Cody Russell wrote:
> >
> > 2/ Corner resize grips. I want to add support for this directly to
> > GtkWindow anyway.
> >
> Is anybody actively working on this? Are there ways of doing this that
> don't a)
On Wed, 2010-05-12 at 09:29 +0200, Cody Russell wrote:
>
> 2/ Corner resize grips. I want to add support for this directly to
> GtkWindow anyway.
>
Is anybody actively working on this? Are there ways of doing this that
don't a) require vertical padding a'la GtkStatusBar, or b) unilaterally
cover
2010/5/12 Cody Russell :
> I think it would be kind of nice to deprecate GtkStatusbar. It's one of the
> more useless widgets we have, imo. It basically serves two purposes:
> 1/ Pushing and popping text messages. This is a really terrible way to
> communicate information to users, imo.
> 2/ Cor
On Mi, 12.05.2010 12:49, Cody Russell wrote:
>On Wed, May 12, 2010 at 11:44 AM, Christian Dywan wrote:
>
>> I am curious, as GtkStatusbar is used in every second application,
>> about your suggestions on how to replace it in the typical use cases.
>>
>
>I don't actually have thoughts on this yet..
On Wed, May 12, 2010 at 11:44 AM, Christian Dywan wrote:
> I am curious, as GtkStatusbar is used in every second application,
> about your suggestions on how to replace it in the typical use cases.
>
I don't actually have thoughts on this yet.. most of the apps I can think of
that use statusbars
On 05/12/2010 09:29 AM, Cody Russell wrote:
I think it would be kind of nice to deprecate GtkStatusbar. It's one of
the more useless widgets we have, imo. It basically serves two purposes:
1/ Pushing and popping text messages. This is a really terrible way to
communicate information to users,
Am Wed, 12 May 2010 09:29:29 +0200
schrieb Cody Russell :
> I think it would be kind of nice to deprecate GtkStatusbar. It's one
> of the more useless widgets we have, imo. It basically serves two
> purposes:
>
> 1/ Pushing and popping text messages. This is a really terrible way
> to communic
On Wed, May 12, 2010 at 09:29:29AM +0200, Cody Russell wrote:
> I think it would be kind of nice to deprecate GtkStatusbar. It's one of the
> more useless widgets we have, imo. It basically serves two purposes:
>
> 1/ Pushing and popping text messages. This is a really terrible way to
> communi
re easily.
> Take a look to this query in bugzilla: [1] ( They are the bugs with
> the 'deprecations' tag ).
>
> Is it necessary to add some more?
>
> Regards,
>
> [1]
> https://bugzilla.gnome.org/buglist.cgi?status_whiteboard_type=casesubstring;status_whi
Hello,
After the lastest GTK+ meeting I've assembled a list of "deprecatable"
classes so you can review them more easily.
Take a look to this query in bugzilla: [1] ( They are the bugs with
the 'deprecations' tag ).
Is it necessary to add some more?
Regards,
[1]
h
Cody Russell schrieb:
> Hi all,
>
> gtk+ currently does not build with GSEAL enabled, and I want to remedy
> this so we can make progress on 3.0. I'm planning to post a large
> series of patches unless someone has a suggestion for how better to do
> proceed with this.
>
> Right now I was thinkin
Hi Cody,
On Sun, May 10, 2009 at 12:19 AM, Cody Russell wrote:
> gtk+ currently does not build with GSEAL enabled, and I want to remedy
> this so we can make progress on 3.0. I'm planning to post a large
> series of patches unless someone has a suggestion for how better to do
> proceed with this
Hi all,
gtk+ currently does not build with GSEAL enabled, and I want to remedy
this so we can make progress on 3.0. I'm planning to post a large
series of patches unless someone has a suggestion for how better to do
proceed with this.
Right now I was thinking to break this up by widget in order
On Thu, 27 Apr 2006 16:41:29 -0400, Behdad Esfahbod wrote:
[...]
> What we are doing in Pango and Gtk+ right now is to enable
> G_DISABLE_DEPRECATED if and only if the major.minor version of
> the available glib version is the same as the one we require.
>
> I also like if there was a way to detec
> I also like if there was a way to detect when the required
> version of a module (glib and Gtk+ mainly) should be increased in
> an application. But that requires marking all the API with
> macros and version number that I know is not going to happen...
The "poor man's version" of that would b
... -Wcast-align ...
That one will give you tons of warnings on some platforms with
different alignments than i386.
We do lots of GTK_NOTEBOOK(widget) type casts that are perfectly
fine -- because there is an implied type check -- but can very
well increase alignment. (GTK_NOTEBOOK is a sample.
On Thu, 27 Apr 2006, Owen Taylor wrote:
> On Thu, 2006-04-27 at 01:22 +0300, Mart Raudsepp wrote:
> > On Wed, 2006-04-26 at 21:23 +0100, Ross Burton wrote:
> > > On Wed, 2006-04-26 at 15:18 -0400, David Hampton wrote:
> > > > > Would it make sense to mark all of the deprecated API in GLib and GTK+
On Thu, 27 Apr 2006 10:30:12 -0400
Owen Taylor <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-04-26 at 09:22 +0100, Ross Burton wrote:
> > Hi,
> >
> > Would it make sense to mark all of the deprecated API in GLib and
> > GTK+ with G_GNUC_DEPRECATED, so that people who are not using the
> > DISABLE_DEP
onfigure switch or not. If he has an enforced minimum version
of gtk, and he has ensured it doesn't utilize any functions deprecated
in that minimum supported version, it doesn't need a configure switch.
A --enable-deprecation-warnings switch could then be used to define the
ver
On Thu, 2006-04-27 at 01:22 +0300, Mart Raudsepp wrote:
> On Wed, 2006-04-26 at 21:23 +0100, Ross Burton wrote:
> > On Wed, 2006-04-26 at 15:18 -0400, David Hampton wrote:
> > > > Would it make sense to mark all of the deprecated API in GLib and GTK+
> > > > with G_GNUC_DEPRECATED, so that people w
On Wed, 2006-04-26 at 09:22 +0100, Ross Burton wrote:
> Hi,
>
> Would it make sense to mark all of the deprecated API in GLib and GTK+
> with G_GNUC_DEPRECATED, so that people who are not using the
> DISABLE_DEPRECATED macros still get warned that they are using
> deprecated functions? At the mom
On Wed, 26 Apr 2006, David Hampton wrote:
> Here's my problem. GnuCash currently compiles cleanly using gcc-4.1 and
> -Werror on both i386 and amd64 systems, so Ross's issue of aliasing
> warnings has already been handled. If you add the G_GNUC_DEPRECATED tag
> to these functions as proposed, gn
On 4/26/06, David Hampton <[EMAIL PROTECTED]> wrote:
> Here's my problem. GnuCash currently compiles cleanly using gcc-4.1 and
> -Werror on both i386 and amd64 systems, so Ross's issue of aliasing
> warnings has already been handled. If you add the G_GNUC_DEPRECATED tag
> to these functions as pr
On Wed, 2006-04-26 at 18:19 -0400, Behdad Esfahbod wrote:
> On Wed, 26 Apr 2006, David Hampton wrote:
>
> > On Wed, 2006-04-26 at 09:22 +0100, Ross Burton wrote:
> > > Hi,
> > >
> > > Would it make sense to mark all of the deprecated API in GLib and GTK+
> > > with G_GNUC_DEPRECATED, so that peopl
On Wed, 2006-04-26 at 21:23 +0100, Ross Burton wrote:
> On Wed, 2006-04-26 at 15:18 -0400, David Hampton wrote:
> > > Would it make sense to mark all of the deprecated API in GLib and GTK+
> > > with G_GNUC_DEPRECATED, so that people who are not using the
> > > DISABLE_DEPRECATED macros still get w
On Wed, 26 Apr 2006, David Hampton wrote:
> On Wed, 2006-04-26 at 09:22 +0100, Ross Burton wrote:
> > Hi,
> >
> > Would it make sense to mark all of the deprecated API in GLib and GTK+
> > with G_GNUC_DEPRECATED, so that people who are not using the
> > DISABLE_DEPRECATED macros still get warned t
On Wed, 2006-04-26 at 15:18 -0400, David Hampton wrote:
> > Would it make sense to mark all of the deprecated API in GLib and GTK+
> > with G_GNUC_DEPRECATED, so that people who are not using the
> > DISABLE_DEPRECATED macros still get warned that they are using
> > deprecated functions? At the mo
On Wed, 2006-04-26 at 09:22 +0100, Ross Burton wrote:
> Hi,
>
> Would it make sense to mark all of the deprecated API in GLib and GTK+
> with G_GNUC_DEPRECATED, so that people who are not using the
> DISABLE_DEPRECATED macros still get warned that they are using
> deprecated functions? At the mom
Hi,
Would it make sense to mark all of the deprecated API in GLib and GTK+
with G_GNUC_DEPRECATED, so that people who are not using the
DISABLE_DEPRECATED macros still get warned that they are using
deprecated functions? At the moment it's very black and white, and I
think deprecation functions n
34 matches
Mail list logo
