Jean-Marc Lasgouttes wrote: > > Conceptually, I think it makes sense to have two. I can imagine scenarios > > where one wants to change the alignment of a column from within a > > multicolumn cell (just not by default maybe). > > So we could have a function that works for either multicolumn or colum, > and another special one that only considers the underlying column.
What is your specific problem with the command-alternatives approach? > But how does the underlying column alignment act on a multicolumn? > Wouldn't it be more intuivie for the user not to have this distinction? > If the underlying column alignment matters, then the user can change > this alignment in a column where there is no multicolumn. I think this > is more intuitive. Well, the multicolumn happens to be part of a column, so the context of the current column changes. Basically, it's "change the alignment of the rest of this column" vs. "change the alignment of the multicolumn only". I might want to do the former without having to move the cursor (I'm not saying this is something that is worth being reflected in the GUI, but rather a power user thing, for which lfuns are sufficient). > > Apart from that, the GuiApplication changes were necessary anyway, given > > that we want to support command-alternatives in the toolbar. > > Do we really? It would only make sense if we can change the icon > depending on what action is going to happen. I would be surprised if > this is something standard in a GUI :) But this makes sense: an icon is > for one action that has well defined semantics. If we have a good > meaning, we can define an lfun... I think it makes sense if different actions are to be performed, but the differences are too technical to bother the user. In the given case, the ordinary user (presumably) expects that pressing the button aligns the content in the "thing" the cursor is currently in. S/he is not interested in whether this is a multicolumn or not, not to mention that LaTeX tabulars build on this conceptual distinction, which more or less forces us to build on it as well. I see no conceptual difference between command-alternatives and a wrapper lfun, despite the fact that the latter limits the lfun variability. Jürgen
