lyx_mirror/src/frontends/Toolbars.h

168 lines
4.3 KiB
C
Raw Normal View History

// -*- C++ -*-
/**
* \file Toolbars.h
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* \author Lars Gullik Bjønnes
* \author Angus Leeming
*
* Full author contact details are available in file CREDITS.
*
* The Toolbars class is a container of toolbars.
* It provides accessors to each Toolbar and to the LayoutBox.
*
* Each GUI frontend should provide toolbar and layout boxes by derivation
* from the LayoutBox and Toolbar pure abstract classes.
*
* The Toolbars class has no knowledge at all of the details of each
* frontend's implementation, which requires that each frontend should
* provide a 'make_toolbar' function, signature below.
*/
#ifndef TOOLBARS_H
#define TOOLBARS_H
This is one of a series of patches that will merge the layout modules development in personal/branches/rgheck back into the tree. Design goal: Allow the use of layout "modules", which are to LaTeX packages as layout files are to LaTeX document classes. Thus, one could have a module that defined certain character styles, environments, commands, or what have you, and include it in various documents, each of which uses a different document class, without having to modify the layout files themselves. For example, a theorems.module could be used with article.layout to provide support for theorem-type environments, without having to modify article.layout itself, and the same module could be used with book.layout, etc. This first patch does some reworking of the infrastructrue. We need to distinguish between the TextClass that a particular document is using and the layout of that document, since modules, in particular, can modify the layout. The solution adopted here is to add a TextClass pointer to BufferParams, which will hold the layout. The layout itself is then constructed from the TextClass the document is using. At present, this is completely trivial, but that will change when modules are added. The pointer in question is a boost::shared_ptr. This is needed because CutAndPaste saves a copy of the layout with each cut or copied selection. We cannot assume the selection vanishes when the document is closed, so there are two options: (i) keep a list of all the layouts that have ever been used by any document; (ii) used some kind of smart pointer. The latter seems preferable, as the former would waste memory. More importantly, the use of a smart pointer allows modules to be modified on disk and then reloaded while LyX is running, and it will eventually allow the same for layout files. git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@19756 a592a061-630c-0410-9148-cb99ea01b6c8
2007-08-23 16:41:13 +00:00
#include "TextClass_ptr.h"
#include "ToolbarBackend.h"
#include "Session.h"
#include <boost/shared_ptr.hpp>
#include <map>
namespace lyx {
namespace frontend {
class LyXView;
class LayoutBox {
public:
virtual ~LayoutBox() {}
/// Select the correct layout in the combox.
virtual void set(docstring const & layout) = 0;
/// Populate the layout combox.
virtual void update() = 0;
/// Erase the layout list.
virtual void clear() = 0;
/// Display the layout list.
virtual void open() = 0;
/// Set the activation status of the combox.
virtual void setEnabled(bool) = 0;
};
class Toolbar {
public:
virtual ~Toolbar() {}
/// Add a button to the bar.
virtual void add(ToolbarItem const & item) = 0;
/** Hide the bar.
* \param update_metrics is a hint to the layout engine that the
* metrics should be updated.
*/
virtual void hide(bool update_metrics) = 0;
/** Show the bar.
* \param update_metrics is a hint to the layout engine that the
* metrics should be updated.
*/
virtual void show(bool update_metrics) = 0;
/** update toolbar information
* ToolbarInfo will then be saved by session
*/
virtual void saveInfo(ToolbarSection::ToolbarInfo & tbinfo) = 0;
/// whether toolbar is visible
virtual bool isVisible() const = 0;
/// Refresh the contents of the bar.
virtual void update() = 0;
/// Accessor to the layout combox, if any.
virtual LayoutBox * layout() const = 0;
};
class Toolbars {
public:
///
Toolbars(LyXView & owner);
/// Initialize the toolbars using the backend database.
void init();
/// Show/hide the named toolbar.
void display(std::string const & name, bool show);
/// get toolbar info
ToolbarInfo * getToolbarInfo(std::string const & name);
/** toggle the state of toolbars (on/off/auto). Skip "auto"
* when allowauto is false.
*/
void toggleToolbarState(std::string const & name, bool allowauto);
/// Update the state of the toolbars.
void update(bool in_math, bool in_table, bool review);
/// Is the Toolbar currently visible?
bool visible(std::string const & name) const;
/// save toolbar information
void saveToolbarInfo();
/// Select the right layout in the combox.
void setLayout(docstring const & layout);
/** Populate the layout combox - returns whether we did a full
* update or not
*/
This is one of a series of patches that will merge the layout modules development in personal/branches/rgheck back into the tree. Design goal: Allow the use of layout "modules", which are to LaTeX packages as layout files are to LaTeX document classes. Thus, one could have a module that defined certain character styles, environments, commands, or what have you, and include it in various documents, each of which uses a different document class, without having to modify the layout files themselves. For example, a theorems.module could be used with article.layout to provide support for theorem-type environments, without having to modify article.layout itself, and the same module could be used with book.layout, etc. This first patch does some reworking of the infrastructrue. We need to distinguish between the TextClass that a particular document is using and the layout of that document, since modules, in particular, can modify the layout. The solution adopted here is to add a TextClass pointer to BufferParams, which will hold the layout. The layout itself is then constructed from the TextClass the document is using. At present, this is completely trivial, but that will change when modules are added. The pointer in question is a boost::shared_ptr. This is needed because CutAndPaste saves a copy of the layout with each cut or copied selection. We cannot assume the selection vanishes when the document is closed, so there are two options: (i) keep a list of all the layouts that have ever been used by any document; (ii) used some kind of smart pointer. The latter seems preferable, as the former would waste memory. More importantly, the use of a smart pointer allows modules to be modified on disk and then reloaded while LyX is running, and it will eventually allow the same for layout files. git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@19756 a592a061-630c-0410-9148-cb99ea01b6c8
2007-08-23 16:41:13 +00:00
bool updateLayoutList(TextClass_ptr textclass);
/// Drop down the layout list.
void openLayoutList();
/// Erase the layout list.
void clearLayoutList();
///
typedef boost::shared_ptr<Toolbar> ToolbarPtr;
private:
/// Add a new toolbar. if newline==true, start from a new line
void add(ToolbarInfo const & tbinfo, bool newline);
/// Show or hide a toolbar.
void displayToolbar(ToolbarInfo const & tbinfo, bool show);
/// Update the state of the icons
void update();
/// The parent window.
LyXView & owner_;
/** The layout box is actually owned by whichever toolbar
* contains it. All the Toolbars class needs is a means of
* accessing it.
*
* We don't need to use boost::weak_ptr here because the toolbars
* are also stored here. There are, therefore, no lifetime issues.
*/
LayoutBox * layout_;
/// Toolbar store providing access to individual toolbars by name.
typedef std::map<std::string, ToolbarPtr> ToolbarsMap;
ToolbarsMap toolbars_;
/// The last textclass layout list in the layout choice selector
This is one of a series of patches that will merge the layout modules development in personal/branches/rgheck back into the tree. Design goal: Allow the use of layout "modules", which are to LaTeX packages as layout files are to LaTeX document classes. Thus, one could have a module that defined certain character styles, environments, commands, or what have you, and include it in various documents, each of which uses a different document class, without having to modify the layout files themselves. For example, a theorems.module could be used with article.layout to provide support for theorem-type environments, without having to modify article.layout itself, and the same module could be used with book.layout, etc. This first patch does some reworking of the infrastructrue. We need to distinguish between the TextClass that a particular document is using and the layout of that document, since modules, in particular, can modify the layout. The solution adopted here is to add a TextClass pointer to BufferParams, which will hold the layout. The layout itself is then constructed from the TextClass the document is using. At present, this is completely trivial, but that will change when modules are added. The pointer in question is a boost::shared_ptr. This is needed because CutAndPaste saves a copy of the layout with each cut or copied selection. We cannot assume the selection vanishes when the document is closed, so there are two options: (i) keep a list of all the layouts that have ever been used by any document; (ii) used some kind of smart pointer. The latter seems preferable, as the former would waste memory. More importantly, the use of a smart pointer allows modules to be modified on disk and then reloaded while LyX is running, and it will eventually allow the same for layout files. git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@19756 a592a061-630c-0410-9148-cb99ea01b6c8
2007-08-23 16:41:13 +00:00
TextClass_ptr last_textclass_;
// load flags with saved values
void initFlags(ToolbarInfo & tbinfo);
};
/// Set the layout in the kernel when an entry has been selected
void layoutSelected(LyXView & lv, docstring const & name);
} // namespace frontend
} // namespace lyx
#endif // NOT TOOLBARS_H