X-Git-Url: https://git.lyx.org/gitweb/?a=blobdiff_plain;f=src%2Ffrontends%2FApplication.h;h=6c11007bbb15fb23ca7cdf76cbcb315742ea8a1e;hb=9be03a87f93796665dc5d28a5d3ff7ffb80bcf1d;hp=bfe4a9229f924925cf30880c98f0e4bb68caef4b;hpb=897436efbb9bd641b61467d185a2dfae9839e575;p=lyx.git diff --git a/src/frontends/Application.h b/src/frontends/Application.h index bfe4a9229f..6c11007bbb 100644 --- a/src/frontends/Application.h +++ b/src/frontends/Application.h @@ -11,6 +11,8 @@ #ifndef LYX_APPLICATION_H #define LYX_APPLICATION_H +#include "ColorCode.h" + #include #include @@ -18,8 +20,6 @@ namespace lyx { class BufferView; -class LyXView; -class Color_color; struct RGBColor; namespace frontend { @@ -27,6 +27,7 @@ namespace frontend { class Clipboard; class FontLoader; class Gui; +class LyXView; class Selection; /// The main application class @@ -34,29 +35,56 @@ class Selection; There should be only one instance of this class. No Qt object initialisation should be done before the instanciation of this class. -\todo The work areas handling could be moved to a base virtual class -common to all frontends. + Model/View/Controller separation at frontend level in LyX-qt4: + + BufferList (N Buffers) + | + Buffer-a + Buffer-b + Buffer-c + Buffer-d + + Application (this is the frontend really, should probably be renamed). + | + LyXView-1 (M1 WorkAreas, M1 <= N) + | | + | + | | (many) + | WorkArea-1 + | | + | BufferView <-----------> Buffer-c + | | + | Cursor + | + LyXView-2 (M2 WorkAreas, M2 <= N, M2 independent of M1) + | + ... - Model/View/Controller separation in LyX: 1) The Model: \c Buffer The Buffer is the in-memory representation of a LyX file format. The Buffer does not (should not) have any information on what part of it is represented on screen. There is one unique Buffer per opened LyX - file. + file. A Buffer may or may not be represented on screen; typically, a + child document does not have an associated BufferView unless the user + choose to visualize it. - 2) The Controller: \c BufferView / \c Painter + 2) The Controller: \c BufferView / \c Painter \c Cursor - The BufferView is a tool used by the view that translates a part of - the Buffer contents into drawing routines. The BufferView asks each - inset of the Buffer to draw itself onto the screen using the Painter. - There can be only one Buffer displayed in a BufferView. While there - is the possibility to switch Buffer inside the BufferView, the goal - is to instantiate a new BufferView on each Buffer switch. + The BufferView is a tool used by the view (\sa WorkArea) that + translates a part of the Buffer contents into drawing routines. The + BufferView asks each inset of the Buffer to draw itself onto the + screen using the Painter. There can be only one Buffer displayed in + a BufferView and it is set on construction. Ideally, a BufferView + should not be able to change the contents of its associated Buffer. + A BufferView is instanciated and destroyed by a \c WorkArea; it is + automatically destroyed by the parent WorkArea when its Buffer is + closed. - \todo Instantiate a new BufferView on each Buffer switch. + \todo Move all Buffer changing LFUN to LyXFunc or Cursor. + \todo BufferView::buffer() should only offer const access. The \c Painter is just a virtual interface to formalize each kind of drawing routines (text, line, rectangle, etc). @@ -69,9 +97,10 @@ common to all frontends. 3) The View: \c WorkArea (and it's qt4 specialisation GuiWorkArea) This contains the real screen area where the drawing is done by the - Painter. One WorkArea holds one unique \c BufferView. While it could be - possible that multiple WorkArea share one BufferView, this is not - possible right now. + Painter. One WorkArea holds one unique \c BufferView. While it could + be possible that multiple WorkArea share one BufferView, this is not + something desirable because a BufferView is dependent of the WorkArea + size. The WorkArea also provide a scrollbar which position is translated into scrolling command to the inner \c BufferView. @@ -84,18 +113,32 @@ common to all frontends. 4) The Window: \c LyXView (and its qt4 specialisation \c GuiView) - This is a full window containing a menubar, toolbars, a tabbar and a - WorkArea. One LyXView could in theory contain multiple WorkArea - (ex: with split window) but this number is limited to one only for - now. In any case, there would be only one WorkArea that gets the focus + This is a full window containing a menubar, toolbars and a central + widget. A LyXView is in charge of creating and closing a View for a + given Buffer. + In the qt4 specialisation, \c GuiView, the central widget is a tab + widget. Each tab is reverved to the visualisation of one Buffer and + contains one WorkArea. In the qt4 frontend, one LyXView thus contains + multiple WorkAreas but this number can limited to one for another + frontend. The idea is that the kernel should not know how a Buffer + is displayed on screen; it's the frontend business. + In the future, we may also have multiple Workareas showing + simultaneously in the same GuiView (ex: with split window). + + \todo Implement split-window + + In any case, there would be only one WorkArea that gets the focus at a time. - Now, concerning the TabBar versus TabWidget issue. Right now, there is - only one WorkArea and the TabBar just used to tell the BufferView inside - the WorkArea to switch to this another Buffer. + With our current implementation using a QTabWidget, each Tab own its + own \c WorkArea. Clicking on a tab switch a WorkArea and not really + a Buffer. LFUN_BUFFER_SWITCH will tell the frontend to search the + WorkArea associated to this Buffer. The WorkArea is automatically + created if not already present. + + A WorkArea is connected to the Buffer::closing signal and is thus + automatically destroyed when its Buffer is closed. - With a TabWidget, each Tab would own its own \c WorkArea. Clicking on a tab - would switch a WorkArea instead of a Buffer. */ class Application { @@ -111,7 +154,7 @@ public: /// Start the main event loop. /// The batch command is programmed to be execute once /// the event loop is started. - virtual int const exec() = 0; + virtual int exec() = 0; /// Quit running LyX. /** @@ -145,24 +188,24 @@ public: * The function returns true if successful. * It returns false on failure and sets r, g, b to 0. */ - virtual bool getRgbColor(Color_color col, RGBColor & rgbcol) = 0; + virtual bool getRgbColor(ColorCode col, RGBColor & rgbcol) = 0; - /** Eg, passing Color::black returns "000000", - * passing Color::white returns "ffffff". + /** Eg, passing Color_black returns "000000", + * passing Color_white returns "ffffff". */ - virtual std::string const hexName(Color_color col) = 0; + virtual std::string const hexName(ColorCode col) = 0; /** * update an altered GUI color */ - virtual void updateColor(Color_color col) = 0; + virtual void updateColor(ColorCode col) = 0; /** * add a callback for socket read notification * @param fd socket descriptor (file/socket/etc) */ - virtual void registerSocketCallback( - int fd, boost::function func) = 0; + typedef boost::function SocketCallback; + virtual void registerSocketCallback(int fd, SocketCallback func) = 0; /** * remove a I/O read callback