Re: Table menu patch for GtkMenu
- From: Kristian Rietveld <kris gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: GTK Development list <gtk-devel-list gnome org>
- Subject: Re: Table menu patch for GtkMenu
- Date: 03 Aug 2003 03:37:04 +0200
On Thu, 2003-07-24 at 18:26, Owen Taylor wrote:
> > - in the size requisition/allocation algorithm, the width is
> > homogeneous, but the height is not. Why is this? For example, think of a
> > menu with usual text items and a separator item. Then the separator item
> > *has* to have another height then the text items in order to look nice.
>
> Maybe *neither* should be homogeneous - the mix seems a bit confusing.
> What's the inspiration for having the columns homogenous?
>
Hmm, I think I got confused by your comment in your previous mail: "If
you are only supporting homogeneous tables, then I think a much simpler
implementation is possible than what you have now". So I assumed I had
to go for homogeneous tables (I know your comment doesn't exactly say
that though).
Though if you rather want non-homogenous columns, that's possible. It
will probably make the code a bit more difficult though.
> As Matthias said, you seem to have used properties, not child properties
> here; so, well, it's not quit what I was, expecting, no :-)
>
> Child properties are implemented in the parent container, not in
> the child, so the parent doesn't need to wait for notification.
Oh, eek, how embarrassing :/ I misunderstood I think. I just found out
what child properties *really* are (didn't know about them before).
Sorry :/
>
> I don't think we want to drop gtk_menu_attach() - we typically expose
> a straightforward C API along with properties ... the only exceptions
> to that are GtkCellRenderer and GtkTextTag.
Indeed, agreed.
> One random notes about somethins noticed when browing through
> the patch (I didn't go through it line-by-line because of the
> property/child-property issue.)
>
> * When gtk_menu_shell_insert() are called on a non-trivial table
> menu, the result is complete mangling. I think an appropriate
> intepretation would be to:
>
> - Attach after the last row for postiion < 0
> - Otherwise move any items where the top is >= position
> down one row, and attach the item with left_attach=0
> right_attach=1, top_attach = position,
> bottom_attach = position+1.
>
> (Or maybe right_attach = n_cols+1?)
Yeah, that's a thing which needs fixing/fine-tuning. I will try to
address that too.
I will try to get everything right in the next patch. I hope I can mail
it somewhere next week (I will probably not have internet access the
coming week ...).
thanks,
-Kris
>
> Regards,
> Owen
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]