Havoc Pennington wrote:
...
(if one is compelled to hack on boxes, my suggestion is to leave
GtkBox alone but add a new nicer container like HippoCanvasBox, its
features include:
* have left/right/center/fill x/y alignment
* you only need 1 "expand" boolean, alignment replaces "fill" with
someth
Even though the update to each line may be trivial, I would say that
if a deprecation touches a lot of lines in every app, it really has to
meet a high bar for worthwhile-ness, or we're just wasting a whole lot
of people's time.
Deprecation should not be about aesthetics, or second-guessing the
ki
On Fri, 2008-09-26 at 17:24 -0400, Allin Cottrell wrote:
> On Fri, 26 Sep 2008, Michael Natterer wrote:
>
> > On Fri, 2008-09-26 at 14:29 -0400, Allin Cottrell wrote:
> > > On Fri, 26 Sep 2008, Tor Lillqvist wrote:
> > >
> > > > > Any ideas on what's going on?
> > > >
> > > > http://bugzilla.gno
On Fri, 26 Sep 2008, Michael Natterer wrote:
> On Fri, 2008-09-26 at 14:29 -0400, Allin Cottrell wrote:
> > On Fri, 26 Sep 2008, Tor Lillqvist wrote:
> >
> > > > Any ideas on what's going on?
> > >
> > > http://bugzilla.gnome.org/show_bug.cgi?id=553135#c8 ?
> >
> > On closer inspection, I see t
On Fri, 2008-09-26 at 14:29 -0400, Allin Cottrell wrote:
> On Fri, 26 Sep 2008, Tor Lillqvist wrote:
>
> > > Any ideas on what's going on?
> >
> > http://bugzilla.gnome.org/show_bug.cgi?id=553135#c8 ?
>
> On closer inspection, I see that Michael Natterer's patch is
> already in gtk 2.14.3, and
On Fri, 26 Sep 2008, Tor Lillqvist wrote:
> > Any ideas on what's going on?
>
> http://bugzilla.gnome.org/show_bug.cgi?id=553135#c8 ?
On closer inspection, I see that Michael Natterer's patch is
already in gtk 2.14.3, and does not solve the problem I mentioned,
namely
GLib-GObject-CRITICAL **
Tim Janik schrieb:
> On Fri, 26 Sep 2008, Andrew Cowie wrote:
>
>> On Thu, 2008-09-25 at 13:06 -0400, Matthias Clasen wrote:
>>> The important part of the assert semantics are: if the assertion
>>> fails, the program aborts.
>>>
>>> If you are using assertions in a way that make it important where
On Fri, 26 Sep 2008, Peter Clifton wrote:
On Fri, 2008-09-26 at 12:57 +0200, Tim Janik wrote:
As i said above, there is no need at all for micro speed optimization
in these code paths. And using GTK_IS_HBOX() adds a type registration
dependency, which prevents things like moving GtkHBox/GtkVB
On Fri, 2008-09-26 at 12:57 +0200, Tim Janik wrote:
> On Fri, 26 Sep 2008, Peter Clifton wrote:
>
> > On Fri, 2008-09-26 at 11:44 +0200, Tim Janik wrote:
>
> >> - Change additional defaults as needed, e.g.:
> >>gtk_box_init (GtkBox *self)
> >>{
> >> gboolean compat_type =
> >>
On Fri, 26 Sep 2008, Peter Clifton wrote:
On Fri, 2008-09-26 at 11:44 +0200, Tim Janik wrote:
- Change additional defaults as needed, e.g.:
gtk_box_init (GtkBox *self)
{
gboolean compat_type =
g_type_is_named (G_OBJECT_TYPE (box), "GtkHBox") ||
g_type_is_named (G_OBJE
On Fri, 2008-09-26 at 11:44 +0200, Tim Janik wrote:
> On Thu, 25 Sep 2008, Mike Kestner wrote:
[snip]
> - Change the packing defaults for gtk_box_pack_start_defaults and friends
>unless old compat types are detected, i.e.:
> void
> gtk_box_pack_start_defaults (GtkBox *box, GtkWidget
On Thu, 25 Sep 2008, Mike Kestner wrote:
The types would essentially be
boilerplate, so it's not like they are going to be a maintenance issue.
If the motivation for removing the types is that, "things aren't as
beautiful as they could be" then that argument doesn't really outweigh
the pain of
On Fri, 26 Sep 2008, Andrew Cowie wrote:
On Thu, 2008-09-25 at 13:06 -0400, Matthias Clasen wrote:
The important part of the assert semantics are: if the assertion
fails, the program aborts.
If you are using assertions in a way that make it important where or
how the message is reported
In t
Am Thu, 25 Sep 2008 22:20:17 +0200
schrieb Michael Natterer <[EMAIL PROTECTED]>:
> On Thu, 2008-09-25 at 15:07 -0400, Morten Welinder wrote:
> > If all you really want is to change the defaults for box packing,
> > then why isn't that all you are proposing? It would be a simple
> > 1-line patch t
14 matches
Mail list logo
