Re: r35666 - lyx-devel/branches/BRANCH_1_6_X/po
sanda wrote: #: lib/layouts/lettre.layout:260 -#, fuzzy msgid Office: -msgstr Vypnuto +msgstr Office:Office: one paste too much? Jürgen
Re: r35617 - lyx-devel/trunk
Pavel Sanda wrote: Juergen, can this go in? OK. Jürgen
Re: r35575 - lyx-devel/trunk/src
Am 17.10.2010 um 21:00 schrieb Stephan Witt: Am 15.10.2010 um 21:28 schrieb Stephan Witt: Am 15.10.2010 um 18:00 schrieb Pavel Sanda: Pavel Sanda wrote: this is already bug #chrrm (bugzilla is down). #6396 Ok, thanks. An attempt to attack it (together with repoUpdate implementation) is attached... Pavel, can you have a look please? If the principle way is ok I can do the same for the RCS and SVN backend too. One question regarding the View log button of repoUpdate: here on Mac the dialog to display the log is unusable. It is blocked by the next confirmation dialog. Is this platform specific or on all platforms? Stephan
[RFC] [patch] bug 6944: crash on drag and drop multiple files
http://www.lyx.org/trac/ticket/6944
I had a go on that bug, which I consider the last mustfix before an 1.6.8
release. The attached patch is against branch and fixes the crash for me.
However, I'm not sure I really understand the func queue idea, so I'd
appreciate a careful and critical review.
The idea of the patch is to only fill the queue within the loop (while
processing multiple files in a drop event), and then process the queue after
the loop was iterated. Until now, the processQueue was filled and processed
asynchronously (via a QTimer) immediately at every iteration. My impression is
that the crash was triggered by some kind of race condition triggered by this
procedure.
The second thing I did is fixing a thinko (I think). In
GuiApplication::processFuncRequestQueue(), the queue was handled from the
back(), but pop() removes elements at the front(). Therefore we need to
process the queue from the front() side (which also makes sense logically,
given that we want to handle the funcs according to the first come, first
serve principle).
Does this make sense?
Jürgen
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp (Revision 35694)
+++ src/frontends/qt4/GuiView.cpp (Arbeitskopie)
@@ -697,9 +697,10 @@
// Asynchronously post the event. DropEvent usually come
// from the BufferView. But reloading a file might close
// the BufferView from within its own event handler.
- guiApp-dispatchDelayed(cmd);
+ guiApp-addtoFuncRequestQueue(cmd);
event-accept();
}
+ guiApp-performFuncRequests();
}
Index: src/frontends/qt4/GuiApplication.cpp
===
--- src/frontends/qt4/GuiApplication.cpp (Revision 35694)
+++ src/frontends/qt4/GuiApplication.cpp (Arbeitskopie)
@@ -947,6 +947,18 @@
}
+void GuiApplication::addtoFuncRequestQueue(FuncRequest const func)
+{
+ d-func_request_queue_.push(func);
+}
+
+
+void GuiApplication::performFuncRequests()
+{
+ processFuncRequestQueue();
+}
+
+
void GuiApplication::resetGui()
{
// Set the language defined by the user.
@@ -1130,7 +1142,7 @@
void GuiApplication::processFuncRequestQueue()
{
while (!d-func_request_queue_.empty()) {
- lyx::dispatch(d-func_request_queue_.back());
+ lyx::dispatch(d-func_request_queue_.front());
d-func_request_queue_.pop();
}
}
Index: src/frontends/qt4/GuiApplication.h
===
--- src/frontends/qt4/GuiApplication.h (Revision 35694)
+++ src/frontends/qt4/GuiApplication.h (Arbeitskopie)
@@ -60,6 +60,8 @@
bool getStatus(FuncRequest const cmd, FuncStatus flag) const;
bool dispatch(FuncRequest const );
void dispatchDelayed(FuncRequest const );
+ void addtoFuncRequestQueue(FuncRequest const );
+ void performFuncRequests();
void resetGui();
void restoreGuiSession();
Clipboard clipboard();
Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files
One change that might be considered:
Jürgen Spitzmüller wrote:
Index: src/frontends/qt4/GuiApplication.cpp
===
--- src/frontends/qt4/GuiApplication.cpp(Revision 35694)
+++ src/frontends/qt4/GuiApplication.cpp(Arbeitskopie)
@@ -947,6 +947,18 @@
}
+void GuiApplication::addtoFuncRequestQueue(FuncRequest const func)
+{
+ d-func_request_queue_.push(func);
+}
+
+
+void GuiApplication::performFuncRequests()
+{
+ processFuncRequestQueue();
+}
+void GuiApplication::performFuncRequests()
+{
+ QTimer::singleShot(0, this, SLOT(processFuncRequestQueue()));
+}
in case the asynchronous process is still needed?
Jürgen
Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4
Am Sonntag, den 17.10.2010, 17:52 -0400 schrieb Richard Heck: On 10/17/2010 04:19 PM, Pavel Sanda wrote: Peter Kümmel wrote: #412: Opening the box of QProcess short before a release? I don't know if this is a good idea. We had so much problems when introducing unblocked texing, so I think we should postpone it. i thought that once we have it for viewing, it might be piece of cake to add export. if it means risking the same problems as with introducing it on view, then lets postpone it. I think it might be worth trying this. Viewing is a two step process: (i) Create the file and its friends in the temporary directory; (ii) Launch a viewer on that file. Exporting is also a two step process: (i) Create the file and its friends in the temporary directory; (ii) Copy the files to their ultimate location. I could be wrong, but it seems to me that the problems must have lay mostly at (i). But (i) is the same both times. The fix should be as easy as doing the same thing in LFUN_BUFFER_EXPORT as we do in LFUN_BUFFER_VIEW, in GuiView.cpp. Richard OK, committed a fix, but it needs testing. Peter
Things that may be appropriate to go into 2.0.x.
I had a quick look at my tree and thought I'd discuss which bits may be suitable for 2.0.x Things that seem to be ready now: Patch for Ticket #6550 LYX warns that Any Changes will be lost even when there are no changes. http://www.lyx.org/trac/attachment/ticket/6550/GuiView.patch Patch for Ticket #3934 Document xxx converted to ver 1.4 should get the filename xxx_14.lyx http://www.lyx.org/trac/attachment/ticket/3934/configure.py.patch (Note I implemented this as giving the filename xxx.14.lyx. This is perhaps cleaner as we can also think of .14.lyx being the extension; I don't recall if I also had a better reason, but it fixes the original problem and also is trivial to change.) Things I think I should clean up and submit: 1) Warning the user that they are editing an document that is externally modified. I currently feel that a simple yet adequate architecture is to check in two cases: a) When a clean buffer is marked dirty. This is the one time that a warning can prevent the need for a merge, so I think generating an IO operation is worthwhile. See: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg158338.html b) When no IO is required: we keep a cache of the isExternallyModified property that is only updated when the isExternallyModified function is called for other reasons (i.e. when the File menu is displayed). If this cached property is set to true and the document is modified, we present the warning (if we haven't presented the warning for this external modification before). Does this sound reasonable? If so should I submit (a) first or merge these into a single patch? 2) Adding File/URL buttons to citation dialog. This was fully discussed, I just need to address the existing concerns. -- John C. McCabe-Dansted P.S. if anyone is interested the things sitting in my tree that I think *shouldn't* go into 2.0.x are: * My Backtrace Helper. I think Ubuntu disabled the ability to attach gdb to arbitrary processes, so it doesn't work out-of-the-box on Ubuntu 10.10 let alone WIndows etc. There was discussion about this at: https://lists.ubuntu.com/archives/ubuntu-devel/2010-June/030939.html but none of the proposed solutions were implemented. There are ways to work around this, but I think it is best not to worry about this while this is up in the air. * Some cleanup I promised Abdel, but that ended up being trickier than I thought. I think we can leave this till 2.1.x. * My keytest stuff. This I am moving to a new home, as I have reproduced a bug in abiword with it, and so not it is not really LyX specific anymore.
Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4
OK, committed a fix, but it needs testing. Now exporting is broken: I don't get a PDF when e.g. exporting the UserGuide to PDF (pdflatex). regards Uwe
Re: r35575 - lyx-devel/trunk/src
Stephan Witt wrote: Pavel, can you have a look please? hopefully towards the end of this week. actually it would be really helpful if we can proceed in usual incremental manner - different patches for different issues, its much harder to keep your track if everything is muddled into one big patch, ie patch for CVS related stuff and fixing other bugs on the top of it. quick peek into diff - doVCCommand change looks ok (maybe call the param reportError?). why + // to be sure test readonly state again... + FileName fn(owner_-absFileName()); + fn.refresh(); + if (!fn.isReadOnly()) is not inside checkoutenabled? just fast screening, i really need to go sleep now, sorry ;) If the principle way is ok I can do the same for the RCS and SVN backend too. One question regarding the View log button of repoUpdate: here on Mac the dialog to display the log is unusable. It is blocked by the next confirmation dialog. Is this platform specific or on all platforms? no, this glitch is on all platforms (iirc resize did work, but the button was silent). i carry the idea of trying to show that dialog as nonmodal. it maybe oneliner somewhere, but i never really get to solve it... pavel
Re: r35575 - lyx-devel/trunk/src
Am 19.10.2010 um 03:34 schrieb Pavel Sanda: Stephan Witt wrote: Pavel, can you have a look please? hopefully towards the end of this week. actually it would be really helpful if we can proceed in usual incremental manner - different patches for different issues, its much harder to keep your track if everything is muddled into one big patch, ie patch for CVS related stuff and fixing other bugs on the top of it. I don't know how to do that. I have only one LyX source tree in compilable state. I'll try to make two patches out of it. quick peek into diff - doVCCommand change looks ok (maybe call the param reportError?). why + // to be sure test readonly state again... + FileName fn(owner_-absFileName()); + fn.refresh(); + if (!fn.isReadOnly()) is not inside checkoutenabled? I thought checkoutEnabled() is called too often. just fast screening, i really need to go sleep now, sorry ;) Thank you for answering me. If the principle way is ok I can do the same for the RCS and SVN backend too. One question regarding the View log button of repoUpdate: here on Mac the dialog to display the log is unusable. It is blocked by the next confirmation dialog. Is this platform specific or on all platforms? no, this glitch is on all platforms (iirc resize did work, but the button was silent). On Mac it's blocked completely. i carry the idea of trying to show that dialog as nonmodal. it maybe oneliner somewhere, but i never really get to solve it... Ok. Stephan
Re: r35666 - lyx-devel/branches/BRANCH_1_6_X/po
sanda wrote: > #: lib/layouts/lettre.layout:260 > -#, fuzzy > msgid "Office:" > -msgstr "Vypnuto" > +msgstr "Office:Office:" one paste too much? Jürgen
Re: r35617 - lyx-devel/trunk
Pavel Sanda wrote: > Juergen, can this go in? OK. Jürgen
Re: r35575 - lyx-devel/trunk/src
Am 17.10.2010 um 21:00 schrieb Stephan Witt: > Am 15.10.2010 um 21:28 schrieb Stephan Witt: > >> Am 15.10.2010 um 18:00 schrieb Pavel Sanda: >> >>> Pavel Sanda wrote: this is already bug #chrrm (bugzilla is down). >>> >>> #6396 >> >> Ok, thanks. > > An attempt to attack it (together with repoUpdate implementation) is > attached... Pavel, can you have a look please? If the principle way is ok I can do the same for the RCS and SVN backend too. One question regarding the "View log" button of repoUpdate: here on Mac the dialog to display the log is unusable. It is blocked by the next confirmation dialog. Is this platform specific or on all platforms? Stephan
[RFC] [patch] bug 6944: crash on drag and drop multiple files
http://www.lyx.org/trac/ticket/6944
I had a go on that bug, which I consider the last mustfix before an 1.6.8
release. The attached patch is against branch and fixes the crash for me.
However, I'm not sure I really understand the func queue idea, so I'd
appreciate a careful and critical review.
The idea of the patch is to only fill the queue within the loop (while
processing multiple files in a drop event), and then process the queue after
the loop was iterated. Until now, the processQueue was filled and processed
asynchronously (via a QTimer) immediately at every iteration. My impression is
that the crash was triggered by some kind of race condition triggered by this
procedure.
The second thing I did is fixing a thinko (I think). In
GuiApplication::processFuncRequestQueue(), the queue was handled from the
back(), but pop() removes elements at the front(). Therefore we need to
process the queue from the front() side (which also makes sense logically,
given that we want to handle the funcs according to the "first come, first
serve" principle).
Does this make sense?
Jürgen
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp (Revision 35694)
+++ src/frontends/qt4/GuiView.cpp (Arbeitskopie)
@@ -697,9 +697,10 @@
// Asynchronously post the event. DropEvent usually come
// from the BufferView. But reloading a file might close
// the BufferView from within its own event handler.
- guiApp->dispatchDelayed(cmd);
+ guiApp->addtoFuncRequestQueue(cmd);
event->accept();
}
+ guiApp->performFuncRequests();
}
Index: src/frontends/qt4/GuiApplication.cpp
===
--- src/frontends/qt4/GuiApplication.cpp (Revision 35694)
+++ src/frontends/qt4/GuiApplication.cpp (Arbeitskopie)
@@ -947,6 +947,18 @@
}
+void GuiApplication::addtoFuncRequestQueue(FuncRequest const & func)
+{
+ d->func_request_queue_.push(func);
+}
+
+
+void GuiApplication::performFuncRequests()
+{
+ processFuncRequestQueue();
+}
+
+
void GuiApplication::resetGui()
{
// Set the language defined by the user.
@@ -1130,7 +1142,7 @@
void GuiApplication::processFuncRequestQueue()
{
while (!d->func_request_queue_.empty()) {
- lyx::dispatch(d->func_request_queue_.back());
+ lyx::dispatch(d->func_request_queue_.front());
d->func_request_queue_.pop();
}
}
Index: src/frontends/qt4/GuiApplication.h
===
--- src/frontends/qt4/GuiApplication.h (Revision 35694)
+++ src/frontends/qt4/GuiApplication.h (Arbeitskopie)
@@ -60,6 +60,8 @@
bool getStatus(FuncRequest const & cmd, FuncStatus & flag) const;
bool dispatch(FuncRequest const &);
void dispatchDelayed(FuncRequest const &);
+ void addtoFuncRequestQueue(FuncRequest const &);
+ void performFuncRequests();
void resetGui();
void restoreGuiSession();
Clipboard & clipboard();
Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files
One change that might be considered:
Jürgen Spitzmüller wrote:
> Index: src/frontends/qt4/GuiApplication.cpp
> ===
> --- src/frontends/qt4/GuiApplication.cpp(Revision 35694)
> +++ src/frontends/qt4/GuiApplication.cpp(Arbeitskopie)
> @@ -947,6 +947,18 @@
> }
>
>
> +void GuiApplication::addtoFuncRequestQueue(FuncRequest const & func)
> +{
> + d->func_request_queue_.push(func);
> +}
> +
> +
> +void GuiApplication::performFuncRequests()
> +{
> + processFuncRequestQueue();
> +}
+void GuiApplication::performFuncRequests()
+{
+ QTimer::singleShot(0, this, SLOT(processFuncRequestQueue()));
+}
in case the asynchronous process is still needed?
Jürgen
Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4
Am Sonntag, den 17.10.2010, 17:52 -0400 schrieb Richard Heck: > On 10/17/2010 04:19 PM, Pavel Sanda wrote: > > Peter Kümmel wrote: > > > >> #412: Opening the box of QProcess short before a release? > >> I don't know if this is a good idea. We had so much problems > >> when introducing unblocked texing, so I think we should > >> postpone it. > >> > > i thought that once we have it for viewing, it might be piece of cake > > to add export. if it means risking the same problems as with > > introducing it on view, then lets postpone it. > > > > > I think it might be worth trying this. > > Viewing is a two step process: > > (i) Create the file and its friends in the temporary directory; > (ii) Launch a viewer on that file. > > Exporting is also a two step process: > > (i) Create the file and its friends in the temporary directory; > (ii) Copy the files to their ultimate location. > > I could be wrong, but it seems to me that the problems must have lay > mostly at (i). But (i) is the same both times. > > The fix should be as easy as doing the same thing in LFUN_BUFFER_EXPORT > as we do in LFUN_BUFFER_VIEW, in GuiView.cpp. > > Richard > OK, committed a fix, but it needs testing. Peter
Things that may be appropriate to go into 2.0.x.
I had a quick look at my tree and thought I'd discuss which bits may be suitable for 2.0.x Things that seem to be ready now: Patch for Ticket #6550 LYX warns that "Any Changes will be lost" even when there are no changes. http://www.lyx.org/trac/attachment/ticket/6550/GuiView.patch Patch for Ticket #3934 Document xxx converted to ver 1.4 should get the filename xxx_14.lyx http://www.lyx.org/trac/attachment/ticket/3934/configure.py.patch (Note I implemented this as giving the filename xxx.14.lyx. This is perhaps cleaner as we can also think of .14.lyx being the extension; I don't recall if I also had a better reason, but it fixes the original problem and also is trivial to change.) Things I think I should clean up and submit: 1) Warning the user that they are editing an document that is externally modified. I currently feel that a simple yet adequate architecture is to check in two cases: a) When a clean buffer is marked dirty. This is the one time that a warning can prevent the need for a merge, so I think generating an IO operation is worthwhile. See: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg158338.html b) When no IO is required: we keep a cache of the isExternallyModified property that is only updated when the isExternallyModified function is called for other reasons (i.e. when the File menu is displayed). If this cached property is set to "true" and the document is modified, we present the warning (if we haven't presented the warning for this external modification before). Does this sound reasonable? If so should I submit (a) first or merge these into a single patch? 2) Adding File/URL buttons to citation dialog. This was fully discussed, I just need to address the existing concerns. -- John C. McCabe-Dansted P.S. if anyone is interested the things sitting in my tree that I think *shouldn't* go into 2.0.x are: * My Backtrace Helper. I think Ubuntu disabled the ability to attach gdb to arbitrary processes, so it doesn't work out-of-the-box on Ubuntu 10.10 let alone WIndows etc. There was discussion about this at: https://lists.ubuntu.com/archives/ubuntu-devel/2010-June/030939.html but none of the proposed solutions were implemented. There are ways to work around this, but I think it is best not to worry about this while this is up in the air. * Some cleanup I promised Abdel, but that ended up being trickier than I thought. I think we can leave this till 2.1.x. * My keytest stuff. This I am moving to a new home, as I have reproduced a bug in abiword with it, and so not it is not really LyX specific anymore.
Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4
> OK, committed a fix, but it needs testing. Now exporting is broken: I don't get a PDF when e.g. exporting the UserGuide to PDF (pdflatex). regards Uwe
Re: r35575 - lyx-devel/trunk/src
Stephan Witt wrote: > Pavel, can you have a look please? hopefully towards the end of this week. actually it would be really helpful if we can proceed in usual incremental manner - different patches for different issues, its much harder to keep your track if everything is muddled into one big patch, ie patch for CVS related stuff and fixing other bugs on the top of it. quick peek into diff - doVCCommand change looks ok (maybe call the param reportError?). why + // to be sure test readonly state again... + FileName fn(owner_->absFileName()); + fn.refresh(); + if (!fn.isReadOnly()) is not inside checkoutenabled? just fast screening, i really need to go sleep now, sorry ;) > If the principle way is ok I can do the same for the RCS and SVN backend too. > > One question regarding the "View log" button of repoUpdate: > here on Mac the dialog to display the log is unusable. > It is blocked by the next confirmation dialog. > Is this platform specific or on all platforms? no, this glitch is on all platforms (iirc resize did work, but the button was silent). i carry the idea of trying to show that dialog as nonmodal. it maybe oneliner somewhere, but i never really get to solve it... pavel
Re: r35575 - lyx-devel/trunk/src
Am 19.10.2010 um 03:34 schrieb Pavel Sanda: > Stephan Witt wrote: >> Pavel, can you have a look please? > > hopefully towards the end of this week. actually it would be really helpful > if we can proceed in usual incremental manner - different patches for > different > issues, its much harder to keep your track if everything is muddled into > one big patch, ie patch for CVS related stuff and fixing other bugs on the > top of it. I don't know how to do that. I have only one LyX source tree in compilable state. I'll try to make two patches out of it. > > quick peek into diff - doVCCommand change looks ok (maybe call the param > reportError?). > why > + // to be sure test readonly state again... > > > + FileName fn(owner_->absFileName()); > > > + fn.refresh(); > > > + if (!fn.isReadOnly()) > is not inside checkoutenabled? I thought checkoutEnabled() is called too often. > > just fast screening, i really need to go sleep now, sorry ;) Thank you for answering me. >> If the principle way is ok I can do the same for the RCS and SVN backend too. >> >> One question regarding the "View log" button of repoUpdate: >> here on Mac the dialog to display the log is unusable. >> It is blocked by the next confirmation dialog. >> Is this platform specific or on all platforms? > > no, this glitch is on all platforms (iirc resize did work, but the button was > silent). On Mac it's blocked completely. > i carry the idea of trying to show that dialog as nonmodal. it maybe > oneliner somewhere, but i never really get to solve it... Ok. Stephan
