6 API-ish issues
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list gnome org
- Subject: 6 API-ish issues
- Date: Mon, 21 Jan 2002 16:55:27 -0500 (EST)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]