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 to
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, 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 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
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 =
g_type_is_named
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
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
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
something
On Thu, 2008-09-25 at 10:02 +0200, Mikael Hallendal wrote:
Hi,
Why not simply keep gtk_hbox_new and gtk_vbox_new?
I can see a number of reasons for doing so:
1) They are used all over the place
2) The cost of maintaining them are next to zero
3) They make sense on their own,
On Thu, 2008-09-25 at 10:02 +0200, Mikael Hallendal wrote:
Hi,
Why not simply keep gtk_hbox_new and gtk_vbox_new?
I can see a number of reasons for doing so:
1) They are used all over the place
2) The cost of maintaining them are next to zero
3) They make sense on their own,
On Thu, 2008-09-25 at 10:02 +0200, Mikael Hallendal wrote:
Hi,
Why not simply keep gtk_hbox_new and gtk_vbox_new?
I can see a number of reasons for doing so:
1) They are used all over the place
2) The cost of maintaining them are next to zero
3) They make sense on their own,
I disagree. If we keep gtk_hbox_new() and gtk_vbox_new() around,
we can't change the packing defaults, which is a *huge* benefit
of introducing a new class with new API (GtkBox was abstract before,
so now allowing to instantiate it is in fact a new widget, and
that has to be reflected in
On Thu, 25 Sep 2008, Mikael Hallendal wrote:
Why not simply keep gtk_hbox_new and gtk_vbox_new?
I can see a number of reasons for doing so:
1) They are used all over the place ...
Yes. If these functions are _not_ retained, in practical terms it
means that almost everyone who maintains
On Thu, 2008-09-25 at 09:56 -0400, Allin Cottrell wrote:
On Thu, 25 Sep 2008, Mikael Hallendal wrote:
Why not simply keep gtk_hbox_new and gtk_vbox_new?
I can see a number of reasons for doing so:
1) They are used all over the place ...
Yes. If these functions are _not_
On Thu, 2008-09-25 at 16:31 +0200, Milosz Derezynski wrote:
They are functions now and their address can be taken; this should be
taken into consideration when thinking about whether to make them be
macros or functions in the future (and it would seem that they should
be retained as
On Thu, 2008-09-25 at 17:31 +0200, Xavier Bestel wrote:
On Thu, 2008-09-25 at 16:31 +0200, Milosz Derezynski wrote:
They are functions now and their address can be taken; this should be
taken into consideration when thinking about whether to make them be
macros or functions in the future
On Thu, 2008-09-25 at 10:35 +0200, Alexander Larsson wrote:
I think removing the classes but keep gtk_hbox_new/gtk_vbox_new that
simply creates a GtkBox with the correct orientation is the right
approach here.
Yeah. I agree. Why are these bad? They are just helper functions (that
On Thu, 2008-09-25 at 11:38 -0500, Mike Kestner wrote:
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 porting existing code. Especially when the cost of
supporting existing code is so low.
On Thu, Sep 25, 2008 at 1:03 PM, Alexander Larsson [EMAIL PROTECTED] wrote:
On Thu, 2008-09-25 at 11:38 -0500, Mike Kestner wrote:
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 porting
On Thu, 2008-09-25 at 19:03 +0200, Alexander Larsson wrote:
On Thu, 2008-09-25 at 11:38 -0500, Mike Kestner wrote:
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 porting existing code.
I think the general problem is that if you have a box type that can
change orientation on the fly, what type is it? A HBox or a Vbox?
I cannot actually imagine why I would want such a box, but if you
wanted to you could do
#define GTK_IS_HBOX(w) (GTK_IS_BOX(w)
On Thu, 2008-09-25 at 13:16 -0400, Morten Welinder wrote:
I think the general problem is that if you have a box type that can
change orientation on the fly, what type is it? A HBox or a Vbox?
I cannot actually imagine why I would want such a box, but if you
wanted to you could do
2008/9/25, Michael Natterer [EMAIL PROTECTED]:
Yes this is a problem, and this is exactly where the uploaded patches
are incomplete. Boxes, Separators, Paneds created with the old APIs
must not be flippable. We can't have a HPaned that is vertical.
I'd say this is too theoretical; this is
Alexander Larsson wrote:
On Thu, 2008-09-25 at 11:38 -0500, Mike Kestner wrote:
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 porting existing code. Especially when the cost of
supporting
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 to gtk_box_pack_start_defaults, if I understand things right.
Some thing will break if you do that, but nowhere near as many things
as with changing the
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 to gtk_box_pack_start_defaults, if I understand things right.
If all you do is change the
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 to gtk_box_pack_start_defaults, if I understand things right.
Because I would never suggest
If the pain is all you care about, I suggest you grep some source
codes a bit. Gnumeric has like ten HBoxes and ten VBoxes in C code
and a lot of them in .glade files. The C ones take half and hour to
port, the glade ones take a regex. Where is the pain? It no more
pain than any other
On Thu, 2008-09-25 at 19:24 +0200, Michael Natterer wrote:
Currently 90-something-ish% of all children have to be packed into
boxes using gtk_box_pack_foo(box, child, FALSE, FALSE, pad).
That's totally redundant clutter and keeps people from using
the generic gtk_container_add() API. If the
On Tue, 2008-09-23 at 18:31 -0400, Morten Welinder wrote:
* Deprecate the H/V split and add orientation instead
+ mitch has a patch deprecating all the H/V classes
+ adds a constructor for base classes
+ defaults can be fixed
+ subclassing is easier
+ change orientation at runtime
+
I don't think the minutes reflect what was said in the meeting here.
My understanding was hat the H/V subclasses get deprecated as soon
as the code to enable flipping in their parent classes is in SVN.
If, say, gtk_hbox_new was to get deprecated and disappear in 3.x then
it would be
On Wed, 2008-09-24 at 11:23 -0400, Morten Welinder wrote:
I don't think the minutes reflect what was said in the meeting here.
My understanding was hat the H/V subclasses get deprecated as soon
as the code to enable flipping in their parent classes is in SVN.
If, say, gtk_hbox_new was to
Am Mittwoch, den 24.09.2008, 18:03 +0200 schrieb Xavier Bestel:
BTW where can I find a list of 2.90/3.0-deprecations ?
2.90 and 3.0 won't deprecate anything. Your list will be the list of
deprecated API shipped with 2.16.0.
Regards,
Sven
___
Le mercredi 24 septembre 2008 à 18:06 +0200, Sven Herzberg a écrit :
Am Mittwoch, den 24.09.2008, 18:03 +0200 schrieb Xavier Bestel:
BTW where can I find a list of 2.90/3.0-deprecations ?
2.90 and 3.0 won't deprecate anything. Your list will be the list of
deprecated API shipped with
2008/9/24 Michael Natterer [EMAIL PROTECTED]:
On Wed, 2008-09-24 at 11:23 -0400, Morten Welinder wrote:
I don't think the minutes reflect what was said in the meeting here.
My understanding was hat the H/V subclasses get deprecated as soon
as the code to enable flipping in their parent
Personally if i had the choice (but i'm not into all factors and standard
procedures and their motivations at Gtk+ in the past), i'd keep the API
calls of GtkVBox/HBox for a really long time, and (yes) certainly past 3.0,
and make them just be wrappers for the new orientation API.
In theory
How is this different from any other deprecated function that got
replaced by another one and will disappear in 3.0?
1. The number of uses of hbox and vbox is *huge*. Working around it
with an #ifdef or two is not going to work well. We're easily talking
hundreds of instances here for a
On Wed, Sep 24, 2008 at 12:12 AM, Emmanuele Bassi [EMAIL PROTECTED] wrote:
= minutes for the 2008-09-23 meeting =
* Deprecate the H/V split and add orientation instead
+ mitch has a patch deprecating all the H/V classes
+ adds a constructor for base classes
+ defaults can be fixed
+
Am Thu, 25 Sep 2008 02:20:35 +0300
schrieb Vlad Grecescu [EMAIL PROTECTED]:
On Wed, Sep 24, 2008 at 12:12 AM, Emmanuele Bassi [EMAIL PROTECTED]
wrote:
= minutes for the 2008-09-23 meeting =
* Deprecate the H/V split and add orientation instead
+ mitch has a patch deprecating all the H/V
= minutes for the 2008-09-23 meeting =
* GtkAdjustment change
- applications should be considered broken
- apparently strictness caused too much trouble
- four options
+ revert
+ keep the strictness
+ limit the strictness to SpinButtons
+ revert and add a warning
- revert + add a warning
* Deprecate the H/V split and add orientation instead
+ mitch has a patch deprecating all the H/V classes
+ adds a constructor for base classes
+ defaults can be fixed
+ subclassing is easier
+ change orientation at runtime
+ massive deprecation at branch for 2.90
+ everyone agrees
On Tue, 2008-09-23 at 18:31 -0400, Morten Welinder wrote:
+ massive deprecation at branch for 2.90
+ everyone agrees
ACTION: mitch files bugs with the various patches
This late-cycle deprecation will make it hard to write code that is
kosher in both the old and the new world. That is
42 matches
Mail list logo
