Re: switch mouse to busy symbol

[Edwin Leuven]

Vincent van Ravesteijn v...@lyx.org wrote:
 I committed what works for me. I had it in my tree anyway.

i suspected something like that, thanks

ed.

Re: iPad?

[Abdelrazak Younes]

On 10/24/2010 07:53 PM, Richard Heck wrote:

On 10/24/2010 12:31 PM, David Whetstone wrote:
Hi, I'm new here.  I only recently joined this list.  I've recently 
acquired an iPad, and found myself wanting to be able to take notes 
with embedded equations and such.  AFAICT, no such app yet exists.


Then I thought about LyX.  Even if one was not able to compile a 
latex document on the ipad, LyX's editing features could still be 
very useful.  So my question is, how feasible is this?


I've spent the last couple of weeks on an exploratory mission - to 
see how hard it would be to build LyX for the iPad.  I've gotten as 
far as getting a clean build.  Completely non-functional, of course.  
Much in front-end and support is just stubbed out.  But it's a start.


I ask this question now because I've noticed recent comments to the 
effect of removing the GUI agnosticism that exists in the LyX 
codebase.  It's this agnosticism that gave me the idea that it just 
might be possible.


I realize it will be a lot of work.  But I think LyX for iPad could 
occupy a useful niche in the iPad appverse.  So tell me, am I wasting 
my time?


Well, as you presumably know, LyX depends pretty heavily upon Qt, both 
in the frontend and in support. Since Qt does not run on the iPad, 
you'd have to replace all of that. This is a massive undertaking. Some 
years ago, there was an attempt to produce a Gtk frontend for LyX. 
This was at a time when the core-gui stuff was much less entangled 
than it is now.


This is not true. The core and gui stuff was very much more entangled at 
this time than it is now... lots of glue glue code everywhere. Nowadays, 
all you have to do is to rewrite frontend/qt4. QtCore is also used in 
src/support/ but the project that listed below shows that this is not a 
problem. Still, having a ported QtGui is the much easier path of course.



That project was never completed. It'd be hard enough to do if LyX 
weren't a moving target.


I think maybe the way to go is to support the fledgling attempts to 
port Qt to the iPad. See this thread:

http://lists.trolltech.com/pipermail/qt-interest/2010-April/021359.html

If that were done, then LyX would run no problem.


Cheers,
Abdel.

Approaching LyX 1.6.8 [status update #1]

[Jürgen Spitzmüller]

This is just to let you know that I *do* have plans wrt LyX 1.6.8 :-)

I think another release is due. We have collected a range of fixes, including 
some important ones (the misdetection of pLaTeX with TeXLive 2010, and of 
course the crashes).

I see only two issues that should be sorted out before the release:

http://www.lyx.org/trac/ticket/6965
This is a crash in mathed due to a broken cursor. I'd appreciate if someone 
could have a look (I did, but this is not really my area of expertise).

http://www.lyx.org/trac/ticket/6967
A regression introduced within the 1.6.8 cycle. Vincent is on this, I think.

Please let me know of other issues. Note particularly that all fixes that 
entail a string change should go in very soon, since we will turn to string 
freeze soon.

Pavel, do you still have plans for a coordinated beta/branch release?

Jürgen
-*- text -*-

This file describes what has been done in the preparation of LyX 1.6.8
All comments are welcome.

I'd be glad if some of you could take the time to check it out (or fix
a bug or two if you are feeling adventurous). Let me recall that all
these fixes have been checked into the BRANCH_1_6_X branch, which you
can get with the command
  svn co svn://svn.lyx.org/lyx/lyx-devel/branches/BRANCH_1_6_X lyx-1.6.x

Juergen

[In this list, I try to group things by topic and in decreasing
order of importance. This is, of course, subjective...]


What's new
==


** Updates and new features:
***

* DOCUMENT INPUT/OUTPUT

- Add support for pBibTeX (formerly known as jBibTeX), a specific Japanese
  BibTeX variant (bug 6808).

- New environment variable LYX_FORCE_OVERWRITE allows changing default
  behavior when exporting from command line. Now LyX overwrites the main
  file by default, but not the ancillary files. Set this variable to
  all for letting LyX behave as in 1.6.6 and previous versions; set it
  to none for mimicking the 1.6.7 behavior of not overwriting any file.

- New layout and template file for submissions to journals published by
  the American Geophysical Union (AGU).

- New layout and template file for submissions to journals published by
  the Econometric Society (bug 6761).

- New layout and template file for the document class frletter that is
  used to write letters in French (bug 6915).

- New layout and template file for the document class lettre, another
  French letter class.

- Add support for subtitles in the KOMA classes.

- Add support for lists and quotes in the g-brief2 letter class
  (bug 6857).

- Add support for the math command \ot (part of bug 6872).


* USER INTERFACE

- Improve the detection of LaTeX warnings in the Log dialog.

- Citations in the outline now display the key (bug 6837).


* DOCUMENTATION AND LOCALIZATION

- Revised section 4.2 Footnotes of the EmbeddedObjects manual.

- Revised section 5.1 Installing a new LaTeX package of the
  Customization manual.

- Describe how to use formulas in program listings in sec. 7 of the
  EmbeddedObjects manual.

- Updated LaTeXConfig file.

- Updated English and German Linguistics manual.

- Updated French, German, Italian, Spanish and Slovak User
  Interface localizations.


* WINDOWS INSTALLER




* BUILD/INSTALLATION

- Allow autoconf 2.67.


** Bug fixes:
*

* DOCUMENT INPUT/OUTPUT

- Fix a crash when dropping multiple files onto LyX (bug 6944).

- Assure that Japanese LaTeX (pLaTeX) is in fact only used for Japanese
  documents. This fixes major configuration problems with TeXLive 2010.

- Fix the output of glyph 0x02e0 (MODIFIER LETTER SMALL GAMMA) (bug 6817).

- Load the amsmath LaTeX-package when the math command \dddot is used to
  avoid LaTeX errors (bug 6872).

- Do not popup invalid path warning when using View  Source (bug 6904).

- Small tweaks to the memoir text class.

- Allow pathnames with commas for BibTeX files (bug 6914).

- Set correct anchor for the link to the bibliography in the table
  of contents if hyperref is used (bug 6470).


* USER INTERFACE

- Do not allow to rename a format's short name if the format is used by a
  converter. This prevents a crash (bug 6815).

- Fix crash when mutating eqnarray-like environments with labeled lines
  to display equations (bug 6858).

- Disable cut and paste inside the Math Delimters dialog. This was of no
  use and could trigger a crash (bug 6942).

- Fix an assertion when unindenting empty lines in a listings inset
  (bug 6869).

- Box dialog: only shaded boxes can have multiple paragraphs if there
  is no inner box.

- Fix mouse wheel scrolling on Mac OS 10.6 (bug 6775).

- Fix tab-switching keyboard shortcut (bug 5970).

- Fix parsing of inline math environments nested in (unknown to LyX)
  text-mode user macros (bug 1337).

- When undo returns to a state where the file was saved, make sure to
  reset the (changed) status (bug 3733).

- Don't allow to insert margin notes and floats into tables because this
  would lead to LaTeX errors (bug 6844).

- Don't allow to insert margin 

Improvements to Recover Emergency File prompts. (pseudo-patch with discussion)

[John McCabe-Dansted]

I've been using a number of changes to Buffer::readFileHelper that
I've found useful. I err on the side off not delete emergency files,
and also add a Recover All option that is useful when you have a
master document that has several modified child documents.

I think that these modifications require a little discussion before
being formally proposed, so I discuss them inline rather than submit
them as a formal patch.

--
switch (Alert::prompt(_(Load backup?), text, 0, 2,
  _(Load backup), _(Load original),
  _(Cancel) ))
{
...
case 1:
-   // Here we delete the autosave
-   a.removeFile();

I don't see why we delete the autosave here. What I sometimes do is think:
   OK, I was doing some experimental stuff. I should probably open
the original file. Opps, I didn't do a proper save in the last hour,
never-mind I'll just restart LyX and pick load Backup. Huh, my
autosave file and all my work is gone!

Simply removing that line prevents that problem, and doesn't seem to
cause any significant regressions.

If we want to automatically delete the autosave file, I'd do it once
we have verified that the file is old and obsolete. E.g. something
like the psuedo-code:

IF auto-save is newer
Prompt user etc.
ELSE
delete auto-save.

-

-   if (!Alert::prompt(_(Delete emergency file?), str, 1, 
1,
-   _(Remove), _(Keep it))) {
-  ...

Well, here at least we warn the user that we are about to delete
stuff. However, when LyX crashes the only thing on my mind is getting
my data back as quickly as possible. I think we should just keep the
emergency file (unless it is obsolete). We could possibly ask the user
this question on shutdown.

Otherwise I'd add a Keep All option.

-
-   if (e.exists()  s.exists()  e.lastModified()  s.lastModified()) {
+
+   if (e.exists()  s.exists()  e.lastModified()  s.lastModified() 
+e.checksum() != s.checksum()) {

There are a number of ways to get a dirty buffer without actually
changing the file. E.g we can add two spaces that get converted to a
single space, or we can add a character and then remove it by
backspacing. This seems to happen fairly regularly to me, so it seems
worth checking for.

However I am not sure .checksum() is the best way to do it. The
checksum is a long, so even if we assume the checksum algorithm is
ideal, we still get a false positive once per 4 billion checks. It
seems like something like:
e.fileContents() == s.fileContents()
would be cleaner and just as fast. However that could use a lot of
memory on large files. It seems the best way would be to do:
e.fileContentsEqual(s)
where FileName::fileContentsEqual is a new method that compares the
two files in (say) 1MB chunks. However I think it would be adequate to
implement this as something like:

bool FileName::fileContentsEqual(FileName const  other_file)
{
return (d-fi.size() == other_file-fi.size() 
fileContents() == other_file-fileContents())
}

as
0) this is way simpler,
1)  it seems unlikely that we would have a single valid lyx file that
does not easily fit in memory,
2)  the file size check should stop us from loading emergency files
larger than the valid lyx file, and
3) we could always improve fileContentsEqual later if need be.

-
-   switch (Alert::prompt(_(Load emergency save?), text, 0, 2,
- _(Recover),  _(Load Original),
- _(Cancel)))
+   int ret;
+   if (recover_all) {
+   ret = 0;
+   } else {
+   ret = Alert::prompt(_(Load emergency save?),
+   text, 0, 2,
+   _(Recover),  _(Load Original),
+   _(Cancel), _(Recover All));
+   if (ret == 3) {
+   ret = 0;
+   recover_all = true;
+   }
+   }
+   switch (ret)

This is the code for the Recover All emergency save.

-- 
John C. McCabe-Dansted

[Patch] #3934 Document xxx converted to ver 1.4 should get the filename xxx_14.lyx

[John McCabe-Dansted]

As discussed in trac [1] naming lyx files .lyx14 makes them hard to
open in LyX. Richard suggested instead naming them .14.lyx [1], and
targeted this to 2.0.0, however this has not been touched since then.
This has a simple patch against configure.py that I have been using on
Linux for months without noticing any unexpected consequences.

Richard, should this patch (see also [2]) go into beta 1?

[1] http://www.lyx.org/trac/attachment/ticket/3934/
[2] http://www.lyx.org/trac/attachment/ticket/3934/configure.py.patch

-- 
John C. McCabe-Dansted


configure.py.patch
Description: Binary data

Re: PATCH for save-as and VC

[Pavel Sanda]

Stephan Witt wrote:
 Or I can go to rcs and you'll do the svn implementation?

i came to the conclusion that its less energy spent when i write the patch 
myself
than doing detailed review and flame about nitpicks.

please make documentation for the current cvs state inside additional manual
and indicate to the users what are the supposed usecases.

  here is the superflous-dialog fix which is on the top of your first patch.
  it basically (should) not change behaviour of svn and rcs and let you do 
  any 
  bussiness inside cvs (i let the cvs routines in your version.)
  untested, i will get to the svn/rcs part later.
 
 Ok. I went to sleep yesterday.
 I did commit the first patch now.
 (with typo corrected and the unused method revertWithConfirmation() removed.)
 
 One general question:
 What's the problem with the following construct?

you mean why i changed it to the virtual function?
generally no problem. in this particular case i changed the construct
in order to be consistent with the rest of other code we use.

pavel

Re: iPad?

[Richard Heck]

On 10/25/2010 03:52 AM, Abdelrazak Younes wrote:

On 10/24/2010 07:53 PM, Richard Heck wrote:

On 10/24/2010 12:31 PM, David Whetstone wrote:
Hi, I'm new here.  I only recently joined this list.  I've recently 
acquired an iPad, and found myself wanting to be able to take notes 
with embedded equations and such.  AFAICT, no such app yet exists.


Then I thought about LyX.  Even if one was not able to compile a 
latex document on the ipad, LyX's editing features could still be 
very useful.  So my question is, how feasible is this?


I've spent the last couple of weeks on an exploratory mission - to 
see how hard it would be to build LyX for the iPad.  I've gotten as 
far as getting a clean build.  Completely non-functional, of 
course.  Much in front-end and support is just stubbed out.  But 
it's a start.


I ask this question now because I've noticed recent comments to the 
effect of removing the GUI agnosticism that exists in the LyX 
codebase.  It's this agnosticism that gave me the idea that it just 
might be possible.


I realize it will be a lot of work.  But I think LyX for iPad could 
occupy a useful niche in the iPad appverse.  So tell me, am I 
wasting my time?


Well, as you presumably know, LyX depends pretty heavily upon Qt, 
both in the frontend and in support. Since Qt does not run on the 
iPad, you'd have to replace all of that. This is a massive 
undertaking. Some years ago, there was an attempt to produce a Gtk 
frontend for LyX. This was at a time when the core-gui stuff was much 
less entangled than it is now.


This is not true. The core and gui stuff was very much more entangled 
at this time than it is now... lots of glue glue code everywhere. 
Nowadays, all you have to do is to rewrite frontend/qt4. QtCore is 
also used in src/support/ but the project that listed below shows that 
this is not a problem. Still, having a ported QtGui is the much easier 
path of course.


I could be wrong, but I think we now have much more application logic in 
the Gui* classes then we did before the removal of all the Controller* 
classes. Perhaps alot of that could just be copied over, but it is still 
more work.


Anyway, I had a different thought, namely: If what you're looking at is 
more of a note-taking application with the ability to handle formulas, 
then there is a LOT of LyX that can remain in stub form. You probably 
don't need tables or any of the InsetCommand hierarchy. Probably not 
footnotes, etc. If so, then the problem becomes at least somewhat 
easier. Indeed, you might just want to fork us, as many of the 
improvements in LyX wouldn't be that relevant to what you were doing.


Richard

Re: PATCH for save-as and VC

[Stephan Witt]

Am 25.10.2010 um 13:02 schrieb Pavel Sanda:

 Stephan Witt wrote:
 Or I can go to rcs and you'll do the svn implementation?
 
 i came to the conclusion that its less energy spent when i write the patch 
 myself
 than doing detailed review and flame about nitpicks.

Ok. I finished the part2 of my patch using your patch.
(It had to be changed slightly because
 1. I'd corrected my mistake already (removed revertWithConfirmation) and
 2. the revert logic had to be corrected.)
Patch is attached. Ok to apply?

 please make documentation for the current cvs state inside additional manual
 and indicate to the users what are the supposed usecases.

I'll do that.

 here is the superflous-dialog fix which is on the top of your first patch.
 it basically (should) not change behaviour of svn and rcs and let you do 
 any 
 bussiness inside cvs (i let the cvs routines in your version.)
 untested, i will get to the svn/rcs part later.
 
 Ok. I went to sleep yesterday.
 I did commit the first patch now.
 (with typo corrected and the unused method revertWithConfirmation() removed.)
 
 One general question:
 What's the problem with the following construct?
 
 you mean why i changed it to the virtual function?

Yes :-)

 generally no problem. in this particular case i changed the construct
 in order to be consistent with the rest of other code we use.

I see.

Stephan

Index: src/VCBackend.h
===
--- src/VCBackend.h (Revision 35818)
+++ src/VCBackend.h (Arbeitskopie)
@@ -42,6 +42,8 @@
virtual std::string checkIn(std::string const  msg) = 0;
// can be this operation processed in the current RCS?
virtual bool checkInEnabled() = 0;
+   // should a log message provided for next checkin?
+   virtual bool isCheckInWithConfirmation() = 0;
/// check out for editing, returns log
virtual std::string checkOut() = 0;
// can be this operation processed in the current RCS?
@@ -56,6 +58,8 @@
virtual bool lockingToggleEnabled() = 0;
/// revert current edits
virtual void revert() = 0;
+   // should a confirmation before revert requested?
+   virtual bool isRevertWithConfirmation() = 0;
/// FIXME
virtual void undoLast() = 0;
// can be this operation processed in the current RCS?
@@ -129,6 +133,8 @@
 
virtual bool checkInEnabled();
 
+   virtual bool isCheckInWithConfirmation();
+
virtual std::string checkOut();
 
virtual bool checkOutEnabled();
@@ -143,6 +149,8 @@
 
virtual void revert();
 
+   virtual bool isRevertWithConfirmation();
+
virtual void undoLast();
 
virtual bool undoLastEnabled();
@@ -190,6 +198,8 @@
 
virtual bool checkInEnabled();
 
+   virtual bool isCheckInWithConfirmation();
+
virtual std::string checkOut();
 
virtual bool checkOutEnabled();
@@ -202,6 +212,8 @@
 
virtual bool lockingToggleEnabled();
 
+   virtual bool isRevertWithConfirmation();
+
virtual void revert();
 
virtual void undoLast();
@@ -287,6 +299,8 @@
 
virtual bool checkInEnabled();
 
+   virtual bool isCheckInWithConfirmation();
+
virtual std::string checkOut();
 
virtual bool checkOutEnabled();
@@ -301,6 +315,8 @@
 
virtual void revert();
 
+   virtual bool isRevertWithConfirmation();
+
virtual void undoLast();
 
virtual bool undoLastEnabled();
Index: src/LyXVC.cpp
===
--- src/LyXVC.cpp   (Revision 35818)
+++ src/LyXVC.cpp   (Arbeitskopie)
@@ -165,7 +165,9 @@
docstring empty(_((no log message)));
docstring response;
string log;
-   bool ok = Alert::askForText(response, _(LyX VC: Log Message));
+   bool ok = true;
+   if (vcs-isCheckInWithConfirmation())
+   ok = Alert::askForText(response, _(LyX VC: Log Message));
if (ok) {
if (response.empty())
response = empty;
@@ -214,8 +216,10 @@
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));
+   int ret = 0;
+   if (vcs-isRevertWithConfirmation())
+   ret = Alert::prompt(_(Revert to stored version of document?),
+   text, 0, 1, _(Revert), _(Cancel));
 
if (ret == 0)
vcs-revert();
Index: src/VCBackend.cpp
===
--- src/VCBackend.cpp   (Revision 35818)
+++ src/VCBackend.cpp   (Arbeitskopie)
@@ -195,7 +195,13 @@
return owner_  !owner_-isReadonly();
 }
 
+bool 

Re: [Patch] #3934 Document xxx converted to ver 1.4 should get the filename xxx_14.lyx

[Richard Heck]

On 10/25/2010 04:22 AM, John McCabe-Dansted wrote:

As discussed in trac [1] naming lyx files .lyx14 makes them hard to
open in LyX. Richard suggested instead naming them .14.lyx [1], and
targeted this to 2.0.0, however this has not been touched since then.
This has a simple patch against configure.py that I have been using on
Linux for months without noticing any unexpected consequences.

Richard, should this patch (see also [2]) go into beta 1?

[1] http://www.lyx.org/trac/attachment/ticket/3934/
[2] http://www.lyx.org/trac/attachment/ticket/3934/configure.py.patch

   

Committed. Thanks for the bump

Richard

Re: r35819 - lyx-devel/trunk/src

[Richard Heck]

On 10/25/2010 07:57 AM, v...@lyx.org wrote:

Author: vfr
Date: Mon Oct 25 13:57:56 2010
New Revision: 35819
URL: http://www.lyx.org/trac/changeset/35819

Log:
Refactor Buffer.cpp: loadLyXFile():

...

- add more ReadStatus elements to describe failures.

   

I get several warnings now about values not handled in Buffer::readString().

rh

Forked calls

[Pavel Sanda]

Most probably Peter,

is there some way how to get rid of this:
  CXXForkedCalls.o
  /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional: In 
static member function 'static void 
boost::detail::function::void_function_obj_invoker2FunctionObj, R, T0, 
T1::invoke(boost::detail::function::function_buffer, T0, T1) [with 
FunctionObj = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]':
  ../../boost/boost/function/function_template.hpp:913:   instantiated from 
'void boost::function2R, T1, T2::assign_to(Functor) [with Functor = 
std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
  ../../boost/boost/function/function_template.hpp:722:   instantiated from 
'boost::function2R, T1, T2::function2(Functor, typename 
boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
  ../../boost/boost/function/function_template.hpp:1064:   instantiated from 
'boost::functionR ()(T0, T1)::function(Functor, typename 
boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = pid_t, T1 = int]'
  ../../boost/boost/signals/slot.hpp:111:   instantiated from 
'boost::slotSlotFunction::slot(const F) [with F = std::tr1::_Bindvoid (* 
()(std::tr1::_Placeholder1, std::tr1::_Placeholder2))(pid_t, int), 
SlotFunction = boost::functionvoid ()(pid_t, int)]'
  ForkedCalls.cpp:451:   instantiated from here
  /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1226: 
warning: type qualifiers ignored on function return type
  ../../boost/boost/function/function_template.hpp:913:   instantiated from 
'void boost::function2R, T1, T2::assign_to(Functor) [with Functor = 
std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
  ../../boost/boost/function/function_template.hpp:722:   instantiated from 
'boost::function2R, T1, T2::function2(Functor, typename 
boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
  ../../boost/boost/function/function_template.hpp:1064:   instantiated from 
'boost::functionR ()(T0, T1)::function(Functor, typename 
boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = pid_t, T1 = int]'
  ../../boost/boost/signals/slot.hpp:111:   instantiated from 
'boost::slotSlotFunction::slot(const F) [with F = std::tr1::_Bindvoid (* 
()(std::tr1::_Placeholder1, std::tr1::_Placeholder2))(pid_t, int), 
SlotFunction = boost::functionvoid ()(pid_t, int)]'
  ForkedCalls.cpp:451:   instantiated from here
  /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1213: 
warning: type qualifiers ignored on function return type
  ../../boost/boost/function/function_template.hpp:913:   instantiated from 
'void boost::function2R, T1, T2::assign_to(Functor) [with Functor = 
std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
  ../../boost/boost/function/function_template.hpp:722:   instantiated from 
'boost::function2R, T1, T2::function2(Functor, typename 
boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
  ../../boost/boost/function/function_template.hpp:1064:   instantiated from 
'boost::functionR ()(T0, T1)::function(Functor, typename 
boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = pid_t, T1 = int]'
  ../../boost/boost/signals/slot.hpp:111:   instantiated from 
'boost::slotSlotFunction::slot(const F) [with F = std::tr1::_Bindvoid (* 
()(std::tr1::_Placeholder1, std::tr1::_Placeholder2))(pid_t, int), 
SlotFunction = boost::functionvoid ()(pid_t, int)]'
  ForkedCalls.cpp:451:   instantiated from here
  /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1201: 
warning: type qualifiers ignored on function return type

pavel

Re: PATCH for save-as and VC

[Pavel Sanda]

Stephan Witt wrote:
 Patch is attached. Ok to apply?

please go on.

pavel

Re: Approaching LyX 1.6.8 [status update #1]

[Pavel Sanda]

Jürgen Spitzmüller wrote:
 Pavel, do you still have plans for a coordinated beta/branch release?

i'm basically happy that 1.6.8 is going soon (without some particular 
arrangements).

my idea was that once both beta and 1.6.8 are out i would send mail to doc
lists and cc all .po maintainers that its time to focus on 2.0 translation.
secondly to ask you to become more strict for backporting any stuff so the
possibility of introducing new regression in branch is small.

pavel

Re: Approaching LyX 1.6.8 [status update #1]

[Jürgen Spitzmüller]

Pavel Sanda wrote:
 my idea was that once both beta and 1.6.8 are out i would send mail to doc
 lists and cc all .po maintainers that its time to focus on 2.0 translation.
 secondly to ask you to become more strict for backporting any stuff so the
 possibility of introducing new regression in branch is small.

OK. Both is fine wih me.

Jürgen

Re: PATCH for save-as and VC

[Stephan Witt]

Am 25.10.2010 um 14:45 schrieb Pavel Sanda:

 Stephan Witt wrote:
 Patch is attached. Ok to apply?
 
 please go on.

Done. (r35828)

I'd like to prepare a backport of the CVS backend changes to make it usable in 
1.6.8.
The dialog part of the changes I would skip so the other backends are not 
modified.
 
May I do that or is it too late?

Stephan

error

[Pavel Sanda]

Buffer.cpp:889: error: no 'lyx::Buffer::ReadStatus 
lyx::Buffer::parseLyXFormat(lyx::Lexer, const lyx::support::FileName, int) 
const' member function declared in class 'lyx::Buffer'
Buffer.cpp: In member function 'lyx::Buffer::ReadStatus 
lyx::Buffer::readFile(lyx::Lexer, const lyx::support::FileName, bool)':
Buffer.cpp:917: error: 'parseLyXFormat' was not declared in this scope
Buffer.cpp: In member function 'lyx::Buffer::ReadStatus 
lyx::Buffer::readEmergency(const lyx::support::FileName)':
Buffer.cpp:3651: warning: suggest parentheses around assignment used as truth 
value

Re: iPad?

[Abdelrazak Younes]

On 10/25/2010 01:51 PM, Richard Heck wrote:

On 10/25/2010 03:52 AM, Abdelrazak Younes wrote:

On 10/24/2010 07:53 PM, Richard Heck wrote:

On 10/24/2010 12:31 PM, David Whetstone wrote:
Hi, I'm new here.  I only recently joined this list.  I've recently 
acquired an iPad, and found myself wanting to be able to take notes 
with embedded equations and such.  AFAICT, no such app yet exists.


Then I thought about LyX.  Even if one was not able to compile a 
latex document on the ipad, LyX's editing features could still be 
very useful.  So my question is, how feasible is this?


I've spent the last couple of weeks on an exploratory mission - to 
see how hard it would be to build LyX for the iPad.  I've gotten as 
far as getting a clean build.  Completely non-functional, of 
course.  Much in front-end and support is just stubbed out.  But 
it's a start.


I ask this question now because I've noticed recent comments to the 
effect of removing the GUI agnosticism that exists in the LyX 
codebase.  It's this agnosticism that gave me the idea that it just 
might be possible.


I realize it will be a lot of work.  But I think LyX for iPad could 
occupy a useful niche in the iPad appverse.  So tell me, am I 
wasting my time?


Well, as you presumably know, LyX depends pretty heavily upon Qt, 
both in the frontend and in support. Since Qt does not run on the 
iPad, you'd have to replace all of that. This is a massive 
undertaking. Some years ago, there was an attempt to produce a Gtk 
frontend for LyX. This was at a time when the core-gui stuff was 
much less entangled than it is now.


This is not true. The core and gui stuff was very much more entangled 
at this time than it is now... lots of glue glue code everywhere. 
Nowadays, all you have to do is to rewrite frontend/qt4. QtCore is 
also used in src/support/ but the project that listed below shows 
that this is not a problem. Still, having a ported QtGui is the much 
easier path of course.


I could be wrong, but I think we now have much more application logic 
in the Gui* classes then we did before the removal of all the 
Controller* classes. Perhaps alot of that could just be copied over, 
but it is still more work.


Well, most of the controller code was useless indirection and 
complication (most of the controller code was necessitating almost the 
same amount of code in the gui implementation). So I am ready to bet 
that, at feature equality, we actually have no more code than in the 
past. But of course this is difficult to measure now that we have so 
much more gui features... thanks to the controller stuff removal.


Just adding food to a pretty useless flamewar :-P

I grant you though that we could (and should) put back some code into 
the core after the transfer of the GUI related lfuns to the frontend. 
This still needs to be done.


Abdel.

Re: PATCH for save-as and VC

[Pavel Sanda]

Stephan Witt wrote:
 Am 25.10.2010 um 14:45 schrieb Pavel Sanda:
 
  Stephan Witt wrote:
  Patch is attached. Ok to apply?
  
  please go on.
 
 Done. (r35828)
 
 I'd like to prepare a backport of the CVS backend changes to make it usable 
 in 1.6.8.
 The dialog part of the changes I would skip so the other backends are not 
 modified.
  
 May I do that or is it too late?

ask Juergen. if you only touch things inside CVS:: its imho still ok.

pavel

Re: PATCH for save-as and VC

[Jürgen Spitzmüller]

Stephan Witt wrote:
 I'd like to prepare a backport of the CVS backend changes to make it usable
 in 1.6.8. The dialog part of the changes I would skip so the other
 backends are not modified. 
 May I do that or is it too late?

If you are very fast and if the changes are safe. In general, I'd rather avoid 
non-critical fixes at this point in time.

Jürgen

Autosave [was: Improvements to Recover Emergency File prompts]

[Richard Heck]

So with Vincent's cleanup, we now have:

Buffer::ReadStatus Buffer::readAutosave(FileName const  fn)
{
// Now check if autosave file is newer.
FileName const autosaveFile = getAutosaveFileNameFor(fn);
if (!autosaveFile.exists()
  || autosaveFile.lastModified() = fn.lastModified())
return ReadFileNotFound;

docstring const file = makeDisplayPath(fn.absFileName(), 20);
docstring const text = bformat(_(The backup of the document %1$s 
is newer.\n\nLoad the backup instead?), file);
int const ret = Alert::prompt(_(Load backup?), text, 0, 2,
_(Load backup), _(Load original),_(Cancel));

switch (ret)
{
case 0: {
ReadStatus const ret_rf = readFile(autosaveFile);
// the file is not saved if we load the autosave file.
if (ret_rf == ReadSuccess) {
markDirty();
saveCheckSum(fn);
return ReadSuccess;
}
return ReadAutosaveFailure;
}
case 1:
// Here we delete the autosave
autosaveFile.removeFile();
return ReadOriginal;
default:
break;
}
return ReadCancel;
}

As John said, it looks to me as if we remove the autosave file at the 
wrong time: What if the attempt to read the original file fails? It 
seems to me that we should remove it (a) if we read it successfully; (b) 
if we read the original successfully. That would be the attached patch.


Does this seem right?

Richard

Index: src/Buffer.cpp
===
--- src/Buffer.cpp  (revision 35834)
+++ src/Buffer.cpp  (working copy)
@@ -3693,14 +3693,13 @@
// the file is not saved if we load the autosave file.
if (ret_rf == ReadSuccess) {
markDirty();
+   autosaveFile.removeFile();
saveCheckSum(fn);
return ReadSuccess;
}
return ReadAutosaveFailure;
}
case 1:
-   // Here we delete the autosave
-   autosaveFile.removeFile();
return ReadOriginal;
default:
break;
@@ -3725,7 +3724,13 @@
if (ret_ra == ReadSuccess || ret_ra == ReadCancel)
return ret_ra;
 
-   return readFile(fn);
+   ReadStatus const success = readFile(fn);
+   if (success == ReadSuccess) {
+   FileName const autosaveFile = getAutosaveFileNameFor(fn);
+   if (!autosaveFile.exists())
+   autosaveFile.removeFile();
+   }
+   return success;
 }
 
 

[Patch] #6550: LyX warns that Any Changes will be lost even when there are no changes.

[John McCabe-Dansted]

When my file is modified externally and I select
   File-Revert to Saved
I get the following warning.
   Any changes will be lost. Are you sure you want to revert to the
saved version
of the document ...

I get this warning even when the buffer is clean so there are no
changes to be lost. I would not expect to get this warning when the
Buffer is clean because:
1) when the Buffer is clean, at best the warning forces me to waste a
mouse click.
2) Typically it forces me to stop and think Do I really have unsaved changes?
3) At worst it is Crying wolf so when I finally do accidentally
select Revert to Saved when I have unsaved changes I will select
Revert without thinking.

How does the attached patch against trunk look?

Note that this is the same as the patch below except that it has been
reformatted to fit in 80 columns. I have been using the patch below
for 8 months without noticing any regressions.
  http://www.lyx.org/trac/attachment/ticket/6550/GuiView.patch

I trust that reformatting the presentation of the text does not
require a re-translation?
I.e _(aa) vs. _(a a)

-- 
John C. McCabe-Dansted
Index: frontends/qt4/GuiView.cpp
===
--- frontends/qt4/GuiView.cpp	(revision 35426)
+++ frontends/qt4/GuiView.cpp	(working copy)
@@ -3036,11 +3036,21 @@
 
 		case LFUN_BUFFER_RELOAD: {
 			LASSERT(doc_buffer, break);
-			docstring const file = makeDisplayPath(doc_buffer-absFileName(), 20);
-			docstring text = bformat(_(Any changes will be lost. Are you sure 
- you want to revert to the saved version of the document %1$s?), file);
-			int const ret = Alert::prompt(_(Revert to saved document?),
-text, 1, 1, _(Revert), _(Cancel));
+			int ret;
+			
+			if (doc_buffer-isClean()) {
+ret = 0;
+			} else {
+docstring const file = makeDisplayPath(
+	doc_buffer-absFileName(), 20);
+docstring text = bformat(_(
+	Any changes will be lost. Are you sure
+	 you want to revert to the saved 
+	version of the document %1$s?), file);
+ret = Alert::prompt(
+	_(Revert to saved document?),
+	text, 1, 1, _(Revert), _(Cancel));
+			}
 
 			if (ret == 0) {
 doc_buffer-markClean();

Re: Autosave [was: Improvements to Recover Emergency File prompts]

[John McCabe-Dansted]

On Mon, Oct 25, 2010 at 11:48 PM, Richard Heck rgh...@comcast.net wrote:
 As John said, it looks to me as if we remove the autosave file at the wrong
 time: What if the attempt to read the original file fails? It seems to me
 that we should remove it (a) if we read it successfully; (b) if we read the
 original successfully. That would be the attached patch.

 Does this seem right?

 Richard

My concern was that the user would accidentally pick Load Original,
and LyX would instantly delete the autosave file.

In my experience, user (me) error is more common than the bug you found.

I'd instead put autosaveFile.removeFile(); somewhere in Buffer::save().

-- 
John C. McCabe-Dansted

Re: Improvements to Recover Emergency File prompts. (pseudo-patch with discussion)

[Richard Heck]

On 10/25/2010 03:58 AM, John McCabe-Dansted wrote:

-

-   if (!Alert::prompt(_(Delete emergency file?), str, 1, 
1,
-   _(Remove), _(Keep it))) {
-  ...

Well, here at least we warn the user that we are about to delete
stuff. However, when LyX crashes the only thing on my mind is getting
my data back as quickly as possible. I think we should just keep the
emergency file (unless it is obsolete). We could possibly ask the user
this question on shutdown.

   
I think this was added a while ago, because we were leaving emergency 
files lying around. We only ask about this if an attempt to recover the 
file has been made, either successfully or not. So either the document 
is now loaded in the buffer or else we couldn't load it.



Otherwise I'd add a Keep All option.

   

What does this mean?


-
-   if (e.exists()  s.exists()  e.lastModified()  s.lastModified()) {
+
+   if (e.exists()  s.exists()  e.lastModified()  s.lastModified()
+e.checksum() != s.checksum()) {

There are a number of ways to get a dirty buffer without actually
changing the file. E.g we can add two spaces that get converted to a
single space, or we can add a character and then remove it by
backspacing. This seems to happen fairly regularly to me, so it seems
worth checking for.

   
I'm not sure where this code is. I'd want to see the context before 
deciding whether this is worth it.



However I am not sure .checksum() is the best way to do it. The
checksum is a long, so even if we assume the checksum algorithm is
ideal, we still get a false positive once per 4 billion checks. It
seems like something like:
 e.fileContents() == s.fileContents()
would be cleaner and just as fast.

   
Just use some new function equalContents(e,s). We don't actually care 
about the contents; only if they're equal. Then you can use an 
istreambuf_iterator, as in the checksum code, and the memory issue is 
less serious. You can also return false as soon as you find a difference.



-
-   switch (Alert::prompt(_(Load emergency save?), text, 0, 2,
- _(Recover),  _(Load Original),
- _(Cancel)))
+   int ret;
+   if (recover_all) {
+   ret = 0;
+   } else {
+   ret = Alert::prompt(_(Load emergency save?),
+   text, 0, 2,
+   _(Recover),  _(Load Original),
+   _(Cancel), _(RecoverAll));
+   if (ret == 3) {
+   ret = 0;
+   recover_all = true;
+   }
+   }
+   switch (ret)

This is the code for the Recover All emergency save.

   

Can you redo this, separately, given the recent changes?

Richard

Re: [Patch] #6550: LyX warns that Any Changes will be lost even when there are no changes.

[Vincent van Ravesteijn]

Committed.

Vincent

--with-version-suffix_tex2lyx_~/.lyx-1.6.7/lyxrc.default

[Klaus-Peter Reimers]

Moin from Kiel, Germany !

I installed lyx 1.6.7 from sources on an UBUNTU 10.4, which had 1.6.5
already installed, configured --with-version-suffix. When importing a
large bunch of LaTeX-sources into 1.6.7 indirectly (the construction is a.
little bit tricky, hard to be explained and unnecessary to be talked.
about here) I found that there is a dependency-issue in the automatically 
generated 

~/.lyx-1.6.7/lyxrc.default :

Instead of
'\converter latex  lyxtex2lyx -f $$i $$o---
\converter literate   lyxtex2lyx -n -f $$i $$o'
it should be
'\converter latex  lyxtex2lyx-1.6.7 -f $$i $$o---
\converter literate   lyxtex2lyx-1.6.7 -n -f $$i $$o'
because the simple 'tex2lyx' is realized via the original 1.6.5 install.
and I wanted 1.6.7 to start the surely better 'tex2lyx-1.6.7'.

If there are other dependencies of this kind in the new home-directory.
.lyx-1.6.7 with the same kind of misbehavior I really don't know -.
but YOU will ... :-)

Regards
kpr
(Klaus-Peter Reimers)

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

[Andre Poenitz]

On Sun, Oct 24, 2010 at 11:01:53PM +0200, Vincent van Ravesteijn wrote:
  I took a look and this looks good so far and a bit simpler than what I
  thought would be necessary but I haven't tried to test it yet.
 
 
 Please test if you have time. It was a long time ago for me too that I
 worked on that code.
 
  I do remember that someone commented that they didn't like the use of
 
  boost::uint32_t
 
  and that (IIRC) just using an unsigned int with an assertion about its size
  should be fine.
 
 Yes, I read that Andre mentioned this as a personal preference. Well,
 if he still feels this should be changed, he will shout again ;).

 Besides we use boost::uint32_t in more places in the code, so if
 anyone changes this, please change it everywhere. Besides that, we use
 more datatypes from boost: boost::int32_t, boost::crc_32_type. I think
 there are people that want to get rid of boost in the end, but then
 all these datatypes should be replaced.

The quest to keep LyX compile times and dependencies reasonable and to
reduce the level of overengineering was some major sink of time in the
past and I think that any further activity in that direction (including
writing this mail here...) just makes it worse.

I don't have problems with using boost in the implementation _if and
only if_ it provides actual benefits over less intrusive alternatives.
I do have a problem with needlessly sprinkling 'boost::' over interfaces,
especially if it does not add any value.

Given that there seems to be an unconditional typedef unsigned int
quint32; in qglobal.h I don't think there's any platform supported by
current LyX that could not use 'unsigned int' (and an static assert in
some implementation file for the unlikely case some ILP64 zombie raises
its ugly head again. And if that happens, using cstdint would still
be a better choice...)

Anyway, I don't think I should have a say on such issues anymore.

Andre'

Re: iPad?

[David Whetstone]

On Oct 25, 2010, at 4:51 AM, Richard Heck wrote:
 On 10/25/2010 03:52 AM, Abdelrazak Younes wrote:
 On 10/24/2010 07:53 PM, Richard Heck wrote:
 On 10/24/2010 12:31 PM, David Whetstone wrote:
 Hi, I'm new here.  I only recently joined this list.  I've recently 
 acquired an iPad, and found myself wanting to be able to take notes with 
 embedded equations and such.  AFAICT, no such app yet exists.
 
 Then I thought about LyX.  Even if one was not able to compile a latex 
 document on the ipad, LyX's editing features could still be very useful.  
 So my question is, how feasible is this?
 
 I've spent the last couple of weeks on an exploratory mission - to see how 
 hard it would be to build LyX for the iPad.  I've gotten as far as getting 
 a clean build.  Completely non-functional, of course.  Much in front-end 
 and support is just stubbed out.  But it's a start.
 
 I ask this question now because I've noticed recent comments to the effect 
 of removing the GUI agnosticism that exists in the LyX codebase.  It's 
 this agnosticism that gave me the idea that it just might be possible.
 
 I realize it will be a lot of work.  But I think LyX for iPad could occupy 
 a useful niche in the iPad appverse.  So tell me, am I wasting my time?
 
 Well, as you presumably know, LyX depends pretty heavily upon Qt, both in 
 the frontend and in support. Since Qt does not run on the iPad, you'd have 
 to replace all of that. This is a massive undertaking. Some years ago, 
 there was an attempt to produce a Gtk frontend for LyX. This was at a time 
 when the core-gui stuff was much less entangled than it is now.
 
 This is not true. The core and gui stuff was very much more entangled at 
 this time than it is now... lots of glue glue code everywhere. Nowadays, all 
 you have to do is to rewrite frontend/qt4. QtCore is also used in 
 src/support/ but the project that listed below shows that this is not a 
 problem. Still, having a ported QtGui is the much easier path of course.
 
 I could be wrong, but I think we now have much more application logic in the 
 Gui* classes then we did before the removal of all the Controller* classes. 
 Perhaps alot of that could just be copied over, but it is still more work.
 
 Anyway, I had a different thought, namely: If what you're looking at is more 
 of a note-taking application with the ability to handle formulas, then there 
 is a LOT of LyX that can remain in stub form. You probably don't need tables 
 or any of the InsetCommand hierarchy. Probably not footnotes, etc. If so, 
 then the problem becomes at least somewhat easier. Indeed, you might just 
 want to fork us, as many of the improvements in LyX wouldn't be that relevant 
 to what you were doing.
 
 Richard
 

Indeed, this is really what I was attempting at the outset - to extract the 
equation editing pieces from LyX to use in my own app.  But once I got into the 
code a bit and noticed that there was at least some attempt to make LyX GUI 
agnostic, I got a big head and thought maybe I could port the whole thing.

I think I'll take your advice and fall back to my original plan.

Re: Improvements to Recover Emergency File prompts. (pseudo-patch with discussion)

[John McCabe-Dansted]

On Tue, Oct 26, 2010 at 12:03 AM, Richard Heck rgh...@comcast.net wrote:
 I think this was added a while ago, because we were leaving emergency files
 lying around. We only ask about this if an attempt to recover the file has
 been made, either successfully or not. So either the document is now loaded
 in the buffer or else we couldn't load it.

Again, I'd personally put this in ::save(). Leaving an emergency file
around until the user next saves doesn't sound too bad to me. If
everything goes well the user will continue working on the file and
save it soon enough. If it doesn't go well, keeping the file around is
probably a good idea. (The user might not know whether everything will
go well at the point we ask them)

 Otherwise I'd add a Keep All option.

 What does this mean?

Once you click Keep All, we keep all the saves without prompting the user.

 +                        e.checksum() != s.checksum()) {

 There are a number of ways to get a dirty buffer without actually
 changing the file. E.g we can add two spaces that get converted to a
 single space, or we can add a character and then remove it by
 backspacing. This seems to happen fairly regularly to me, so it seems
 worth checking for.

 I'm not sure where this code is. I'd want to see the context before deciding
 whether this is worth it.

It occurs immediately prior to prompting the user whether we want to
open the original or the emergency file. I consider it worthwhile
since even IO is cheap compared to user time (and user concentration).

This is now like:
--
Buffer::ReadStatus Buffer::readEmergency(FileName const  fn)
{
   FileName const emergencyFile = getEmergencyFileNameFor(fn);
if (!emergencyFile.exists()
  || emergencyFile.lastModified() = fn.lastModified() ||
+   emergencyFile.checksum() ==  fn.checksum())
return ReadFileNotFound;

docstring const file = makeDisplayPath(fn.absFileName(), 20);


(and similar for autosave files)

 This is the code for the Recover All emergency save.

 Can you redo this, separately, given the recent changes?

Sure (attached), but note that without having an e.g. Keep All
option, if you open several files you'll still have several windows
popping up asking you if you want to keep the emergency saves.

-- 
John C. McCabe-Dansted
Index: Buffer.cpp
===
--- Buffer.cpp	(revision 35834)
+++ Buffer.cpp	(working copy)
@@ -3617,6 +3627,8 @@
 
 Buffer::ReadStatus Buffer::readEmergency(FileName const  fn)
 {
+	static bool recover_all = false;
+
 	FileName const emergencyFile = getEmergencyFileNameFor(fn);
 	if (!emergencyFile.exists() 
 		  || emergencyFile.lastModified() = fn.lastModified())
@@ -3626,9 +3638,20 @@
 	docstring const text = bformat(_(An emergency save of the document 
 		%1$s exists.\n\nRecover emergency save?), file);
 	
-	int const load_emerg = Alert::prompt(_(Load emergency save?), text,
-		0, 2, _(Recover), _(Load Original), _(Cancel));
+	int load_emerg;
 
+	if (recover_all) {
+		load_emerg = 0;
+	} else {
+		load_emerg = Alert::prompt(_(Load emergency save?), text,
+			0, 2, _(Recover), _(Load Original),
+			_(Cancel), _(Recover All));
+		if (load_emerg == 3) {
+			load_emerg = 0;
+			recover_all = true;
+		}
+	}
+
 	switch (load_emerg)
 	{
 	case 0: {

Re: Improvements to Recover Emergency File prompts. (pseudo-patch with discussion)

[Jose Quesada]

Having lost a few mins of inspired writing, I'm all for leaving the
emergency files lying around...
Best,
-Jose

Jose Quesada, PhD.
Research scientist,
Max Planck Institute,
Center for Adaptive Behavior and Cognition,
Berlin
http://www.josequesada.name/
http://twitter.com/Quesada


On Mon, Oct 25, 2010 at 7:23 PM, John McCabe-Dansted gma...@gmail.comwrote:

 On Tue, Oct 26, 2010 at 12:03 AM, Richard Heck rgh...@comcast.net wrote:
  I think this was added a while ago, because we were leaving emergency
 files
  lying around. We only ask about this if an attempt to recover the file
 has
  been made, either successfully or not. So either the document is now
 loaded
  in the buffer or else we couldn't load it.

 Again, I'd personally put this in ::save(). Leaving an emergency file
 around until the user next saves doesn't sound too bad to me. If
 everything goes well the user will continue working on the file and
 save it soon enough. If it doesn't go well, keeping the file around is
 probably a good idea. (The user might not know whether everything will
 go well at the point we ask them)

  Otherwise I'd add a Keep All option.
 
  What does this mean?

 Once you click Keep All, we keep all the saves without prompting the
 user.

  +e.checksum() != s.checksum()) {
 
  There are a number of ways to get a dirty buffer without actually
  changing the file. E.g we can add two spaces that get converted to a
  single space, or we can add a character and then remove it by
  backspacing. This seems to happen fairly regularly to me, so it seems
  worth checking for.
 
  I'm not sure where this code is. I'd want to see the context before
 deciding
  whether this is worth it.

 It occurs immediately prior to prompting the user whether we want to
 open the original or the emergency file. I consider it worthwhile
 since even IO is cheap compared to user time (and user concentration).

 This is now like:
 --
 Buffer::ReadStatus Buffer::readEmergency(FileName const  fn)
 {
   FileName const emergencyFile = getEmergencyFileNameFor(fn);
if (!emergencyFile.exists()
  || emergencyFile.lastModified() = fn.lastModified() ||
 +   emergencyFile.checksum() ==  fn.checksum())
return ReadFileNotFound;

docstring const file = makeDisplayPath(fn.absFileName(), 20);
 

 (and similar for autosave files)

  This is the code for the Recover All emergency save.
 
  Can you redo this, separately, given the recent changes?

 Sure (attached), but note that without having an e.g. Keep All
 option, if you open several files you'll still have several windows
 popping up asking you if you want to keep the emergency saves.

 --
 John C. McCabe-Dansted

Re: Autosave [was: Improvements to Recover Emergency File prompts]

[Jose Quesada]

I agree with John, having had the exact same problem. Rather than deleting
emergency files, they should be copied to a /tmp folder somewhere. This is
what vim does, and there's no reason not to do it in lyx.
Oh, and the autosave that goes down to 1 min only may be too little. I'd let
the user autosave every second if need be. Crashes happen...
Best,
-Jose

Jose Quesada, PhD.
Research scientist,
Max Planck Institute,
Center for Adaptive Behavior and Cognition,
Berlin
http://www.josequesada.name/
http://twitter.com/Quesada


On Mon, Oct 25, 2010 at 6:00 PM, John McCabe-Dansted gma...@gmail.comwrote:

 On Mon, Oct 25, 2010 at 11:48 PM, Richard Heck rgh...@comcast.net wrote:
  As John said, it looks to me as if we remove the autosave file at the
 wrong
  time: What if the attempt to read the original file fails? It seems to me
  that we should remove it (a) if we read it successfully; (b) if we read
 the
  original successfully. That would be the attached patch.
 
  Does this seem right?
 
  Richard

 My concern was that the user would accidentally pick Load Original,
 and LyX would instantly delete the autosave file.

 In my experience, user (me) error is more common than the bug you found.

 I'd instead put autosaveFile.removeFile(); somewhere in Buffer::save().

 --
 John C. McCabe-Dansted

Re: r35714 - lyx-devel/trunk/src/frontends/qt4

[Vincent van Ravesteijn]

 The only safe way to use them is when you control not only sender and
 receiver but also all the code paths inbetween - i.e. basically only
 within the same function or at least not from a deeply nested function.
 And in that cases using a singular return value does the trick as well.

 Andre'


I did something like this for Buffer::loadLyxFile(). Where would you
advice to put the UI then ? I can now spit out a lot of error messages
according to the number the functions comes up with. In Buffer ? In
buffer_funcs ? In GuiView ?

Vincent

PATCH: backport for branch to make CVS usable (Re: PATCH for save-as and VC)

[Stephan Witt]

Am 25.10.2010 um 16:53 schrieb Jürgen Spitzmüller:

 Stephan Witt wrote:
 I'd like to prepare a backport of the CVS backend changes to make it usable
 in 1.6.8. The dialog part of the changes I would skip so the other
 backends are not modified. 
 May I do that or is it too late?
 
 If you are very fast and if the changes are safe. In general, I'd rather 
 avoid 
 non-critical fixes at this point in time.

The patch is ready and attached.
I tested all CVS functions and it works here.

Stephan

Index: src/VCBackend.h
===
--- src/VCBackend.h (Revision 35832)
+++ src/VCBackend.h (Arbeitskopie)
@@ -82,7 +82,7 @@
virtual void scanMaster() = 0;
 
// GUI container for doVCCommandCall
-   int doVCCommand(std::string const  cmd, support::FileName const  
path);
+   int doVCCommand(std::string const  cmd, support::FileName const  
path, bool reportError = true);
/**
 * doVCCommandCall - call out to the version control utility
 * @param cmd the command to execute
@@ -206,9 +206,50 @@
 
 protected:
virtual void scanMaster();
+   /// the mode of operation for some VC commands
+   enum OperationMode {
+   Directory = 0,
+   File = 1
+   };
+   /// possible status values of file
+   enum CvsStatus {
+   UpToDate = 0,
+   LocallyModified = 1,
+   LocallyAdded = 2,
+   NeedsMerge = 3,
+   NeedsCheckout = 4,
+   NoCvsFile = 5,
+   StatusError = 6
+   };
 
 private:
support::FileName file_;
+   // revision number from scanMaster
+   std::string version_;
+
+   /// Check for messages in cvs output. 
+   /// Returns conflict line.
+   std::string scanLogFile(support::FileName const  f, std::string  
status);
+
+   /// return the quoted pathname if Directory or filename if File
+   virtual std::string const getTarget(OperationMode opmode) const;
+   /// collect the diff of file or directory against repository
+   /// result is placed in temporary file
+   void getDiff(OperationMode opmode, support::FileName const  tmpf);
+   /// make the file ready for editing:
+   /// save a copy in CVS/Base and change file permissions to rw if needed
+   virtual int edit();
+   /// revert the edit operation
+   virtual int unedit();
+   /// retrieve repository changes into working copy
+   virtual int update(OperationMode opmode, support::FileName const  
tmpf);
+   /// check readonly state for file
+   /// assume true when file is writable
+   virtual bool isLocked() const;
+   /// query and parse the cvs status of file
+   virtual CvsStatus getStatus();
+   /// convert enum to string
+   virtual docstring toString(CvsStatus status) const;
 };
 
 
Index: src/VCBackend.cpp
===
--- src/VCBackend.cpp   (Revision 35832)
+++ src/VCBackend.cpp   (Arbeitskopie)
@@ -48,7 +48,7 @@
 }
 
 
-int VCS::doVCCommand(string const  cmd, FileName const  path)
+int VCS::doVCCommand(string const  cmd, FileName const  path, bool 
reportError)
 {
if (owner_)
owner_-setBusy(true);
@@ -57,7 +57,7 @@
 
if (owner_)
owner_-setBusy(false);
-   if (ret)
+   if (ret  reportError)
frontend::Alert::error(_(Revision control error.),
bformat(_(Some problem occured while running the 
command:\n
  '%1$s'.),
@@ -320,7 +320,8 @@
LYXERR(Debug::LYXVC, LyXVC::CVS: scanMaster. \n Checking:   
master_);
// Ok now we do the real scan...
ifstream ifs(master_.toFilesystemEncoding().c_str());
-   string tmpf = '/' + onlyFilename(file_.absFilename()) + '/';
+   string name = onlyFilename(file_.absFilename());
+   string tmpf = '/' + name + '/';
LYXERR(Debug::LYXVC, \tlooking for `  tmpf  '\'');
string line;
static regex const reg(/(.*)/(.*)/(.*)/(.*)/(.*));
@@ -339,21 +340,22 @@
 
//sm[4]; // options
//sm[5]; // tag or tagdate
-   // FIXME: must double check file is stattable/existing
+   if (file_.isReadableFile()) {
time_t mod = file_.lastModified();
string mod_date = rtrim(asctime(gmtime(mod)), \n);
LYXERR(Debug::LYXVC, Date in Entries: `  file_date
 '\nModification date of file: `  
mod_date  '\'');
-   //FIXME this whole locking bussiness is not working 
under cvs and the machinery
-   // conforms to the ci usage, not cvs.
-   if (file_date == mod_date) {
-   locker_ = Unlocked;
+  

Re: Improvements to Recover Emergency File prompts. (pseudo-patch with discussion)

[Richard Heck]

On 10/25/2010 01:23 PM, John McCabe-Dansted wrote:

On Tue, Oct 26, 2010 at 12:03 AM, Richard Heckrgh...@comcast.net  wrote:
   

I think this was added a while ago, because we were leaving emergency files
lying around. We only ask about this if an attempt to recover the file has
been made, either successfully or not. So either the document is now loaded
in the buffer or else we couldn't load it.
 

Again, I'd personally put this in ::save(). Leaving an emergency file
around until the user next saves doesn't sound too bad to me. If
everything goes well the user will continue working on the file and
save it soon enough. If it doesn't go well, keeping the file around is
probably a good idea. (The user might not know whether everything will
go well at the point we ask them)

   

Otherwise I'd add a Keep All option.
   

What does this mean?
 

Once you click Keep All, we keep all the saves without prompting the user.

   

+e.checksum() != s.checksum()) {

There are a number of ways to get a dirty buffer without actually
changing the file. E.g we can add two spaces that get converted to a
single space, or we can add a character and then remove it by
backspacing. This seems to happen fairly regularly to me, so it seems
worth checking for.
   

I'm not sure where this code is. I'd want to see the context before deciding
whether this is worth it.
 

It occurs immediately prior to prompting the user whether we want to
open the original or the emergency file. I consider it worthwhile
since even IO is cheap compared to user time (and user concentration).

   

OK. Does anyone else have a view about this?


This is now like:
--
Buffer::ReadStatus Buffer::readEmergency(FileName const  fn)
{
FileName const emergencyFile = getEmergencyFileNameFor(fn);
 if (!emergencyFile.exists()
   || emergencyFile.lastModified()= fn.lastModified() ||
+   emergencyFile.checksum() ==  fn.checksum())
 return ReadFileNotFound;

 docstring const file = makeDisplayPath(fn.absFileName(), 20);


(and similar for autosave files)

   

This is the code for the Recover All emergency save.
   

Can you redo this, separately, given the recent changes?
 

Sure (attached), but note that without having an e.g. Keep All
option, if you open several files you'll still have several windows
popping up asking you if you want to keep the emergency saves.

   
Unless I'm mistaken, recover_all remains true once set true. That is, it 
won't just effect the relatives of the file I'm opening now, but will 
also affect any file I open later. I.e., say I previously has a.lyx, 
b.lyx, and c.lyx open, where b is a child of a, but c is independent; 
LyX crashes. Now I restart LyX and open a.lyx and choose Recover all, 
so b.lyx gets opened from the emergency file. Now I go to open c.lyx, 
and it does, too, without my being asked.


We need some way to constrain this to relatives of the first file we try 
to open in this batch.


Richard

Re: --with-version-suffix_tex2lyx_~/.lyx-1.6.7/lyxrc.default

[Richard Heck]

On 10/25/2010 12:42 PM, Klaus-Peter Reimers wrote:

Moin from Kiel, Germany !

I installed lyx 1.6.7 from sources on an UBUNTU 10.4, which had 1.6.5
already installed, configured --with-version-suffix. When importing a
large bunch of LaTeX-sources into 1.6.7 indirectly (the construction is a.
little bit tricky, hard to be explained and unnecessary to be talked.
about here) I found that there is a dependency-issue in the automatically
generated

~/.lyx-1.6.7/lyxrc.default :

Instead of
'\converter latex  lyxtex2lyx -f $$i $$o---
\converter literate   lyxtex2lyx -n -f $$i $$o'
it should be
'\converter latex  lyxtex2lyx-1.6.7 -f $$i $$o---
\converter literate   lyxtex2lyx-1.6.7 -n -f $$i $$o'
because the simple 'tex2lyx' is realized via the original 1.6.5 install.
and I wanted 1.6.7 to start the surely better 'tex2lyx-1.6.7'.

If there are other dependencies of this kind in the new home-directory.
.lyx-1.6.7 with the same kind of misbehavior I really don't know -.
but YOU will ... :-)

   
Can you please submit a bug at 
http://www.lyx.org/trac/wiki/BugTrackerHome? I think this is actually 
not very easy to fix, though it clearly is a problem.


Richard

Re: Forked calls

[Peter Kümmel]

Am Montag, den 25.10.2010, 14:33 +0200 schrieb Pavel Sanda:
 Most probably Peter,
 
 is there some way how to get rid of this:

maybe
- compiler update 
- boost update to 1.44 
- using Qt signals
- suppressing the warning -Wno-ignored-qualifiers

   CXXForkedCalls.o
   /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional: In 
 static member function 'static void 
 boost::detail::function::void_function_obj_invoker2FunctionObj, R, T0, 
 T1::invoke(boost::detail::function::function_buffer, T0, T1) [with 
 FunctionObj = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
 std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]':
   ../../boost/boost/function/function_template.hpp:913:   instantiated from 
 'void boost::function2R, T1, T2::assign_to(Functor) [with Functor = 
 std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
 std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
   ../../boost/boost/function/function_template.hpp:722:   instantiated from 
 'boost::function2R, T1, T2::function2(Functor, typename 
 boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
 Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
 std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
   ../../boost/boost/function/function_template.hpp:1064:   instantiated from 
 'boost::functionR ()(T0, T1)::function(Functor, typename 
 boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
 Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
 std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = pid_t, T1 = int]'
   ../../boost/boost/signals/slot.hpp:111:   instantiated from 
 'boost::slotSlotFunction::slot(const F) [with F = std::tr1::_Bindvoid (* 
 ()(std::tr1::_Placeholder1, std::tr1::_Placeholder2))(pid_t, int), 
 SlotFunction = boost::functionvoid ()(pid_t, int)]'
   ForkedCalls.cpp:451:   instantiated from here
   
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1226: 
 warning: type qualifiers ignored on function return type
   ../../boost/boost/function/function_template.hpp:913:   instantiated from 
 'void boost::function2R, T1, T2::assign_to(Functor) [with Functor = 
 std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
 std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
   ../../boost/boost/function/function_template.hpp:722:   instantiated from 
 'boost::function2R, T1, T2::function2(Functor, typename 
 boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
 Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
 std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
   ../../boost/boost/function/function_template.hpp:1064:   instantiated from 
 'boost::functionR ()(T0, T1)::function(Functor, typename 
 boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
 Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
 std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = pid_t, T1 = int]'
   ../../boost/boost/signals/slot.hpp:111:   instantiated from 
 'boost::slotSlotFunction::slot(const F) [with F = std::tr1::_Bindvoid (* 
 ()(std::tr1::_Placeholder1, std::tr1::_Placeholder2))(pid_t, int), 
 SlotFunction = boost::functionvoid ()(pid_t, int)]'
   ForkedCalls.cpp:451:   instantiated from here
   
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1213: 
 warning: type qualifiers ignored on function return type
   ../../boost/boost/function/function_template.hpp:913:   instantiated from 
 'void boost::function2R, T1, T2::assign_to(Functor) [with Functor = 
 std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
 std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
   ../../boost/boost/function/function_template.hpp:722:   instantiated from 
 'boost::function2R, T1, T2::function2(Functor, typename 
 boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
 Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
 std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
   ../../boost/boost/function/function_template.hpp:1064:   instantiated from 
 'boost::functionR ()(T0, T1)::function(Functor, typename 
 boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
 Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
 std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = pid_t, T1 = int]'
   ../../boost/boost/signals/slot.hpp:111:   instantiated from 
 'boost::slotSlotFunction::slot(const F) [with F = std::tr1::_Bindvoid (* 
 ()(std::tr1::_Placeholder1, std::tr1::_Placeholder2))(pid_t, int), 
 SlotFunction = boost::functionvoid ()(pid_t, int)]'
   ForkedCalls.cpp:451:   instantiated from here
   
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1201: 
 warning: type qualifiers ignored on function return type
 
 pavel

Re: Forked calls

[Peter Kümmel]

Am Montag, den 25.10.2010, 20:30 +0200 schrieb Peter Kümmel:
 Am Montag, den 25.10.2010, 14:33 +0200 schrieb Pavel Sanda:
  Most probably Peter,
  
  is there some way how to get rid of this:
 
 maybe
 - compiler update 
 - boost update to 1.44 
I've updated boost. (Updating boost was never critical.)

 - using Qt signals
 - suppressing the warning -Wno-ignored-qualifiers
 
CXXForkedCalls.o
/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional: 
  In static member function 'static void 
  boost::detail::function::void_function_obj_invoker2FunctionObj, R, T0, 
  T1::invoke(boost::detail::function::function_buffer, T0, T1) [with 
  FunctionObj = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
  std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]':
../../boost/boost/function/function_template.hpp:913:   instantiated from 
  'void boost::function2R, T1, T2::assign_to(Functor) [with Functor = 
  std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
  std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
../../boost/boost/function/function_template.hpp:722:   instantiated from 
  'boost::function2R, T1, T2::function2(Functor, typename 
  boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
  Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
  std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
../../boost/boost/function/function_template.hpp:1064:   instantiated 
  from 'boost::functionR ()(T0, T1)::function(Functor, typename 
  boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
  Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
  std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = pid_t, T1 = int]'
../../boost/boost/signals/slot.hpp:111:   instantiated from 
  'boost::slotSlotFunction::slot(const F) [with F = std::tr1::_Bindvoid 
  (* ()(std::tr1::_Placeholder1, std::tr1::_Placeholder2))(pid_t, int), 
  SlotFunction = boost::functionvoid ()(pid_t, int)]'
ForkedCalls.cpp:451:   instantiated from here

  /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1226:
   warning: type qualifiers ignored on function return type
../../boost/boost/function/function_template.hpp:913:   instantiated from 
  'void boost::function2R, T1, T2::assign_to(Functor) [with Functor = 
  std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
  std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
../../boost/boost/function/function_template.hpp:722:   instantiated from 
  'boost::function2R, T1, T2::function2(Functor, typename 
  boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
  Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
  std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
../../boost/boost/function/function_template.hpp:1064:   instantiated 
  from 'boost::functionR ()(T0, T1)::function(Functor, typename 
  boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
  Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
  std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = pid_t, T1 = int]'
../../boost/boost/signals/slot.hpp:111:   instantiated from 
  'boost::slotSlotFunction::slot(const F) [with F = std::tr1::_Bindvoid 
  (* ()(std::tr1::_Placeholder1, std::tr1::_Placeholder2))(pid_t, int), 
  SlotFunction = boost::functionvoid ()(pid_t, int)]'
ForkedCalls.cpp:451:   instantiated from here

  /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1213:
   warning: type qualifiers ignored on function return type
../../boost/boost/function/function_template.hpp:913:   instantiated from 
  'void boost::function2R, T1, T2::assign_to(Functor) [with Functor = 
  std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
  std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
../../boost/boost/function/function_template.hpp:722:   instantiated from 
  'boost::function2R, T1, T2::function2(Functor, typename 
  boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
  Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
  std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = int, T1 = int]'
../../boost/boost/function/function_template.hpp:1064:   instantiated 
  from 'boost::functionR ()(T0, T1)::function(Functor, typename 
  boost::enable_if_cboost::type_traits::ice_not::value, int::type) [with 
  Functor = std::tr1::_Bindvoid (* ()(std::tr1::_Placeholder1, 
  std::tr1::_Placeholder2))(pid_t, int), R = void, T0 = pid_t, T1 = int]'
../../boost/boost/signals/slot.hpp:111:   instantiated from 
  'boost::slotSlotFunction::slot(const F) [with F = std::tr1::_Bindvoid 
  (* ()(std::tr1::_Placeholder1, std::tr1::_Placeholder2))(pid_t, int), 
  SlotFunction = boost::functionvoid ()(pid_t, int)]'
ForkedCalls.cpp:451:   instantiated from here

  

Re: Forked calls

[Peter Kümmel]

  - compiler update 
  - boost update to 1.44 

There's a typo in the log message (1.43),
but it IS boost 1.44.

Peter

Re: PATCH: backport for branch to make CVS usable (Re: PATCH for save-as and VC)

[Pavel Sanda]

Stephan Witt wrote:
 The patch is ready and attached.
 I tested all CVS functions and it works here.

looks fine. the documentation of course ;)
pavel

Re: Improvements to Recover Emergency File prompts. (pseudo-patch with discussion)

[Pavel Sanda]

John McCabe-Dansted wrote:
 - if (!Alert::prompt(_(Delete emergency file?), str, 1, 
 1,
 - _(Remove), _(Keep it))) {
 -  ...
 
 I think we should just keep the
 emergency file (unless it is obsolete). 

no, i dont agree here. it instantly drove me crazy that lyx was not able
the remove emergency files by itself so please let this dialog alive.

pavel

Re: Improvements to Recover Emergency File prompts. (pseudo-patch with discussion)

[Guenter Milde]

On 2010-10-25, Richard Heck wrote:
 On 10/25/2010 01:23 PM, John McCabe-Dansted wrote:
 On Tue, Oct 26, 2010 at 12:03 AM, Richard Heckrgh...@comcast.net  wrote:


 +e.checksum() != s.checksum()) {

 There are a number of ways to get a dirty buffer without actually
 changing the file. E.g we can add two spaces that get converted to a
 single space, or we can add a character and then remove it by
 backspacing. This seems to happen fairly regularly to me, so it seems
 worth checking for.

 I'm not sure where this code is. I'd want to see the context before deciding
 whether this is worth it.

 It occurs immediately prior to prompting the user whether we want to
 open the original or the emergency file. I consider it worthwhile
 since even IO is cheap compared to user time (and user concentration).

 OK. Does anyone else have a view about this?

I'd like this test also before the save buffer? popup when closing LyX.
(Currently, even change-something; undo will trigger this prompt.)

Günter

Re: PATCH: backport for branch to make CVS usable (Re: PATCH for save-as and VC)

[Stephan Witt]

Am 25.10.2010 um 22:01 schrieb Pavel Sanda:

 Stephan Witt wrote:
 The patch is ready and attached.
 I tested all CVS functions and it works here.
 
 looks fine.

Thanks.

 the documentation of course ;)

Sorry, I don't understand you.
You mean after writing the documentation I should backport the latter too?

Stephan

Re: Improvements to Recover Emergency File prompts. (pseudo-patch with discussion)

[Richard Heck]

On 10/25/2010 04:22 PM, Pavel Sanda wrote:

John McCabe-Dansted wrote:
   

-   if (!Alert::prompt(_(Delete emergency file?), str, 1, 
1,
-   _(Remove), _(Keep it))) {
-  ...

I think we should just keep the
emergency file (unless it is obsolete).
 

no, i dont agree here. it instantly drove me crazy that lyx was not able
the remove emergency files by itself so please let this dialog alive.

   

There was actually a bug report about this, if I remember correctly.

Richard

Re: Improvements to Recover Emergency File prompts. (pseudo-patch with discussion)

[Vincent van Ravesteijn]

 no, i dont agree here. it instantly drove me crazy that lyx was not able
 the remove emergency files by itself so please let this dialog alive.

 pavel


Well this dialog is just as frustrating :(.

Vincent

Re: PATCH: backport for branch to make CVS usable (Re: PATCH for save-as and VC)

[Pavel Sanda]

Stephan Witt wrote:
 Am 25.10.2010 um 22:01 schrieb Pavel Sanda:
 
  Stephan Witt wrote:
  The patch is ready and attached.
  I tested all CVS functions and it works here.
  
  looks fine.
 
 Thanks.
 
  the documentation of course ;)
 
 Sorry, I don't understand you.
 You mean after writing the documentation I should backport the latter too?

well, the documentation should reflect how lyx works.
whats the point of backporting cvs stuff if anybody except you know how to use 
it in 1.6?

pavel

Re: Improvements to Recover Emergency File prompts. (pseudo-patch with discussion)

[Pavel Sanda]

Richard Heck wrote:
 -   if (!Alert::prompt(_(Delete emergency file?), str, 1, 
 1,
 -   _(Remove), _(Keep it))) {
 -  ...

 I think we should just keep the
 emergency file (unless it is obsolete).
  
 no, i dont agree here. it instantly drove me crazy that lyx was not able
 the remove emergency files by itself so please let this dialog alive.


 There was actually a bug report about this, if I remember correctly.

yes there was bug about it was and we fixed it by the dialog obove not so long 
ago.
constant re-asking again about recovering the file until one gets deep down in
dir structure where the file is located.

pavel

Re: iPad?

[Andre Poenitz]

On Mon, Oct 25, 2010 at 07:51:04AM -0400, Richard Heck wrote:
 I could be wrong, but I think we now have much more application
 logic in the Gui* classes then we did before the removal of all the
 Controller* classes. Perhaps alot of that could just be copied over,
 but it is still more work.

Immediately after the removal of the controllers there was _less_ code
in frontends/qt4/* then before. I think there was a mail to the list
to that effect.

Andre' 

Re: iPad?

[Andre Poenitz]

On Mon, Oct 25, 2010 at 03:49:33PM +0200, Abdelrazak Younes wrote:
 Well, most of the controller code was useless indirection and
 complication (most of the controller code was necessitating almost
 the same amount of code in the gui implementation). So I am ready to
 bet that, at feature equality, we actually have no more code than in
 the past. But of course this is difficult to measure now that we
 have so much more gui features... thanks to the controller stuff
 removal.

For some numbers a glimpse of the old battles:

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg126692.html

I am surprised this was only three years ago.

Andre', feeling younger suddenly.

Re: r35714 - lyx-devel/trunk/src/frontends/qt4

[Andre Poenitz]

On Mon, Oct 25, 2010 at 07:43:54PM +0200, Vincent van Ravesteijn wrote:
  The only safe way to use them is when you control not only sender and
  receiver but also all the code paths inbetween - i.e. basically only
  within the same function or at least not from a deeply nested function.
  And in that cases using a singular return value does the trick as well.
 
  Andre'
 
 
 I did something like this for Buffer::loadLyxFile(). Where would you
 advice to put the UI then ? I can now spit out a lot of error messages
 according to the number the functions comes up with. In Buffer ? In
 buffer_funcs ? In GuiView ?

Any direct user interaction in src/frontends/*, worker methods that can
run unattended, possibly bailing out on error in src/{!frontend}. If
errors are non-fatal they could be accumulated and returned or signalled
individually to the gui using a signaling mechanism that does _not_
require the existence of an observer (gui or lyxserver)

Andre'

Inset handling question

[Uwe Stöhr]

In order to fix http://www.lyx.org/trac/ticket/6585 I need to check in InsetTabular if the table is 
inside a float.


i thought I can do this by iterating the insets starting with the table inset down to the outer 
insets. if one of the outer insets is a float I thought that I can say that the table is inside it. 
Attached is a patch where I tried this with out success.

Can anybody give me a pointer what I am doing wrong?

thanks and regards
Uwe
Index: frontends/qt4/GuiTabular.cpp
===
--- frontends/qt4/GuiTabular.cpp	(revision 35845)
+++ frontends/qt4/GuiTabular.cpp	(working copy)
@@ -176,6 +176,8 @@
 	interlinespaceED-setEnabled(interlinespaceCO-currentIndex() == 2);
 	interlinespaceUnit-setEnabled(interlinespaceCO-currentIndex() == 2);
 
+	// setting as longtable is not allowed when table is inside a float
+	longTabularCB-setEnabled(funcEnabled(Tabular::SET_LONGTABULAR));
 	bool const longtabular = longTabularCB-isChecked();
 	longtableGB-setEnabled(true);
 	newpageCB-setEnabled(longtabular);
Index: insets/InsetTabular.cpp
===
--- insets/InsetTabular.cpp	(revision 35845)
+++ insets/InsetTabular.cpp	(working copy)
@@ -32,6 +32,7 @@
 #include DispatchResult.h
 #include FuncRequest.h
 #include FuncStatus.h
+#include InsetIterator.h
 #include Language.h
 #include LaTeXFeatures.h
 #include Lexer.h
@@ -4314,6 +4315,11 @@
 			break;
 
 		case Tabular::SET_LONGTABULAR:
+			// setting as longtable is not allowed when table is inside a float
+			for (InsetIterator it = inset_iterator_begin(cur.inset()); it; ++it) {
+if (it-lyxCode() == FLOAT_CODE)
+	status.setEnabled(false);
+			}
 			status.setOnOff(tabular.is_long_tabular);
 			break;
 

Re: Improvements to Recover Emergency File prompts. (pseudo-patch with discussion)

[John McCabe-Dansted]

On Tue, Oct 26, 2010 at 5:22 AM, Pavel Sanda sa...@lyx.org wrote:
 Richard Heck wrote:
 I think we should just keep the
 emergency file (unless it is obsolete).

 no, i dont agree here. it instantly drove me crazy that lyx was not able
 the remove emergency files by itself so please let this dialog alive.


 There was actually a bug report about this, if I remember correctly.

 yes there was bug about it was and we fixed it by the dialog obove not so 
 long ago.
 constant re-asking again about recovering the file until one gets deep down in
 dir structure where the file is located.

By constant re-asking, do you mean asking each time LyX starts?

Would a comment on the dialog saying To prevent this dialog being
displayed in future, please save this document suffice?

To me, deleting these files on Save seems the correct place; at the
point we can infer that the user has decided what they want to do. As
it is I just comment out the deletes in my tree because they have
burnt and/or frustrated me too often.

-- 
John C. McCabe-Dansted

[Patch] Rename Invisible in View menu to Hidden|H.

[John McCabe-Dansted]

On Mon, Oct 25, 2010 at 3:55 PM, Jürgen Spitzmüller sp...@lyx.org wrote:
 Please let me know of other issues. Note particularly that all fixes that
 entail a string change should go in very soon, since we will turn to string
 freeze soon.

Well this string change doesn't affect branch, but I think we should
rename Invisible as Hidden|H in the View menu as:
1) This allows a natural keyboard accelerator H (I is already used).
2) This matches the terminology Hide tab used in the context menu
when hiding the tab.

-- 
John C. McCabe-Dansted
Index: frontends/qt4/Menus.cpp
===
--- frontends/qt4/Menus.cpp (revision 35426)
+++ frontends/qt4/Menus.cpp (working copy)
@@ -879,8 +879,8 @@

 void MenuDefinition::expandDocuments()
 {
-   MenuItem item(MenuItem::Submenu, qt_(Invisible));
-   item.setSubmenu(MenuDefinition(qt_(Invisible)));
+   MenuItem item(MenuItem::Submenu, qt_(Hidden|H));
+   item.setSubmenu(MenuDefinition(qt_(Hidden|H)));

Buffer * first = theBufferList().first();
if (first) {

Re: PATCH: backport for branch to make CVS usable (Re: PATCH for save-as and VC)

[Stephan Witt]

Am 25.10.2010 um 23:14 schrieb Pavel Sanda:

 Stephan Witt wrote:
 Am 25.10.2010 um 22:01 schrieb Pavel Sanda:
 
 Stephan Witt wrote:
 The patch is ready and attached.
 I tested all CVS functions and it works here.
 
 looks fine.
 
 Thanks.
 
 the documentation of course ;)
 
 Sorry, I don't understand you.
 You mean after writing the documentation I should backport the latter too?
 
 well, the documentation should reflect how lyx works.

True. I couldn't parse your sentence. That's why I asked.

 whats the point of backporting cvs stuff if anybody except you know how to 
 use it in 1.6?

The previous state of CVS backend was bad. My colleges and I, we are using LyX 
for
productive work to document our software. We're combine it with CVS since years.
All the time we're using a patched version of 1.5 to be able to do so.
We had to do so because of our readonly checkouts.
This patch never went in because in 1.5 the situation was not that bad for the
common (out of the CVS box - writable checkout) usage.

As I tried to switch to 1.6 I learned two things:
1. CVS backend usage was broken and
2. my patch (obviously) did not work anymore.
Now, I have an patch at hand again. I can continue to use and provide a patched 
version
for my colleges, of course. But I claim it's useful for others, too.
The current CVS backend is working as the menu items suggest. And I'll add the 
documentation.
Jürgen said, the time window is closing. That's why I made the backport patch 
first.

Stephan

Re: switch mouse to busy symbol

[Edwin Leuven]

Vincent van Ravesteijn  wrote:
> I committed what works for me. I had it in my tree anyway.

i suspected something like that, thanks

ed.

Re: iPad?

[Abdelrazak Younes]

On 10/24/2010 07:53 PM, Richard Heck wrote:

On 10/24/2010 12:31 PM, David Whetstone wrote:
Hi, I'm new here.  I only recently joined this list.  I've recently 
acquired an iPad, and found myself wanting to be able to take notes 
with embedded equations and such.  AFAICT, no such app yet exists.


Then I thought about LyX.  Even if one was not able to compile a 
latex document on the ipad, LyX's editing features could still be 
very useful.  So my question is, how feasible is this?


I've spent the last couple of weeks on an exploratory mission - to 
see how hard it would be to build LyX for the iPad.  I've gotten as 
far as getting a clean build.  Completely non-functional, of course.  
Much in front-end and support is just stubbed out.  But it's a start.


I ask this question now because I've noticed recent comments to the 
effect of removing the GUI agnosticism that exists in the LyX 
codebase.  It's this agnosticism that gave me the idea that it just 
might be possible.


I realize it will be a lot of work.  But I think LyX for iPad could 
occupy a useful niche in the iPad appverse.  So tell me, am I wasting 
my time?


Well, as you presumably know, LyX depends pretty heavily upon Qt, both 
in the frontend and in support. Since Qt does not run on the iPad, 
you'd have to replace all of that. This is a massive undertaking. Some 
years ago, there was an attempt to produce a Gtk frontend for LyX. 
This was at a time when the core-gui stuff was much less entangled 
than it is now.


This is not true. The core and gui stuff was very much more entangled at 
this time than it is now... lots of glue glue code everywhere. Nowadays, 
all you have to do is to rewrite frontend/qt4. QtCore is also used in 
src/support/ but the project that listed below shows that this is not a 
problem. Still, having a ported QtGui is the much easier path of course.



That project was never completed. It'd be hard enough to do if LyX 
weren't a moving target.


I think maybe the way to go is to support the fledgling attempts to 
port Qt to the iPad. See this thread:

http://lists.trolltech.com/pipermail/qt-interest/2010-April/021359.html

If that were done, then LyX would run no problem.


Cheers,
Abdel.

Approaching LyX 1.6.8 [status update #1]

[Jürgen Spitzmüller]

This is just to let you know that I *do* have plans wrt LyX 1.6.8 :-)

I think another release is due. We have collected a range of fixes, including 
some important ones (the misdetection of pLaTeX with TeXLive 2010, and of 
course the crashes).

I see only two issues that should be sorted out before the release:

http://www.lyx.org/trac/ticket/6965
This is a crash in mathed due to a broken cursor. I'd appreciate if someone 
could have a look (I did, but this is not really my area of expertise).

http://www.lyx.org/trac/ticket/6967
A regression introduced within the 1.6.8 cycle. Vincent is on this, I think.

Please let me know of other issues. Note particularly that all fixes that 
entail a string change should go in very soon, since we will turn to string 
freeze soon.

Pavel, do you still have plans for a coordinated beta/branch release?

Jürgen
-*- text -*-

This file describes what has been done in the preparation of LyX 1.6.8
All comments are welcome.

I'd be glad if some of you could take the time to check it out (or fix
a bug or two if you are feeling adventurous). Let me recall that all
these fixes have been checked into the BRANCH_1_6_X branch, which you
can get with the command
  svn co svn://svn.lyx.org/lyx/lyx-devel/branches/BRANCH_1_6_X lyx-1.6.x

Juergen

[In this list, I try to group things by topic and in decreasing
order of importance. This is, of course, subjective...]


What's new
==


** Updates and new features:
***

* DOCUMENT INPUT/OUTPUT

- Add support for pBibTeX (formerly known as jBibTeX), a specific Japanese
  BibTeX variant (bug 6808).

- New environment variable LYX_FORCE_OVERWRITE allows changing default
  behavior when exporting from command line. Now LyX overwrites the main
  file by default, but not the ancillary files. Set this variable to
  "all" for letting LyX behave as in 1.6.6 and previous versions; set it
  to "none" for mimicking the 1.6.7 behavior of not overwriting any file.

- New layout and template file for submissions to journals published by
  the American Geophysical Union (AGU).

- New layout and template file for submissions to journals published by
  the Econometric Society (bug 6761).

- New layout and template file for the document class frletter that is
  used to write letters in French (bug 6915).

- New layout and template file for the document class lettre, another
  French letter class.

- Add support for subtitles in the KOMA classes.

- Add support for lists and quotes in the g-brief2 letter class
  (bug 6857).

- Add support for the math command \ot (part of bug 6872).


* USER INTERFACE

- Improve the detection of LaTeX warnings in the Log dialog.

- Citations in the outline now display the key (bug 6837).


* DOCUMENTATION AND LOCALIZATION

- Revised section 4.2 "Footnotes" of the EmbeddedObjects manual.

- Revised section 5.1 "Installing a new LaTeX package" of the
  Customization manual.

- Describe how to use formulas in program listings in sec. 7 of the
  EmbeddedObjects manual.

- Updated LaTeXConfig file.

- Updated English and German Linguistics manual.

- Updated French, German, Italian, Spanish and Slovak User
  Interface localizations.


* WINDOWS INSTALLER




* BUILD/INSTALLATION

- Allow autoconf 2.67.


** Bug fixes:
*

* DOCUMENT INPUT/OUTPUT

- Fix a crash when dropping multiple files onto LyX (bug 6944).

- Assure that Japanese LaTeX (pLaTeX) is in fact only used for Japanese
  documents. This fixes major configuration problems with TeXLive 2010.

- Fix the output of glyph 0x02e0 (MODIFIER LETTER SMALL GAMMA) (bug 6817).

- Load the amsmath LaTeX-package when the math command \dddot is used to
  avoid LaTeX errors (bug 6872).

- Do not popup "invalid path" warning when using View > Source (bug 6904).

- Small tweaks to the memoir text class.

- Allow pathnames with commas for BibTeX files (bug 6914).

- Set correct anchor for the link to the bibliography in the table
  of contents if hyperref is used (bug 6470).


* USER INTERFACE

- Do not allow to rename a format's short name if the format is used by a
  converter. This prevents a crash (bug 6815).

- Fix crash when mutating eqnarray-like environments with labeled lines
  to display equations (bug 6858).

- Disable cut and paste inside the Math Delimters dialog. This was of no
  use and could trigger a crash (bug 6942).

- Fix an assertion when unindenting empty lines in a listings inset
  (bug 6869).

- Box dialog: only shaded boxes can have multiple paragraphs if there
  is no inner box.

- Fix mouse wheel scrolling on Mac OS 10.6 (bug 6775).

- Fix tab-switching keyboard shortcut (bug 5970).

- Fix parsing of inline math environments nested in (unknown to LyX)
  text-mode user macros (bug 1337).

- When undo returns to a state where the file was saved, make sure to
  reset the (changed) status (bug 3733).

- Don't allow to insert margin notes and floats into tables because this
  would lead to LaTeX errors (bug 6844).

- Don't allow to 

Improvements to "Recover Emergency File" prompts. (pseudo-patch with discussion)

[John McCabe-Dansted]

I've been using a number of changes to Buffer::readFileHelper that
I've found useful. I err on the side off not delete emergency files,
and also add a Recover All option that is useful when you have a
master document that has several modified child documents.

I think that these modifications require a little discussion before
being formally proposed, so I discuss them inline rather than submit
them as a formal patch.

--
switch (Alert::prompt(_("Load backup?"), text, 0, 2,
  _(" backup"), _("Load "),
  _("") ))
{
...
case 1:
-   // Here we delete the autosave
-   a.removeFile();

I don't see why we delete the autosave here. What I sometimes do is think:
   "OK, I was doing some experimental stuff. I should probably open
the original file. Opps, I didn't do a proper save in the last hour,
never-mind I'll just restart LyX and pick load Backup. Huh, my
autosave file and all my work is gone!"

Simply removing that line prevents that problem, and doesn't seem to
cause any significant regressions.

If we want to automatically delete the autosave file, I'd do it once
we have verified that the file is old and obsolete. E.g. something
like the psuedo-code:

IF auto-save is newer
Prompt user etc.
ELSE
delete auto-save.

-

-   if (!Alert::prompt(_("Delete emergency file?"), str, 1, 
1,
-   _(""), _(" it"))) {
-  ...

Well, here at least we warn the user that we are about to delete
stuff. However, when LyX crashes the only thing on my mind is getting
my data back as quickly as possible. I think we should just keep the
emergency file (unless it is obsolete). We could possibly ask the user
this question on shutdown.

Otherwise I'd add a "Keep All" option.

-
-   if (e.exists() && s.exists() && e.lastModified() > s.lastModified()) {
+
+   if (e.exists() && s.exists() && e.lastModified() > s.lastModified() &&
+e.checksum() != s.checksum()) {

There are a number of ways to get a dirty buffer without actually
changing the file. E.g we can add two spaces that get converted to a
single space, or we can add a character and then remove it by
backspacing. This seems to happen fairly regularly to me, so it seems
worth checking for.

However I am not sure .checksum() is the best way to do it. The
checksum is a long, so even if we assume the checksum algorithm is
ideal, we still get a false positive once per 4 billion checks. It
seems like something like:
e.fileContents() == s.fileContents()
would be cleaner and just as fast. However that could use a lot of
memory on large files. It seems the best way would be to do:
e.fileContentsEqual(s)
where FileName::fileContentsEqual is a new method that compares the
two files in (say) 1MB chunks. However I think it would be adequate to
implement this as something like:

bool FileName::fileContentsEqual(FileName const & other_file)
{
return (d->fi.size() == other_file->fi.size() &&
fileContents() == other_file->fileContents())
}

as
0) this is way simpler,
1)  it seems unlikely that we would have a single valid lyx file that
does not easily fit in memory,
2)  the file size check should stop us from loading emergency files
larger than the valid lyx file, and
3) we could always improve fileContentsEqual later if need be.

-
-   switch (Alert::prompt(_("Load emergency save?"), text, 0, 2,
- _(""),  _(" Original"),
- _("")))
+   int ret;
+   if (recover_all) {
+   ret = 0;
+   } else {
+   ret = Alert::prompt(_("Load emergency save?"),
+   text, 0, 2,
+   _(""),  _(" Original"),
+   _(""), _("Recover "));
+   if (ret == 3) {
+   ret = 0;
+   recover_all = true;
+   }
+   }
+   switch (ret)

This is the code for the "Recover All" emergency save.

-- 
John C. McCabe-Dansted

[Patch] #3934 Document xxx converted to ver 1.4 should get the filename xxx_14.lyx

[John McCabe-Dansted]

As discussed in trac [1] naming lyx files .lyx14 makes them hard to
open in LyX. Richard suggested instead naming them .14.lyx [1], and
targeted this to 2.0.0, however this has not been touched since then.
This has a simple patch against configure.py that I have been using on
Linux for months without noticing any unexpected consequences.

Richard, should this patch (see also [2]) go into beta 1?

[1] http://www.lyx.org/trac/attachment/ticket/3934/
[2] http://www.lyx.org/trac/attachment/ticket/3934/configure.py.patch

-- 
John C. McCabe-Dansted


configure.py.patch
Description: Binary data

Re: PATCH for save-as and VC

[Pavel Sanda]

Stephan Witt wrote:
> Or I can go to rcs and you'll do the svn implementation?

i came to the conclusion that its less energy spent when i write the patch 
myself
than doing detailed review and flame about nitpicks.

please make documentation for the current cvs state inside additional manual
and indicate to the users what are the supposed usecases.

> > here is the superflous-dialog fix which is on the top of your first patch.
> > it basically (should) not change behaviour of svn and rcs and let you do 
> > any 
> > bussiness inside cvs (i let the cvs routines in your version.)
> > untested, i will get to the svn/rcs part later.
> 
> Ok. I went to sleep yesterday.
> I did commit the first patch now.
> (with typo corrected and the unused method revertWithConfirmation() removed.)
> 
> One general question:
> What's the problem with the following construct?

you mean why i changed it to the virtual function?
generally no problem. in this particular case i changed the construct
in order to be consistent with the rest of other code we use.

pavel

Re: iPad?

[Richard Heck]

On 10/25/2010 03:52 AM, Abdelrazak Younes wrote:

On 10/24/2010 07:53 PM, Richard Heck wrote:

On 10/24/2010 12:31 PM, David Whetstone wrote:
Hi, I'm new here.  I only recently joined this list.  I've recently 
acquired an iPad, and found myself wanting to be able to take notes 
with embedded equations and such.  AFAICT, no such app yet exists.


Then I thought about LyX.  Even if one was not able to compile a 
latex document on the ipad, LyX's editing features could still be 
very useful.  So my question is, how feasible is this?


I've spent the last couple of weeks on an exploratory mission - to 
see how hard it would be to build LyX for the iPad.  I've gotten as 
far as getting a clean build.  Completely non-functional, of 
course.  Much in front-end and support is just stubbed out.  But 
it's a start.


I ask this question now because I've noticed recent comments to the 
effect of removing the GUI agnosticism that exists in the LyX 
codebase.  It's this agnosticism that gave me the idea that it just 
might be possible.


I realize it will be a lot of work.  But I think LyX for iPad could 
occupy a useful niche in the iPad appverse.  So tell me, am I 
wasting my time?


Well, as you presumably know, LyX depends pretty heavily upon Qt, 
both in the frontend and in support. Since Qt does not run on the 
iPad, you'd have to replace all of that. This is a massive 
undertaking. Some years ago, there was an attempt to produce a Gtk 
frontend for LyX. This was at a time when the core-gui stuff was much 
less entangled than it is now.


This is not true. The core and gui stuff was very much more entangled 
at this time than it is now... lots of glue glue code everywhere. 
Nowadays, all you have to do is to rewrite frontend/qt4. QtCore is 
also used in src/support/ but the project that listed below shows that 
this is not a problem. Still, having a ported QtGui is the much easier 
path of course.


I could be wrong, but I think we now have much more application logic in 
the Gui* classes then we did before the removal of all the Controller* 
classes. Perhaps alot of that could just be copied over, but it is still 
more work.


Anyway, I had a different thought, namely: If what you're looking at is 
more of a note-taking application with the ability to handle formulas, 
then there is a LOT of LyX that can remain in stub form. You probably 
don't need tables or any of the InsetCommand hierarchy. Probably not 
footnotes, etc. If so, then the problem becomes at least somewhat 
easier. Indeed, you might just want to fork us, as many of the 
improvements in LyX wouldn't be that relevant to what you were doing.


Richard

Re: PATCH for save-as and VC

[Stephan Witt]

Am 25.10.2010 um 13:02 schrieb Pavel Sanda:

> Stephan Witt wrote:
>> Or I can go to rcs and you'll do the svn implementation?
> 
> i came to the conclusion that its less energy spent when i write the patch 
> myself
> than doing detailed review and flame about nitpicks.

Ok. I finished the part2 of my patch using your patch.
(It had to be changed slightly because
 1. I'd corrected my mistake already (removed revertWithConfirmation) and
 2. the revert logic had to be corrected.)
Patch is attached. Ok to apply?

> please make documentation for the current cvs state inside additional manual
> and indicate to the users what are the supposed usecases.

I'll do that.

>>> here is the superflous-dialog fix which is on the top of your first patch.
>>> it basically (should) not change behaviour of svn and rcs and let you do 
>>> any 
>>> bussiness inside cvs (i let the cvs routines in your version.)
>>> untested, i will get to the svn/rcs part later.
>> 
>> Ok. I went to sleep yesterday.
>> I did commit the first patch now.
>> (with typo corrected and the unused method revertWithConfirmation() removed.)
>> 
>> One general question:
>> What's the problem with the following construct?
> 
> you mean why i changed it to the virtual function?

Yes :-)

> generally no problem. in this particular case i changed the construct
> in order to be consistent with the rest of other code we use.

I see.

Stephan

Index: src/VCBackend.h
===
--- src/VCBackend.h (Revision 35818)
+++ src/VCBackend.h (Arbeitskopie)
@@ -42,6 +42,8 @@
virtual std::string checkIn(std::string const & msg) = 0;
// can be this operation processed in the current RCS?
virtual bool checkInEnabled() = 0;
+   // should a log message provided for next checkin?
+   virtual bool isCheckInWithConfirmation() = 0;
/// check out for editing, returns log
virtual std::string checkOut() = 0;
// can be this operation processed in the current RCS?
@@ -56,6 +58,8 @@
virtual bool lockingToggleEnabled() = 0;
/// revert current edits
virtual void revert() = 0;
+   // should a confirmation before revert requested?
+   virtual bool isRevertWithConfirmation() = 0;
/// FIXME
virtual void undoLast() = 0;
// can be this operation processed in the current RCS?
@@ -129,6 +133,8 @@
 
virtual bool checkInEnabled();
 
+   virtual bool isCheckInWithConfirmation();
+
virtual std::string checkOut();
 
virtual bool checkOutEnabled();
@@ -143,6 +149,8 @@
 
virtual void revert();
 
+   virtual bool isRevertWithConfirmation();
+
virtual void undoLast();
 
virtual bool undoLastEnabled();
@@ -190,6 +198,8 @@
 
virtual bool checkInEnabled();
 
+   virtual bool isCheckInWithConfirmation();
+
virtual std::string checkOut();
 
virtual bool checkOutEnabled();
@@ -202,6 +212,8 @@
 
virtual bool lockingToggleEnabled();
 
+   virtual bool isRevertWithConfirmation();
+
virtual void revert();
 
virtual void undoLast();
@@ -287,6 +299,8 @@
 
virtual bool checkInEnabled();
 
+   virtual bool isCheckInWithConfirmation();
+
virtual std::string checkOut();
 
virtual bool checkOutEnabled();
@@ -301,6 +315,8 @@
 
virtual void revert();
 
+   virtual bool isRevertWithConfirmation();
+
virtual void undoLast();
 
virtual bool undoLastEnabled();
Index: src/LyXVC.cpp
===
--- src/LyXVC.cpp   (Revision 35818)
+++ src/LyXVC.cpp   (Arbeitskopie)
@@ -165,7 +165,9 @@
docstring empty(_("(no log message)"));
docstring response;
string log;
-   bool ok = Alert::askForText(response, _("LyX VC: Log Message"));
+   bool ok = true;
+   if (vcs->isCheckInWithConfirmation())
+   ok = Alert::askForText(response, _("LyX VC: Log Message"));
if (ok) {
if (response.empty())
response = empty;
@@ -214,8 +216,10 @@
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, _(""), _(""));
+   int ret = 0;
+   if (vcs->isRevertWithConfirmation())
+   ret = Alert::prompt(_("Revert to stored version of document?"),
+   text, 0, 1, _(""), _(""));
 
if (ret == 0)
vcs->revert();
Index: src/VCBackend.cpp
===
--- src/VCBackend.cpp   (Revision 35818)
+++ src/VCBackend.cpp   (Arbeitskopie)
@@ -195,7 +195,13 @@

Re: [Patch] #3934 Document xxx converted to ver 1.4 should get the filename xxx_14.lyx

[Richard Heck]

On 10/25/2010 04:22 AM, John McCabe-Dansted wrote:

As discussed in trac [1] naming lyx files .lyx14 makes them hard to
open in LyX. Richard suggested instead naming them .14.lyx [1], and
targeted this to 2.0.0, however this has not been touched since then.
This has a simple patch against configure.py that I have been using on
Linux for months without noticing any unexpected consequences.

Richard, should this patch (see also [2]) go into beta 1?

[1] http://www.lyx.org/trac/attachment/ticket/3934/
[2] http://www.lyx.org/trac/attachment/ticket/3934/configure.py.patch

   

Committed. Thanks for the bump

Richard

Re: r35819 - lyx-devel/trunk/src

[Richard Heck]

On 10/25/2010 07:57 AM, v...@lyx.org wrote:

Author: vfr
Date: Mon Oct 25 13:57:56 2010
New Revision: 35819
URL: http://www.lyx.org/trac/changeset/35819

Log:
Refactor Buffer.cpp: loadLyXFile():

...

- add more ReadStatus elements to describe failures.

   

I get several warnings now about values not handled in Buffer::readString().

rh

Forked calls

[Pavel Sanda]

Most probably Peter,

is there some way how to get rid of this:
  CXXForkedCalls.o
  /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional: In 
static member function 'static void 
boost::detail::function::void_function_obj_invoker2::invoke(boost::detail::function::function_buffer&, T0, T1) [with 
FunctionObj = std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]':
  ../../boost/boost/function/function_template.hpp:913:   instantiated from 
'void boost::function2::assign_to(Functor) [with Functor = 
std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
  ../../boost/boost/function/function_template.hpp:722:   instantiated from 
'boost::function2::function2(Functor, typename 
boost::enable_if_c::type) [with 
Functor = std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
  ../../boost/boost/function/function_template.hpp:1064:   instantiated from 
'boost::function::function(Functor, typename 
boost::enable_if_c::type) [with 
Functor = std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = pid_t, T1 = int]'
  ../../boost/boost/signals/slot.hpp:111:   instantiated from 
'boost::slot::slot(const F&) [with F = std::tr1::_Bind, std::tr1::_Placeholder<2>))(pid_t, int)>, 
SlotFunction = boost::function]'
  ForkedCalls.cpp:451:   instantiated from here
  /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1226: 
warning: type qualifiers ignored on function return type
  ../../boost/boost/function/function_template.hpp:913:   instantiated from 
'void boost::function2::assign_to(Functor) [with Functor = 
std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
  ../../boost/boost/function/function_template.hpp:722:   instantiated from 
'boost::function2::function2(Functor, typename 
boost::enable_if_c::type) [with 
Functor = std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
  ../../boost/boost/function/function_template.hpp:1064:   instantiated from 
'boost::function::function(Functor, typename 
boost::enable_if_c::type) [with 
Functor = std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = pid_t, T1 = int]'
  ../../boost/boost/signals/slot.hpp:111:   instantiated from 
'boost::slot::slot(const F&) [with F = std::tr1::_Bind, std::tr1::_Placeholder<2>))(pid_t, int)>, 
SlotFunction = boost::function]'
  ForkedCalls.cpp:451:   instantiated from here
  /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1213: 
warning: type qualifiers ignored on function return type
  ../../boost/boost/function/function_template.hpp:913:   instantiated from 
'void boost::function2::assign_to(Functor) [with Functor = 
std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
  ../../boost/boost/function/function_template.hpp:722:   instantiated from 
'boost::function2::function2(Functor, typename 
boost::enable_if_c::type) [with 
Functor = std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
  ../../boost/boost/function/function_template.hpp:1064:   instantiated from 
'boost::function::function(Functor, typename 
boost::enable_if_c::type) [with 
Functor = std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = pid_t, T1 = int]'
  ../../boost/boost/signals/slot.hpp:111:   instantiated from 
'boost::slot::slot(const F&) [with F = std::tr1::_Bind, std::tr1::_Placeholder<2>))(pid_t, int)>, 
SlotFunction = boost::function]'
  ForkedCalls.cpp:451:   instantiated from here
  /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1201: 
warning: type qualifiers ignored on function return type

pavel

Re: PATCH for save-as and VC

[Pavel Sanda]

Stephan Witt wrote:
> Patch is attached. Ok to apply?

please go on.

pavel

Re: Approaching LyX 1.6.8 [status update #1]

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> Pavel, do you still have plans for a coordinated beta/branch release?

i'm basically happy that 1.6.8 is going soon (without some particular 
arrangements).

my idea was that once both beta and 1.6.8 are out i would send mail to doc
lists and cc all .po maintainers that its time to focus on 2.0 translation.
secondly to ask you to become more strict for backporting any stuff so the
possibility of introducing new regression in branch is small.

pavel

Re: Approaching LyX 1.6.8 [status update #1]

[Jürgen Spitzmüller]

Pavel Sanda wrote:
> my idea was that once both beta and 1.6.8 are out i would send mail to doc
> lists and cc all .po maintainers that its time to focus on 2.0 translation.
> secondly to ask you to become more strict for backporting any stuff so the
> possibility of introducing new regression in branch is small.

OK. Both is fine wih me.

Jürgen

Re: PATCH for save-as and VC

[Stephan Witt]

Am 25.10.2010 um 14:45 schrieb Pavel Sanda:

> Stephan Witt wrote:
>> Patch is attached. Ok to apply?
> 
> please go on.

Done. (r35828)

I'd like to prepare a backport of the CVS backend changes to make it usable in 
1.6.8.
The dialog part of the changes I would skip so the other backends are not 
modified.
 
May I do that or is it too late?

Stephan

error

[Pavel Sanda]

Buffer.cpp:889: error: no 'lyx::Buffer::ReadStatus 
lyx::Buffer::parseLyXFormat(lyx::Lexer&, const lyx::support::FileName&, int&) 
const' member function declared in class 'lyx::Buffer'
Buffer.cpp: In member function 'lyx::Buffer::ReadStatus 
lyx::Buffer::readFile(lyx::Lexer&, const lyx::support::FileName&, bool)':
Buffer.cpp:917: error: 'parseLyXFormat' was not declared in this scope
Buffer.cpp: In member function 'lyx::Buffer::ReadStatus 
lyx::Buffer::readEmergency(const lyx::support::FileName&)':
Buffer.cpp:3651: warning: suggest parentheses around assignment used as truth 
value

Re: iPad?

[Abdelrazak Younes]

On 10/25/2010 01:51 PM, Richard Heck wrote:

On 10/25/2010 03:52 AM, Abdelrazak Younes wrote:

On 10/24/2010 07:53 PM, Richard Heck wrote:

On 10/24/2010 12:31 PM, David Whetstone wrote:
Hi, I'm new here.  I only recently joined this list.  I've recently 
acquired an iPad, and found myself wanting to be able to take notes 
with embedded equations and such.  AFAICT, no such app yet exists.


Then I thought about LyX.  Even if one was not able to compile a 
latex document on the ipad, LyX's editing features could still be 
very useful.  So my question is, how feasible is this?


I've spent the last couple of weeks on an exploratory mission - to 
see how hard it would be to build LyX for the iPad.  I've gotten as 
far as getting a clean build.  Completely non-functional, of 
course.  Much in front-end and support is just stubbed out.  But 
it's a start.


I ask this question now because I've noticed recent comments to the 
effect of removing the GUI agnosticism that exists in the LyX 
codebase.  It's this agnosticism that gave me the idea that it just 
might be possible.


I realize it will be a lot of work.  But I think LyX for iPad could 
occupy a useful niche in the iPad appverse.  So tell me, am I 
wasting my time?


Well, as you presumably know, LyX depends pretty heavily upon Qt, 
both in the frontend and in support. Since Qt does not run on the 
iPad, you'd have to replace all of that. This is a massive 
undertaking. Some years ago, there was an attempt to produce a Gtk 
frontend for LyX. This was at a time when the core-gui stuff was 
much less entangled than it is now.


This is not true. The core and gui stuff was very much more entangled 
at this time than it is now... lots of glue glue code everywhere. 
Nowadays, all you have to do is to rewrite frontend/qt4. QtCore is 
also used in src/support/ but the project that listed below shows 
that this is not a problem. Still, having a ported QtGui is the much 
easier path of course.


I could be wrong, but I think we now have much more application logic 
in the Gui* classes then we did before the removal of all the 
Controller* classes. Perhaps alot of that could just be copied over, 
but it is still more work.


Well, most of the controller code was useless indirection and 
complication (most of the controller code was necessitating almost the 
same amount of code in the gui implementation). So I am ready to bet 
that, at feature equality, we actually have no more code than in the 
past. But of course this is difficult to measure now that we have so 
much more gui features... thanks to the controller stuff removal.


Just adding food to a pretty useless flamewar :-P

I grant you though that we could (and should) put back some code into 
the core after the transfer of the GUI related lfuns to the frontend. 
This still needs to be done.


Abdel.

Re: PATCH for save-as and VC

[Pavel Sanda]

Stephan Witt wrote:
> Am 25.10.2010 um 14:45 schrieb Pavel Sanda:
> 
> > Stephan Witt wrote:
> >> Patch is attached. Ok to apply?
> > 
> > please go on.
> 
> Done. (r35828)
> 
> I'd like to prepare a backport of the CVS backend changes to make it usable 
> in 1.6.8.
> The dialog part of the changes I would skip so the other backends are not 
> modified.
>  
> May I do that or is it too late?

ask Juergen. if you only touch things inside CVS:: its imho still ok.

pavel

Re: PATCH for save-as and VC

[Jürgen Spitzmüller]

Stephan Witt wrote:
> I'd like to prepare a backport of the CVS backend changes to make it usable
> in 1.6.8. The dialog part of the changes I would skip so the other
> backends are not modified. 
> May I do that or is it too late?

If you are very fast and if the changes are safe. In general, I'd rather avoid 
non-critical fixes at this point in time.

Jürgen

Autosave [was: Improvements to "Recover Emergency File" prompts]

[Richard Heck]

So with Vincent's cleanup, we now have:

Buffer::ReadStatus Buffer::readAutosave(FileName const & fn)
{
// Now check if autosave file is newer.
FileName const autosaveFile = getAutosaveFileNameFor(fn);
if (!autosaveFile.exists()
  || autosaveFile.lastModified() <= fn.lastModified())
return ReadFileNotFound;

docstring const file = makeDisplayPath(fn.absFileName(), 20);
docstring const text = bformat(_("The backup of the document %1$s "
"is newer.\n\nLoad the backup instead?"), file);
int const ret = Alert::prompt(_("Load backup?"), text, 0, 2,
_(" backup"), _("Load "),_(""));

switch (ret)
{
case 0: {
ReadStatus const ret_rf = readFile(autosaveFile);
// the file is not saved if we load the autosave file.
if (ret_rf == ReadSuccess) {
markDirty();
saveCheckSum(fn);
return ReadSuccess;
}
return ReadAutosaveFailure;
}
case 1:
// Here we delete the autosave
autosaveFile.removeFile();
return ReadOriginal;
default:
break;
}
return ReadCancel;
}

As John said, it looks to me as if we remove the autosave file at the 
wrong time: What if the attempt to read the original file fails? It 
seems to me that we should remove it (a) if we read it successfully; (b) 
if we read the original successfully. That would be the attached patch.


Does this seem right?

Richard

Index: src/Buffer.cpp
===
--- src/Buffer.cpp  (revision 35834)
+++ src/Buffer.cpp  (working copy)
@@ -3693,14 +3693,13 @@
// the file is not saved if we load the autosave file.
if (ret_rf == ReadSuccess) {
markDirty();
+   autosaveFile.removeFile();
saveCheckSum(fn);
return ReadSuccess;
}
return ReadAutosaveFailure;
}
case 1:
-   // Here we delete the autosave
-   autosaveFile.removeFile();
return ReadOriginal;
default:
break;
@@ -3725,7 +3724,13 @@
if (ret_ra == ReadSuccess || ret_ra == ReadCancel)
return ret_ra;
 
-   return readFile(fn);
+   ReadStatus const success = readFile(fn);
+   if (success == ReadSuccess) {
+   FileName const autosaveFile = getAutosaveFileNameFor(fn);
+   if (!autosaveFile.exists())
+   autosaveFile.removeFile();
+   }
+   return success;
 }
 
 

[Patch] #6550: LyX warns that "Any Changes will be lost" even when there are no changes.

[John McCabe-Dansted]

When my file is modified externally and I select
   File->Revert to Saved
I get the following warning.
   "Any changes will be lost. Are you sure you want to revert to the
saved version
of the document ..."

I get this warning even when the buffer is clean so there are no
changes to be lost. I would not expect to get this warning when the
Buffer is clean because:
1) when the Buffer is clean, at best the warning forces me to waste a
mouse click.
2) Typically it forces me to stop and think "Do I really have unsaved changes"?
3) At worst it is "Crying wolf" so when I finally do accidentally
select Revert to Saved when I have unsaved changes I will select
"Revert" without thinking.

How does the attached patch against trunk look?

Note that this is the same as the patch below except that it has been
reformatted to fit in 80 columns. I have been using the patch below
for 8 months without noticing any regressions.
  http://www.lyx.org/trac/attachment/ticket/6550/GuiView.patch

I trust that reformatting the presentation of the text does not
require a re-translation?
I.e _("aa") vs. _("a" "a")

-- 
John C. McCabe-Dansted
Index: frontends/qt4/GuiView.cpp
===
--- frontends/qt4/GuiView.cpp	(revision 35426)
+++ frontends/qt4/GuiView.cpp	(working copy)
@@ -3036,11 +3036,21 @@
 
 		case LFUN_BUFFER_RELOAD: {
 			LASSERT(doc_buffer, break);
-			docstring const file = makeDisplayPath(doc_buffer->absFileName(), 20);
-			docstring text = bformat(_("Any changes will be lost. Are you sure "
- "you want to revert to the saved version of the document %1$s?"), file);
-			int const ret = Alert::prompt(_("Revert to saved document?"),
-text, 1, 1, _(""), _(""));
+			int ret;
+			
+			if (doc_buffer->isClean()) {
+ret = 0;
+			} else {
+docstring const file = makeDisplayPath(
+	doc_buffer->absFileName(), 20);
+docstring text = bformat(_(
+	"Any changes will be lost. Are you sure"
+	" you want to revert to the saved "
+	"version of the document %1$s?"), file);
+ret = Alert::prompt(
+	_("Revert to saved document?"),
+	text, 1, 1, _(""), _(""));
+			}
 
 			if (ret == 0) {
 doc_buffer->markClean();

Re: Autosave [was: Improvements to "Recover Emergency File" prompts]

[John McCabe-Dansted]

On Mon, Oct 25, 2010 at 11:48 PM, Richard Heck  wrote:
> As John said, it looks to me as if we remove the autosave file at the wrong
> time: What if the attempt to read the original file fails? It seems to me
> that we should remove it (a) if we read it successfully; (b) if we read the
> original successfully. That would be the attached patch.
>
> Does this seem right?
>
> Richard

My concern was that the user would accidentally pick "Load Original",
and LyX would instantly delete the autosave file.

In my experience, user (me) error is more common than the bug you found.

I'd instead put "autosaveFile.removeFile();" somewhere in Buffer::save().

-- 
John C. McCabe-Dansted

Re: Improvements to "Recover Emergency File" prompts. (pseudo-patch with discussion)

[Richard Heck]

On 10/25/2010 03:58 AM, John McCabe-Dansted wrote:

-

-   if (!Alert::prompt(_("Delete emergency file?"), str, 1, 
1,
-   _(""), _(" it"))) {
-  ...

Well, here at least we warn the user that we are about to delete
stuff. However, when LyX crashes the only thing on my mind is getting
my data back as quickly as possible. I think we should just keep the
emergency file (unless it is obsolete). We could possibly ask the user
this question on shutdown.

   
I think this was added a while ago, because we were leaving emergency 
files lying around. We only ask about this if an attempt to recover the 
file has been made, either successfully or not. So either the document 
is now loaded in the buffer or else we couldn't load it.



Otherwise I'd add a "Keep All" option.

   

What does this mean?


-
-   if (e.exists()&&  s.exists()&&  e.lastModified()>  s.lastModified()) {
+
+   if (e.exists()&&  s.exists()&&  e.lastModified()>  s.lastModified()&&
+e.checksum() != s.checksum()) {

There are a number of ways to get a dirty buffer without actually
changing the file. E.g we can add two spaces that get converted to a
single space, or we can add a character and then remove it by
backspacing. This seems to happen fairly regularly to me, so it seems
worth checking for.

   
I'm not sure where this code is. I'd want to see the context before 
deciding whether this is worth it.



However I am not sure .checksum() is the best way to do it. The
checksum is a long, so even if we assume the checksum algorithm is
ideal, we still get a false positive once per 4 billion checks. It
seems like something like:
 e.fileContents() == s.fileContents()
would be cleaner and just as fast.

   
Just use some new function equalContents(e,s). We don't actually care 
about the contents; only if they're equal. Then you can use an 
istreambuf_iterator, as in the checksum code, and the memory issue is 
less serious. You can also return false as soon as you find a difference.



-
-   switch (Alert::prompt(_("Load emergency save?"), text, 0, 2,
- _(""),  _(" Original"),
- _("")))
+   int ret;
+   if (recover_all) {
+   ret = 0;
+   } else {
+   ret = Alert::prompt(_("Load emergency save?"),
+   text, 0, 2,
+   _(""),  _(" Original"),
+   _(""), _("Recover"));
+   if (ret == 3) {
+   ret = 0;
+   recover_all = true;
+   }
+   }
+   switch (ret)

This is the code for the "Recover All" emergency save.

   

Can you redo this, separately, given the recent changes?

Richard

Re: [Patch] #6550: LyX warns that "Any Changes will be lost" even when there are no changes.

[Vincent van Ravesteijn]

Committed.

Vincent

"--with-version-suffix_tex2lyx_~/.lyx-1.6.7/lyxrc.default"

[Klaus-Peter Reimers]

Moin from Kiel, Germany !

I installed lyx 1.6.7 from sources on an UBUNTU 10.4, which had 1.6.5
already installed, configured --with-version-suffix. When importing a
large bunch of LaTeX-sources into 1.6.7 indirectly (the construction is a.
little bit tricky, hard to be explained and unnecessary to be talked.
about here) I found that there is a dependency-issue in the automatically 
generated 

~/.lyx-1.6.7/lyxrc.default :

Instead of
'\converter latex  lyx"tex2lyx -f $$i $$o"<--->""
\converter literate   lyx"tex2lyx -n -f $$i $$o"<>""'
it should be
'\converter latex  lyx"tex2lyx-1.6.7 -f $$i $$o"<--->""
\converter literate   lyx"tex2lyx-1.6.7 -n -f $$i $$o"<>""'
because the simple 'tex2lyx' is realized via the original 1.6.5 install.
and I wanted 1.6.7 to start the surely "better" 'tex2lyx-1.6.7'.

If there are other dependencies of this kind in the new home-directory.
.lyx-1.6.7 with the same kind of misbehavior I really don't know -.
but YOU will ... :-)

Regards
kpr
(Klaus-Peter Reimers)

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

[Andre Poenitz]

On Sun, Oct 24, 2010 at 11:01:53PM +0200, Vincent van Ravesteijn wrote:
> > I took a look and this looks good so far and a bit simpler than what I
> > thought would be necessary but I haven't tried to test it yet.
> >
> 
> Please test if you have time. It was a long time ago for me too that I
> worked on that code.
> 
> > I do remember that someone commented that they didn't like the use of
> >
> > boost::uint32_t
> >
> > and that (IIRC) just using an unsigned int with an assertion about its size
> > should be fine.
> 
> Yes, I read that Andre mentioned this as a personal preference. Well,
> if he still feels this should be changed, he will shout again ;).
>
> Besides we use boost::uint32_t in more places in the code, so if
> anyone changes this, please change it everywhere. Besides that, we use
> more datatypes from boost: boost::int32_t, boost::crc_32_type. I think
> there are people that want to get rid of boost in the end, but then
> all these datatypes should be replaced.

The quest to keep LyX compile times and dependencies reasonable and to
reduce the level of overengineering was some major sink of time in the
past and I think that any further activity in that direction (including
writing this mail here...) just makes it worse.

I don't have problems with using boost in the implementation _if and
only if_ it provides actual benefits over less intrusive alternatives.
I do have a problem with needlessly sprinkling 'boost::' over interfaces,
especially if it does not add any value.

Given that there seems to be an unconditional "typedef unsigned int
quint32;" in qglobal.h I don't think there's any platform supported by
current LyX that could not use 'unsigned int' (and an static assert in
some implementation file for the unlikely case some ILP64 zombie raises
its ugly head again. And if that happens, using  would still
be a better choice...)

Anyway, I don't think I should have a say on such issues anymore.

Andre'

Re: iPad?

[David Whetstone]

On Oct 25, 2010, at 4:51 AM, Richard Heck wrote:
> On 10/25/2010 03:52 AM, Abdelrazak Younes wrote:
>> On 10/24/2010 07:53 PM, Richard Heck wrote:
>>> On 10/24/2010 12:31 PM, David Whetstone wrote:
 Hi, I'm new here.  I only recently joined this list.  I've recently 
 acquired an iPad, and found myself wanting to be able to take notes with 
 embedded equations and such.  AFAICT, no such app yet exists.
 
 Then I thought about LyX.  Even if one was not able to compile a latex 
 document on the ipad, LyX's editing features could still be very useful.  
 So my question is, how feasible is this?
 
 I've spent the last couple of weeks on an exploratory mission - to see how 
 hard it would be to build LyX for the iPad.  I've gotten as far as getting 
 a clean build.  Completely non-functional, of course.  Much in front-end 
 and support is just stubbed out.  But it's a start.
 
 I ask this question now because I've noticed recent comments to the effect 
 of removing the GUI agnosticism that exists in the LyX codebase.  It's 
 this agnosticism that gave me the idea that it just might be possible.
 
 I realize it will be a lot of work.  But I think LyX for iPad could occupy 
 a useful niche in the iPad appverse.  So tell me, am I wasting my time?
 
>>> Well, as you presumably know, LyX depends pretty heavily upon Qt, both in 
>>> the frontend and in support. Since Qt does not run on the iPad, you'd have 
>>> to replace all of that. This is a massive undertaking. Some years ago, 
>>> there was an attempt to produce a Gtk frontend for LyX. This was at a time 
>>> when the core-gui stuff was much less entangled than it is now.
>> 
>> This is not true. The core and gui stuff was very much more entangled at 
>> this time than it is now... lots of glue glue code everywhere. Nowadays, all 
>> you have to do is to rewrite frontend/qt4. QtCore is also used in 
>> src/support/ but the project that listed below shows that this is not a 
>> problem. Still, having a ported QtGui is the much easier path of course.
>> 
> I could be wrong, but I think we now have much more application logic in the 
> Gui* classes then we did before the removal of all the Controller* classes. 
> Perhaps alot of that could just be copied over, but it is still more work.
> 
> Anyway, I had a different thought, namely: If what you're looking at is more 
> of a note-taking application with the ability to handle formulas, then there 
> is a LOT of LyX that can remain in stub form. You probably don't need tables 
> or any of the InsetCommand hierarchy. Probably not footnotes, etc. If so, 
> then the problem becomes at least somewhat easier. Indeed, you might just 
> want to fork us, as many of the improvements in LyX wouldn't be that relevant 
> to what you were doing.
> 
> Richard
> 

Indeed, this is really what I was attempting at the outset - to extract the 
equation editing pieces from LyX to use in my own app.  But once I got into the 
code a bit and noticed that there was at least some attempt to make LyX GUI 
agnostic, I got a big head and thought maybe I could port the whole thing.

I think I'll take your advice and fall back to my original plan.

Re: Improvements to "Recover Emergency File" prompts. (pseudo-patch with discussion)

[John McCabe-Dansted]

On Tue, Oct 26, 2010 at 12:03 AM, Richard Heck  wrote:
> I think this was added a while ago, because we were leaving emergency files
> lying around. We only ask about this if an attempt to recover the file has
> been made, either successfully or not. So either the document is now loaded
> in the buffer or else we couldn't load it.

Again, I'd personally put this in ::save(). Leaving an emergency file
around until the user next saves doesn't sound too bad to me. If
everything goes well the user will continue working on the file and
save it soon enough. If it doesn't go well, keeping the file around is
probably a good idea. (The user might not know whether everything will
go well at the point we ask them)

>> Otherwise I'd add a "Keep All" option.
>
> What does this mean?

Once you click "Keep All", we keep all the saves without prompting the user.

>> +                        e.checksum() != s.checksum()) {
>>
>> There are a number of ways to get a dirty buffer without actually
>> changing the file. E.g we can add two spaces that get converted to a
>> single space, or we can add a character and then remove it by
>> backspacing. This seems to happen fairly regularly to me, so it seems
>> worth checking for.
>
> I'm not sure where this code is. I'd want to see the context before deciding
> whether this is worth it.

It occurs immediately prior to prompting the user whether we want to
open the original or the emergency file. I consider it worthwhile
since even IO is cheap compared to user time (and user concentration).

This is now like:
--
Buffer::ReadStatus Buffer::readEmergency(FileName const & fn)
{
   FileName const emergencyFile = getEmergencyFileNameFor(fn);
if (!emergencyFile.exists()
  || emergencyFile.lastModified() <= fn.lastModified() ||
+   emergencyFile.checksum() ==  fn.checksum())
return ReadFileNotFound;

docstring const file = makeDisplayPath(fn.absFileName(), 20);


(and similar for autosave files)

>> This is the code for the "Recover All" emergency save.
>
> Can you redo this, separately, given the recent changes?

Sure (attached), but note that without having an e.g. "Keep All"
option, if you open several files you'll still have several windows
popping up asking you if you want to keep the emergency saves.

-- 
John C. McCabe-Dansted
Index: Buffer.cpp
===
--- Buffer.cpp	(revision 35834)
+++ Buffer.cpp	(working copy)
@@ -3617,6 +3627,8 @@
 
 Buffer::ReadStatus Buffer::readEmergency(FileName const & fn)
 {
+	static bool recover_all = false;
+
 	FileName const emergencyFile = getEmergencyFileNameFor(fn);
 	if (!emergencyFile.exists() 
 		  || emergencyFile.lastModified() <= fn.lastModified())
@@ -3626,9 +3638,20 @@
 	docstring const text = bformat(_("An emergency save of the document "
 		"%1$s exists.\n\nRecover emergency save?"), file);
 	
-	int const load_emerg = Alert::prompt(_("Load emergency save?"), text,
-		0, 2, _(""), _(" Original"), _(""));
+	int load_emerg;
 
+	if (recover_all) {
+		load_emerg = 0;
+	} else {
+		load_emerg = Alert::prompt(_("Load emergency save?"), text,
+			0, 2, _(""), _(" Original"),
+			_(""), _("Recover "));
+		if (load_emerg == 3) {
+			load_emerg = 0;
+			recover_all = true;
+		}
+	}
+
 	switch (load_emerg)
 	{
 	case 0: {

Re: Improvements to "Recover Emergency File" prompts. (pseudo-patch with discussion)

[Jose Quesada]

Having lost a few mins of inspired writing, I'm all for leaving the
emergency files lying around...
Best,
-Jose

Jose Quesada, PhD.
Research scientist,
Max Planck Institute,
Center for Adaptive Behavior and Cognition,
Berlin
http://www.josequesada.name/
http://twitter.com/Quesada


On Mon, Oct 25, 2010 at 7:23 PM, John McCabe-Dansted wrote:

> On Tue, Oct 26, 2010 at 12:03 AM, Richard Heck  wrote:
> > I think this was added a while ago, because we were leaving emergency
> files
> > lying around. We only ask about this if an attempt to recover the file
> has
> > been made, either successfully or not. So either the document is now
> loaded
> > in the buffer or else we couldn't load it.
>
> Again, I'd personally put this in ::save(). Leaving an emergency file
> around until the user next saves doesn't sound too bad to me. If
> everything goes well the user will continue working on the file and
> save it soon enough. If it doesn't go well, keeping the file around is
> probably a good idea. (The user might not know whether everything will
> go well at the point we ask them)
>
> >> Otherwise I'd add a "Keep All" option.
> >
> > What does this mean?
>
> Once you click "Keep All", we keep all the saves without prompting the
> user.
>
> >> +e.checksum() != s.checksum()) {
> >>
> >> There are a number of ways to get a dirty buffer without actually
> >> changing the file. E.g we can add two spaces that get converted to a
> >> single space, or we can add a character and then remove it by
> >> backspacing. This seems to happen fairly regularly to me, so it seems
> >> worth checking for.
> >
> > I'm not sure where this code is. I'd want to see the context before
> deciding
> > whether this is worth it.
>
> It occurs immediately prior to prompting the user whether we want to
> open the original or the emergency file. I consider it worthwhile
> since even IO is cheap compared to user time (and user concentration).
>
> This is now like:
> --
> Buffer::ReadStatus Buffer::readEmergency(FileName const & fn)
> {
>   FileName const emergencyFile = getEmergencyFileNameFor(fn);
>if (!emergencyFile.exists()
>  || emergencyFile.lastModified() <= fn.lastModified() ||
> +   emergencyFile.checksum() ==  fn.checksum())
>return ReadFileNotFound;
>
>docstring const file = makeDisplayPath(fn.absFileName(), 20);
> 
>
> (and similar for autosave files)
>
> >> This is the code for the "Recover All" emergency save.
> >
> > Can you redo this, separately, given the recent changes?
>
> Sure (attached), but note that without having an e.g. "Keep All"
> option, if you open several files you'll still have several windows
> popping up asking you if you want to keep the emergency saves.
>
> --
> John C. McCabe-Dansted
>

Re: Autosave [was: Improvements to "Recover Emergency File" prompts]

[Jose Quesada]

I agree with John, having had the exact same problem. Rather than deleting
emergency files, they should be copied to a /tmp folder somewhere. This is
what vim does, and there's no reason not to do it in lyx.
Oh, and the autosave that goes down to 1 min only may be too little. I'd let
the user autosave every second if need be. Crashes happen...
Best,
-Jose

Jose Quesada, PhD.
Research scientist,
Max Planck Institute,
Center for Adaptive Behavior and Cognition,
Berlin
http://www.josequesada.name/
http://twitter.com/Quesada


On Mon, Oct 25, 2010 at 6:00 PM, John McCabe-Dansted wrote:

> On Mon, Oct 25, 2010 at 11:48 PM, Richard Heck  wrote:
> > As John said, it looks to me as if we remove the autosave file at the
> wrong
> > time: What if the attempt to read the original file fails? It seems to me
> > that we should remove it (a) if we read it successfully; (b) if we read
> the
> > original successfully. That would be the attached patch.
> >
> > Does this seem right?
> >
> > Richard
>
> My concern was that the user would accidentally pick "Load Original",
> and LyX would instantly delete the autosave file.
>
> In my experience, user (me) error is more common than the bug you found.
>
> I'd instead put "autosaveFile.removeFile();" somewhere in Buffer::save().
>
> --
> John C. McCabe-Dansted
>

Re: r35714 - lyx-devel/trunk/src/frontends/qt4

[Vincent van Ravesteijn]

> The only safe way to use them is when you control not only "sender" and
> "receiver" but also all the code paths inbetween - i.e. basically only
> within the same function or at least not from a deeply nested function.
> And in that cases using a singular return value does the trick as well.
>
> Andre'
>

I did something like this for Buffer::loadLyxFile(). Where would you
advice to put the UI then ? I can now spit out a lot of error messages
according to the number the functions comes up with. In Buffer ? In
buffer_funcs ? In GuiView ?

Vincent

PATCH: backport for branch to make CVS usable (Re: PATCH for save-as and VC)

[Stephan Witt]

Am 25.10.2010 um 16:53 schrieb Jürgen Spitzmüller:

> Stephan Witt wrote:
>> I'd like to prepare a backport of the CVS backend changes to make it usable
>> in 1.6.8. The dialog part of the changes I would skip so the other
>> backends are not modified. 
>> May I do that or is it too late?
> 
> If you are very fast and if the changes are safe. In general, I'd rather 
> avoid 
> non-critical fixes at this point in time.

The patch is ready and attached.
I tested all CVS functions and it works here.

Stephan

Index: src/VCBackend.h
===
--- src/VCBackend.h (Revision 35832)
+++ src/VCBackend.h (Arbeitskopie)
@@ -82,7 +82,7 @@
virtual void scanMaster() = 0;
 
// GUI container for doVCCommandCall
-   int doVCCommand(std::string const & cmd, support::FileName const & 
path);
+   int doVCCommand(std::string const & cmd, support::FileName const & 
path, bool reportError = true);
/**
 * doVCCommandCall - call out to the version control utility
 * @param cmd the command to execute
@@ -206,9 +206,50 @@
 
 protected:
virtual void scanMaster();
+   /// the mode of operation for some VC commands
+   enum OperationMode {
+   Directory = 0,
+   File = 1
+   };
+   /// possible status values of file
+   enum CvsStatus {
+   UpToDate = 0,
+   LocallyModified = 1,
+   LocallyAdded = 2,
+   NeedsMerge = 3,
+   NeedsCheckout = 4,
+   NoCvsFile = 5,
+   StatusError = 6
+   };
 
 private:
support::FileName file_;
+   // revision number from scanMaster
+   std::string version_;
+
+   /// Check for messages in cvs output. 
+   /// Returns conflict line.
+   std::string scanLogFile(support::FileName const & f, std::string & 
status);
+
+   /// return the quoted pathname if Directory or filename if File
+   virtual std::string const getTarget(OperationMode opmode) const;
+   /// collect the diff of file or directory against repository
+   /// result is placed in temporary file
+   void getDiff(OperationMode opmode, support::FileName const & tmpf);
+   /// make the file ready for editing:
+   /// save a copy in CVS/Base and change file permissions to rw if needed
+   virtual int edit();
+   /// revert the edit operation
+   virtual int unedit();
+   /// retrieve repository changes into working copy
+   virtual int update(OperationMode opmode, support::FileName const & 
tmpf);
+   /// check readonly state for file
+   /// assume true when file is writable
+   virtual bool isLocked() const;
+   /// query and parse the cvs status of file
+   virtual CvsStatus getStatus();
+   /// convert enum to string
+   virtual docstring toString(CvsStatus status) const;
 };
 
 
Index: src/VCBackend.cpp
===
--- src/VCBackend.cpp   (Revision 35832)
+++ src/VCBackend.cpp   (Arbeitskopie)
@@ -48,7 +48,7 @@
 }
 
 
-int VCS::doVCCommand(string const & cmd, FileName const & path)
+int VCS::doVCCommand(string const & cmd, FileName const & path, bool 
reportError)
 {
if (owner_)
owner_->setBusy(true);
@@ -57,7 +57,7 @@
 
if (owner_)
owner_->setBusy(false);
-   if (ret)
+   if (ret && reportError)
frontend::Alert::error(_("Revision control error."),
bformat(_("Some problem occured while running the 
command:\n"
  "'%1$s'."),
@@ -320,7 +320,8 @@
LYXERR(Debug::LYXVC, "LyXVC::CVS: scanMaster. \n Checking: " << 
master_);
// Ok now we do the real scan...
ifstream ifs(master_.toFilesystemEncoding().c_str());
-   string tmpf = '/' + onlyFilename(file_.absFilename()) + '/';
+   string name = onlyFilename(file_.absFilename());
+   string tmpf = '/' + name + '/';
LYXERR(Debug::LYXVC, "\tlooking for `" << tmpf << '\'');
string line;
static regex const reg("/(.*)/(.*)/(.*)/(.*)/(.*)");
@@ -339,21 +340,22 @@
 
//sm[4]; // options
//sm[5]; // tag or tagdate
-   // FIXME: must double check file is stattable/existing
+   if (file_.isReadableFile()) {
time_t mod = file_.lastModified();
string mod_date = rtrim(asctime(gmtime()), "\n");
LYXERR(Debug::LYXVC, "Date in Entries: `" << file_date
<< "'\nModification date of file: `" << 
mod_date << '\'');
-   //FIXME this whole locking bussiness is not working 
under cvs and the machinery
-   // conforms to the ci usage, not cvs.
-   if (file_date == mod_date) {
-

Re: Improvements to "Recover Emergency File" prompts. (pseudo-patch with discussion)

[Richard Heck]

On 10/25/2010 01:23 PM, John McCabe-Dansted wrote:

On Tue, Oct 26, 2010 at 12:03 AM, Richard Heck  wrote:
   

I think this was added a while ago, because we were leaving emergency files
lying around. We only ask about this if an attempt to recover the file has
been made, either successfully or not. So either the document is now loaded
in the buffer or else we couldn't load it.
 

Again, I'd personally put this in ::save(). Leaving an emergency file
around until the user next saves doesn't sound too bad to me. If
everything goes well the user will continue working on the file and
save it soon enough. If it doesn't go well, keeping the file around is
probably a good idea. (The user might not know whether everything will
go well at the point we ask them)

   

Otherwise I'd add a "Keep All" option.
   

What does this mean?
 

Once you click "Keep All", we keep all the saves without prompting the user.

   

+e.checksum() != s.checksum()) {

There are a number of ways to get a dirty buffer without actually
changing the file. E.g we can add two spaces that get converted to a
single space, or we can add a character and then remove it by
backspacing. This seems to happen fairly regularly to me, so it seems
worth checking for.
   

I'm not sure where this code is. I'd want to see the context before deciding
whether this is worth it.
 

It occurs immediately prior to prompting the user whether we want to
open the original or the emergency file. I consider it worthwhile
since even IO is cheap compared to user time (and user concentration).

   

OK. Does anyone else have a view about this?


This is now like:
--
Buffer::ReadStatus Buffer::readEmergency(FileName const&  fn)
{
FileName const emergencyFile = getEmergencyFileNameFor(fn);
 if (!emergencyFile.exists()
   || emergencyFile.lastModified()<= fn.lastModified() ||
+   emergencyFile.checksum() ==  fn.checksum())
 return ReadFileNotFound;

 docstring const file = makeDisplayPath(fn.absFileName(), 20);


(and similar for autosave files)

   

This is the code for the "Recover All" emergency save.
   

Can you redo this, separately, given the recent changes?
 

Sure (attached), but note that without having an e.g. "Keep All"
option, if you open several files you'll still have several windows
popping up asking you if you want to keep the emergency saves.

   
Unless I'm mistaken, recover_all remains true once set true. That is, it 
won't just effect the relatives of the file I'm opening now, but will 
also affect any file I open later. I.e., say I previously has a.lyx, 
b.lyx, and c.lyx open, where b is a child of a, but c is independent; 
LyX crashes. Now I restart LyX and open a.lyx and choose "Recover all", 
so b.lyx gets opened from the emergency file. Now I go to open c.lyx, 
and it does, too, without my being asked.


We need some way to constrain this to relatives of the first file we try 
to open in this "batch".


Richard

Re: "--with-version-suffix_tex2lyx_~/.lyx-1.6.7/lyxrc.default"

[Richard Heck]

On 10/25/2010 12:42 PM, Klaus-Peter Reimers wrote:

Moin from Kiel, Germany !

I installed lyx 1.6.7 from sources on an UBUNTU 10.4, which had 1.6.5
already installed, configured --with-version-suffix. When importing a
large bunch of LaTeX-sources into 1.6.7 indirectly (the construction is a.
little bit tricky, hard to be explained and unnecessary to be talked.
about here) I found that there is a dependency-issue in the automatically
generated

~/.lyx-1.6.7/lyxrc.default :

Instead of
'\converter latex  lyx"tex2lyx -f $$i $$o"<--->""
\converter literate   lyx"tex2lyx -n -f $$i $$o"<>""'
it should be
'\converter latex  lyx"tex2lyx-1.6.7 -f $$i $$o"<--->""
\converter literate   lyx"tex2lyx-1.6.7 -n -f $$i $$o"<>""'
because the simple 'tex2lyx' is realized via the original 1.6.5 install.
and I wanted 1.6.7 to start the surely "better" 'tex2lyx-1.6.7'.

If there are other dependencies of this kind in the new home-directory.
.lyx-1.6.7 with the same kind of misbehavior I really don't know -.
but YOU will ... :-)

   
Can you please submit a bug at 
http://www.lyx.org/trac/wiki/BugTrackerHome? I think this is actually 
not very easy to fix, though it clearly is a problem.


Richard

Re: Forked calls

[Peter Kümmel]

Am Montag, den 25.10.2010, 14:33 +0200 schrieb Pavel Sanda:
> Most probably Peter,
> 
> is there some way how to get rid of this:

maybe
- compiler update 
- boost update to 1.44 
- using Qt signals
- suppressing the warning -Wno-ignored-qualifiers

>   CXXForkedCalls.o
>   /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional: In 
> static member function 'static void 
> boost::detail::function::void_function_obj_invoker2 T1>::invoke(boost::detail::function::function_buffer&, T0, T1) [with 
> FunctionObj = std::tr1::_Bind, 
> std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]':
>   ../../boost/boost/function/function_template.hpp:913:   instantiated from 
> 'void boost::function2::assign_to(Functor) [with Functor = 
> std::tr1::_Bind, 
> std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
>   ../../boost/boost/function/function_template.hpp:722:   instantiated from 
> 'boost::function2::function2(Functor, typename 
> boost::enable_if_c::type) [with 
> Functor = std::tr1::_Bind, 
> std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
>   ../../boost/boost/function/function_template.hpp:1064:   instantiated from 
> 'boost::function::function(Functor, typename 
> boost::enable_if_c::type) [with 
> Functor = std::tr1::_Bind, 
> std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = pid_t, T1 = int]'
>   ../../boost/boost/signals/slot.hpp:111:   instantiated from 
> 'boost::slot::slot(const F&) [with F = std::tr1::_Bind ()(std::tr1::_Placeholder<1>, std::tr1::_Placeholder<2>))(pid_t, int)>, 
> SlotFunction = boost::function]'
>   ForkedCalls.cpp:451:   instantiated from here
>   
> /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1226: 
> warning: type qualifiers ignored on function return type
>   ../../boost/boost/function/function_template.hpp:913:   instantiated from 
> 'void boost::function2::assign_to(Functor) [with Functor = 
> std::tr1::_Bind, 
> std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
>   ../../boost/boost/function/function_template.hpp:722:   instantiated from 
> 'boost::function2::function2(Functor, typename 
> boost::enable_if_c::type) [with 
> Functor = std::tr1::_Bind, 
> std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
>   ../../boost/boost/function/function_template.hpp:1064:   instantiated from 
> 'boost::function::function(Functor, typename 
> boost::enable_if_c::type) [with 
> Functor = std::tr1::_Bind, 
> std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = pid_t, T1 = int]'
>   ../../boost/boost/signals/slot.hpp:111:   instantiated from 
> 'boost::slot::slot(const F&) [with F = std::tr1::_Bind ()(std::tr1::_Placeholder<1>, std::tr1::_Placeholder<2>))(pid_t, int)>, 
> SlotFunction = boost::function]'
>   ForkedCalls.cpp:451:   instantiated from here
>   
> /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1213: 
> warning: type qualifiers ignored on function return type
>   ../../boost/boost/function/function_template.hpp:913:   instantiated from 
> 'void boost::function2::assign_to(Functor) [with Functor = 
> std::tr1::_Bind, 
> std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
>   ../../boost/boost/function/function_template.hpp:722:   instantiated from 
> 'boost::function2::function2(Functor, typename 
> boost::enable_if_c::type) [with 
> Functor = std::tr1::_Bind, 
> std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
>   ../../boost/boost/function/function_template.hpp:1064:   instantiated from 
> 'boost::function::function(Functor, typename 
> boost::enable_if_c::type) [with 
> Functor = std::tr1::_Bind, 
> std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = pid_t, T1 = int]'
>   ../../boost/boost/signals/slot.hpp:111:   instantiated from 
> 'boost::slot::slot(const F&) [with F = std::tr1::_Bind ()(std::tr1::_Placeholder<1>, std::tr1::_Placeholder<2>))(pid_t, int)>, 
> SlotFunction = boost::function]'
>   ForkedCalls.cpp:451:   instantiated from here
>   
> /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1201: 
> warning: type qualifiers ignored on function return type
> 
> pavel

Re: Forked calls

[Peter Kümmel]

Am Montag, den 25.10.2010, 20:30 +0200 schrieb Peter Kümmel:
> Am Montag, den 25.10.2010, 14:33 +0200 schrieb Pavel Sanda:
> > Most probably Peter,
> > 
> > is there some way how to get rid of this:
> 
> maybe
> - compiler update 
> - boost update to 1.44 
I've updated boost. (Updating boost was never critical.)

> - using Qt signals
> - suppressing the warning -Wno-ignored-qualifiers
> 
> >   CXXForkedCalls.o
> >   /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional: 
> > In static member function 'static void 
> > boost::detail::function::void_function_obj_invoker2 > T1>::invoke(boost::detail::function::function_buffer&, T0, T1) [with 
> > FunctionObj = std::tr1::_Bind, 
> > std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]':
> >   ../../boost/boost/function/function_template.hpp:913:   instantiated from 
> > 'void boost::function2::assign_to(Functor) [with Functor = 
> > std::tr1::_Bind, 
> > std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
> >   ../../boost/boost/function/function_template.hpp:722:   instantiated from 
> > 'boost::function2::function2(Functor, typename 
> > boost::enable_if_c::type) [with 
> > Functor = std::tr1::_Bind, 
> > std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
> >   ../../boost/boost/function/function_template.hpp:1064:   instantiated 
> > from 'boost::function::function(Functor, typename 
> > boost::enable_if_c::type) [with 
> > Functor = std::tr1::_Bind, 
> > std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = pid_t, T1 = int]'
> >   ../../boost/boost/signals/slot.hpp:111:   instantiated from 
> > 'boost::slot::slot(const F&) [with F = std::tr1::_Bind > (* ()(std::tr1::_Placeholder<1>, std::tr1::_Placeholder<2>))(pid_t, int)>, 
> > SlotFunction = boost::function]'
> >   ForkedCalls.cpp:451:   instantiated from here
> >   
> > /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1226:
> >  warning: type qualifiers ignored on function return type
> >   ../../boost/boost/function/function_template.hpp:913:   instantiated from 
> > 'void boost::function2::assign_to(Functor) [with Functor = 
> > std::tr1::_Bind, 
> > std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
> >   ../../boost/boost/function/function_template.hpp:722:   instantiated from 
> > 'boost::function2::function2(Functor, typename 
> > boost::enable_if_c::type) [with 
> > Functor = std::tr1::_Bind, 
> > std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
> >   ../../boost/boost/function/function_template.hpp:1064:   instantiated 
> > from 'boost::function::function(Functor, typename 
> > boost::enable_if_c::type) [with 
> > Functor = std::tr1::_Bind, 
> > std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = pid_t, T1 = int]'
> >   ../../boost/boost/signals/slot.hpp:111:   instantiated from 
> > 'boost::slot::slot(const F&) [with F = std::tr1::_Bind > (* ()(std::tr1::_Placeholder<1>, std::tr1::_Placeholder<2>))(pid_t, int)>, 
> > SlotFunction = boost::function]'
> >   ForkedCalls.cpp:451:   instantiated from here
> >   
> > /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1213:
> >  warning: type qualifiers ignored on function return type
> >   ../../boost/boost/function/function_template.hpp:913:   instantiated from 
> > 'void boost::function2::assign_to(Functor) [with Functor = 
> > std::tr1::_Bind, 
> > std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
> >   ../../boost/boost/function/function_template.hpp:722:   instantiated from 
> > 'boost::function2::function2(Functor, typename 
> > boost::enable_if_c::type) [with 
> > Functor = std::tr1::_Bind, 
> > std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]'
> >   ../../boost/boost/function/function_template.hpp:1064:   instantiated 
> > from 'boost::function::function(Functor, typename 
> > boost::enable_if_c::type) [with 
> > Functor = std::tr1::_Bind, 
> > std::tr1::_Placeholder<2>))(pid_t, int)>, R = void, T0 = pid_t, T1 = int]'
> >   ../../boost/boost/signals/slot.hpp:111:   instantiated from 
> > 'boost::slot::slot(const F&) [with F = std::tr1::_Bind > (* ()(std::tr1::_Placeholder<1>, std::tr1::_Placeholder<2>))(pid_t, int)>, 
> > SlotFunction = boost::function]'
> >   ForkedCalls.cpp:451:   instantiated from here
> >   
> > /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/functional:1201:
> >  warning: type qualifiers ignored on function return type
> > 
> > pavel
> 
> 

Re: Forked calls

[Peter Kümmel]

> > - compiler update 
> > - boost update to 1.44 

There's a typo in the log message (1.43),
but it IS boost 1.44.

Peter

Re: PATCH: backport for branch to make CVS usable (Re: PATCH for save-as and VC)

[Pavel Sanda]

Stephan Witt wrote:
> The patch is ready and attached.
> I tested all CVS functions and it works here.

looks fine. the documentation of course ;)
pavel

Re: Improvements to "Recover Emergency File" prompts. (pseudo-patch with discussion)

[Pavel Sanda]

John McCabe-Dansted wrote:
> - if (!Alert::prompt(_("Delete emergency file?"), str, 1, 
> 1,
> - _(""), _(" it"))) {
> -  ...
> 
> I think we should just keep the
> emergency file (unless it is obsolete). 

no, i dont agree here. it instantly drove me crazy that lyx was not able
the remove emergency files by itself so please let this dialog alive.

pavel

Re: Improvements to "Recover Emergency File" prompts. (pseudo-patch with discussion)

[Guenter Milde]

On 2010-10-25, Richard Heck wrote:
> On 10/25/2010 01:23 PM, John McCabe-Dansted wrote:
>> On Tue, Oct 26, 2010 at 12:03 AM, Richard Heck  wrote:


 +e.checksum() != s.checksum()) {

 There are a number of ways to get a dirty buffer without actually
 changing the file. E.g we can add two spaces that get converted to a
 single space, or we can add a character and then remove it by
 backspacing. This seems to happen fairly regularly to me, so it seems
 worth checking for.

>>> I'm not sure where this code is. I'd want to see the context before deciding
>>> whether this is worth it.

>> It occurs immediately prior to prompting the user whether we want to
>> open the original or the emergency file. I consider it worthwhile
>> since even IO is cheap compared to user time (and user concentration).

> OK. Does anyone else have a view about this?

I'd like this test also before the "save buffer?" popup when closing LyX.
(Currently, even "; undo" will trigger this prompt.)

Günter

Re: PATCH: backport for branch to make CVS usable (Re: PATCH for save-as and VC)

[Stephan Witt]

Am 25.10.2010 um 22:01 schrieb Pavel Sanda:

> Stephan Witt wrote:
>> The patch is ready and attached.
>> I tested all CVS functions and it works here.
> 
> looks fine.

Thanks.

> the documentation of course ;)

Sorry, I don't understand you.
You mean after writing the documentation I should backport the latter too?

Stephan

Re: Improvements to "Recover Emergency File" prompts. (pseudo-patch with discussion)

[Richard Heck]

On 10/25/2010 04:22 PM, Pavel Sanda wrote:

John McCabe-Dansted wrote:
   

-   if (!Alert::prompt(_("Delete emergency file?"), str, 1, 
1,
-   _(""), _(" it"))) {
-  ...

I think we should just keep the
emergency file (unless it is obsolete).
 

no, i dont agree here. it instantly drove me crazy that lyx was not able
the remove emergency files by itself so please let this dialog alive.

   

There was actually a bug report about this, if I remember correctly.

Richard

Re: Improvements to "Recover Emergency File" prompts. (pseudo-patch with discussion)

[Vincent van Ravesteijn]

> no, i dont agree here. it instantly drove me crazy that lyx was not able
> the remove emergency files by itself so please let this dialog alive.
>
> pavel
>

Well this dialog is just as frustrating :(.

Vincent

Re: PATCH: backport for branch to make CVS usable (Re: PATCH for save-as and VC)

[Pavel Sanda]

Stephan Witt wrote:
> Am 25.10.2010 um 22:01 schrieb Pavel Sanda:
> 
> > Stephan Witt wrote:
> >> The patch is ready and attached.
> >> I tested all CVS functions and it works here.
> > 
> > looks fine.
> 
> Thanks.
> 
> > the documentation of course ;)
> 
> Sorry, I don't understand you.
> You mean after writing the documentation I should backport the latter too?

well, the documentation should reflect how lyx works.
whats the point of backporting cvs stuff if anybody except you know how to use 
it in 1.6?

pavel

Re: Improvements to "Recover Emergency File" prompts. (pseudo-patch with discussion)

[Pavel Sanda]

Richard Heck wrote:
>>> -   if (!Alert::prompt(_("Delete emergency file?"), str, 1, 
>>> 1,
>>> -   _(""), _(" it"))) {
>>> -  ...
>>>
>>> I think we should just keep the
>>> emergency file (unless it is obsolete).
>>>  
>> no, i dont agree here. it instantly drove me crazy that lyx was not able
>> the remove emergency files by itself so please let this dialog alive.
>>
>>
> There was actually a bug report about this, if I remember correctly.

yes there was bug about it was and we fixed it by the dialog obove not so long 
ago.
constant re-asking again about recovering the file until one gets deep down in
dir structure where the file is located.

pavel

Re: iPad?

[Andre Poenitz]

On Mon, Oct 25, 2010 at 07:51:04AM -0400, Richard Heck wrote:
> I could be wrong, but I think we now have much more application
> logic in the Gui* classes then we did before the removal of all the
> Controller* classes. Perhaps alot of that could just be copied over,
> but it is still more work.

Immediately after the removal of the controllers there was _less_ code
in frontends/qt4/* then before. I think there was a mail to the list
to that effect.

Andre' 

Re: iPad?

[Andre Poenitz]

On Mon, Oct 25, 2010 at 03:49:33PM +0200, Abdelrazak Younes wrote:
> Well, most of the controller code was useless indirection and
> complication (most of the controller code was necessitating almost
> the same amount of code in the gui implementation). So I am ready to
> bet that, at feature equality, we actually have no more code than in
> the past. But of course this is difficult to measure now that we
> have so much more gui features... thanks to the controller stuff
> removal.

For some numbers a glimpse of the old battles:

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg126692.html

I am surprised this was only three years ago.

Andre', feeling younger suddenly.

Re: r35714 - lyx-devel/trunk/src/frontends/qt4

[Andre Poenitz]

On Mon, Oct 25, 2010 at 07:43:54PM +0200, Vincent van Ravesteijn wrote:
> > The only safe way to use them is when you control not only "sender" and
> > "receiver" but also all the code paths inbetween - i.e. basically only
> > within the same function or at least not from a deeply nested function.
> > And in that cases using a singular return value does the trick as well.
> >
> > Andre'
> >
> 
> I did something like this for Buffer::loadLyxFile(). Where would you
> advice to put the UI then ? I can now spit out a lot of error messages
> according to the number the functions comes up with. In Buffer ? In
> buffer_funcs ? In GuiView ?

Any direct user interaction in src/frontends/*, worker methods that can
run unattended, possibly bailing out on error in src/{!frontend}. If
errors are non-fatal they could be accumulated and returned or signalled
individually to the gui using a signaling mechanism that does _not_
require the existence of an "observer" (gui or lyxserver)

Andre'