Abdelrazak Younes ha scritto:
I would say "for having more workarea widgets around".
Probably, whether embedded into dialogs, toolbars or tab
panes is not that important.
Yes, we also want split views but I see the two kinds as separate. I
have plans to implement split view but not as an embedded dialog.
Of course. Infact, in such case, we would need to replace the "central
widget" of the QMainWindow
with a QMdiArea, containing multiple (tabbed) widgets as subwindows.
Anyway, the problem in the
current code base is that setCurrentWorkarea() expects to find the new
work area into one of the
tabbed panes, so to show/activate it, while it would be possible that
the new workarea to be set as
current:
1) resides into a dialog
2) resides into a docked window
3) resides into the tabbed pane
Probably, the LyXView should be aware of all of the workareas that are
being shown at the same
time (now the patch does not really work that way), but I'm not sure
whether this is needed or not.
>
>could you explain briefly why?
For advance search&replace.
Probably a few other use cases where it could be used are:
- having a split-window feature, that would allow to have
more workareas (on same or different buffers) in the same
LyX View
Yes (see above) but this is different as this needs direct interaction
with the other "real" workareas. Those other types (embedded ones) do
not need the same kind of interaction:
Yes, except the Mdi case, the other ones will probably not need all of
the surrounding
toolbars/menu voices functionality. However, the advanced search would
seem to
need a good amount of them, if not all (searching for notes, layouts,
faces, breaks,
floats, maths would seems to be all feasible things).
Bye,
T.
