Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Guenter Milde]

On 2010-10-21, Vincent van Ravesteijn wrote:

  but now we have new problem - how to notice user that exporting is stillbr=
  in progress or finished (some subvserion of hourglass cursor?).br

 Status bar: Moving icons. Text. Messages.

greyed out (or otherwise modified) export toolbar buttons?

Günter

Re: r35575 - lyx-devel/trunk/src

[Stephan Witt]

Am 22.10.2010 um 01:07 schrieb Pavel Sanda:

 Stephan Witt wrote:
 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.
 
 i tried hopeless experiment to set the log window modal for this usecases
 but it does not work. dispatch returns from show-dialog lfun and does not
 wait for completion and i guess it would need deeper surgery or completely
 new dialog to arrange this.

A new dialog similar to display the VC log...

 maybe there is another way how to trigger the dialog which would wait,
 but my curiousity is exhausted now ;)

I had the same idea already. Luckily I didn't try it.
The other idea I had was the special dialog combining the buttons and the
presentation of the diff.

Stephan

PS. I'll answer your other mail later. Thanks for it already.

Re: r35769 - in lyx-devel/trunk/lib: . scripts

[Jean-Marc Lasgouttes]

Le 22/10/2010 02:10, uwesto...@lyx.org a écrit :

Log:
- lyxsweave.R: set missing SVN EOL style and add missing makefile entry

- lib/Makefile.am: add missing scripts


Thanks, Uwe.

JMarc

Re: #6710: table dialog broken

[Abdelrazak Younes]

On 10/22/2010 03:25 AM, LyX Ticket Tracker wrote:

#6710: table dialog broken
--+-
  Reporter:  uwestoehr |Owner:  nob...@…
  Type:  defect|   Status:  closed
  Priority:  high  |Milestone:  2.0.0
Component:  frontend-qt4  |  Version:  2.0.0svn
  Severity:  major |   Resolution:  fixed
  Keywords:  regression|
--+-
Changes (by uwestoehr):

   * status:  new =  closed
   * resolution:  =  fixed


Comment:

This is certainly possible and it make sense indeed.

  Thanks for fixing this in r35747. -  Marking as FIXED.

For the second point (its content is also not refreshed) this is by
  design, you
have to check the Immediate Apply button if you want it to be
  automatically
refreshed.

  Ah, I didn't know that one needs to set this option to get LyX's 1.6.x's
  behaviour. I'll document this.
  But shouldn't we enable this option by default?


AFAIU Most other devs don't like the synchronous behavior. But we should 
save the checkbox status in the session settings... I'll try do that 
when I have some time.



  Without this option
  working with tables is a nightmare as you have to open/close the dialog
  permanently.
   


Why that? You can click on the [Restore] button after changing the 
cursor position; no need to leave the dialog. If you are going to 
document this (thanks by the way) please note that the asynchronous mode 
is useful when you want to apply a same config to multiple table cell. 
You just have to change the cursor position and hit [Apply]; you can do 
this multiple time for many table cell.


Abdel.

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Jürgen Spitzmüller]

Pavel Sanda wrote:
 this thinko-part smells like trunk stuff unless it really fixes something.

It really fixes something. If you drop file a.tex and b.tex onto LyX, current 
LyX tries to import a.tex twice, and b.tex not at all. The fix assures that 
both a.tex and b.tex are imported (and only once). 

Jürgen

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Vincent van Ravesteijn]

 // 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();

One remark: I refactored the buffer reloading, so I don't think it is
still true that a BufferView can close itself now on reloading.

Vincent

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Jürgen Spitzmüller]

Vincent van Ravesteijn wrote:
  // 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();
 
 One remark: I refactored the buffer reloading, so I don't think it is
 still true that a BufferView can close itself now on reloading.

So you think I can just ditch the comment? (Actually, it's also not posted 
asynchronously anymore, unless I do my second proposed change).

Jürgen

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Vincent van Ravesteijn]

 One remark: I refactored the buffer reloading, so I don't think it is
 still true that a BufferView can close itself now on reloading.

 So you think I can just ditch the comment? (Actually, it's also not posted
 asynchronously anymore, unless I do my second proposed change).

 Jürgen


I think you can. However, I can't judge right now whether it's better
to do it asynchronously or not. So, it might be that we should still
do it asynchronously, but the reasoning stated in the comment is not
valid anymore.

Vincent

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Guenter Milde wrote:
  Status bar: Moving icons. Text. Messages.
 
 greyed out (or otherwise modified) export toolbar buttons?

wont help in case you use only menu.
pavel

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Jürgen Spitzmüller]

Vincent van Ravesteijn wrote:
 I think you can. However, I can't judge right now whether it's better
 to do it asynchronously or not. So, it might be that we should still
 do it asynchronously, but the reasoning stated in the comment is not
 valid anymore.

I propose the following patch (diff against trunk). I moved the comment to the 
actual function, so we know at least why the asynchronous call was introduced.

I propose to commit this to trunk and later, if no problems arise, to branch.

OK?

Jürgen
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp	(Revision 35775)
+++ src/frontends/qt4/GuiView.cpp	(Arbeitskopie)
@@ -794,13 +794,10 @@
 No formats found, trying to open it as a lyx file);
 			cmd = FuncRequest(LFUN_FILE_OPEN, file);
 		}
-
-		// Asynchronously post the event. DropEvent usually comes
-		// 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 35775)
+++ src/frontends/qt4/GuiApplication.cpp	(Arbeitskopie)
@@ -1788,6 +1788,20 @@
 void GuiApplication::dispatchDelayed(FuncRequest const  func)
 {
 	d-func_request_queue_.push(func);
+	performFuncRequests();
+}
+
+
+void GuiApplication::addtoFuncRequestQueue(FuncRequest const  func)
+{
+	d-func_request_queue_.push(func);
+}
+
+
+void GuiApplication::performFuncRequests()
+{
+	// We perform the events asynchronously. This prevents potential
+	// problems in case the BufferView is closed within an event.
 	QTimer::singleShot(0, this, SLOT(processFuncRequestQueue()));
 }
 
@@ -1976,7 +1990,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 35775)
+++ src/frontends/qt4/GuiApplication.h	(Arbeitskopie)
@@ -61,6 +61,8 @@
 	void dispatch(FuncRequest const , DispatchResult  dr);
 	FuncStatus getStatus(FuncRequest const  cmd) const;
 	void dispatchDelayed(FuncRequest const );
+	void addtoFuncRequestQueue(FuncRequest const );
+	void performFuncRequests();
 	void restoreGuiSession();
 	Clipboard  clipboard();
 	Selection  selection();

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Vincent van Ravesteijn]

On Fri, Oct 22, 2010 at 1:03 PM, Jürgen Spitzmüller sp...@lyx.org wrote:
 Vincent van Ravesteijn wrote:
 I think you can. However, I can't judge right now whether it's better
 to do it asynchronously or not. So, it might be that we should still
 do it asynchronously, but the reasoning stated in the comment is not
 valid anymore.

 I propose the following patch (diff against trunk). I moved the comment to the
 actual function, so we know at least why the asynchronous call was introduced.

 I propose to commit this to trunk and later, if no problems arise, to branch.

 OK?

 Jürgen


It's fine with me.

Only three nitpicks:

- There will be some point in time that I will start wondering what
the difference is between processing the queue and performing the
requests. Then I'll find out that they do the same thing but that the
only difference is that performing means it's done asynchronously.
That's why I would prefer to call the function
processFuncRequestQueueAsynchronously() or some abbreviated form.

- You add the two function declarations to GuiApplication.h in the
section with the description Methods inherited from Application, but
these function are not inherited. Maybe they should be declared in
Application.h as well. (I still want to make a guiless LyX in some
point of time).
There are more functions not located appropriately, but well, don't
mess it up more than necessary.

- Please add some description to these function declarations.

Vincent

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Jürgen Spitzmüller]

Vincent van Ravesteijn wrote:
 Only three nitpicks:
 
 - There will be some point in time that I will start wondering what
 the difference is between processing the queue and performing the
 requests. Then I'll find out that they do the same thing but that the
 only difference is that performing means it's done asynchronously.
 That's why I would prefer to call the function
 processFuncRequestQueueAsynchronously() or some abbreviated form.

OK

 - You add the two function declarations to GuiApplication.h in the
 section with the description Methods inherited from Application, but
 these function are not inherited. Maybe they should be declared in
 Application.h as well. (I still want to make a guiless LyX in some
 point of time).
 There are more functions not located appropriately, but well, don't
 mess it up more than necessary.

It turns out that dispatchDelayed is also not inherited. I moved the functions 
to another place in the header and made dispatchDelayed a private function, 
since it's not only used in GuiApplication itself.

 - Please add some description to these function declarations.

Done

Jürgen
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp	(Revision 35775)
+++ src/frontends/qt4/GuiView.cpp	(Arbeitskopie)
@@ -794,13 +794,12 @@
 No formats found, trying to open it as a lyx file);
 			cmd = FuncRequest(LFUN_FILE_OPEN, file);
 		}
-
-		// Asynchronously post the event. DropEvent usually comes
-		// from the BufferView. But reloading a file might close
-		// the BufferView from within its own event handler.
-		guiApp-dispatchDelayed(cmd);
+		// add the functions to the queue
+		guiApp-addtoFuncRequestQueue(cmd);
 		event-accept();
 	}
+	// now process the collected functions
+	guiApp-processFuncRequestQueueAsync();
 }
 
 
Index: src/frontends/qt4/GuiApplication.cpp
===
--- src/frontends/qt4/GuiApplication.cpp	(Revision 35775)
+++ src/frontends/qt4/GuiApplication.cpp	(Arbeitskopie)
@@ -1787,7 +1787,21 @@
 
 void GuiApplication::dispatchDelayed(FuncRequest const  func)
 {
+	addtoFuncRequestQueue(func);
+	processFuncRequestQueueAsync();
+}
+
+
+void GuiApplication::addtoFuncRequestQueue(FuncRequest const  func)
+{
 	d-func_request_queue_.push(func);
+}
+
+
+void GuiApplication::processFuncRequestQueueAsync()
+{
+	// We perform the events asynchronously. This prevents potential
+	// problems in case the BufferView is closed within an event.
 	QTimer::singleShot(0, this, SLOT(processFuncRequestQueue()));
 }
 
@@ -1976,7 +1990,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 35775)
+++ src/frontends/qt4/GuiApplication.h	(Arbeitskopie)
@@ -60,7 +60,6 @@
 	void dispatch(FuncRequest const );
 	void dispatch(FuncRequest const , DispatchResult  dr);
 	FuncStatus getStatus(FuncRequest const  cmd) const;
-	void dispatchDelayed(FuncRequest const );
 	void restoreGuiSession();
 	Clipboard  clipboard();
 	Selection  selection();
@@ -136,6 +135,11 @@
 	/// return the status bar state string
 	docstring viewStatusMessage();
 
+	/// add a func request to the queue for later procession
+	void addtoFuncRequestQueue(FuncRequest const );
+	/// process the func request in the queue asynchronously
+	void processFuncRequestQueueAsync();
+
 	/// goto a bookmark
 	/// openFile: whether or not open a file if the file is not opened
 	/// switchToBuffer: whether or not switch to buffer if the buffer is
@@ -164,6 +168,8 @@
 	void setGuiLanguage();
 	///
 	void reconfigure(std::string const  option);
+	/// add a func request to the queue and process it asynchronously
+	void dispatchDelayed(FuncRequest const );
 
 	/// This GuiView is the one receiving Clipboard and Selection
 	/// events

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Jürgen Spitzmüller]

Jürgen Spitzmüller wrote:
 since it's not only used in GuiApplication itself.

not  now

Jürgen

Re: r35765 - lyx-devel/branches/BRANCH_1_6_X

[Pavel Sanda]

sa...@lyx.org wrote:
 Author: sanda
 Date: Fri Oct 22 01:10:02 2010
 New Revision: 35765
 URL: http://www.lyx.org/trac/changeset/35765
 
 Log:
 Allow newer autoconf
 
 Modified:
lyx-devel/branches/BRANCH_1_6_X/autogen.sh
lyx-devel/branches/BRANCH_1_6_X/status.16x
 
 Modified: lyx-devel/branches/BRANCH_1_6_X/autogen.sh
 ==
 --- lyx-devel/branches/BRANCH_1_6_X/autogen.shFri Oct 22 00:04:06 
 2010(r35764)
 +++ lyx-devel/branches/BRANCH_1_6_X/autogen.shFri Oct 22 01:10:02 
 2010(r35765)
 @@ -38,11 +38,11 @@
  
  
  case $autoversion in
 -*' '2.59[cd]|*' '2.60[ab]|*' '2.6[0-57])
 +*' '2.59[cd]|*' '2.60[ab]|*' '2.6[0-578])
   ;;
  *)
   echo This autoconf version is not supported by LyX.
 - echo LyX only supports autoconf 2.59c-2.65, 2.67.
 + echo LyX only supports autoconf 2.59c-2.65, 2.67 and 2.68.
   exit 1
   ;;
  esac
 
 Modified: lyx-devel/branches/BRANCH_1_6_X/status.16x
 ==
 --- lyx-devel/branches/BRANCH_1_6_X/status.16xFri Oct 22 00:04:06 
 2010(r35764)
 +++ lyx-devel/branches/BRANCH_1_6_X/status.16xFri Oct 22 01:10:02 
 2010(r35765)
 @@ -83,7 +83,7 @@
  
  * BUILD/INSTALLATION
  
 -- Allow autoconf 2.67.
 +- Allow autoconf 2.67 and 2.68.

hum, i was too fast here:
configure.ac:155: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in 
body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
config/libtool.m4:363: _LT_AC_SYS_LIBPATH_AIX is expanded from...
config/libtool.m4:5560: AC_LIBTOOL_PROG_LD_SHLIBS is expanded from...
config/libtool.m4:2783: _LT_AC_LANG_C_CONFIG is expanded from...
config/libtool.m4:2782: AC_LIBTOOL_LANG_C_CONFIG is expanded from...
config/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from...
config/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from...
config/libtool.m4:25: AC_PROG_LIBTOOL is expanded from...
config/lyxinclude.m4:674: LYX_PROG_LIBTOOL is expanded from...
configure.ac:155: the top level


trunk does not show this behaviour. JMarc, do you have idea?

pavel

Re: r35765 - lyx-devel/branches/BRANCH_1_6_X

[Jean-Marc Lasgouttes]

Le 22/10/2010 14:21, Pavel Sanda a écrit :

trunk does not show this behaviour. JMarc, do you have idea?


Branch uses libtool, trunk does not. I fear that using recent autoconf 
means switching to libtool 2. See for example this mail:

  http://www.spinics.net/lists/ac/msg10004.html

Re: r35575 - lyx-devel/trunk/src

[Stephan Witt]

Am 22.10.2010 um 02:11 schrieb Pavel Sanda:

 Stephan Witt wrote:
 I made a new patch to implement getDiff() and use it to avoid the query for 
 log message
 before checkIn() is done and the confirmation on revert when no diff is 
 found.
 
 thanks for your patience, i went closely through the patch now and generally 
 liked the approach.
 
 +FileName const CVS::getDiff(OperationMode opmode)
 +{
 +FileName tmpf = FileName::tempName(lyxvcout);
 +if (tmpf.empty()) {
 +LYXERR(Debug::LYXVC, Could not generate logfile   tmpf);
 +return tmpf;
 +}
 +
 +doVCCommand(cvs diff  + getTarget(opmode)
 +++ quoteName(tmpf.toFilesystemEncoding()),
 +FileName(owner_-filePath()), false);
 +return tmpf;
 +}
 
 the error case is suspicious. if tempName fails or cvs diff fails how you 
 detect
 this on a higher stage? cmiiw but if something fails you identify it with 
 having
 empty diff, which looks wrong, even more if you release lock automatically in 
 such
 a case...

Your right. I'll try to come up with a better solution.
BTW, I copied the tmpf allocation code sequence.
I think the debug message does not need to print the empty tmpf.

But I've found another way to solve the same goal - using cvs status.
Checking for the diff is not good enough.

While doing some stress test with checkIn() I found the error message when 
merge is needed
Something's wrong with cvs commit not acceptable. Then I tried to change that 
and failed to
solve it because of the stderr output of the VC command is lost silently. So I 
came to the
idea to implement getStatus() and use the result accordingly.

The result would be one out of
* uptodate
* locally modified
* needs checkout
* needs merge
* no cvs file

The checkInWithMessage() implementation would be then
{ return getStatus() == LocallyModified; }
And the checkIn() would do a switch on the getStatus() and
raise more descriptive error messages according the status.

 
 +int CVS::update(OperationMode opmode, FileName const tmpf)
 
 unless you want to mix this with repoupdate why is opmode here?

Yes. That's the plan.

 +// should a log message provided for next checkin?
 +virtual bool checkInWithMessage() { return true; }
 
 +// should a confirmation before revert requested?
 +virtual bool revertWithConfirmation() { return true; }
 
 i would change naming, so its clear what the function really does.
 for example isCheckinWithConfirmation...

Ok.

 
 private:
  support::FileName file_;
  // revision number from scanMaster
  std::string version_;
  /// The user currently keeping the lock on the VC file.
  std::string locker_;
 +
 +virtual std::string const getTarget(OperationMode opmode);
 +virtual support::FileName const getDiff(OperationMode opmode);
 +virtual int edit();
 +virtual int unedit();
 +virtual int update(OperationMode opmode, support::FileName const tmpf);
 +virtual bool const hasDiff(OperationMode opmode);
 +virtual bool const hasDiff() { return hasDiff(File); }
 };
 
 comments missing

Ok.

 
 --- src/LyXVC.cpp(Revision 35732)
 +++ src/LyXVC.cpp(Arbeitskopie)
 @@ -163,9 +163,10 @@
  docstring empty(_((no log message)));
  docstring response;
  string log;
 -bool ok = Alert::askForText(response, _(LyX VC: Log Message));
 +bool dolog = vcs-checkInWithMessage();
 +bool ok = !dolog || Alert::askForText(response, _(LyX VC: Log 
 Message));
 
 hmm, but if !dolog then user automatically gets cancel message?

You mean the user should have the option to cancel the operation if the file is 
up-to-date?
Seems reasonable.

 
  if (ok) {
 -if (response.empty())
 +if (dolog  response.empty())
  response = empty;
 
 why response=empty harms in !nodolog?

It doesn't harm. It wastes CPU cycles to set response when !nodolog.

 
 @@ -212,8 +213,9 @@
  docstring text = bformat(_(Reverting to the stored version of the 
  document %1$s will lose all current 
 changes.\n\n
  Do you want to revert to the older version?), 
 file);
 -int const ret = Alert::prompt(_(Revert to stored version of 
 document?),
 -text, 0, 1, _(Revert), _(Cancel));
 +bool const doask = vcs-revertWithConfirmation();
 
 i would need to check whats above this function in guiview but isn't possible 
 that we will skip
 reverting in case the document is edited but not saved?

Yes, so it is. Then reverting should be guarded with revertEnabled() too?

 
 +int const ret = doask ? Alert::prompt(_(Revert to stored version of 
 document?),
 +text, 0, 1, _(Revert), _(Cancel)) : 0;
 
 correspondingly to your previous coding style one would expect ret = doask  
 prompt ;  ;)

I don't think so. The first is bool and the second is int.
But I can change the style to be more verbose if you like.
E. g.

if 

Re: r35765 - lyx-devel/branches/BRANCH_1_6_X

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 Branch uses libtool, trunk does not. I fear that using recent autoconf 
 means switching to libtool 2. See for example this mail:
   http://www.spinics.net/lists/ac/msg10004.html

ok, so i'll revert this patch.
pavel

Re: r35765 - lyx-devel/branches/BRANCH_1_6_X

[Stephan Witt]

Am 22.10.2010 um 14:53 schrieb Jean-Marc Lasgouttes:

 Le 22/10/2010 14:21, Pavel Sanda a écrit :
 trunk does not show this behaviour. JMarc, do you have idea?
 
 Branch uses libtool, trunk does not. I fear that using recent autoconf means 
 switching to libtool 2. See for example this mail:
  http://www.spinics.net/lists/ac/msg10004.html

So you suggest one should use libtool from macports on mac?

Stephan

Re: r35767 - lyx-devel/trunk/lib/doc

[Richard Heck]

On 10/21/2010 07:50 PM, Pavel Sanda wrote:

sa...@lyx.org wrote:
   

Author: sanda
Date: Fri Oct 22 01:34:22 2010
New Revision: 35767
URL: http://www.lyx.org/trac/changeset/35767

Log:
(no log message)

Modified:
lyx-devel/trunk/lib/doc/Additional.lyx
 

i looked why lyx ignored my message and it looks that
Alert::askForText(response, _(LyX VC: Log Message));
does not return messages anymore in trunk.

   
For how long? Could be a consequence of recent changes to asynchronous 
Alert::*.


rh

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/21/2010 07:17 PM, Vincent van Ravesteijn wrote:


Status bar: Moving icons. Text. Messages.

Op 22 okt 2010 01:13 schreef Pavel Sanda sa...@lyx.org 
mailto:sa...@lyx.org:


Richard Heck wrote:
 On 10/20/2010 08:59 PM, Peter Kümmel wrote:
 Am Dienstag, den 19.10.2010, 20...

i checked that export works on simple document here too.
but now we have new problem - how to notice user that exporting is still
in progress or finished (some subvserion of hourglass cursor?).


Along these same lines, I wonder if we should pop up an info box when
the export is done. If it takes a while, then the user may not notice the
status message, and those get over-written quickly, anyway.

In a way, that would solve this issue: It's still going until you get 
told that

it's not.

Richard

Re: r35575 - lyx-devel/trunk/src

[Stephan Witt]

Am 22.10.2010 um 15:28 schrieb Stephan Witt:

 Am 22.10.2010 um 02:11 schrieb Pavel Sanda:
 
 Stephan Witt wrote:
 
 @@ -212,8 +213,9 @@
 docstring text = bformat(_(Reverting to the stored version of the 
 document %1$s will lose all current 
 changes.\n\n
 Do you want to revert to the older version?), 
 file);
 -   int const ret = Alert::prompt(_(Revert to stored version of 
 document?),
 -   text, 0, 1, _(Revert), _(Cancel));
 +   bool const doask = vcs-revertWithConfirmation();
 
 i would need to check whats above this function in guiview but isn't 
 possible that we will skip
 reverting in case the document is edited but not saved?
 
 Yes, so it is. Then reverting should be guarded with revertEnabled() too?

The simpler solution would be to check owner_-isClean() in 
CVS::revertWithConfirmation()...

Stephan

New thread offshoot ( Re: r35767 - lyx-devel/trunk/lib/doc )

[Pavel Sanda]

Richard Heck wrote:
 On 10/21/2010 07:50 PM, Pavel Sanda wrote:
 sa...@lyx.org wrote:

 Author: sanda
 Date: Fri Oct 22 01:34:22 2010
 New Revision: 35767
 URL: http://www.lyx.org/trac/changeset/35767

 Log:
 (no log message)

 Modified:
 lyx-devel/trunk/lib/doc/Additional.lyx
  
 i looked why lyx ignored my message and it looks that
 Alert::askForText(response, _(LyX VC: Log Message));
 does not return messages anymore in trunk.


 For how long? Could be a consequence of recent changes to asynchronous 
 Alert::*.

git bisect shows its somewhere around 35734-35742 which are almost all Peter's
commits. direct one is difficult obtain since it won't build due to the mess in 
makefiles...

i wonder why Alert:: code is affected when no preview or export is done?

pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Richard Heck wrote:
 Along these same lines, I wonder if we should pop up an info box when
 the export is done. If it takes a while, then the user may not notice the
 status message, and those get over-written quickly, anyway.

 In a way, that would solve this issue: It's still going until you get told 
 that
 it's not.

previously we had to wait some time for generation now we will spend it via
mouse haunting of ok button :) why can't we have the normal mouse cursor
with small hourglass cursor as windows have when something goes in background?

pavel

Re: r35575 - lyx-devel/trunk/src

[Stephan Witt]

Am 22.10.2010 um 15:28 schrieb Stephan Witt:

 Am 22.10.2010 um 02:11 schrieb Pavel Sanda:
 
 Stephan Witt wrote:
 While doing some stress test with checkIn() I found the error message when 
 merge is needed
 Something's wrong with cvs commit not acceptable. Then I tried to change 
 that and failed to
 solve it because of the stderr output of the VC command is lost silently. So 
 I came to the
 idea to implement getStatus() and use the result accordingly.
 
 The result would be one out of
 * uptodate
 * locally modified
 * needs checkout
 * needs merge
 * no cvs file
 
 The checkInWithMessage() implementation would be then
 { return getStatus() == LocallyModified; }
 And the checkIn() would do a switch on the getStatus() and
 raise more descriptive error messages according the status.

Unfortunately this doesn't solve all possible cases.
If the checkout is not the head version you cannot commit any changes.
But the cvs status output isn't aware of that - it's locally modified only.
In this case the error message of the commit is needed to tell the user what 
happened.
Hmm, isn't it possible to get both stdout and stderr from doVCcommandCall() 
into some result?

 
 But I can change the style to be more verbose if you like.
 E. g.
 
   if (vcs-checkInWithMessage()) {
   log = vcs-checkIn(to_utf8(empty));
   // Reserve empty string for cancel button
   if (log.empty())
   log = to_utf8(empty);
   } else if (Alert::askForText(response, _(LyX VC: Log Message))) {
   if (response.empty())
   response = empty;
   log = vcs-checkIn(to_utf8(response));
   // Reserve empty string for cancel button
   if (log.empty())
   log = to_utf8(empty);
   } else {
   LYXERR(Debug::LYXVC, LyXVC: user cancelled);
   }

Sorry, I meant if (!vcs-checkInWithMessage()) { ...

Stephan

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Edwin Leuven]

i suppose for the same reason that we cannot have a pointing finger
when the mouse hovers something clickable...

On 2010-10-22, Pavel Sanda sa...@lyx.org wrote:
 Richard Heck wrote:
 Along these same lines, I wonder if we should pop up an info box when
 the export is done. If it takes a while, then the user may not notice the
 status message, and those get over-written quickly, anyway.

 In a way, that would solve this issue: It's still going until you get told

 that
 it's not.

 previously we had to wait some time for generation now we will spend it via
 mouse haunting of ok button :) why can't we have the normal mouse cursor
 with small hourglass cursor as windows have when something goes in
 background?

 pavel



-- 
http://leuven.economists.nl

Re: r35575 - lyx-devel/trunk/src

[Pavel Sanda]

Stephan Witt wrote:
  the error case is suspicious. if tempName fails or cvs diff fails how you 
  detect
  this on a higher stage? cmiiw but if something fails you identify it with 
  having
  empty diff, which looks wrong, even more if you release lock automatically 
  in such
  a case...
 
 Your right. I'll try to come up with a better solution.
 BTW, I copied the tmpf allocation code sequence.
 I think the debug message does not need to print the empty tmpf.
 
 But I've found another way to solve the same goal - using cvs status.
 Checking for the diff is not good enough.
 
 While doing some stress test with checkIn() I found the error message when 
 merge is needed
 Something's wrong with cvs commit not acceptable. Then I tried to change 
 that and failed to
 solve it because of the stderr output of the VC command is lost silently. So 
 I came to the
 idea to implement getStatus() and use the result accordingly.
 
 The result would be one out of
 * uptodate
 * locally modified
 * needs checkout
 * needs merge
 * no cvs file
 
 The checkInWithMessage() implementation would be then
 { return getStatus() == LocallyModified; }
 And the checkIn() would do a switch on the getStatus() and
 raise more descriptive error messages according the status.

sorry is starts to go beyond my head, cf end of the mail...

  --- src/LyXVC.cpp  (Revision 35732)
  +++ src/LyXVC.cpp  (Arbeitskopie)
  @@ -163,9 +163,10 @@
 docstring empty(_((no log message)));
 docstring response;
 string log;
  -  bool ok = Alert::askForText(response, _(LyX VC: Log Message));
  +  bool dolog = vcs-checkInWithMessage();
  +  bool ok = !dolog || Alert::askForText(response, _(LyX VC: Log 
  Message));
  
  hmm, but if !dolog then user automatically gets cancel message?
 
 You mean the user should have the option to cancel the operation if the file 
 is up-to-date?
 Seems reasonable.

i meant that there is currently else part in code below (not seen in patch) 
which
triggers cancel message, just in case no diff was found.

 if (ok) {
  -  if (response.empty())
  +  if (dolog  response.empty())
 response = empty;
  
  why response=empty harms in !nodolog?
 
 It doesn't harm. It wastes CPU cycles to set response when !nodolog.

the problem is how can various rcs/svn/cvs version react on empty message
as parameter. compared to this few cpu cycles are negligible.

  @@ -212,8 +213,9 @@
 docstring text = bformat(_(Reverting to the stored version of the 
 document %1$s will lose all current 
  changes.\n\n
 Do you want to revert to the older version?), 
  file);
  -  int const ret = Alert::prompt(_(Revert to stored version of 
  document?),
  -  text, 0, 1, _(Revert), _(Cancel));
  +  bool const doask = vcs-revertWithConfirmation();
  
  i would need to check whats above this function in guiview but isn't 
  possible that we will skip
  reverting in case the document is edited but not saved?
 
 Yes, so it is. Then reverting should be guarded with revertEnabled() too?

either ask for isClean or not touch revert at all

  +  int const ret = doask ? Alert::prompt(_(Revert to stored version of 
  document?),
  +  text, 0, 1, _(Revert), _(Cancel)) : 0;
  
  correspondingly to your previous coding style one would expect ret = doask 
   prompt ;  ;)
 
 I don't think so. The first is bool and the second is int.
 But I can change the style to be more verbose if you like.

not let it as it is. it was kind of joke.

 BTW, I have the problem that returning strings as result code is strange.
 And SVN::checkOut() implementation returns the a non empty string on error
 when the temporary log file name cannot be generated.

yes its ugly hack and i did it because there was no reasonable way how to pass
return info to user at the moment i implemented (this should be better now).

there are many things which can be improved inside revision control code
implementation however i want recall our original settlement - do some changes
inside CVS but dont touch API at this stage of development. i dont have time to
reimplement things and test all possible usescases again before public release
of 2.0.

you wanted to fix that bug that we ask for log even if only lock (or something
like that in cvs) is to be relased, ok, but please dont go beyond that.

pavel

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Vincent van Ravesteijn]

Jurgen,

Because I love to nitpick:

+void GuiApplication::processFuncRequestQueueAsync()
+{
+   // We perform the events asynchronously. This prevents potential
+   // problems in case the BufferView is closed within an event.

Well, this comment is not in the right position after all. The
decision to do it asynchronously is made where
processFuncRequestQueueAsync is called in stead of
processFuncRequestQueue. Besides, later on, noone will understand why
the BufferView determines that we process the events asynchronously
when we are in a function called Async().

+   /// add a func request to the queue for later procession
+   void addtoFuncRequestQueue(FuncRequest const );

typo - procession - processing

+   /// process the func request in the queue asynchronously
+   void processFuncRequestQueueAsync();

typo - func request - func requests, as there are usually
multiple func requests that form a queue.

+   /// add a func request to the queue for later procession
+   void addtoFuncRequestQueue(FuncRequest const );
+   /// process the func request in the queue asynchronously
+   void processFuncRequestQueueAsync();
+   /// add a func request to the queue and process it asynchronously
+   void dispatchDelayed(FuncRequest const );

Why not renaming dispatchDelayed to processFuncRequestAsync() ? (If we
even still need this function).

- First, this matches the other related functions and the difference
is immediately clear.

- Second, the function name uses the same terminology as the comment.

- Third, it's confusing to unnecessarily mix up the terminology:
* dispatch / processFuncRequest
* delayed / asynchronous

Vincent

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Vincent van Ravesteijn]

While eating I thought of more.


I moved the functions to another place in the header and made
dispatchDelayed a private function, since it's now only used in
GuiApplication itself.

I think it's better to make it public anyway.
- the fact whether a function is public or private should be based
more on its functionality and whether it may be used from outside this
class, than on the fact whether it's actually used from outside.
Imagine writing the Qt library. It would be a PITA if they would have
made all function that are not used from outside the library
inaccessible (as you can't use the library then without modifying it
yourself);

- the function only calls two public functions, so it can be public
itself I guess;

- I would prefer the declarations to be next to each other;

- if someone wants to use GuiApplication to asynchronously process a
func request, he now may start wondering why he can only process a
queue aynchronously, but not a single func request. Then he has to
think for himself that he should add the function to the queue and
then process the queue async. If this seems obvious, we wouldn't need
this dispatchDelayed function anyway. If it seems less obvious, it
should be more important to offer it public as a user using this class
generally has no knowledge about the internals, while someone writing
the internals of this class has.



Last, I said it was strange that dispatchDelayed uses the term
dispatch, while the others use the term processFuncRequest. This is
very confusing too in other parts of the code as we use ::dispatch(..)
both to send FuncRequests to the event loop as well as to process
FuncRequests we receive from the event loop. I guess we can rename all
dispatch functions of the first category to something consistent.

Vincent

Re: New thread offshoot ( Re: r35767 - lyx-devel/trunk/lib/doc )

[Richard Heck]

On 10/22/2010 10:42 AM, Pavel Sanda wrote:

Richard Heck wrote:
   

On 10/21/2010 07:50 PM, Pavel Sanda wrote:
 

sa...@lyx.org wrote:

   

Author: sanda
Date: Fri Oct 22 01:34:22 2010
New Revision: 35767
URL: http://www.lyx.org/trac/changeset/35767

Log:
(no log message)

Modified:
 lyx-devel/trunk/lib/doc/Additional.lyx

 

i looked why lyx ignored my message and it looks that
Alert::askForText(response, _(LyX VC: Log Message));
does not return messages anymore in trunk.


   

For how long? Could be a consequence of recent changes to asynchronous
Alert::*.
 

git bisect shows its somewhere around 35734-35742 which are almost all Peter's
commits. direct one is difficult obtain since it won't build due to the mess in 
makefiles...

i wonder why Alert:: code is affected when no preview or export is done?

   
All the Alert::* routines were changed so that they figure out whether 
they are in the main thread and then perform whatever magic is necessary 
if they are not. I think I understand it now, though, so I'll have a 
quick look in a bit.


rh

Re: New thread offshoot ( Re: r35767 - lyx-devel/trunk/lib/doc )

[Richard Heck]

On 10/22/2010 01:01 PM, Richard Heck wrote:

On 10/22/2010 10:42 AM, Pavel Sanda wrote:

Richard Heck wrote:

On 10/21/2010 07:50 PM, Pavel Sanda wrote:

sa...@lyx.org wrote:


Author: sanda
Date: Fri Oct 22 01:34:22 2010
New Revision: 35767
URL: http://www.lyx.org/trac/changeset/35767

Log:
(no log message)

Modified:
 lyx-devel/trunk/lib/doc/Additional.lyx


i looked why lyx ignored my message and it looks that
Alert::askForText(response, _(LyX VC: Log Message));
does not return messages anymore in trunk.



For how long? Could be a consequence of recent changes to asynchronous
Alert::*.
git bisect shows its somewhere around 35734-35742 which are almost 
all Peter's
commits. direct one is difficult obtain since it won't build due to 
the mess in makefiles...


i wonder why Alert:: code is affected when no preview or export is done?

All the Alert::* routines were changed so that they figure out whether 
they are in the main thread and then perform whatever magic is 
necessary if they are not. I think I understand it now, though, so 
I'll have a quick look in a bit.



Unfortunately, I don't see why this would be. Guess we need to ask Peter.

rh

Re: [Patch] Improving the Citation GUI.

[John McCabe-Dansted]

This patch got buried when I was distracted by my thesis. Apologies
for the delay.

I address the comments to the previous patch.

Notes:
1) The potential security issue has been addressed by only using LyX's viewers.
2) Richard suggested that I regenerate the filename/url on demand, I
discuss why I don't think this is cleaner: because we cannot update
the other bibliographic information on demand and so generating the
filename on demand increases the likelyhood that a future bug would
cause the filename to become out-of-sync with e.g. the filename
displayed in the tooltip.
3) While I was editing the CitationUi.ui, I cut down on vertical
spacing so that this dialog can display all the buttons on my netbook
with a 1024x600 screen. I think that 1024x600 screens should be
supported though there may be a better way of doing this.

On Tue, Mar 23, 2010 at 10:18 PM, rgheck rgh...@bobjweil.com wrote:
 I haven't tested this or even looked at the UI. Just some general
 comments.
 But generally it looks good to me.

 That said, I'm a bit unsure about the file part. There are security risks
 there. True, people usually put pdfs there, not shell scripts, but you
 can
 see the worry. By the same token, we might want to check the URL and make

OK, the updated patch now fixes used viewURL for URL, and adds a
similar function viewFile, that uses the existing LyX viewers.

 I meant not to use camel case, like citationFile but instead to use
 underscores like citation_file. And yes, you are right, names of private
 members should end in an underscore. I'm not sure why I left that off. I
 think because I was anticipating the next point.

The camel case has been removed.

 A more general question is whether you really need or want these
 variables.
 I think we can just re-calculate if one of the buttons gets pushed. This
 will not take enough time to be noticeable. Caching the values costs
 memory,
 and it means we have to be careful always to keep it in sync with the
 dialog, which invites bugs.

 Well, the issue isn't so much time as deciding which citation we want
 to open. To know this we would have to decide which LV has focus (what
 if neither has focus?) and then pick the selected item of the LV. This
 seems more complex and bug prone than updating citationURL_ and
 citationFile_ in the same place we update keytxt. Keeping two extra
 filenames in memory probably isn't any more noticeable than the time
 needed to recalculate them.

 What makes this complicated is the code needed to figure out what the
 selected index is. Let me work on this.

It seems to me that GuiCitation::updateInfo() must be called whenever
we change the selection so that e.g. the displayed citation is
updated. Even if it is not called, it is probably best that we open
the file that matches the bibliographic information displayed. For
example, we cannot set the Tooltip on demand so the ToolTip has to be
cached. May as well cache the actual name of the file to be opened
so that even if a bug stops updateInfo being updated we always open
the file listed in the tooltip.

-- 
John C. McCabe-Dansted
Index: frontends/qt4/GuiCitation.cpp
===
--- frontends/qt4/GuiCitation.cpp	(revision 35745)
+++ frontends/qt4/GuiCitation.cpp	(working copy)
@@ -22,12 +22,14 @@
 #include Buffer.h
 #include BiblioInfo.h
 #include BufferParams.h
+#include Format.h
 #include FuncRequest.h
 
 #include insets/InsetCommand.h
 
 #include support/debug.h
 #include support/docstring.h
+#include support/FileName.h
 #include support/gettext.h
 #include support/lstrings.h
 
@@ -154,6 +156,28 @@
 }
 
 
+void GuiCitation::on_urlPB_clicked()
+{
+	formats.viewURL(to_filesystem8bit(citation_url_));
+}
+
+
+void GuiCitation::on_filePB_clicked()
+{
+	string filename = to_filesystem8bit(citation_file_);
+	size_t pos = filename.find(:);
+	if (pos != string::npos) {
+		filename = filename.substr(pos + 1);
+	} else {
+		lyxerr  file entry \  filename
+			 \ does not contain ':' (missing JabRef filetype; 
+			 but we don't need it anyway)\n;
+	}
+
+	formats.viewFile(FileName(filename));
+}
+
+
 void GuiCitation::on_okPB_clicked()
 {
 	applyView();
@@ -363,8 +387,16 @@
 		return;
 	}
 
-	QString const keytxt = toqstr(
-		bi.getInfo(qstring_to_ucs4(idx.data().toString()), buffer(), true));
+	docstring key = qstring_to_ucs4(idx.data().toString());
+
+	QString const keytxt = toqstr(bi.getInfo(key, buffer(), true));
+	citation_url_ = bi.getURL(key);
+	citation_file_ = bi.getFile(key);
+	urlPB-setEnabled(!citation_url_.empty());
+	urlPB-setToolTip(QString(to_utf8(citation_url_).c_str()));
+	filePB-setEnabled(!citation_file_.empty());
+	filePB-setToolTip(QString(to_utf8(citation_file_).c_str()));
+
 	infoML-document()-setHtml(keytxt);
 }
 
Index: frontends/qt4/GuiCitation.h
===
--- frontends/qt4/GuiCitation.h	(revision 35745)
+++ frontends/qt4/GuiCitation.h	(working copy)
@@ 

Bookmark test on MacOSX

[Vincent van Ravesteijn]

Hi,

Can someone on a Mac test the following ?

- open LyX
- open a document
- save a bookmark
- close the document and make sure you don't have any views left
- try to navigate to the bookmark

Does LyX now assert ?

Thanks,

Vincent

Re: Bookmark test on MacOSX

[BH]

On Fri, Oct 22, 2010 at 2:33 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 Hi,

 Can someone on a Mac test the following ?

 - open LyX
 - open a document
 - save a bookmark
 - close the document and make sure you don't have any views left
 - try to navigate to the bookmark

 Does LyX now assert ?

Nope -- it works fine for me with near current svn (built yesterday).

BH

Re: Bookmark test on MacOSX

[Vincent van Ravesteijn]

 Nope -- it works fine for me with near current svn (built yesterday).

 BH


Thanks.

But it is strange as I see this code:

void GuiApplication::gotoBookmark(unsigned int idx, bool openFile,
   bool switchToBuffer)
{
   LASSERT(current_view_);

}

I don't understand this. On a Mac you can navigate to a bookmark
without a current_view_ right ??? Why don't you get an assert then ?
Did you understand that I meant to close all windows, such that you
only have a menubar of LyX ?

I've another question:

1. Open Lyx,
2. Open a document,
3. Choose View-Close Current View
4. Close All Windows
5. View-Invisible Buffers
6. Choose a buffer.

What happens now ?

Vincent

Re: Bookmark test on MacOSX

[BH]

On Fri, Oct 22, 2010 at 2:57 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 Nope -- it works fine for me with near current svn (built yesterday).

 BH


 Thanks.

 But it is strange as I see this code:

 void GuiApplication::gotoBookmark(unsigned int idx, bool openFile,
   bool switchToBuffer)
 {
   LASSERT(current_view_);
 
 }

 I don't understand this. On a Mac you can navigate to a bookmark
 without a current_view_ right ??? Why don't you get an assert then ?
 Did you understand that I meant to close all windows, such that you
 only have a menubar of LyX ?

Sorry -- I had other windows open. If I close everything else, and
then try navigating to a bookmark, I get an error beep and nothing
else happens. Moreover -- something I hadn't noticed before -- if all
windows are closed, it's not possible to open a new window using the
menus or keybindings. (It is possible to double click on a LyX
document in the Finder -- the file browser -- and have it open in
LyX.)


 I've another question:

 1. Open Lyx,
 2. Open a document,
 3. Choose View-Close Current View
 4. Close All Windows
 5. View-Invisible Buffers
 6. Choose a buffer.

 What happens now ?

Again, in this case, with no windows open, trying to open any new
window from within LyX fails. Once a window has been opened via the
Finder, I can then select invisible buffers, and the window is opened
as you'd expect.

Incidentally, in testing all this, I had LyX crash on me twice. I
don't have time now to get a backtrace, but let me know if you want me
to post one later.

BH

Re: Bookmark test on MacOSX

[Vincent van Ravesteijn]

 Sorry -- I had other windows open. If I close everything else, and
 then try navigating to a bookmark, I get an error beep and nothing
 else happens.

That must be the assert then.

Moreover -- something I hadn't noticed before -- if all
 windows are closed, it's not possible to open a new window using the
 menus or keybindings. (It is possible to double click on a LyX
 document in the Finder -- the file browser -- and have it open in
 LyX.)

Does this mean that File-Open doesn't work as well ? and File-New
Windows ? and File-New ?

 Again, in this case, with no windows open, trying to open any new
 window from within LyX fails. Once a window has been opened via the
 Finder, I can then select invisible buffers, and the window is opened
 as you'd expect.

This is caused by the fact that BUFFER_SWITCH is implemented in GuiView.

 Incidentally, in testing all this, I had LyX crash on me twice. I
 don't have time now to get a backtrace, but let me know if you want me
 to post one later.


Yes, please.

Also please remember any recipe to get a bug, so you can test later
whether all things works then.

For now I see the following bugs:

- assert when navigate to bookmark,
- you can't switch to invisible buffers,
- you can't open a new window by menus,
- some crashes.

Vincent

Re: Bookmark test on MacOSX

[BH]

On Fri, Oct 22, 2010 at 3:25 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 Sorry -- I had other windows open. If I close everything else, and
 then try navigating to a bookmark, I get an error beep and nothing
 else happens.

 That must be the assert then.

No. It's just the OS's warning beep that you're trying to do something
you can't do. LyX keeps running along just fine.

Moreover -- something I hadn't noticed before -- if all
 windows are closed, it's not possible to open a new window using the
 menus or keybindings. (It is possible to double click on a LyX
 document in the Finder -- the file browser -- and have it open in
 LyX.)

 Does this mean that File-Open doesn't work as well ? and File-New
 Windows ? and File-New ?

Yes.

 Again, in this case, with no windows open, trying to open any new
 window from within LyX fails. Once a window has been opened via the
 Finder, I can then select invisible buffers, and the window is opened
 as you'd expect.

 This is caused by the fact that BUFFER_SWITCH is implemented in GuiView.

 Incidentally, in testing all this, I had LyX crash on me twice. I
 don't have time now to get a backtrace, but let me know if you want me
 to post one later.


 Yes, please.

 Also please remember any recipe to get a bug, so you can test later
 whether all things works then.

I don't have a recipe now, which is why it will take longer than I now
have to do it

 For now I see the following bugs:

 - assert when navigate to bookmark,

Again, I'm not seeing this.

 - you can't switch to invisible buffers,

Only when no window is open. (When other windows are open, it works fine.)

 - you can't open a new window by menus,

Again, only when no window is open.

 - some crashes.

Yep.

BH

Re: Bookmark test on MacOSX

[Vincent van Ravesteijn]

Yet another question.

If you normally would reconfigure LyX, you get a message like Running
configure... in the status bar. Then you know you have to wait.

What do you expect on Mac if you don't have any window open ? Now,
there is no way of telling that configure is running, right ?

Do you expect some sort of message popping up ? Do you expect a
message box on your screen (as you probably don't want to do any work
as you don't even have a view open). Do you expect a sheet to slide
down from your menu bar ?

Vincent

Fwd: Bookmark test on MacOSX

[Vincent van Ravesteijn]

Yet another question.

If you normally would reconfigure LyX, you get a message like Running
configure... in the status bar. Then you know you have to wait.

What do you expect on Mac if you don't have any window open ? Now,
there is no way of telling that configure is running, right ?

Do you expect some sort of message popping up ? Do you expect a
message box on your screen (as you probably don't want to do any work
as you don't even have a view open). Do you expect a sheet to slide
down from your menu bar ?

Vincent

Re: Bookmark test on MacOSX

[Vincent van Ravesteijn]

 Incidentally, in testing all this, I had LyX crash on me twice. I
 don't have time now to get a backtrace, but let me know if you want me
 to post one later.

 BH


I think the culprit might be in this code:

void GuiApplication::processKeySym(KeySymbol const  keysym, KeyModifier state)
{
LYXERR(Debug::KEY, KeySym is   keysym.getSymbolName());

// Do nothing if we have nothing (JMarc)
if (!keysym.isOK()) {
LYXERR(Debug::KEY, Empty kbd action (probably composing));
current_view_-restartCursor();
return;
}
  [..]
}

So, if you don't have any window open and when you send a key
combination to LyX which is not OK, LyX will crash on current_view_.

Vincent

Re: Bookmark test on MacOSX

[Vincent van Ravesteijn]

On Fri, Oct 22, 2010 at 10:34 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 Incidentally, in testing all this, I had LyX crash on me twice. I
 don't have time now to get a backtrace, but let me know if you want me
 to post one later.

 BH



I fixed a number of problems that might occur without a view in
http://www.lyx.org/trac/changeset/35787.

Hope it crashes less now.

Vincent

Re: LyX Additional features Version 1.6.7 suggested corrections

[John R Hudson]

Hi Pavel

Thanks. Will do.

I will change to 2.0 - Uwe has just made the same suggestion. The way I have 
worked in the past was because that was the instruction in the Help files when 
I first began submitting changes occasionally some years ago.

John
-- 

On Friday 22 October 2010 20:08:50 you wrote:
 John R Hudson wrote:
  Hi Richard
  
  Here are some suggested corrections for the Additional features manual.
 
 Hello John,
 
 most corrections are in.
 
  5.1.1 Introduction
  [Version 7.00 (Jauary 2010) is available from the website listed; so this
  whole section needs to be updated; I am happy to have a go at this if you
  would like]
 
 nobody else will do otherwise ;)
 
  5.13 Kluwer
  [Kluwer is now part of Springer and the url links to:
  http://www.springer.com/?SGWID=0-102-0-0-0
  ? delete whole section]
 
 if delete then not only this sections but other kluwer related stuff we
 have, dunno whether this should happen.
 
  5.19 RevTeX4
  [paragraph 1]The Revtex 4 textclass works with the American Physical
  Sociey's RevTeX 4.1 class. [I haven't tried this but RevTeX4.1 was
  issued in August 2010 and the announcement refers mostly to bugfixes and
  additional features and only mentions having the most recent version of
  natbib installed as essential]
 
 iirc there has been some movement in trunk wrt revtex. perhaps this didn't
 got updated.
 
  6.1 Checking TeX
  [chktex is now listed as obsolete in CTAN; this section needs deleting]
 
 iirc its still living and JMarc is one of its maintainers.
 
  6.2.2.5 Undo Last Checkin
  This pretends that the last check in never happened . . . ['pretends
  that' is more idiomatic]
 
 but the last checkin is really deleted, so this is not good description
 either.
 
 
 last but not least - its tedious work to manually enter again the
 corrections and its must be even more tedious for you. why can't we use
 change tracking? or -- if its not technical problem for you - use living
 version of manuals via subversion and send us patches? it would take 5% of
 time on both sides.
 
 also using lyx 2.0 from trunk would make possible to review new changes
 from 1.6 to 2.0 due to the comparison feature.
 
 thanks for your review,
 pavel

Re: LyX Additional features Version 1.6.7 suggested corrections

[Pavel Sanda]

John R Hudson wrote:
 Hi Pavel
 
 Thanks. Will do.
 
 I will change to 2.0 - Uwe has just made the same suggestion. The way I have 
 worked in the past was because that was the instruction in the Help files 
 when 
 I first began submitting changes occasionally some years ago.

btw are you able to use subversion?
pavel

Re: LyX Additional features Version 1.6.7 suggested corrections

[Julien Rioux]

On 22/10/2010 4:15 PM, John R Hudson wrote:

5.19 RevTeX4
[paragraph 1]The Revtex 4 textclass works with the American Physical
Sociey's RevTeX 4.1 class. [I haven't tried this but RevTeX4.1 was
issued in August 2010 and the announcement refers mostly to bugfixes and
additional features and only mentions having the most recent version of
natbib installed as essential]

 iirc there has been some movement in trunk wrt revtex. perhaps this didn't
 got updated.


The text above is incorrect. The current revtex4.layout expects revtex4.cls

When creating version 4.1, the author of the latex class file found it 
necessary to have a different file name (revtex4-1.cls) and revtex4.cls 
was removed completely from CTAN, rendering it obsolete.


Currently LyX does not ship a layout file for revtex 4.1

--
Julien

Re: Some thoughts on further development process towards beta and RCs

[Vincent van Ravesteijn]

 ok, thanks for the info. unless Vincent put it in, i will do before
 beta goes out.


I looked at the patch again and in the Qt Docs and I read:

{{{

void QClipboard::dataChanged () [signal]

This signal is emitted when the clipboard data is changed.

On Mac OS X and with Qt version 4.3 or higher, clipboard changes made
by other applications will only be detected when the application is
activated.

}}}

Can someone on a Mac then please explain me that this is no problem.
Or do I misunderstand this sentence? Does it mean that if application
X changes the clipboard, application X should be activated ?

Anyway, if the Mac people tested it, I will put it in.

It would be nice if someone could think of a way to try to let another
application change the clipboard without it being activated.

Vincent

Re: Bookmark test on MacOSX

[Peter Kümmel]

 A. Am Freitag, den 22.10.2010, 22:34 +0200 schrieb Vincent van
Ravesteijn:
  Incidentally, in testing all this, I had LyX crash on me twice. I
  don't have time now to get a backtrace, but let me know if you want me
  to post one later.
 
  BH
 
 
 I think the culprit might be in this code:
 
 void GuiApplication::processKeySym(KeySymbol const  keysym, KeyModifier 
 state)
 {
   LYXERR(Debug::KEY, KeySym is   keysym.getSymbolName());
 
   // Do nothing if we have nothing (JMarc)
   if (!keysym.isOK()) {
   LYXERR(Debug::KEY, Empty kbd action (probably composing));
   current_view_-restartCursor();
   return;
   }
   [..]
 }
 
 So, if you don't have any window open and when you send a key
 combination to LyX which is not OK, LyX will crash on current_view_.
 
 Vincent

I've also seen crashes in processKeySym:

- Open LyX
- Load a file
- Menu-Document-Outline
- create several new documents by simply pressinc Crtl-N for several
seconds
- then close all by pressing Ctrl-W
- crash

(I've not checked with your latest changes)

Peter

Re: Some thoughts on further development process towards beta and RCs

[Peter Kümmel]

Am Sonntag, den 17.10.2010, 18:28 +0200 schrieb Pavel Sanda:
 John McCabe-Dansted wrote:
   the most problematic cases of our copypaste typically happen when
   middle button is used for getting, or puting stuff from/into another
   applications and when more lyx instances are used. dunno whether
   the patch affects these use cases... its very fragile stuff and i
   remeber having some hard debugging nights, thats why i fear to take
   responsibility for this patch :)
  
  This patch shouldn't affect middle click, as it only caches the
  clipboard status, not the Primary Selection. Also, I have been using
  the patch for months, use middle-click extensively, and haven't
  noticed anything wrong. I think this patch has also been sitting in
  Vincent's tree. I presume he hasn't noticed any regressions.
 
 ok, thanks for the info. unless Vincent put it in, i will do before
 beta goes out.
 
 pavel

Re: New thread offshoot ( Re: r35767 - lyx-devel/trunk/lib/doc )

[Peter Kümmel]

Am Freitag, den 22.10.2010, 13:28 -0400 schrieb Richard Heck:
  i wonder why Alert:: code is affected when no preview or export is done?

It was a bug in InGuiThread.h, see commit message:

bind makes a copy of the arguments by default. This is secure if the
bound object survives the existence of the arguments, but it also breaks
change by non-const reference  parameter passing, like in
Alert::askForString. Here the arguments exists the whole bound function
call so we could pass by reference.

 I think I understand it now, though
Multi threading isn't that hard ;)
And have a look at bind:
you can go a long way with just boost::bind

Peter

Re: Bookmark test on MacOSX

[BH]

On Fri, Oct 22, 2010 at 4:08 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 Yet another question.

 If you normally would reconfigure LyX, you get a message like Running
 configure... in the status bar. Then you know you have to wait.

 What do you expect on Mac if you don't have any window open ? Now,
 there is no way of telling that configure is running, right ?

Right -- there's no way to tell it's reconfiguring if no window is
open. However, even if a window is open, the Reloading configuration
... message doesn't show up until *after* the The system has been
reconfigured message has popped up. That's a bug.

 Do you expect some sort of message popping up ? Do you expect a
 message box on your screen (as you probably don't want to do any work
 as you don't even have a view open). Do you expect a sheet to slide
 down from your menu bar ?

Normally, I'd expect some form of progress indicator -- a spinner or
an indefinite progress bar, for example -- to appear, possibly in the
frontmost window if there is one, or possibly in its own dialog.
(Sheets only slide down from windows, not the menu bar, and they are
supposed to be for modal dialogs that pertain to a particular window,
like save or print; they wouldn't be appropriate here.)

Perhaps Stephan should weigh in here

BH

Re: Change Tracking and Versioning (#6058) was Re: more on collaboration

[Vincent van Ravesteijn]

Hi Gregory,

 1) I have a patch set for 1.6.X which will no longer apply because Vincent
 (vfr) already contributed an alternative.  I presume that I need to modify
 my patch to layer on top of his.

Actually, I wouldn't say I contributed an alternative. I just put in
your idea but implemented slightly different. Because I kept your idea
in mind, it was easy to implement the hash function part and I think
that the very simple patch I attach, is exactly what you had in mind.
If not, let me know.

 3) How should lyx2lyx be handled in this case?  I guess I need to layer a
 conversion from vfr's patch (format 369) to my proposal.  Or if that file
 format was never a stable release can it be ignored?

Now we only need to revert the hash numbers to 1,2,3... but I'm not
proficient at all when it comes to Python.


 Many thanks for your help,

 Greg Jefferis.


Thank you too,

please check whether the patch that I attach to the bug report is what
you had in mind.
http://www.lyx.org/trac/attachment/ticket/6058/bug6058.patch

Vincent

Re: Bookmark test on MacOSX

[BH]

On Fri, Oct 22, 2010 at 4:58 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 On Fri, Oct 22, 2010 at 10:34 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 Incidentally, in testing all this, I had LyX crash on me twice. I
 don't have time now to get a backtrace, but let me know if you want me
 to post one later.

 BH



 I fixed a number of problems that might occur without a view in
 http://www.lyx.org/trac/changeset/35787.

 Hope it crashes less now.

I updated to 35787 and have been trying the same things I was doing
before that led to crashes, but it seems stable enough now. I'll let
you know (and provide a backtrace) if it crashes again.

BH

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Guenter Milde]

On 2010-10-21, Vincent van Ravesteijn wrote:

> > but now we have new problem - how to notice user that exporting is 

Re: r35575 - lyx-devel/trunk/src

[Stephan Witt]

Am 22.10.2010 um 01:07 schrieb Pavel Sanda:

> Stephan Witt wrote:
 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.
> 
> i tried hopeless experiment to set the log window modal for this usecases
> but it does not work. dispatch returns from show-dialog lfun and does not
> wait for completion and i guess it would need deeper surgery or completely
> new dialog to arrange this.

A new dialog similar to display the VC log...

> maybe there is another way how to trigger the dialog which would wait,
> but my curiousity is exhausted now ;)

I had the same idea already. Luckily I didn't try it.
The other idea I had was the special dialog combining the buttons and the
presentation of the diff.

Stephan

PS. I'll answer your other mail later. Thanks for it already.

Re: r35769 - in lyx-devel/trunk/lib: . scripts

[Jean-Marc Lasgouttes]

Le 22/10/2010 02:10, uwesto...@lyx.org a écrit :

Log:
- lyxsweave.R: set missing SVN EOL style and add missing makefile entry

- lib/Makefile.am: add missing scripts


Thanks, Uwe.

JMarc

Re: #6710: table dialog broken

[Abdelrazak Younes]

On 10/22/2010 03:25 AM, LyX Ticket Tracker wrote:

#6710: table dialog broken
--+-
  Reporter:  uwestoehr |Owner:  nob...@…
  Type:  defect|   Status:  closed
  Priority:  high  |Milestone:  2.0.0
Component:  frontend-qt4  |  Version:  2.0.0svn
  Severity:  major |   Resolution:  fixed
  Keywords:  regression|
--+-
Changes (by uwestoehr):

   * status:  new =>  closed
   * resolution:  =>  fixed


Comment:

  >  This is certainly possible and it make sense indeed.

  Thanks for fixing this in r35747. ->  Marking as FIXED.

  >  For the second point ("its content is also not refreshed") this is by
  design, you
  >  have to check the "Immediate Apply" button if you want it to be
  automatically
  >  refreshed.

  Ah, I didn't know that one needs to set this option to get LyX's 1.6.x's
  behaviour. I'll document this.
  But shouldn't we enable this option by default?


AFAIU Most other devs don't like the synchronous behavior. But we should 
save the checkbox status in the session settings... I'll try do that 
when I have some time.



  Without this option
  working with tables is a nightmare as you have to open/close the dialog
  permanently.
   


Why that? You can click on the [Restore] button after changing the 
cursor position; no need to leave the dialog. If you are going to 
document this (thanks by the way) please note that the asynchronous mode 
is useful when you want to apply a same config to multiple table cell. 
You just have to change the cursor position and hit [Apply]; you can do 
this multiple time for many table cell.


Abdel.

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Jürgen Spitzmüller]

Pavel Sanda wrote:
> this thinko-part smells like trunk stuff unless it really fixes something.

It really fixes something. If you drop file a.tex and b.tex onto LyX, current 
LyX tries to import a.tex twice, and b.tex not at all. The fix assures that 
both a.tex and b.tex are imported (and only once). 

Jürgen

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Vincent van Ravesteijn]

> // 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();

One remark: I refactored the buffer reloading, so I don't think it is
still true that a BufferView can close itself now on reloading.

Vincent

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Jürgen Spitzmüller]

Vincent van Ravesteijn wrote:
> > // 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();
> 
> One remark: I refactored the buffer reloading, so I don't think it is
> still true that a BufferView can close itself now on reloading.

So you think I can just ditch the comment? (Actually, it's also not posted 
asynchronously anymore, unless I do my second proposed change).

Jürgen

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Vincent van Ravesteijn]

>> One remark: I refactored the buffer reloading, so I don't think it is
>> still true that a BufferView can close itself now on reloading.
>
> So you think I can just ditch the comment? (Actually, it's also not posted
> asynchronously anymore, unless I do my second proposed change).
>
> Jürgen
>

I think you can. However, I can't judge right now whether it's better
to do it asynchronously or not. So, it might be that we should still
do it asynchronously, but the reasoning stated in the comment is not
valid anymore.

Vincent

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Guenter Milde wrote:
> > Status bar: Moving icons. Text. Messages.
> 
> greyed out (or otherwise modified) export toolbar buttons?

wont help in case you use only menu.
pavel

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Jürgen Spitzmüller]

Vincent van Ravesteijn wrote:
> I think you can. However, I can't judge right now whether it's better
> to do it asynchronously or not. So, it might be that we should still
> do it asynchronously, but the reasoning stated in the comment is not
> valid anymore.

I propose the following patch (diff against trunk). I moved the comment to the 
actual function, so we know at least why the asynchronous call was introduced.

I propose to commit this to trunk and later, if no problems arise, to branch.

OK?

Jürgen
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp	(Revision 35775)
+++ src/frontends/qt4/GuiView.cpp	(Arbeitskopie)
@@ -794,13 +794,10 @@
 "No formats found, trying to open it as a lyx file");
 			cmd = FuncRequest(LFUN_FILE_OPEN, file);
 		}
-
-		// Asynchronously post the event. DropEvent usually comes
-		// 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 35775)
+++ src/frontends/qt4/GuiApplication.cpp	(Arbeitskopie)
@@ -1788,6 +1788,20 @@
 void GuiApplication::dispatchDelayed(FuncRequest const & func)
 {
 	d->func_request_queue_.push(func);
+	performFuncRequests();
+}
+
+
+void GuiApplication::addtoFuncRequestQueue(FuncRequest const & func)
+{
+	d->func_request_queue_.push(func);
+}
+
+
+void GuiApplication::performFuncRequests()
+{
+	// We perform the events asynchronously. This prevents potential
+	// problems in case the BufferView is closed within an event.
 	QTimer::singleShot(0, this, SLOT(processFuncRequestQueue()));
 }
 
@@ -1976,7 +1990,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 35775)
+++ src/frontends/qt4/GuiApplication.h	(Arbeitskopie)
@@ -61,6 +61,8 @@
 	void dispatch(FuncRequest const &, DispatchResult & dr);
 	FuncStatus getStatus(FuncRequest const & cmd) const;
 	void dispatchDelayed(FuncRequest const &);
+	void addtoFuncRequestQueue(FuncRequest const &);
+	void performFuncRequests();
 	void restoreGuiSession();
 	Clipboard & clipboard();
 	Selection & selection();

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Vincent van Ravesteijn]

On Fri, Oct 22, 2010 at 1:03 PM, Jürgen Spitzmüller  wrote:
> Vincent van Ravesteijn wrote:
>> I think you can. However, I can't judge right now whether it's better
>> to do it asynchronously or not. So, it might be that we should still
>> do it asynchronously, but the reasoning stated in the comment is not
>> valid anymore.
>
> I propose the following patch (diff against trunk). I moved the comment to the
> actual function, so we know at least why the asynchronous call was introduced.
>
> I propose to commit this to trunk and later, if no problems arise, to branch.
>
> OK?
>
> Jürgen
>

It's fine with me.

Only three nitpicks:

- There will be some point in time that I will start wondering what
the difference is between processing the queue and performing the
requests. Then I'll find out that they do the same thing but that the
only difference is that performing means it's done asynchronously.
That's why I would prefer to call the function
processFuncRequestQueueAsynchronously() or some abbreviated form.

- You add the two function declarations to GuiApplication.h in the
section with the description "Methods inherited from Application", but
these function are not inherited. Maybe they should be declared in
Application.h as well. (I still want to make a guiless LyX in some
point of time).
There are more functions not located appropriately, but well, don't
mess it up more than necessary.

- Please add some description to these function declarations.

Vincent

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Jürgen Spitzmüller]

Vincent van Ravesteijn wrote:
> Only three nitpicks:
> 
> - There will be some point in time that I will start wondering what
> the difference is between processing the queue and performing the
> requests. Then I'll find out that they do the same thing but that the
> only difference is that performing means it's done asynchronously.
> That's why I would prefer to call the function
> processFuncRequestQueueAsynchronously() or some abbreviated form.

OK

> - You add the two function declarations to GuiApplication.h in the
> section with the description "Methods inherited from Application", but
> these function are not inherited. Maybe they should be declared in
> Application.h as well. (I still want to make a guiless LyX in some
> point of time).
> There are more functions not located appropriately, but well, don't
> mess it up more than necessary.

It turns out that dispatchDelayed is also not inherited. I moved the functions 
to another place in the header and made dispatchDelayed a private function, 
since it's not only used in GuiApplication itself.

> - Please add some description to these function declarations.

Done

Jürgen
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp	(Revision 35775)
+++ src/frontends/qt4/GuiView.cpp	(Arbeitskopie)
@@ -794,13 +794,12 @@
 "No formats found, trying to open it as a lyx file");
 			cmd = FuncRequest(LFUN_FILE_OPEN, file);
 		}
-
-		// Asynchronously post the event. DropEvent usually comes
-		// from the BufferView. But reloading a file might close
-		// the BufferView from within its own event handler.
-		guiApp->dispatchDelayed(cmd);
+		// add the functions to the queue
+		guiApp->addtoFuncRequestQueue(cmd);
 		event->accept();
 	}
+	// now process the collected functions
+	guiApp->processFuncRequestQueueAsync();
 }
 
 
Index: src/frontends/qt4/GuiApplication.cpp
===
--- src/frontends/qt4/GuiApplication.cpp	(Revision 35775)
+++ src/frontends/qt4/GuiApplication.cpp	(Arbeitskopie)
@@ -1787,7 +1787,21 @@
 
 void GuiApplication::dispatchDelayed(FuncRequest const & func)
 {
+	addtoFuncRequestQueue(func);
+	processFuncRequestQueueAsync();
+}
+
+
+void GuiApplication::addtoFuncRequestQueue(FuncRequest const & func)
+{
 	d->func_request_queue_.push(func);
+}
+
+
+void GuiApplication::processFuncRequestQueueAsync()
+{
+	// We perform the events asynchronously. This prevents potential
+	// problems in case the BufferView is closed within an event.
 	QTimer::singleShot(0, this, SLOT(processFuncRequestQueue()));
 }
 
@@ -1976,7 +1990,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 35775)
+++ src/frontends/qt4/GuiApplication.h	(Arbeitskopie)
@@ -60,7 +60,6 @@
 	void dispatch(FuncRequest const &);
 	void dispatch(FuncRequest const &, DispatchResult & dr);
 	FuncStatus getStatus(FuncRequest const & cmd) const;
-	void dispatchDelayed(FuncRequest const &);
 	void restoreGuiSession();
 	Clipboard & clipboard();
 	Selection & selection();
@@ -136,6 +135,11 @@
 	/// return the status bar state string
 	docstring viewStatusMessage();
 
+	/// add a func request to the queue for later procession
+	void addtoFuncRequestQueue(FuncRequest const &);
+	/// process the func request in the queue asynchronously
+	void processFuncRequestQueueAsync();
+
 	/// goto a bookmark
 	/// openFile: whether or not open a file if the file is not opened
 	/// switchToBuffer: whether or not switch to buffer if the buffer is
@@ -164,6 +168,8 @@
 	void setGuiLanguage();
 	///
 	void reconfigure(std::string const & option);
+	/// add a func request to the queue and process it asynchronously
+	void dispatchDelayed(FuncRequest const &);
 
 	/// This GuiView is the one receiving Clipboard and Selection
 	/// events

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Jürgen Spitzmüller]

Jürgen Spitzmüller wrote:
> since it's not only used in GuiApplication itself.

not > now

Jürgen

Re: r35765 - lyx-devel/branches/BRANCH_1_6_X

[Pavel Sanda]

sa...@lyx.org wrote:
> Author: sanda
> Date: Fri Oct 22 01:10:02 2010
> New Revision: 35765
> URL: http://www.lyx.org/trac/changeset/35765
> 
> Log:
> Allow newer autoconf
> 
> Modified:
>lyx-devel/branches/BRANCH_1_6_X/autogen.sh
>lyx-devel/branches/BRANCH_1_6_X/status.16x
> 
> Modified: lyx-devel/branches/BRANCH_1_6_X/autogen.sh
> ==
> --- lyx-devel/branches/BRANCH_1_6_X/autogen.shFri Oct 22 00:04:06 
> 2010(r35764)
> +++ lyx-devel/branches/BRANCH_1_6_X/autogen.shFri Oct 22 01:10:02 
> 2010(r35765)
> @@ -38,11 +38,11 @@
>  
>  
>  case $autoversion in
> -*' '2.59[cd]|*' '2.60[ab]|*' '2.6[0-57])
> +*' '2.59[cd]|*' '2.60[ab]|*' '2.6[0-578])
>   ;;
>  *)
>   echo "This autoconf version is not supported by LyX."
> - echo "LyX only supports autoconf 2.59c-2.65, 2.67."
> + echo "LyX only supports autoconf 2.59c-2.65, 2.67 and 2.68."
>   exit 1
>   ;;
>  esac
> 
> Modified: lyx-devel/branches/BRANCH_1_6_X/status.16x
> ==
> --- lyx-devel/branches/BRANCH_1_6_X/status.16xFri Oct 22 00:04:06 
> 2010(r35764)
> +++ lyx-devel/branches/BRANCH_1_6_X/status.16xFri Oct 22 01:10:02 
> 2010(r35765)
> @@ -83,7 +83,7 @@
>  
>  * BUILD/INSTALLATION
>  
> -- Allow autoconf 2.67.
> +- Allow autoconf 2.67 and 2.68.

hum, i was too fast here:
configure.ac:155: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in 
body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
config/libtool.m4:363: _LT_AC_SYS_LIBPATH_AIX is expanded from...
config/libtool.m4:5560: AC_LIBTOOL_PROG_LD_SHLIBS is expanded from...
config/libtool.m4:2783: _LT_AC_LANG_C_CONFIG is expanded from...
config/libtool.m4:2782: AC_LIBTOOL_LANG_C_CONFIG is expanded from...
config/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from...
config/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from...
config/libtool.m4:25: AC_PROG_LIBTOOL is expanded from...
config/lyxinclude.m4:674: LYX_PROG_LIBTOOL is expanded from...
configure.ac:155: the top level


trunk does not show this behaviour. JMarc, do you have idea?

pavel

Re: r35765 - lyx-devel/branches/BRANCH_1_6_X

[Jean-Marc Lasgouttes]

Le 22/10/2010 14:21, Pavel Sanda a écrit :

trunk does not show this behaviour. JMarc, do you have idea?


Branch uses libtool, trunk does not. I fear that using recent autoconf 
means switching to libtool 2. See for example this mail:

  http://www.spinics.net/lists/ac/msg10004.html

Re: r35575 - lyx-devel/trunk/src

[Stephan Witt]

Am 22.10.2010 um 02:11 schrieb Pavel Sanda:

> Stephan Witt wrote:
>> I made a new patch to implement getDiff() and use it to avoid the query for 
>> log message
>> before checkIn() is done and the confirmation on revert when no diff is 
>> found.
> 
> thanks for your patience, i went closely through the patch now and generally 
> liked the approach.
> 
>> +FileName const CVS::getDiff(OperationMode opmode)
>> +{
>> +FileName tmpf = FileName::tempName("lyxvcout");
>> +if (tmpf.empty()) {
>> +LYXERR(Debug::LYXVC, "Could not generate logfile " << tmpf);
>> +return tmpf;
>> +}
>> +
>> +doVCCommand("cvs diff " + getTarget(opmode)
>> ++ " > " + quoteName(tmpf.toFilesystemEncoding()),
>> +FileName(owner_->filePath()), false);
>> +return tmpf;
>> +}
> 
> the error case is suspicious. if tempName fails or "cvs diff" fails how you 
> detect
> this on a higher stage? cmiiw but if something fails you identify it with 
> having
> empty diff, which looks wrong, even more if you release lock automatically in 
> such
> a case...

Your right. I'll try to come up with a better solution.
BTW, I copied the tmpf allocation code sequence.
I think the debug message does not need to print the empty tmpf.

But I've found another way to solve the same goal - using "cvs status".
Checking for the diff is not good enough.

While doing some "stress test" with checkIn() I found the error message when 
merge is needed
"Something's wrong with cvs commit" not acceptable. Then I tried to change that 
and failed to
solve it because of the stderr output of the VC command is lost silently. So I 
came to the
idea to implement getStatus() and use the result accordingly.

The result would be one out of
* uptodate
* locally modified
* needs checkout
* needs merge
* no cvs file

The checkInWithMessage() implementation would be then
{ return getStatus() == LocallyModified; }
And the checkIn() would do a switch on the getStatus() and
raise more descriptive error messages according the status.

> 
>> +int CVS::update(OperationMode opmode, FileName const tmpf)
> 
> unless you want to mix this with repoupdate why is opmode here?

Yes. That's the plan.

>> +// should a log message provided for next checkin?
>> +virtual bool checkInWithMessage() { return true; }
> 
>> +// should a confirmation before revert requested?
>> +virtual bool revertWithConfirmation() { return true; }
> 
> i would change naming, so its clear what the function really does.
> for example isCheckinWithConfirmation...

Ok.

> 
>> private:
>>  support::FileName file_;
>>  // revision number from scanMaster
>>  std::string version_;
>>  /// The user currently keeping the lock on the VC file.
>>  std::string locker_;
>> +
>> +virtual std::string const getTarget(OperationMode opmode);
>> +virtual support::FileName const getDiff(OperationMode opmode);
>> +virtual int edit();
>> +virtual int unedit();
>> +virtual int update(OperationMode opmode, support::FileName const tmpf);
>> +virtual bool const hasDiff(OperationMode opmode);
>> +virtual bool const hasDiff() { return hasDiff(File); }
>> };
> 
> comments missing

Ok.

> 
>> --- src/LyXVC.cpp(Revision 35732)
>> +++ src/LyXVC.cpp(Arbeitskopie)
>> @@ -163,9 +163,10 @@
>>  docstring empty(_("(no log message)"));
>>  docstring response;
>>  string log;
>> -bool ok = Alert::askForText(response, _("LyX VC: Log Message"));
>> +bool dolog = vcs->checkInWithMessage();
>> +bool ok = !dolog || Alert::askForText(response, _("LyX VC: Log 
>> Message"));
> 
> hmm, but if !dolog then user automatically gets "cancel" message?

You mean the user should have the option to cancel the operation if the file is 
up-to-date?
Seems reasonable.

> 
>>  if (ok) {
>> -if (response.empty())
>> +if (dolog && response.empty())
>>  response = empty;
> 
> why response=empty harms in !nodolog?

It doesn't harm. It wastes CPU cycles to set response when !nodolog.

> 
>> @@ -212,8 +213,9 @@
>>  docstring text = bformat(_("Reverting to the stored version of the "
>>  "document %1$s will lose all current 
>> changes.\n\n"
>>  "Do you want to revert to the older version?"), 
>> file);
>> -int const ret = Alert::prompt(_("Revert to stored version of 
>> document?"),
>> -text, 0, 1, _(""), _(""));
>> +bool const doask = vcs->revertWithConfirmation();
> 
> i would need to check whats above this function in guiview but isn't possible 
> that we will skip
> reverting in case the document is edited but not saved?

Yes, so it is. Then reverting should be guarded with revertEnabled() too?

> 
>> +int const ret = doask ? Alert::prompt(_("Revert to stored version of 
>> document?"),
>> +text, 0, 1, _(""), _("")) : 0;
> 
> correspondingly to your previous coding style one would expect 

Re: r35765 - lyx-devel/branches/BRANCH_1_6_X

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Branch uses libtool, trunk does not. I fear that using recent autoconf 
> means switching to libtool 2. See for example this mail:
>   http://www.spinics.net/lists/ac/msg10004.html

ok, so i'll revert this patch.
pavel

Re: r35765 - lyx-devel/branches/BRANCH_1_6_X

[Stephan Witt]

Am 22.10.2010 um 14:53 schrieb Jean-Marc Lasgouttes:

> Le 22/10/2010 14:21, Pavel Sanda a écrit :
>> trunk does not show this behaviour. JMarc, do you have idea?
> 
> Branch uses libtool, trunk does not. I fear that using recent autoconf means 
> switching to libtool 2. See for example this mail:
>  http://www.spinics.net/lists/ac/msg10004.html

So you suggest one should use libtool from macports on mac?

Stephan

Re: r35767 - lyx-devel/trunk/lib/doc

[Richard Heck]

On 10/21/2010 07:50 PM, Pavel Sanda wrote:

sa...@lyx.org wrote:
   

Author: sanda
Date: Fri Oct 22 01:34:22 2010
New Revision: 35767
URL: http://www.lyx.org/trac/changeset/35767

Log:
(no log message)

Modified:
lyx-devel/trunk/lib/doc/Additional.lyx
 

i looked why lyx ignored my message and it looks that
Alert::askForText(response, _("LyX VC: Log Message"));
does not return messages anymore in trunk.

   
For how long? Could be a consequence of recent changes to asynchronous 
Alert::*.


rh

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/21/2010 07:17 PM, Vincent van Ravesteijn wrote:


Status bar: Moving icons. Text. Messages.

Op 22 okt 2010 01:13 schreef "Pavel Sanda" >:


Richard Heck wrote:
> On 10/20/2010 08:59 PM, Peter Kümmel wrote:
>> Am Dienstag, den 19.10.2010, 20...

i checked that export works on simple document here too.
but now we have new problem - how to notice user that exporting is still
in progress or finished (some subvserion of hourglass cursor?).


Along these same lines, I wonder if we should pop up an info box when
the export is done. If it takes a while, then the user may not notice the
status message, and those get over-written quickly, anyway.

In a way, that would solve this issue: It's still going until you get 
told that

it's not.

Richard

Re: r35575 - lyx-devel/trunk/src

[Stephan Witt]

Am 22.10.2010 um 15:28 schrieb Stephan Witt:

> Am 22.10.2010 um 02:11 schrieb Pavel Sanda:
> 
>> Stephan Witt wrote:
>> 
>>> @@ -212,8 +213,9 @@
>>> docstring text = bformat(_("Reverting to the stored version of the "
>>> "document %1$s will lose all current 
>>> changes.\n\n"
>>> "Do you want to revert to the older version?"), 
>>> file);
>>> -   int const ret = Alert::prompt(_("Revert to stored version of 
>>> document?"),
>>> -   text, 0, 1, _(""), _(""));
>>> +   bool const doask = vcs->revertWithConfirmation();
>> 
>> i would need to check whats above this function in guiview but isn't 
>> possible that we will skip
>> reverting in case the document is edited but not saved?
> 
> Yes, so it is. Then reverting should be guarded with revertEnabled() too?

The simpler solution would be to check owner_->isClean() in 
CVS::revertWithConfirmation()...

Stephan

New thread offshoot ( Re: r35767 - lyx-devel/trunk/lib/doc )

[Pavel Sanda]

Richard Heck wrote:
> On 10/21/2010 07:50 PM, Pavel Sanda wrote:
>> sa...@lyx.org wrote:
>>
>>> Author: sanda
>>> Date: Fri Oct 22 01:34:22 2010
>>> New Revision: 35767
>>> URL: http://www.lyx.org/trac/changeset/35767
>>>
>>> Log:
>>> (no log message)
>>>
>>> Modified:
>>> lyx-devel/trunk/lib/doc/Additional.lyx
>>>  
>> i looked why lyx ignored my message and it looks that
>> Alert::askForText(response, _("LyX VC: Log Message"));
>> does not return messages anymore in trunk.
>>
>>
> For how long? Could be a consequence of recent changes to asynchronous 
> Alert::*.

git bisect shows its somewhere around 35734-35742 which are almost all Peter's
commits. direct one is difficult obtain since it won't build due to the mess in 
makefiles...

i wonder why Alert:: code is affected when no preview or export is done?

pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Richard Heck wrote:
> Along these same lines, I wonder if we should pop up an info box when
> the export is done. If it takes a while, then the user may not notice the
> status message, and those get over-written quickly, anyway.
>
> In a way, that would solve this issue: It's still going until you get told 
> that
> it's not.

previously we had to wait some time for generation now we will spend it via
mouse haunting of ok button :) why can't we have the normal mouse cursor
with small hourglass cursor as windows have when something goes in background?

pavel

Re: r35575 - lyx-devel/trunk/src

[Stephan Witt]

Am 22.10.2010 um 15:28 schrieb Stephan Witt:

> Am 22.10.2010 um 02:11 schrieb Pavel Sanda:
> 
>> Stephan Witt wrote:
> While doing some "stress test" with checkIn() I found the error message when 
> merge is needed
> "Something's wrong with cvs commit" not acceptable. Then I tried to change 
> that and failed to
> solve it because of the stderr output of the VC command is lost silently. So 
> I came to the
> idea to implement getStatus() and use the result accordingly.
> 
> The result would be one out of
> * uptodate
> * locally modified
> * needs checkout
> * needs merge
> * no cvs file
> 
> The checkInWithMessage() implementation would be then
> { return getStatus() == LocallyModified; }
> And the checkIn() would do a switch on the getStatus() and
> raise more descriptive error messages according the status.

Unfortunately this doesn't solve all possible cases.
If the checkout is not the head version you cannot commit any changes.
But the "cvs status" output isn't aware of that - it's locally modified only.
In this case the error message of the commit is needed to tell the user what 
happened.
Hmm, isn't it possible to get both stdout and stderr from doVCcommandCall() 
into some result?

> 
> But I can change the style to be more verbose if you like.
> E. g.
> 
>   if (vcs->checkInWithMessage()) {
>   log = vcs->checkIn(to_utf8(empty));
>   // Reserve empty string for cancel button
>   if (log.empty())
>   log = to_utf8(empty);
>   } else if (Alert::askForText(response, _("LyX VC: Log Message"))) {
>   if (response.empty())
>   response = empty;
>   log = vcs->checkIn(to_utf8(response));
>   // Reserve empty string for cancel button
>   if (log.empty())
>   log = to_utf8(empty);
>   } else {
>   LYXERR(Debug::LYXVC, "LyXVC: user cancelled");
>   }

Sorry, I meant "if (!vcs->checkInWithMessage()) {" ...

Stephan

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Edwin Leuven]

i suppose for the same reason that we cannot have a pointing finger
when the mouse hovers something clickable...

On 2010-10-22, Pavel Sanda  wrote:
> Richard Heck wrote:
>> Along these same lines, I wonder if we should pop up an info box when
>> the export is done. If it takes a while, then the user may not notice the
>> status message, and those get over-written quickly, anyway.
>>
>> In a way, that would solve this issue: It's still going until you get told
>>
>> that
>> it's not.
>
> previously we had to wait some time for generation now we will spend it via
> mouse haunting of ok button :) why can't we have the normal mouse cursor
> with small hourglass cursor as windows have when something goes in
> background?
>
> pavel
>


-- 
http://leuven.economists.nl

Re: r35575 - lyx-devel/trunk/src

[Pavel Sanda]

Stephan Witt wrote:
> > the error case is suspicious. if tempName fails or "cvs diff" fails how you 
> > detect
> > this on a higher stage? cmiiw but if something fails you identify it with 
> > having
> > empty diff, which looks wrong, even more if you release lock automatically 
> > in such
> > a case...
> 
> Your right. I'll try to come up with a better solution.
> BTW, I copied the tmpf allocation code sequence.
> I think the debug message does not need to print the empty tmpf.
> 
> But I've found another way to solve the same goal - using "cvs status".
> Checking for the diff is not good enough.
> 
> While doing some "stress test" with checkIn() I found the error message when 
> merge is needed
> "Something's wrong with cvs commit" not acceptable. Then I tried to change 
> that and failed to
> solve it because of the stderr output of the VC command is lost silently. So 
> I came to the
> idea to implement getStatus() and use the result accordingly.
> 
> The result would be one out of
> * uptodate
> * locally modified
> * needs checkout
> * needs merge
> * no cvs file
> 
> The checkInWithMessage() implementation would be then
> { return getStatus() == LocallyModified; }
> And the checkIn() would do a switch on the getStatus() and
> raise more descriptive error messages according the status.

sorry is starts to go beyond my head, cf end of the mail...

> >> --- src/LyXVC.cpp  (Revision 35732)
> >> +++ src/LyXVC.cpp  (Arbeitskopie)
> >> @@ -163,9 +163,10 @@
> >>docstring empty(_("(no log message)"));
> >>docstring response;
> >>string log;
> >> -  bool ok = Alert::askForText(response, _("LyX VC: Log Message"));
> >> +  bool dolog = vcs->checkInWithMessage();
> >> +  bool ok = !dolog || Alert::askForText(response, _("LyX VC: Log 
> >> Message"));
> > 
> > hmm, but if !dolog then user automatically gets "cancel" message?
> 
> You mean the user should have the option to cancel the operation if the file 
> is up-to-date?
> Seems reasonable.

i meant that there is currently else part in code below (not seen in patch) 
which
triggers cancel message, just in case no diff was found.

> >>if (ok) {
> >> -  if (response.empty())
> >> +  if (dolog && response.empty())
> >>response = empty;
> > 
> > why response=empty harms in !nodolog?
> 
> It doesn't harm. It wastes CPU cycles to set response when !nodolog.

the problem is how can various rcs/svn/cvs version react on empty message
as parameter. compared to this few cpu cycles are negligible.

> >> @@ -212,8 +213,9 @@
> >>docstring text = bformat(_("Reverting to the stored version of the "
> >>"document %1$s will lose all current 
> >> changes.\n\n"
> >>"Do you want to revert to the older version?"), 
> >> file);
> >> -  int const ret = Alert::prompt(_("Revert to stored version of 
> >> document?"),
> >> -  text, 0, 1, _(""), _(""));
> >> +  bool const doask = vcs->revertWithConfirmation();
> > 
> > i would need to check whats above this function in guiview but isn't 
> > possible that we will skip
> > reverting in case the document is edited but not saved?
> 
> Yes, so it is. Then reverting should be guarded with revertEnabled() too?

either ask for isClean or not touch revert at all

> >> +  int const ret = doask ? Alert::prompt(_("Revert to stored version of 
> >> document?"),
> >> +  text, 0, 1, _(""), _("")) : 0;
> > 
> > correspondingly to your previous coding style one would expect ret = doask 
> > && prompt ;  ;)
> 
> I don't think so. The first is bool and the second is int.
> But I can change the style to be more verbose if you like.

not let it as it is. it was kind of joke.

> BTW, I have the problem that returning strings as result code is strange.
> And SVN::checkOut() implementation returns the a non empty string on error
> when the temporary log file name cannot be generated.

yes its ugly hack and i did it because there was no reasonable way how to pass
return info to user at the moment i implemented (this should be better now).

there are many things which can be improved inside revision control code
implementation however i want recall our original settlement - do some changes
inside CVS but dont touch API at this stage of development. i dont have time to
reimplement things and test all possible usescases again before public release
of 2.0.

you wanted to fix that bug that we ask for log even if only lock (or something
like that in cvs) is to be relased, ok, but please dont go beyond that.

pavel

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Vincent van Ravesteijn]

Jurgen,

Because I love to nitpick:

+void GuiApplication::processFuncRequestQueueAsync()
+{
+   // We perform the events asynchronously. This prevents potential
+   // problems in case the BufferView is closed within an event.

Well, this comment is not in the right position after all. The
decision to do it asynchronously is made where
processFuncRequestQueueAsync is called in stead of
processFuncRequestQueue. Besides, later on, noone will understand why
the BufferView determines that we process the events asynchronously
when we are in a function called "Async()".

+   /// add a func request to the queue for later procession
+   void addtoFuncRequestQueue(FuncRequest const &);

typo -> "procession" -> "processing"

+   /// process the func request in the queue asynchronously
+   void processFuncRequestQueueAsync();

typo -> "func request" -> "func requests", as there are usually
multiple func requests that form a queue.

+   /// add a func request to the queue for later procession
+   void addtoFuncRequestQueue(FuncRequest const &);
+   /// process the func request in the queue asynchronously
+   void processFuncRequestQueueAsync();
+   /// add a func request to the queue and process it asynchronously
+   void dispatchDelayed(FuncRequest const &);

Why not renaming dispatchDelayed to processFuncRequestAsync() ? (If we
even still need this function).

- First, this matches the other related functions and the difference
is immediately clear.

- Second, the function name uses the same terminology as the comment.

- Third, it's confusing to unnecessarily mix up the terminology:
* "dispatch / processFuncRequest"
* "delayed / asynchronous"

Vincent

Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files

[Vincent van Ravesteijn]

While eating I thought of more.


>I moved the functions to another place in the header and made
>dispatchDelayed a private function, since it's now only used in
>GuiApplication itself.

I think it's better to make it public anyway.
- the fact whether a function is public or private should be based
more on its functionality and whether it may be used from outside this
class, than on the fact whether it's actually used from outside.
Imagine writing the Qt library. It would be a PITA if they would have
made all function that are not used from outside the library
inaccessible (as you can't use the library then without modifying it
yourself);

- the function only calls two public functions, so it can be public
itself I guess;

- I would prefer the declarations to be next to each other;

- if someone wants to use GuiApplication to asynchronously process a
func request, he now may start wondering why he can only process a
queue aynchronously, but not a single func request. Then he has to
think for himself that he should add the function to the queue and
then process the queue async. If this seems obvious, we wouldn't need
this dispatchDelayed function anyway. If it seems less obvious, it
should be more important to offer it public as a user using this class
generally has no knowledge about the internals, while someone writing
the internals of this class has.



Last, I said it was strange that dispatchDelayed uses the term
dispatch, while the others use the term processFuncRequest. This is
very confusing too in other parts of the code as we use ::dispatch(..)
both to send FuncRequests to the event loop as well as to process
FuncRequests we receive from the event loop. I guess we can rename all
dispatch functions of the first category to something consistent.

Vincent

Re: New thread offshoot ( Re: r35767 - lyx-devel/trunk/lib/doc )

[Richard Heck]

On 10/22/2010 10:42 AM, Pavel Sanda wrote:

Richard Heck wrote:
   

On 10/21/2010 07:50 PM, Pavel Sanda wrote:
 

sa...@lyx.org wrote:

   

Author: sanda
Date: Fri Oct 22 01:34:22 2010
New Revision: 35767
URL: http://www.lyx.org/trac/changeset/35767

Log:
(no log message)

Modified:
 lyx-devel/trunk/lib/doc/Additional.lyx

 

i looked why lyx ignored my message and it looks that
Alert::askForText(response, _("LyX VC: Log Message"));
does not return messages anymore in trunk.


   

For how long? Could be a consequence of recent changes to asynchronous
Alert::*.
 

git bisect shows its somewhere around 35734-35742 which are almost all Peter's
commits. direct one is difficult obtain since it won't build due to the mess in 
makefiles...

i wonder why Alert:: code is affected when no preview or export is done?

   
All the Alert::* routines were changed so that they figure out whether 
they are in the main thread and then perform whatever magic is necessary 
if they are not. I think I understand it now, though, so I'll have a 
quick look in a bit.


rh

Re: New thread offshoot ( Re: r35767 - lyx-devel/trunk/lib/doc )

[Richard Heck]

On 10/22/2010 01:01 PM, Richard Heck wrote:

On 10/22/2010 10:42 AM, Pavel Sanda wrote:

Richard Heck wrote:

On 10/21/2010 07:50 PM, Pavel Sanda wrote:

sa...@lyx.org wrote:


Author: sanda
Date: Fri Oct 22 01:34:22 2010
New Revision: 35767
URL: http://www.lyx.org/trac/changeset/35767

Log:
(no log message)

Modified:
 lyx-devel/trunk/lib/doc/Additional.lyx


i looked why lyx ignored my message and it looks that
Alert::askForText(response, _("LyX VC: Log Message"));
does not return messages anymore in trunk.



For how long? Could be a consequence of recent changes to asynchronous
Alert::*.
git bisect shows its somewhere around 35734-35742 which are almost 
all Peter's
commits. direct one is difficult obtain since it won't build due to 
the mess in makefiles...


i wonder why Alert:: code is affected when no preview or export is done?

All the Alert::* routines were changed so that they figure out whether 
they are in the main thread and then perform whatever magic is 
necessary if they are not. I think I understand it now, though, so 
I'll have a quick look in a bit.



Unfortunately, I don't see why this would be. Guess we need to ask Peter.

rh

Re: [Patch] Improving the Citation GUI.

[John McCabe-Dansted]

This patch got buried when I was distracted by my thesis. Apologies
for the delay.

I address the comments to the previous patch.

Notes:
1) The potential security issue has been addressed by only using LyX's viewers.
2) Richard suggested that I regenerate the filename/url on demand, I
discuss why I don't think this is cleaner: because we cannot update
the other bibliographic information on demand and so generating the
filename on demand increases the likelyhood that a future bug would
cause the filename to become out-of-sync with e.g. the filename
displayed in the tooltip.
3) While I was editing the CitationUi.ui, I cut down on vertical
spacing so that this dialog can display all the buttons on my netbook
with a 1024x600 screen. I think that 1024x600 screens should be
supported though there may be a better way of doing this.

On Tue, Mar 23, 2010 at 10:18 PM, rgheck  wrote:
>>> I haven't tested this or even looked at the UI. Just some general
>>> comments.
>>> But generally it looks good to me.
>>>
>>> That said, I'm a bit unsure about the file part. There are security risks
>>> there. True, people usually put pdfs there, not shell scripts, but you
>>> can
>>> see the worry. By the same token, we might want to check the URL and make

OK, the updated patch now fixes used viewURL for URL, and adds a
similar function viewFile, that uses the existing LyX viewers.

> I meant not to use camel case, like "citationFile" but instead to use
> underscores like "citation_file". And yes, you are right, names of private
> members should end in an underscore. I'm not sure why I left that off. I
> think because I was anticipating the next point.

The camel case has been removed.

>>> A more general question is whether you really need or want these
>>> variables.
>>> I think we can just re-calculate if one of the buttons gets pushed. This
>>> will not take enough time to be noticeable. Caching the values costs
>>> memory,
>>> and it means we have to be careful always to keep it in sync with the
>>> dialog, which invites bugs.
>>
>> Well, the issue isn't so much time as deciding which citation we want
>> to open. To know this we would have to decide which LV has focus (what
>> if neither has focus?) and then pick the selected item of the LV. This
>> seems more complex and bug prone than updating citationURL_ and
>> citationFile_ in the same place we update keytxt. Keeping two extra
>> filenames in memory probably isn't any more noticeable than the time
>> needed to recalculate them.
>
> What makes this complicated is the code needed to figure out what the
> selected index is. Let me work on this.

It seems to me that GuiCitation::updateInfo() must be called whenever
we change the selection so that e.g. the displayed citation is
updated. Even if it is not called, it is probably best that we open
the file that matches the bibliographic information displayed. For
example, we cannot set the Tooltip on demand so the ToolTip has to be
"cached". May as well "cache" the actual name of the file to be opened
so that even if a bug stops updateInfo being updated we always open
the file listed in the tooltip.

-- 
John C. McCabe-Dansted
Index: frontends/qt4/GuiCitation.cpp
===
--- frontends/qt4/GuiCitation.cpp	(revision 35745)
+++ frontends/qt4/GuiCitation.cpp	(working copy)
@@ -22,12 +22,14 @@
 #include "Buffer.h"
 #include "BiblioInfo.h"
 #include "BufferParams.h"
+#include "Format.h"
 #include "FuncRequest.h"
 
 #include "insets/InsetCommand.h"
 
 #include "support/debug.h"
 #include "support/docstring.h"
+#include "support/FileName.h"
 #include "support/gettext.h"
 #include "support/lstrings.h"
 
@@ -154,6 +156,28 @@
 }
 
 
+void GuiCitation::on_urlPB_clicked()
+{
+	formats.viewURL(to_filesystem8bit(citation_url_));
+}
+
+
+void GuiCitation::on_filePB_clicked()
+{
+	string filename = to_filesystem8bit(citation_file_);
+	size_t pos = filename.find(":");
+	if (pos != string::npos) {
+		filename = filename.substr(pos + 1);
+	} else {
+		lyxerr << "file entry \"" << filename
+			<< "\" does not contain ':' (missing JabRef filetype; "
+			<< "but we don't need it anyway)\n";
+	}
+
+	formats.viewFile(FileName(filename));
+}
+
+
 void GuiCitation::on_okPB_clicked()
 {
 	applyView();
@@ -363,8 +387,16 @@
 		return;
 	}
 
-	QString const keytxt = toqstr(
-		bi.getInfo(qstring_to_ucs4(idx.data().toString()), buffer(), true));
+	docstring key = qstring_to_ucs4(idx.data().toString());
+
+	QString const keytxt = toqstr(bi.getInfo(key, buffer(), true));
+	citation_url_ = bi.getURL(key);
+	citation_file_ = bi.getFile(key);
+	urlPB->setEnabled(!citation_url_.empty());
+	urlPB->setToolTip(QString(to_utf8(citation_url_).c_str()));
+	filePB->setEnabled(!citation_file_.empty());
+	filePB->setToolTip(QString(to_utf8(citation_file_).c_str()));
+
 	infoML->document()->setHtml(keytxt);
 }
 
Index: frontends/qt4/GuiCitation.h

Bookmark test on MacOSX

[Vincent van Ravesteijn]

Hi,

Can someone on a Mac test the following ?

- open LyX
- open a document
- save a bookmark
- close the document and make sure you don't have any views left
- try to navigate to the bookmark

Does LyX now assert ?

Thanks,

Vincent

Re: Bookmark test on MacOSX

[BH]

On Fri, Oct 22, 2010 at 2:33 PM, Vincent van Ravesteijn  wrote:
> Hi,
>
> Can someone on a Mac test the following ?
>
> - open LyX
> - open a document
> - save a bookmark
> - close the document and make sure you don't have any views left
> - try to navigate to the bookmark
>
> Does LyX now assert ?

Nope -- it works fine for me with near current svn (built yesterday).

BH

Re: Bookmark test on MacOSX

[Vincent van Ravesteijn]

> Nope -- it works fine for me with near current svn (built yesterday).
>
> BH
>

Thanks.

But it is strange as I see this code:

"void GuiApplication::gotoBookmark(unsigned int idx, bool openFile,
   bool switchToBuffer)
{
   LASSERT(current_view_);

}

I don't understand this. On a Mac you can navigate to a bookmark
without a current_view_ right ??? Why don't you get an assert then ?
Did you understand that I meant to close all windows, such that you
only have a menubar of LyX ?

I've another question:

1. Open Lyx,
2. Open a document,
3. Choose View->Close Current View
4. Close All Windows
5. View->Invisible Buffers
6. Choose a buffer.

What happens now ?

Vincent

Re: Bookmark test on MacOSX

[BH]

On Fri, Oct 22, 2010 at 2:57 PM, Vincent van Ravesteijn  wrote:
>> Nope -- it works fine for me with near current svn (built yesterday).
>>
>> BH
>>
>
> Thanks.
>
> But it is strange as I see this code:
>
> "void GuiApplication::gotoBookmark(unsigned int idx, bool openFile,
>   bool switchToBuffer)
> {
>   LASSERT(current_view_);
> 
> }
>
> I don't understand this. On a Mac you can navigate to a bookmark
> without a current_view_ right ??? Why don't you get an assert then ?
> Did you understand that I meant to close all windows, such that you
> only have a menubar of LyX ?

Sorry -- I had other windows open. If I close everything else, and
then try navigating to a bookmark, I get an error "beep" and nothing
else happens. Moreover -- something I hadn't noticed before -- if all
windows are closed, it's not possible to open a new window using the
menus or keybindings. (It is possible to double click on a LyX
document in the Finder -- the file browser -- and have it open in
LyX.)

>
> I've another question:
>
> 1. Open Lyx,
> 2. Open a document,
> 3. Choose View->Close Current View
> 4. Close All Windows
> 5. View->Invisible Buffers
> 6. Choose a buffer.
>
> What happens now ?

Again, in this case, with no windows open, trying to open any new
window from within LyX fails. Once a window has been opened via the
Finder, I can then select invisible buffers, and the window is opened
as you'd expect.

Incidentally, in testing all this, I had LyX crash on me twice. I
don't have time now to get a backtrace, but let me know if you want me
to post one later.

BH

Re: Bookmark test on MacOSX

[Vincent van Ravesteijn]

> Sorry -- I had other windows open. If I close everything else, and
> then try navigating to a bookmark, I get an error "beep" and nothing
> else happens.

That must be the assert then.

>Moreover -- something I hadn't noticed before -- if all
> windows are closed, it's not possible to open a new window using the
> menus or keybindings. (It is possible to double click on a LyX
> document in the Finder -- the file browser -- and have it open in
> LyX.)

Does this mean that File->Open doesn't work as well ? and File->New
Windows ? and File->New ?

> Again, in this case, with no windows open, trying to open any new
> window from within LyX fails. Once a window has been opened via the
> Finder, I can then select invisible buffers, and the window is opened
> as you'd expect.

This is caused by the fact that BUFFER_SWITCH is implemented in GuiView.

> Incidentally, in testing all this, I had LyX crash on me twice. I
> don't have time now to get a backtrace, but let me know if you want me
> to post one later.
>

Yes, please.

Also please remember any recipe to get a bug, so you can test later
whether all things works then.

For now I see the following bugs:

- assert when navigate to bookmark,
- you can't switch to invisible buffers,
- you can't open a new window by menus,
- some crashes.

Vincent

Re: Bookmark test on MacOSX

[BH]

On Fri, Oct 22, 2010 at 3:25 PM, Vincent van Ravesteijn  wrote:
>> Sorry -- I had other windows open. If I close everything else, and
>> then try navigating to a bookmark, I get an error "beep" and nothing
>> else happens.
>
> That must be the assert then.

No. It's just the OS's warning beep that you're trying to do something
you can't do. LyX keeps running along just fine.

>>Moreover -- something I hadn't noticed before -- if all
>> windows are closed, it's not possible to open a new window using the
>> menus or keybindings. (It is possible to double click on a LyX
>> document in the Finder -- the file browser -- and have it open in
>> LyX.)
>
> Does this mean that File->Open doesn't work as well ? and File->New
> Windows ? and File->New ?

Yes.

>> Again, in this case, with no windows open, trying to open any new
>> window from within LyX fails. Once a window has been opened via the
>> Finder, I can then select invisible buffers, and the window is opened
>> as you'd expect.
>
> This is caused by the fact that BUFFER_SWITCH is implemented in GuiView.
>
>> Incidentally, in testing all this, I had LyX crash on me twice. I
>> don't have time now to get a backtrace, but let me know if you want me
>> to post one later.
>>
>
> Yes, please.
>
> Also please remember any recipe to get a bug, so you can test later
> whether all things works then.

I don't have a recipe now, which is why it will take longer than I now
have to do it

> For now I see the following bugs:
>
> - assert when navigate to bookmark,

Again, I'm not seeing this.

> - you can't switch to invisible buffers,

Only when no window is open. (When other windows are open, it works fine.)

> - you can't open a new window by menus,

Again, only when no window is open.

> - some crashes.

Yep.

BH

Re: Bookmark test on MacOSX

[Vincent van Ravesteijn]

Yet another question.

If you normally would reconfigure LyX, you get a message like "Running
configure..." in the status bar. Then you know you have to wait.

What do you expect on Mac if you don't have any window open ? Now,
there is no way of telling that configure is running, right ?

Do you expect some sort of message popping up ? Do you expect a
message box on your screen (as you probably don't want to do any work
as you don't even have a view open). Do you expect a sheet to slide
down from your menu bar ?

Vincent

Fwd: Bookmark test on MacOSX

[Vincent van Ravesteijn]

Yet another question.

If you normally would reconfigure LyX, you get a message like "Running
configure..." in the status bar. Then you know you have to wait.

What do you expect on Mac if you don't have any window open ? Now,
there is no way of telling that configure is running, right ?

Do you expect some sort of message popping up ? Do you expect a
message box on your screen (as you probably don't want to do any work
as you don't even have a view open). Do you expect a sheet to slide
down from your menu bar ?

Vincent

Re: Bookmark test on MacOSX

[Vincent van Ravesteijn]

> Incidentally, in testing all this, I had LyX crash on me twice. I
> don't have time now to get a backtrace, but let me know if you want me
> to post one later.
>
> BH
>

I think the culprit might be in this code:

void GuiApplication::processKeySym(KeySymbol const & keysym, KeyModifier state)
{
LYXERR(Debug::KEY, "KeySym is " << keysym.getSymbolName());

// Do nothing if we have nothing (JMarc)
if (!keysym.isOK()) {
LYXERR(Debug::KEY, "Empty kbd action (probably composing)");
current_view_->restartCursor();
return;
}
  [..]
}

So, if you don't have any window open and when you send a key
combination to LyX which is not OK, LyX will crash on current_view_.

Vincent

Re: Bookmark test on MacOSX

[Vincent van Ravesteijn]

On Fri, Oct 22, 2010 at 10:34 PM, Vincent van Ravesteijn  wrote:
>> Incidentally, in testing all this, I had LyX crash on me twice. I
>> don't have time now to get a backtrace, but let me know if you want me
>> to post one later.
>>
>> BH
>>


I fixed a number of problems that might occur without a view in
http://www.lyx.org/trac/changeset/35787.

Hope it crashes less now.

Vincent

Re: LyX Additional features Version 1.6.7 suggested corrections

[John R Hudson]

Hi Pavel

Thanks. Will do.

I will change to 2.0 - Uwe has just made the same suggestion. The way I have 
worked in the past was because that was the instruction in the Help files when 
I first began submitting changes occasionally some years ago.

John
-- 

On Friday 22 October 2010 20:08:50 you wrote:
> John R Hudson wrote:
> > Hi Richard
> > 
> > Here are some suggested corrections for the Additional features manual.
> 
> Hello John,
> 
> most corrections are in.
> 
> > 5.1.1 Introduction
> > [Version 7.00 (Jauary 2010) is available from the website listed; so this
> > whole section needs to be updated; I am happy to have a go at this if you
> > would like]
> 
> nobody else will do otherwise ;)
> 
> > 5.13 Kluwer
> > [Kluwer is now part of Springer and the url links to:
> > http://www.springer.com/?SGWID=0-102-0-0-0
> > ? delete whole section]
> 
> if delete then not only this sections but other kluwer related stuff we
> have, dunno whether this should happen.
> 
> > 5.19 RevTeX4
> > [paragraph 1]The Revtex 4 textclass works with the American Physical
> > Sociey's RevTeX 4.1 class. [I haven't tried this but RevTeX4.1 was
> > issued in August 2010 and the announcement refers mostly to bugfixes and
> > additional features and only mentions having the most recent version of
> > natbib installed as essential]
> 
> iirc there has been some movement in trunk wrt revtex. perhaps this didn't
> got updated.
> 
> > 6.1 Checking TeX
> > [chktex is now listed as obsolete in CTAN; this section needs deleting]
> 
> iirc its still living and JMarc is one of its maintainers.
> 
> > 6.2.2.5 Undo Last Checkin
> > This pretends that the last check in never happened . . . ['pretends
> > that' is more idiomatic]
> 
> but the last checkin is really deleted, so this is not good description
> either.
> 
> 
> last but not least - its tedious work to manually enter again the
> corrections and its must be even more tedious for you. why can't we use
> change tracking? or -- if its not technical problem for you - use living
> version of manuals via subversion and send us patches? it would take 5% of
> time on both sides.
> 
> also using lyx 2.0 from trunk would make possible to review new changes
> from 1.6 to 2.0 due to the comparison feature.
> 
> thanks for your review,
> pavel

Re: LyX Additional features Version 1.6.7 suggested corrections

[Pavel Sanda]

John R Hudson wrote:
> Hi Pavel
> 
> Thanks. Will do.
> 
> I will change to 2.0 - Uwe has just made the same suggestion. The way I have 
> worked in the past was because that was the instruction in the Help files 
> when 
> I first began submitting changes occasionally some years ago.

btw are you able to use subversion?
pavel

Re: LyX Additional features Version 1.6.7 suggested corrections

[Julien Rioux]

On 22/10/2010 4:15 PM, John R Hudson wrote:

5.19 RevTeX4
>  >  [paragraph 1]The Revtex 4 textclass works with the American Physical
>  >  Sociey's RevTeX 4.1 class. [I haven't tried this but RevTeX4.1 was
>  >  issued in August 2010 and the announcement refers mostly to bugfixes and
>  >  additional features and only mentions having the most recent version of
>  >  natbib installed as essential]

 iirc there has been some movement in trunk wrt revtex. perhaps this didn't
 got updated.


The text above is incorrect. The current revtex4.layout expects revtex4.cls

When creating version 4.1, the author of the latex class file found it 
necessary to have a different file name (revtex4-1.cls) and revtex4.cls 
was removed completely from CTAN, rendering it obsolete.


Currently LyX does not ship a layout file for revtex 4.1

--
Julien

Re: Some thoughts on further development process towards beta and RCs

[Vincent van Ravesteijn]

> ok, thanks for the info. unless Vincent put it in, i will do before
> beta goes out.
>

I looked at the patch again and in the Qt Docs and I read:

{{{

void QClipboard::dataChanged () [signal]

This signal is emitted when the clipboard data is changed.

On Mac OS X and with Qt version 4.3 or higher, clipboard changes made
by other applications will only be detected when the application is
activated.

}}}

Can someone on a Mac then please explain me that this is no problem.
Or do I misunderstand this sentence? Does it mean that if application
X changes the clipboard, application X should be activated ?

Anyway, if the Mac people tested it, I will put it in.

It would be nice if someone could think of a way to try to let another
application change the clipboard without it being activated.

Vincent

Re: Bookmark test on MacOSX

[Peter Kümmel]

 A. Am Freitag, den 22.10.2010, 22:34 +0200 schrieb Vincent van
Ravesteijn:
> > Incidentally, in testing all this, I had LyX crash on me twice. I
> > don't have time now to get a backtrace, but let me know if you want me
> > to post one later.
> >
> > BH
> >
> 
> I think the culprit might be in this code:
> 
> void GuiApplication::processKeySym(KeySymbol const & keysym, KeyModifier 
> state)
> {
>   LYXERR(Debug::KEY, "KeySym is " << keysym.getSymbolName());
> 
>   // Do nothing if we have nothing (JMarc)
>   if (!keysym.isOK()) {
>   LYXERR(Debug::KEY, "Empty kbd action (probably composing)");
>   current_view_->restartCursor();
>   return;
>   }
>   [..]
> }
> 
> So, if you don't have any window open and when you send a key
> combination to LyX which is not OK, LyX will crash on current_view_.
> 
> Vincent

I've also seen crashes in processKeySym:

- Open LyX
- Load a file
- Menu->Document->Outline
- create several new documents by simply pressinc Crtl-N for several
seconds
- then close all by pressing Ctrl-W
- crash

(I've not checked with your latest changes)

Peter

Re: Some thoughts on further development process towards beta and RCs

[Peter Kümmel]

Am Sonntag, den 17.10.2010, 18:28 +0200 schrieb Pavel Sanda:
> John McCabe-Dansted wrote:
> > > the most problematic cases of our copy typically happen when
> > > middle button is used for getting, or puting stuff from/into another
> > > applications and when more lyx instances are used. dunno whether
> > > the patch affects these use cases... its very fragile stuff and i
> > > remeber having some hard debugging nights, thats why i fear to take
> > > responsibility for this patch :)
> > 
> > This patch shouldn't affect middle click, as it only caches the
> > clipboard status, not the "Primary Selection". Also, I have been using
> > the patch for months, use middle-click extensively, and haven't
> > noticed anything wrong. I think this patch has also been sitting in
> > Vincent's tree. I presume he hasn't noticed any regressions.
> 
> ok, thanks for the info. unless Vincent put it in, i will do before
> beta goes out.
> 
> pavel

Re: New thread offshoot ( Re: r35767 - lyx-devel/trunk/lib/doc )

[Peter Kümmel]

Am Freitag, den 22.10.2010, 13:28 -0400 schrieb Richard Heck:
> >> i wonder why Alert:: code is affected when no preview or export is done?

It was a bug in InGuiThread.h, see commit message:

"bind makes a copy of the arguments by default. This is secure if the
bound object survives the existence of the arguments, but it also breaks
"change by non-const reference"  parameter passing, like in
Alert::askForString. Here the arguments exists the whole bound function
call so we could pass by reference."

> I think I understand it now, though
Multi threading isn't that hard ;)
And have a look at bind:
"you can go a long way with just boost::bind"

Peter

Re: Bookmark test on MacOSX

[BH]

On Fri, Oct 22, 2010 at 4:08 PM, Vincent van Ravesteijn  wrote:
> Yet another question.
>
> If you normally would reconfigure LyX, you get a message like "Running
> configure..." in the status bar. Then you know you have to wait.
>
> What do you expect on Mac if you don't have any window open ? Now,
> there is no way of telling that configure is running, right ?

Right -- there's no way to tell it's reconfiguring if no window is
open. However, even if a window is open, the "Reloading configuration
..." message doesn't show up until *after* the "The system has been
reconfigured" message has popped up. That's a bug.

> Do you expect some sort of message popping up ? Do you expect a
> message box on your screen (as you probably don't want to do any work
> as you don't even have a view open). Do you expect a sheet to slide
> down from your menu bar ?

Normally, I'd expect some form of progress indicator -- a spinner or
an indefinite progress bar, for example -- to appear, possibly in the
frontmost window if there is one, or possibly in its own dialog.
(Sheets only slide down from windows, not the menu bar, and they are
supposed to be for modal dialogs that pertain to a particular window,
like save or print; they wouldn't be appropriate here.)

Perhaps Stephan should weigh in here

BH