Angus Leeming <[EMAIL PROTECTED]> writes:
| Thanks everybody for the feedback.
|
| Point 1, for Lars:
| this IS almost generic. At least as a first attempt it ain't far
| off.
I realize that, and I think we should go all the way from the beginning.
| And for
| this, I think you/I must extend a special thank you to Jean-Marc for creating| such
|a general toolbar code. Even if toolbarItem should be a base class so
| that combox and FL_OBJECTs can exist in the same list...
I think I am going to thank my self as well. But you are right the
Toolbard handling has turned out pretty nice.
| In order to make the stuff completely generic, I think the following points
| need to be addressed:
| * How to associate Toolbar definitions in default.ui with particular insets?
| Something like
| Toolbar "text"
| ...
| End
| Toolbar "math"
| ...
| End
| springs to mind.
looks ok to me.
| * This would allow the signals to be replaced with showToolbar("name"),
| hideToolbar("name").
| * Finally, the Layout definition in default.ui should be replaced with
| DropdownList "layout".
mmm
| Point 2, for Lars:
| > You are removing some of the boundires... LyXView knows about
| > BufferView which knows about WorkArea, LyXView is not supposed to know
| > anything about WorkArea. (and if it already does, that can be
| > considered a bug)
|
| Well then, why have a publically accessible WorkArea * workarea() in
| BufferView.h? But I agree with you!
| The only things accessing BufferView::workarea() are the new stuff in LyXView
| that call
| width(), height(), xpos(), ypos()
| and insettext, insettabular that call
| getClipboard()
|
| Shall I add some wrappers for these calls to BufferView?
please do. (and in a separate from the toolbar patch please)
| Point 3, for Dekel, Allan.
| The flicker is annoying isn't it!
Can we avoid this by locking the xforms forms/object?
--
Lgb
