The 100% cpu problem is still there and the culprit turns out to be r35795.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36231 a592a061-630c-0410-9148-cb99ea01b6c8
Before, LyX could crash when calling setBusy(false) while LyX is still in a busy state due to a surrounding setBusy(true)/setBusy(false) construction.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36140 a592a061-630c-0410-9148-cb99ea01b6c8
#6884.
1. Open LyX. File>New. Document>Outline, to make sure the TOC is open.
That isn't necessary, but it helps you to see what is happening.
2. Create a section heading (alt-P, 2) with an x in it.
3. Split the screen.
4. File>New. You should now still see the TOC for the OLD buffer.
5. Click in the top screen. You now see an empty TOC (the one for the
empty buffer).
6. Click in the empty buffer. Other TOC!
7. Back to the "x" buffer. Empty TOC. Type something. Boom!
The problem is that teh setCurrentWorkArea() call eventually gets us to
structureChanged(), which accesses documentBufferView(). But that
doesn't get reset until later, and hence everything is out of sync.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35999 a592a061-630c-0410-9148-cb99ea01b6c8
This is why it was worth doing the updateBuffer() rewrite.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35975 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
Besides, now we can always call GuiView::reloadBuffer instead of calling Buffer::reload directly. This means we don't have to do the error handling each time over and over again.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35916 a592a061-630c-0410-9148-cb99ea01b6c8
Buffer::errors("Parse") is called 7 times in the whole project. 4 times from GuiView and three times from functions in other classes, but which are (almost) only called from the GuiView.
Buffer::errors is used to signal the GUI that there might be an error occuring, but what sense does it make if it is only called from the Gui ?
Isn't it better to let the function return wether it succeeded or not and let the GuiView take action in doing something with the possible errors.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35911 a592a061-630c-0410-9148-cb99ea01b6c8
argument from that function. We are always saving the checksum for the
Buffer's file. The argument is a left-over from a time when we did the
wrong thing and saved it for e.g. the emergency file.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35890 a592a061-630c-0410-9148-cb99ea01b6c8
A hidden document does not have an associated Cursor. So, each time we create a new workArea, we should restore the cursor position.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35811 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
exportAndDestroy was calling:
buffer->doExport(format, true, update_unincluded);
where "true" means: Leave it in the tempdir. We need false, which means
we need another parameter, if we're not doing it as cut and paste.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35717 a592a061-630c-0410-9148-cb99ea01b6c8
exportAndDestroy was calling:
buffer->doExport(format, true, update_unincluded);
where "true" means: Leave it in the tempdir. We need false, which means
we need another parameter, if we're not doing it as cut and paste.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35715 a592a061-630c-0410-9148-cb99ea01b6c8
P.S. How do we prevent other cases like this? By throwing exceptions, we never know whether it's assured that we will return to the function to call setBusy(false). In JAVA you always have to either make a function throwable or to catch the exception, but AFAICS you have to crawl through the code to find out whether a function can throw an exception.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35714 a592a061-630c-0410-9148-cb99ea01b6c8
We have to copy the files because export is asynchronous now,
What about the children?
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35703 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
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
- buffer-switch does open tabs even when open in tabs is disabled;
- buffer-switch open the document in a new tab even if it is already opened in another view.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34618 a592a061-630c-0410-9148-cb99ea01b6c8
If the document class is not available, we now issue a warning for the user. This triggers a focusInEvent of the WorkArea and the cursor is issued to start blinking. However, when reverting a document the cursor is probably invalid and there has been no chance yet to fix it as we are still reading the file.
The solution is to not show the cursor when the view is still busy.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34590 a592a061-630c-0410-9148-cb99ea01b6c8
The dialog only offers symbols defined in the unicodesymbols file
and they will be wrapped in \text{} when inserted in math mode,
so there is no risk that an untypesettable symbol gets inserted.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34344 a592a061-630c-0410-9148-cb99ea01b6c8
due to a missing buffer and because the "dialog is only useful in texted".
The problem with the buffer member has been solved since then, and while
it is true that the character dialog is not much useful in mathed, it
is the only way for coloring only parts of equations. Given that this
would also be a regression with respect to 1.6, I am re-enabling it.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34327 a592a061-630c-0410-9148-cb99ea01b6c8
getStatus() returns false for LFUN_BUFFER_VIEW when a previewing process is running. So, if this process has finished we should free the menu item.
P.S. on windows, the item does not get disabled anyway.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34324 a592a061-630c-0410-9148-cb99ea01b6c8
M-o now switches to the TOC pane, and Esc always returns from any DockView to the main window.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34293 a592a061-630c-0410-9148-cb99ea01b6c8
- First, the comment for isBufferDependent is corrected. It seems that the actual use of this function differs from the comment. As the comment said, I decided to close all dialogs that were buffer dependent, but this didn't seem to be correct for the view source pan, the outliner, and find-and-replace.
- Second, the dialogs that are buffer dependent are now closed, but dockviews are not, except for the spellchecker pane, which really depends on an open buffer, but I can't test that.
So, please test whether the spellchecker dockviewed window behaves as one expects.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34291 a592a061-630c-0410-9148-cb99ea01b6c8
Solution: don't use boost::shared_ptr for msvc10 (could also be extended to several GCC versions)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34259 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
both dvi and pdf, let's allow switching forward search from one format
to the other through a timestamp check, such that the most recent
generated format will be used.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34200 a592a061-630c-0410-9148-cb99ea01b6c8
No viewer set by default, which keeps context menu clean for uninterested users.
Settings are hinted at combobox.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34149 a592a061-630c-0410-9148-cb99ea01b6c8
If a dvi file exists in the temp dir, the command specified by the
\forward_search_dvi rc setting is used to initiate the search.
Otherwise, if a pdf file exists, the forward search is performed by
using the command specified by the \forward_search_pdf rc setting.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34148 a592a061-630c-0410-9148-cb99ea01b6c8
