Re: 6 API-ish issues
- From: "Matthias Clasen" <matthiasc poet de>
- To: <gtk-devel-list gnome org>, "Owen Taylor" <otaylor redhat com>
- Subject: Re: 6 API-ish issues
- Date: Tue, 22 Jan 2002 10:30:11 +0100
Owen, if you consider deprecation to be API-relevant, then my additions to
http://bugzilla.gnome.org/show_bug.cgi?id=68183
are also API-ish.
Matthias
----- Original Message -----
From: "Owen Taylor" <otaylor redhat com>
To: <gtk-devel-list gnome org>
Sent: Monday, January 21, 2002 10:55 PM
Subject: 6 API-ish issues
>
> Over the last few weeks, a number of API-related issues have shown up
> that are either:
>
> - Small enough that they might be worth sneaking in
> - Important enough that they might be worth sneaking in
>
> I'd like to solicit feedback about the following bugs, either positive
> ("Without this change, my life is meaningless!") or negative
> ("What idiot would make this change after you've declared an API
> freeze???")
>
> Thanks,
> Owen
>
> * 66590 guint should be flag type
>
> This is probably right; we do _normally_ use GtkModifier type
> for modifier flags field. (In gtk/, about 15 public uses of
> GtkModifierType vs. 7 of uint.) But this breaks source compatibility
> with C++, and I don't think there is a big benefit for fixing
> it unless we fix all uses of uint for modifiers. (Small benefits
> are consistency in GtkAccelMap and not introducing new functions
> with things broken.)
>
> http://bugzilla.gnome.org/show_bug.cgi?id=66590
>
> * 68174 GtkEntry focus/selection problem
>
> Bug wants gtk_widget_grab_focus (entry) not to select the text in the
> entry. I think you generally want the selection, but should we
> force apps to do that themselves? Is there ever a
> reason for an _app_ to know that it should't select the text
> in one particular case?
>
> (The main objections is wanting to maintain the contents of PRIMARY,
> the solution here is to train users to use the clipboard...)
>
> http://bugzilla.gnome.org/show_bug.cgi?id=68174
>
> * 68527 gtk_item_factory_path_from_widget should be G_CONST_RETURN
>
> Certainly right, but would break source compatibility a bit.
>
> http://bugzilla.gnome.org/show_bug.cgi?id=68527
>
> * 68801 Make gdk_pixbuf_render_to_drawable() use the alpha channel
>
> This change would:
>
> - Cause small rendering oddities for people using
> gdk_pixbuf_render_to_drawable() in combination with a mask
> to do bilevel rendering of non-bilevel images. (Note that I
> recently changed gdk_pixbuf_render_alpha() to _never_ do bilevel
> rendering, which is probably a bigger change.)
> - Have the typical new API during an API freeze problems.
>
> http://bugzilla.gnome.org/show_bug.cgi?id=68801
>
> * 68890 Port all selectors to GtkTreeView
>
> The issue here is the change of the clists to tree views in
> GtkFileSel. It's pretty important for accessibility and appearance,
> but will cause problems for the many apps that poke into the internals
> of GtkFileSel directly. See my recent mail on this issue.
>
(http://mail.gnome.org/archives/gtk-devel-list/2002-January/msg00154.html)
>
> http://bugzilla.gnome.org/show_bug.cgi?id=68890
>
> * 69242 _gtk_widget_set_accel_path() should be exported
>
> The reason for doing this is support for accelerators on buttons; the
> reason for supporting accelerators (not mnemonics) on buttons is
unclear
> to me, but Tim thinks it makes sense as part of an action based
> menu/toolbar API. (If it is missing, we could certainly work around
> the problem.)
>
> The main problems with exporting this are:
>
> - It will confuse people that they have to use
gtk_menu_item_set_accel_path()
> instead for menu items.
>
> - Typical problems of adding API in an API freeze.
>
> IMO, it could wait until 2.2.
>
> http://bugzilla.gnome.org/show_bug.cgi?id=69242
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]