- 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
easy access to the current view. So we don't need it. Moreover, it seems
to me that using lv in some of these places could cause bugs. What if
the current_view_ has changed? Then we could be updating completion on
the wrong thing?
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34072 a592a061-630c-0410-9148-cb99ea01b6c8
Abdel's moving the LyXFunc code to GuiApplication. This restores some of
the structure of that code: The early returns bypassed the code that
marked the buffer dirty.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34071 a592a061-630c-0410-9148-cb99ea01b6c8
QThreadPool::maxThreadCount() defaults in general to 2 on single or
dual-processor. This is clearly not enough in a time where we use
threads for document preview and/or export. 20 should be OK.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33790 a592a061-630c-0410-9148-cb99ea01b6c8
- proper message passing for all tabular features
- properly define which feature needs an argument
* replace LFUN_TABULAR_FEATURE with LFUN_INSET_MODIFY
- The math tables are also affected. In the future a common base class
between math and text table will solve this inconsistency.
- There is a hack in GuiApplication in order to not rename the toolbar
icons. This will have to be cleaned up with a general icon naming for
LFUN_INSET_MODIFY... to be discussed.
* Tabular Dialog:
- big cleanup, lots and lots of bug fixing here
- migrated to InsetParamsWidget
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33495 a592a061-630c-0410-9148-cb99ea01b6c8
- mark languages that can be spell checked.
* Thesaurus dialog:
- mark languages that have a thesaurus dictionary.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33405 a592a061-630c-0410-9148-cb99ea01b6c8
a lot of simplification is possible. Except some instability period...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33389 a592a061-630c-0410-9148-cb99ea01b6c8
dialog is open, the menu entries that are buffer or view-related are not
going to be disabled. I'll try to solve that last issue later.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33380 a592a061-630c-0410-9148-cb99ea01b6c8
This fixes problems where Mac users can modify the documentation
by mistake. Note that it is still possible to open those document by
explicit path or to toggle off the read-only status (but this is only
useful to documentors anyway).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33260 a592a061-630c-0410-9148-cb99ea01b6c8
This commit fixes such behaviour, and performs the update immediately.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32794 a592a061-630c-0410-9148-cb99ea01b6c8
