rc2rc project. (Was there a bug number for that? I can't find it, if
there was.)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37247 a592a061-630c-0410-9148-cb99ea01b6c8
preparatory to prefs2prefs conversion here, which will be the last piece
of that work.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37235 a592a061-630c-0410-9148-cb99ea01b6c8
Unfortunately the commandline export of InsetInfo is still broken for MENU_INFO.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37134 a592a061-630c-0410-9148-cb99ea01b6c8
- In GuiApplication::dispatch, do not call markDirty() for lfuns that are not ReadOnly
- In Undo::Private::recordUndo, call markDirty(). The indicator of dirtyness is now the existence of an undo element.
- In lyxfind, remove several markDirty calls that are not needed anymore.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36772 a592a061-630c-0410-9148-cb99ea01b6c8
* create math inset
* enter macro name \ww
* press left arrow to re-enter the macro name inset, add a third 'w'.
* when leaving the inset is is updated through notifyCursorLeaves, but no undo group is active
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36596 a592a061-630c-0410-9148-cb99ea01b6c8
GuiView::loadDocument also already calls setBuffer(), so this is not needed everytime too.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35917 a592a061-630c-0410-9148-cb99ea01b6c8
- move a comment back from to GuiApplication to GuiView.cpp, so we have the comment in the place where we decide to process the func request asynchronously;
- rename dispatchDelayed to processFuncRequestAsync to have the same terminology as in the other processFuncRequest* methods;
- introduce a new function processFuncRequest to complete the set of processFuncRequest* methods. It is strange that for the normal processFuncRequest one should suddenly use lyx::dispatch. Besides, I think it is good that the whole GUI will dispatch funcRequests through GuiApplication::processFuncRequest from now on;
- use the slotProcessFuncRequestQueue to relay to processFuncRequestQueue;
- properly camelBump addToFuncRequestQueue;
- group the implementation of the processFuncRequest* functions;
- document the side-effect of processFuncRequestAsync.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35784 a592a061-630c-0410-9148-cb99ea01b6c8
Make it possible to suppress messages stored in DispatchResult objects.
BUG: 6417
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35662 a592a061-630c-0410-9148-cb99ea01b6c8
What is missing is some feedback on what colors are
set from the system (they should be disabled in the
color list).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35096 a592a061-630c-0410-9148-cb99ea01b6c8
I am not sure that there is something else that we can get from QPalette. Maybe
cursor color, if someone tells me how to get it.
Only tested on mac. I can revert if this causes problems on linux or windows.
I have to check too that it still works in non-gui mode.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35060 a592a061-630c-0410-9148-cb99ea01b6c8
DispatchResult to store a flag that tells us whether we need a buffer
update or not.
So: If you find a missing one, go to an appropriate place in the
dispatch and call cur.forceBufferUpdate() or, if you don't have a cursor
but do have a DispatchResult, call dr.forceBufferUpdate().
There is one remaining call I could not move, in
TextMetrics::redoParagraph. But this looks like an emergency call when
the macro context has not been set. There are also a couple calls that
are connected with buffer creation that I commented out, since the same
call is done again almost immediately. But I'm not positive about those.
Now the nice thing would be to do the same for updateMacros().
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34826 a592a061-630c-0410-9148-cb99ea01b6c8
Solution: don't use boost::bind for msvc10 (could also be extended to several GCC versions)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34257 a592a061-630c-0410-9148-cb99ea01b6c8
* I didn't like the fact that the heart of the dispatch/status machinery is in the default clause of a long switch statement. Now, it is clear that we enter the app in getStatus, which then asks the GuiApplication itself, the GuiView, the current BufferView, the current Buffer, the document BufferView, the document Buffer,
* Shouldn't we let BufferView call the Buffer getStatus() functions ?,
* This also makes sure that if a command is not handled, it is turned off. Before r34164 this was caused by the default clause in BufferView,
* Now it is prevented that if the document BufferView is the same as the current BufferView, that the getStatus() functions are called twice,
* A warning can be outputted if the LFUN is not handled.
PS I want to do the same for the dispatch function.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34165 a592a061-630c-0410-9148-cb99ea01b6c8
