Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
So, if I may ask (again), do we have a deal?
From me, yes. But I'd like to see a class hierarchy together with some thoughts
on how it will all fit together.
Agreed. This needs to be done. A few comments on your proposal (which is
already partly implemented).
Let me start you off:
class GUI {
This is my BaseFrontend class, do you prefer BaseGui instead?
/** The LyX core will own a single GUI
* variable, instantiated by a Factory function
* in the various frontends.
* (Should this class be a singleton then?)
*
* The class owns accessors to
* a single Clipboard (Clipboard),
Done
* a single Selection buffer (Selection),
I think this should be merged with the Clipboard class as Qt4 does:
QClipbard Public Functions:
void clear ( Mode mode = Clipboard )
QImage image ( Mode mode = Clipboard ) const
const QMimeData * mimeData ( Mode mode = Clipboard ) const
bool ownsClipboard () const
bool ownsSelection () const
QPixmap pixmap ( Mode mode = Clipboard ) const
void setImage ( const QImage & image, Mode mode = Clipboard )
void setMimeData ( QMimeData * src, Mode mode = Clipboard )
void setPixmap ( const QPixmap & pixmap, Mode mode = Clipboard )
void setText ( const QString & text, Mode mode = Clipboard )
bool supportsSelection () const
QString text ( Mode mode = Clipboard ) const
QString text ( QString & subtype, Mode mode = Clipboard ) const
* (possibly multiple) LyX windows (LyXView),
Not done yet.
* (possibly multiple) WorkAreas (WorkArea)
Done: Public interface defined by BaseWorkArea
* (possibly multiple) GUICursors (one per WorkArea)
For now there is only one cursor (FrontendCursor) that is connected to
one WorkArea at the same time.
* only one of which can be "active".
So I guess this is done already.
*
* (Should the GUICursor be owned by the WorkArea then?)
No, only connected to it by the owner when the kernel commands a
switching to this WorkArea.
public:
/// Singleton class; control access to the one allowed instance.
static GUI* get();
Yes, this needs to be worked out. Currently the one LyXView is created
inside "lyx_gui.C:start()" by calling "lyx_main.C:addLyXView()"
private:
GUI();
GUI(GUI const &);
~GUI();
GUI & operator=(GUI const &);
};
class Clipboard {
Done for qt4.
class Selection {
Not done yet, Georg posted some code that will support that. As for the
need for a different class, see above: I think we should mimics Qt API
there.
class LyXView {
/** A variable of this class represents a single
* LyX window. The class owns accessors to
* Menubars
* Toolbars
* The minibuffer
* one or more WorkAreas
* The Dialogs (ie, each Window has its own Dialogs)
*/
};
I would call that View for the implementation and BaseView for the
virtual interface.
class GUICursor {
/** The visible representation of the cursor in a document.
* Changes appearance when a WorkArea becomes "active".
*/
};
Done for all frontend: FrontendCursor. It could be extended for this
additional "inactive" mode.
class WorkArea {
/** A variable of this class is used to display a single BufferView.
*/
};
Done for qt4.
If you flesh out how the LyX core will interact with these classes (add the
functions and explain how they're to be used), I'm sure that you'll quickly find
what areas need some deeper thought.
I'll do that on due time.
Thanks for the help,
Abdel.
