Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | | // Build temporary cursor.
| > | - cmd.y = min(max(cmd.y,-1), workarea().workHeight());
| > | + cmd.y = min(max(cmd.y,-1), workarea().height());
| > spacing
|
| You mean:
|
| cmd.y = min(max(cmd.y, -1), workarea().height());
|
| ??
yes
| > | @@ -179,8 +192,10 @@
| > | std::vector<Position> saved_positions;
| > | ///
| > | void menuInsertLyXFile(std::string const & filen);
| > | - /// our workarea
| > | - WorkArea & workarea() const;
| > | +
| > | + lyx::frontend::WorkArea * work_area_;
| > Do we want bald pointers? Even just as cache?
|
| I can't use reference because I want to be able to change work_area_
| at run-time. This work_area_ is not created nor deleted here so it is
| a _safe_ use of pointer. Feel free to suggest something else that
| retain polymorphisms.
boost::shared_ptr<lyx::frontend::WorkArea, no_delete> work_area_;
(you have to create the deleter though, no_delete is just an example)
| > | Index: src/frontends/gtk/GView.h
| > | ===================================================================
| > | --- src/frontends/gtk/GView.h (revision 14120)
| > | +++ src/frontends/gtk/GView.h (working copy)
| > | @@ -12,9 +12,12 @@
| > | #ifndef GVIEW_H
| > | #define GVIEW_H
| > | | -#include "frontends/LyXView.h"
| > | #include "bufferview_funcs.h"
| > | | +#include "frontends/LyXView.h"
| > | +
| > | +#include "TheGui.h"
| > This "TheGui" thing sounds/looks strange. what is it? Can it get a
| > more descriptive name?
|
| Gui.h is the virtual interface to everything Gui related:
| - clipboard
| - work areas
| - views (including menubar, etc)
| - etc
|
| There should be only _one_ instance of Gui object, hence the name:
| _The_ Gui
I think a more descriptive name should be found. And don't have any
real good idea, but TheGui is vague... but... if only once instance,
why not as a singleton? GView::getGuiInstance().<do stuff with it>.
but it is the class name that is vague... hmm... even MainGui is
better imho. (MainGuiClass)
| > | | // ENCODING: we assume that the backend passes us ISO-8859-1
| > and
| > | // convert from that to UTF-8 before passing to GTK
| > | -void GWorkArea::putClipboard(string const & str) const
| > | +void GWorkArea::putClipboard(string const & str)
| > | {
| > Why the const removals?
|
| I can put it back but the const was and still is _wrong_. PutClipbard
| modify the clipboard and for now, the gtk clipboard is part of
| GWorkArea so it should not be const. It used to work without the const
| because the clipboard is not really part of it and putClipboard() just
| modify some global variable.
but const was also removed from getClipboard, wasn't it?
| > | #ifndef I_AM_NOT_AFRAID_OF_HEADER_LIBRARIES
| > | #if USE_BOOST_FORMAT
| > Are thise releated to the gui changes? Why?
|
| It is part of the cleanup. Those #ifdef where in QWorkArea clipboard
| code (qt3 and qt4). Instead of putting them back in the new
| GuiClipboard class I decided to make two helper functions instead.
|
| > (and I donÃ't like the IFDEF implementation. Should be broken out
| > into
| > an win file and a mac file.
|
| Are you suggesting tree additional file that will be compiled
| depending on the platform? Something like:
| - lstring_win.C
| - lstring_mac.C
| - lstring_x11.C
|
| I am fine with that but I don't know enough about m4 to do this. This
| can be done after the merging.
You don't have to know any m4 to do this.
but you might ahve to set a automake conditional
| So I correct those thing that you don't like can I merge to trunk?
Eager now? Yes.
--
Lgb
