Discrimination of New in po files

[Jean-Pierre Chrétien]

Hello,

The string New appears in po files both for branches and indexes.
In French, the gender of the translation differs, so I need à [[...]] marker to 
be able to distinguish the two occurrences of the string.


Here is a patch implementing this (not tested).
Could you commit and regenerate the po files ?

TIA
Jean-Pierre
--- src/frontends/qt4/ui/BranchesUi.ui.orig	2011-10-06 09:39:56.0 +0200
+++ src/frontends/qt4/ui/BranchesUi.ui	2011-10-06 09:41:23.0 +0200
@@ -22,7 +22,7 @@
item row=0 column=0 
 widget class=QLabel name=newBranchLA 
  property name=text 
-  stringamp;New:/string
+  stringamp;New:[[branch]]/string
  /property
  property name=buddy 
   cstringnewBranchLE/cstring
--- src/frontends/qt4/ui_IndicesUi.h.orig	2011-10-06 09:40:13.0 +0200
+++ src/frontends/qt4/ui_IndicesUi.h	2011-10-06 09:43:18.0 +0200
@@ -202,7 +202,7 @@
 multipleIndicesCB-setToolTip(lyx::qt_(Check if you need multiple indexes (e.g., an Index of Names), 0));
 #endif // QT_NO_TOOLTIP
 multipleIndicesCB-setText(lyx::qt_(Use multiple indexes, 0));
-newIndexLA-setText(lyx::qt_(New:, 0));
+newIndexLA-setText(lyx::qt_(New:[[index]], 0));
 #ifndef QT_NO_TOOLTIP
 newIndexLE-setToolTip(lyx::qt_(Enter the name of the desired index (e.g. \Index of Names\) and hit \Add\, 0));
 #endif // QT_NO_TOOLTIP

Re: Using LyX to convert arbitrary files.

[Guenter Milde]

On 2011-10-05, Richard Heck wrote:
 On 10/05/2011 06:09 AM, Guenter Milde wrote:
 On 2011-10-03, Richard Heck wrote:

 ...

 This behavior is controlled by the copier. The point is that we do not wish
 to clutter the file directory with what might be dozens of files.
 Another issue
 is that exporting two LyX files from the same directory might easily lead to
 one's over-writing files exported by the other.
 But, I think these issues will be (partly?) remedied with the new option
 allowing to set an explicite export file name and path. So, maybe, with the
 new -C option, we should revise the policy...

 This would be possible, but only once the same option exists for 
 exporting from within LyX.

Maybe the current discussion can give some momentum to the
long standing issue?

http://www.lyx.org/trac/ticket/3402

http://www.lyx.org/trac/ticket/7246

Günter

Re: #7789: Word count will count words in deleted notes (with change tracking)

[Richard Heck]

On 10/05/2011 06:02 PM, Stephan Witt wrote:
 Am 04.10.2011 um 23:04 schrieb Richard Heck:

 On 10/04/2011 04:22 PM, Stephan Witt wrote:
 Am 30.09.2011 um 13:13 schrieb LyX Ticket Tracker:

 #7789: Word count will count words in deleted notes (with change tracking)
 -+--
 Reporter:  bhelm|   Owner:  rgheck  
Type:  defect   |  Status:  new 
 Priority:  normal   |   Milestone:  
 Component:  changes  | Version:  2.0.Xsvn
 Severity:  normal   |Keywords:  patch   
 -+--
 Changes (by stwitt):

 * cc: stwitt (added)
 * keywords:  = patch
 -- 
 Ticket URL: http://www.lyx.org/trac/ticket/7789#comment:1
 Does anyone has any objection? I'd like to apply the patch.

 None here.

 That said, if possible, I'd prefer if you could separate this patch into
 two parts:
 (i) Whatever is actually needed to fix the bug
 (ii) The unification and code moving stuff
 That would make it easier for me to see what's happening here.
 The patch to fix the reported bug is attached.

 There is one problem: it is incomplete (the word count is fixed,
 the char counts remain wrong). One may fix the char count like I
 did it for word count. Or one may unify the count process and have
 both fixed. This is my final patch.

OK, well, the previous one is fine, then, as it seems there are two
bugs, really.

rh

Re: Using LyX to convert arbitrary files.

[Tommaso Cucinotta]

Il 06/10/2011 10:27, Guenter Milde ha scritto:

Maybe the current discussion can give some momentum to the
long standing issue?

http://www.lyx.org/trac/ticket/3402


Please, try the committed version, it should fix the mentioned ticket.

T.

Re: Using LyX to convert arbitrary files.

[Tommaso Cucinotta]

Il 06/10/2011 15:50, Tommaso Cucinotta ha scritto:

Il 06/10/2011 10:27, Guenter Milde ha scritto:

Maybe the current discussion can give some momentum to the
long standing issue?

http://www.lyx.org/trac/ticket/3402


Please, try the committed version, it should fix the mentioned ticket.


forgot to mention: You do Export-Export As..., and it pops up a dialog
enumerating all formats tagged as document in the filter selection box,
plus a match-everything first entry (*.*). If a specific type is chosen, 
then

the corresponding destination format is used, otherwise the format is
inferred from the specified file extension.

Then, an export to that format with the explicit filename is issued.

T.

Re: #7789: Word count will count words in deleted notes (with change tracking)

[Stephan Witt]

Am 06.10.2011 um 15:09 schrieb Richard Heck:

 On 10/05/2011 06:02 PM, Stephan Witt wrote:
 Am 04.10.2011 um 23:04 schrieb Richard Heck:
 
 On 10/04/2011 04:22 PM, Stephan Witt wrote:
 Am 30.09.2011 um 13:13 schrieb LyX Ticket Tracker:
 
 #7789: Word count will count words in deleted notes (with change tracking)
 -+--
 Reporter:  bhelm|   Owner:  rgheck  
   Type:  defect   |  Status:  new 
 Priority:  normal   |   Milestone:  
 Component:  changes  | Version:  2.0.Xsvn
 Severity:  normal   |Keywords:  patch   
 -+--
 Changes (by stwitt):
 
 * cc: stwitt (added)
 * keywords:  = patch
 -- 
 Ticket URL: http://www.lyx.org/trac/ticket/7789#comment:1
 Does anyone has any objection? I'd like to apply the patch.
 
 None here.
 
 That said, if possible, I'd prefer if you could separate this patch into
 two parts:
 (i) Whatever is actually needed to fix the bug
 (ii) The unification and code moving stuff
 That would make it easier for me to see what's happening here.
 The patch to fix the reported bug is attached.
 
 There is one problem: it is incomplete (the word count is fixed,
 the char counts remain wrong). One may fix the char count like I
 did it for word count. Or one may unify the count process and have
 both fixed. This is my final patch.
 
 OK, well, the previous one is fine, then, as it seems there are two
 bugs, really.

Yes, and there is a FIXME in countWords: merge with countChars...
There was a discussion about that on lyx-devel after r37940...

After this fix is commited one may extend the statistics:
* add more details as Tommaso suggested
* add statistics for child documents, when in parent

Stephan

Re: Memory usage during Advanced Search in math mode.

[Rudi Gaelzer]

Ok.  Give me some days to find the time to compile from the source and do the 
tests.

On Wednesday, October 05, 2011 06:03:44 PM Tommaso Cucinotta wrote:
 Il 05/10/2011 22:54, Tommaso Cucinotta ha scritto:
  2) try to recompile LyX from the sources, to check whether the problem
  still shows up on your system or not in the current trunk. Shortly
  (but it's going to take half an hour or so):
  
  svn co svn://svn.lyx.org/lyx/lyx-devel/trunk lyx-trunk
  cd lyx-trunk
  ./autogen.sh
  ./configure --prefix=/usr/local/lyx-trunk --enable-debug
 
 I forgot to mention: please, add also this option to configure:
 
--with-version-suffix=-trunk
 
 to avoid that the trunk lyx version fiddles around you system-wide lyx's
 configuration files.
 
  T.

-- 
Rudi Gaelzer
Department of Physics
Institute of Physics and Mathematics
Federal University of Pelotas
BRAZIL
Registered linux user # 153741

Re: [patch] add document-wide bibliography style setting

[Julien Rioux]

On 06/10/2011 6:01 PM, Julien Rioux wrote:

First step of moving the bibliography settings to the document settings
(needed, e.g., for biblatex support). We define a default there. A
BibTeX inset takes the default style from the buffer if it doesn't
specify a style of its own. No UI yet, but it's coming. OK?



Sorry, wrong list..

--
Julien

[patch] add document-wide bibliography style setting

[Julien Rioux]

First step of moving the bibliography settings to the document settings 
(needed, e.g., for biblatex support). We define a default there. A 
BibTeX inset takes the default style from the buffer if it doesn't 
specify a style of its own. No UI yet, but it's coming. OK?


--
Julien
From cb7225e511ea0ae8714a7bccc6e0bb94ae0698f6 Mon Sep 17 00:00:00 2001
From: Julien Rioux jri...@lyx.org
Date: Thu, 6 Oct 2011 17:38:05 +0200
Subject: [PATCH] Add a document-wide default bibliography style \biblio_style.

This holds the name of a BibTeX style file for now. Any BibTeX inset
can set the style to default to use the document-wide style.

LyX format incremented to 417.
---
 development/FORMAT |5 
 lib/lyx2lyx/lyx_2_1.py |   52 ---
 src/Buffer.cpp |2 +-
 src/BufferParams.cpp   |   17 ++
 src/BufferParams.h |7 ++
 src/insets/InsetBibtex.cpp |3 ++
 6 files changed, 81 insertions(+), 5 deletions(-)

diff --git a/development/FORMAT b/development/FORMAT
index 10c1d88..577c07c 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -11,6 +11,11 @@ adjustments are made to tex2lyx and bugs are fixed in lyx2lyx.
 
 ---
 
+2011-10-06 Julien Rioux jri...@lyx.org
+	* Format incremented to 417 (rX)
+	  New buffer param \biblio_style to specify a document-wide
+	  default bibliography style (BibTeX style for the moment).
+
 2011-08-29 Uwe Stöhr uwesto...@web.de
 	* Format incremented to 416 (r39557)
 	  support for \negmedspace and \negthinspace outside of math
diff --git a/lib/lyx2lyx/lyx_2_1.py b/lib/lyx2lyx/lyx_2_1.py
index 6c6c6fe..ead33f2 100644
--- a/lib/lyx2lyx/lyx_2_1.py
+++ b/lib/lyx2lyx/lyx_2_1.py
@@ -25,7 +25,8 @@ import sys, os
 
 # Uncomment only what you need to import, please.
 
-from parser_tools import find_token, find_end_of_inset, get_value
+from parser_tools import find_token, find_end_of_inset, get_value, \
+get_quoted_value
 
 #from parser_tools import find_token, find_end_of, find_tokens, \
   #find_token_exact, find_end_of_inset, find_end_of_layout, \
@@ -162,17 +163,60 @@ def revert_math_spaces(document):
   i = i + 1
 
 
+def convert_biblio_style(document):
+Add a sensible default for \\biblio_style based on the citation engine.
+i = find_token(document.header, \\cite_engine, 0)
+if i != -1:
+engine = get_value(document.header, \\cite_engine, i).split(_)[0]
+style = {basic: plain, natbib: plainnat, jurabib: jurabib}
+document.header.insert(i + 1, \\biblio_style  + style[engine])
+
+
+def revert_biblio_style(document):
+BibTeX insets with default option use the style defined by \\biblio_style.
+i = find_token(document.header, \\biblio_style , 0)
+if i == -1:
+document.warning(No \\biblio_style line. Nothing to do.)
+return
+
+default_style = get_value(document.header, \\biblio_style, i)
+del document.header[i]
+
+# We are looking for bibtex insets having the default option
+i = 0
+while True:
+i = find_token(document.body, \\begin_inset CommandInset bibtex, i)
+if i == -1:
+return
+j = find_end_of_inset(document.body, i)
+if j == -1:
+document.warning(Malformed LyX document: Can't find end of bibtex inset at line  + str(i))
+i += 1
+return
+k = find_token(document.body, options, i, j)
+if k != -1:
+options = get_quoted_value(document.body, options, k)
+if options.split(,)[0] == default:
+document.body[k] = 'options %s' \
+% options.replace(default, default_style) + ''
+i = j
+
+
 ##
 # Conversion hub
 #
 
 supported_versions = [2.1.0,2.1]
-convert = [[414, []],
+convert = [
+   [414, []],
[415, [convert_undertilde]],
-   [416, []]
+   [416, []],
+   [417, [convert_biblio_style]],
   ]
 
-revert =  [[415, [revert_negative_space,revert_math_spaces]],
+revert =  [
+   [416, [revert_biblio_style]],
+   [415, [revert_negative_space,revert_math_spaces]],
[414, [revert_undertilde]],
[413, [revert_visible_space]]
   ]
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 6aedab2..1b892e5 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -128,7 +128,7 @@ namespace {
 
 // Do not remove the comment below, so we get merge conflict in
 // independent branches. Instead add your own.
-int const LYX_FORMAT = 416; //uwestoehr : support for horizontal spaces (bug 7728)
+int const LYX_FORMAT = 417; //jrioux : document-wide BibTeX style via \biblio_style
 
 typedef mapstring, bool DepClean;
 typedef mapdocstring, pairInsetLabel const *, Buffer::References  RefCache;
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index 4f1edc1..e0f66a0 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -367,6 +367,7 @@ 

Re: Using LyX to convert arbitrary files.

[Julien Rioux]

On 06/10/2011 3:54 PM, Tommaso Cucinotta wrote:

Please, try the committed version, it should fix the mentioned ticket.


forgot to mention: You do Export-Export As..., and it pops up a dialog
enumerating all formats tagged as document in the filter selection box,
plus a match-everything first entry (*.*). If a specific type is chosen,
then
the corresponding destination format is used, otherwise the format is
inferred from the specified file extension.


We have Export as... at the top of the menu and More options... at 
the bottom, could they be moved together?


In the save dialog, how am I to figure which of the pdf pdf2 pdf3 pdf4 
format do I want?




Then, an export to that format with the explicit filename is issued.

T.




--
Julien

Re: LyX odg drawings

[Julien Rioux]

On 27/09/2011 3:51 PM, Julien Rioux wrote:

On 20/09/2011 12:05 AM, Tommaso Cucinotta wrote:

Il 19/09/2011 23:15, Julien Rioux ha scritto:

Sorry, not much time. Don't you also get this behavior?


Not of course: for me, it works like a charm! I can insert dia files (as
graphics) and odg files (as graphics), and they show up on the screen,
are properly included in generated DVI, PS, PDF.



You have to click on the figure to open the graphics dialog. Then you
get these error messages. Hint: It occurs in readBB_from_PSFile.



By the way I still get this, and it happens whether I have the converter 
cache enabled or not. Could you please look into it?


--
Julien

Re: Using LyX to convert arbitrary files.

[Tommaso Cucinotta]

Il 06/10/2011 18:58, Julien Rioux ha scritto:
We have Export as... at the top of the menu and More options... at 
the bottom, could they be moved together?


I struggle at getting the rationale behind the More Options... entry. 
You are supposed to enter a custom command that performs the actual 
export ? Isn't this somewhat overlapping with the converters 
configuration in the preferences ? I mean, you can define your own 
format (there's also the preferences GUI for that) along with a 
converter from ps or from pdf to that, and later say you want to export 
to that custom format, can't you ?


In the save dialog, how am I to figure which of the pdf pdf2 pdf3 pdf4 
format do I want?


The formats are listed in the filter selection with their name, for example:

Any supported format (*.*)
They are ps (*.ps)
pdf (*.pdf)
pdf2 (*.pdf)
pdf3 (*.pdf)
...

Now, if you leave the selection to the default entry (first line, i.e., 
*.*), then the format is inferred as formats.getFormatFromExtension(). 
Therefore, for .pdf, I don't know what comes out, probably it is the 
first match. However, if you select either pdf2 or pdf3 etc..., then you 
may get exactly the export format you want (assuming the user 
understands these pdf2, pdf3, etc.. and is capable of discriminating 
among them and picking the right one he/she needs -- guess/hope we have 
something in the manual).


T.

Re: LyX odg drawings

[Tommaso Cucinotta]

Il 06/10/2011 19:02, Julien Rioux ha scritto:


By the way I still get this, and it happens whether I have the 
converter cache enabled or not. Could you please look into it?


Sure, let's re-make the point. Can you, please, open that odg.lyx file 
with -dbg any, and send the whole output, along with your 
.lyx/lyxrc-default settings ?


Thanks,

 T.

Re: LyX command-line option for output

[Julien Rioux]

On 05/10/2011 11:49 PM, Tommaso Cucinotta wrote:

Independently of how it can be implemented, this is a possible
re-thinking of the syntax (by examples):

lyx myfile.txt # import from TXT
lyx -i latex myfile.txt # explicitly specify the import format
lyx -o dest.txt source.lyx # export from LYX to TXT
lyx -e latex -o dest.txt source.lyx # export to LATEX, output to dest.txt
lyx -e latex source.lyx # export to LATEX, output to source.tex
lyx -e latex -o /path/to/dest.tex source.lyx # Got the point
lyx -c source.svg -o dest.eps # convert arbitrary formats
(extension-based format detection for output)
lyx -c -i svg source.svg -e eps -o dest.eps # explicitly set the input
and output formats

Summarising, a few options would be common to import/export of document
or image formats:

-i fmt specify input/import format
-e fmt specify export format
-o filename specify output filename

If -e or -o is specified, then assume/imply --batch and attempt an
export. If -c is present, try to act as batch converter.



IMHO that would be a quite nice and natural way to use LyX from the 
command line.



Also, I'd like to see a help message in response to lyx -h or
--help, the userdir, sysdir, batch and version options should
be prefixed by a double dash --userdir, --sysdir, --batch,
--version plus perhaps having an equivalent shorter option (-u, -s,
-b, -v).



Sure, that's more gnu-like. We'll have to keep the one-dash versions 
around, though.


Cheers,
Julien

Re: LyX command-line option for output

[Richard Heck]

On 10/06/2011 02:27 PM, Julien Rioux wrote:
 On 05/10/2011 11:49 PM, Tommaso Cucinotta wrote:
 lyx -c source.svg -o dest.eps # convert arbitrary formats
 (extension-based format detection for output)
 lyx -c -i svg source.svg -e eps -o dest.eps # explicitly set the input
 and output formats

I haven't been following this closely, but I'm puzzled why LyX should act
as a generic converter. This looks like asking for trouble when people
don't get the right results.

Richard

Re: LyX command-line option for output

[Tommaso Cucinotta]

Il 06/10/2011 21:02, Richard Heck ha scritto:

On 10/06/2011 02:27 PM, Julien Rioux wrote:

On 05/10/2011 11:49 PM, Tommaso Cucinotta wrote:

lyx -c source.svg -o dest.eps # convert arbitrary formats
(extension-based format detection for output)
lyx -c -i svg source.svg -e eps -o dest.eps # explicitly set the input
and output formats


I haven't been following this closely, but I'm puzzled why LyX should act
as a generic converter. This looks like asking for trouble when people
don't get the right results.


It already knows how to make a number of conversions. Just make
this capability reusable from the outside. Simply Unix. For example,
this can be used when invoking the external elyxer tool, making it
capable of all the conversions that LyX can handle.
If by chance a user wants to waste time creating an amazing
lyxrc.default configuration that can handle nearly any possible
conversion that is possible in this world, then drop it on the wiki
and let users use it.

I'm sure you have some concrete trouble scenario in your
mind. Please, explicit it.

T.

Re: LyX odg drawings

[Tommaso Cucinotta]

Il 06/10/2011 19:52, Julien Rioux ha scritto:

On 06/10/2011 7:36 PM, Tommaso Cucinotta wrote:

Il 06/10/2011 19:02, Julien Rioux ha scritto:


By the way I still get this, and it happens whether I have the
converter cache enabled or not. Could you please look into it?


A few questions:
1) what was exactly the visible problem ? (from your log I can't see 
anything
different from what I can see in my own log -- the only problem is 
that it
probably still fails to detect the BoundingBox because there's a 
residual
direct call to FileName::isZipped() that makes it believe (again - 
argh!) that
.odg is a zipped file and needs to be decompressed -- however, I 
get that
error and still the .odg is visible on the screen, and is converted 
right in the

pdf etc.)
2) did you produce this log when your additional patch was applied, or 
on the

current trunk ?
3) did you have anything in the cache when you launched lyx ?
4) did you try rm ~/.lyx-trunk/cache/* before launching lyx and 
opening that file ?


Thx,

T.

lyx as an equation editor

[Liviu Andronic]

Dear all
This request comes up every now and then, and was even part of our
aborted GSoC 2011.

But I was wondering whether there was a simple solution to this,
namely re-using the Instant Preview machinery. I am not familiar with
it's internals, but I understand that to display the LaTeX results the
IP uses the 'preview' package to generate images and then embeds these
into the LyX editor window. If I am getting this right, then LyX will
have already generated an image out of a formula.

How difficult would it be to add a 'Save IP' (or similar) to the
c-menu of a math inset and allow users to export the image? Since LyX
already knows how to convert a whole lot of formats, the dialogue
could allow to save to all image formats known to LyX. If the
generated image were in a vector format, then the whole process would
be perfect.

Do you think that this is feasible? Regards
Liviu


-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Re: LyX odg drawings

[Julien Rioux]

On 06/10/2011 11:05 PM, Tommaso Cucinotta wrote:

Il 06/10/2011 19:52, Julien Rioux ha scritto:

On 06/10/2011 7:36 PM, Tommaso Cucinotta wrote:

Il 06/10/2011 19:02, Julien Rioux ha scritto:


By the way I still get this, and it happens whether I have the
converter cache enabled or not. Could you please look into it?


A few questions:
1) what was exactly the visible problem ? (from your log I can't see
anything
different from what I can see in my own log -- the only problem is that it
probably still fails to detect the BoundingBox because there's a residual
direct call to FileName::isZipped() that makes it believe (again -
argh!)


Ah! so you do see the bug then.


that .odg is a zipped file and needs to be decompressed -- however, I get that
error and still the .odg is visible on the screen, and is converted
right in the
pdf etc.)


There is no visual problem. I never mentioned any visual problem. When 
you open the graphics dialog, from the bounding box calculation there is 
a call to gunzip the odg file, which is wrong. But that's all.



2) did you produce this log when your additional patch was applied, or
on the
current trunk ?


Not a clean trunk, but I'm working on citation stuff at the moment, so 
quite unrelated.



3) did you have anything in the cache when you launched lyx ?


Generally I turn the cache off, but I also tried turning it on and I 
still can see that LyX tries to gunzip the odg file when I open the 
graphics dialog.



4) did you try rm ~/.lyx-trunk/cache/* before launching lyx and
opening that file ?



Since I always have the cache off, this folder is already empty (had an 
empty index file in it).



Thx,

T.



No problem,
Cheers,
Julien

Re: LyX odg drawings

[Tommaso Cucinotta]

Il 06/10/2011 23:21, Julien Rioux ha scritto:

On 06/10/2011 11:05 PM, Tommaso Cucinotta wrote:

A few questions:
1) what was exactly the visible problem ? (from your log I can't see
anything
different from what I can see in my own log -- the only problem is 
that it
probably still fails to detect the BoundingBox because there's a 
residual

direct call to FileName::isZipped() that makes it believe (again -
argh!)


Ah! so you do see the bug then.


I hadn't noticed it before, because I couldn't see any evident 
misbehavior. But now that you forced me to look into the log, I can see it.


My easy fix would be to query formats and not even try to call 
readBB_from_PSFile() unless the file is actually eps or eps.gz. Can I 
ask why is this reading of the bounding box done ? Note that it may also 
imply unzipping the file and searching for the contained BB, which may 
be expensive. So, imagine I have a .odg (or other non-EPS format). 
Should we really convert to EPS, then read the BB ?


Any scenario in which I can see the usefulness of this part of code 
where the BB is needed to be extracted from the eps file ? On a related 
note, this seems all tightly related to EPS. What if we embed a PNG or 
PDF image ?


Thanks,

T.

Re: LyX odg drawings

[Julien Rioux]

On 06/10/2011 11:46 PM, Tommaso Cucinotta wrote:

Il 06/10/2011 23:21, Julien Rioux ha scritto:

On 06/10/2011 11:05 PM, Tommaso Cucinotta wrote:

A few questions:
1) what was exactly the visible problem ? (from your log I can't see
anything
different from what I can see in my own log -- the only problem is
that it
probably still fails to detect the BoundingBox because there's a
residual
direct call to FileName::isZipped() that makes it believe (again -
argh!)


Ah! so you do see the bug then.


I hadn't noticed it before, because I couldn't see any evident
misbehavior. But now that you forced me to look into the log, I can see it.

My easy fix would be to query formats and not even try to call
readBB_from_PSFile() unless the file is actually eps or eps.gz. Can I
ask why is this reading of the bounding box done ? Note that it may also
imply unzipping the file and searching for the contained BB, which may
be expensive. So, imagine I have a .odg (or other non-EPS format).
Should we really convert to EPS, then read the BB ?

Any scenario in which I can see the usefulness of this part of code
where the BB is needed to be extracted from the eps file ? On a related
note, this seems all tightly related to EPS. What if we embed a PNG or
PDF image ?

Thanks,

T.




Having the BB allows you to crop the image with less guessing. It 
probably has some other use as well. When you load a .png, the 
readBB_from_PSFile fails and the BB is obtained from elsewhere (using 
converters if I recall, from the last time I checked). When you load an 
.odg it also fails, but it tries too hard, even tries to unzip the file 
in case it was a eps.gz. So I think you are right that we should check 
for the format of the included file, and only when it is an eps or ps, 
then we should call readBB_from_PSFile, and when it is not, go to the 
fallback. And when readBB_from_PSfile fails, still go to the fallback.


Cheers,
Julien

LyX as of r39805 uncompilable

[Uwe Stöhr]

Hi Tommaso,

I get this error:

D:\LyXSVN\lyx-devel\src\frontends\qt4\FileDialog.cpp(99) : error C2664: 
'QFileDialog::getSaveFileName' : cannot convert parameter 5 from 'QString' to 'QString *'
No user-defined-conversion operator available that can perform this conversion, or the 
operator cannot be called


regards Uwe

Re: Time to kill lyxrc.default_papersize ?

[Lars Gullik Bjønnes]

Vincent van Ravesteijn v...@lyx.org writes:

| Hi all,

| Is it time to kill lyxrc.default_papersize ?

| Reasons to do so:
| - except for A3 it has absolutely no effect since a few years;
| - it's against the LyX philosophy that the same document looks
| different on a different pc.

Heh. If I remember correctly, that was one of the first things I did when
introduced to LyX. (Or was it some color stuff?)

Re: LyX odg drawings

[Tommaso Cucinotta]

Il 06/10/2011 23:53, Julien Rioux ha scritto:



My easy fix would be to query formats and not even try to call
readBB_from_PSFile() unless the file is actually eps or eps.gz. Can I
ask why is this reading of the bounding box done ? Note that it may also
imply unzipping the file and searching for the contained BB, which may
be expensive. So, imagine I have a .odg (or other non-EPS format).
Should we really convert to EPS, then read the BB ?

Any scenario in which I can see the usefulness of this part of code
where the BB is needed to be extracted from the eps file ? On a related
note, this seems all tightly related to EPS. What if we embed a PNG or
PDF image ?

Having the BB allows you to crop the image with less guessing. It 
probably has some other use as well. When you load a .png, the 
readBB_from_PSFile fails and the BB is obtained from elsewhere (using 
converters if I recall, from the last time I checked). When you load 
an .odg it also fails, but it tries too hard, even tries to unzip the 
file in case it was a eps.gz. So I think you are right that we should 
check for the format of the included file, and only when it is an eps 
or ps, then we should call readBB_from_PSFile, and when it is not, go 
to the fallback. And when readBB_from_PSfile fails, still go to the 
fallback.


Let's put it in another way:
1) I just added a return string() into the readBB_from_PSFile(), cleaned 
manually the cache, and launched LyX: I can still see on the screen and 
on PDF the included EPS with the correct size (and I can see an included 
.odg as well for what it matters);
2) when we need to display an .eps on the screen, we use some external 
converter to get a bitmap (ImageMagick's convert, I guess); if the 
converter detects a bounding box in the EPS, then it will use it to 
create a bitmap of the proper size.


I must be missing some piece of the puzzle here. Is this related to DPI 
settings and the possibility for the user to crop in cm/mm/in, rather 
than pixels ?


T.

Re: Development for LyX 2.1

[Lars Gullik Bjønnes]

Vincent van Ravesteijn v...@lyx.org writes:


   up to know it was solved via commit hooks on lyx.org server.
   i guess we could proceed with lyx.org again, but it would be
   substantialy more work than gitorious. do you feel like working on it?
   (maybe Lars can help?).
 
  I can. If I am to do anything with this I am more likely to go the
  gitolite way.
 
  Lars, Are you willing to set up a git repo on our server ? Gitolite seems
  interesting indeed. I will have a closer look on it.

 I can look at it. Pity that the server uses debian, I am a lot less
 familiar with that.


| It would be nice if you could try anyway. I'm sure you'll be able to manage.

Before I try, I'd like to do the conversion proper and see if everybody
is comfortable with the result.

Btw. Are still interest in me doing this?
(gitolite and svn - git conversion)





  You really do not want to have all devvies pushing commits.
  Make a small cabal of people to do this instead.


| Hmm.. the LyX devvies are a small cabal of people.. right ?

yeah...

 This seems in general to be the policy, but I'm not sure I want to have
 too many restrictions. The idea was to let all devvies push into their
 own branches

 I don't think that is a good idea. Developers should have their own
 _repos_, at the server.


| That could be a possibility. I didn't want all developers to create a fork
| on github
| or gitorious or the like. However, I don't know how things will be when all
| devvies
| have a repo on the the server.

| Another thing I don't want is that we have to depend on one person to do
| the merging. If this person does not have time for a while, other people
| might
| get angry and demotivated if their features are not pulled into trunk-devel
| for
| some time. That's why I proposed that people with svn commit rights would
| be able to push themselves and merge their branch into trunk-devel. A script
| will then easily pick up the branch and will put it in the process which
| will
| eventually get it to merge into trunk-stable.

Note that the general (distributed) git model is a model where every
developers have two trees: one private one, and one public one.

The devloper uses the private one for personal development, branches
etc. And uses the public one for sharing his work. (a developer can of
course orgainize his work in multiple repos.)

In a project there will be a (one or more) special repos. Being the
pristine upstream repo, the master that all others are originally based
on.


 (merging to the main repo will not be any harder because of that, but
 a lot of cruft can
 be kept out. (after all deveopers come and go))

  and
  let them merge it into trunk-devel (which is a temporary branch). I will
  then merge
  it into trunk-stable.

 I must admit that I don't see the point in having two trunks. (I see a
 real danger in one being tested all the time, and the other almost not at
 all.)

|  The idea is that all features that are well tested and seemed to be ok are
| merged into the trunk-stable branch. In theory, it should not be needed to
| extensively test this branch because all separate features have been tested
| before. Secondly, it will be attractive to much more people to test
| trunk-stable
| as it won't have serious problems from time to time.

 Sure several release branches might be ok, (even if I'd even then
 would prefere multiple repos)
| The trunk-stable branch will be basically the release branch.

Well.. no I think. It will be where you can cut releases from, but the
release branch will either have to be a separate repo (eg. linux kernel
stable repos), or a branch.

 In all things git one really should look hard at the linux kernel
 development model and see what
 would fit and would would require modifcations.


| I'm looking at the Git development model and adapted it to our needs
| and to the feedback I got on the devel-list.

I think I must revise some of my thoughts. I think that you should
intially do deviate too much from the svn model that your are familiar
with, and rather enhance that model when you get experience with git and
begin to see benefits and opurtunities in useing a more gitty model.

Anyhow, I can work on getting this to happen.

Re: LyX odg drawings

[Julien Rioux]

On 07/10/2011 12:10 AM, Tommaso Cucinotta wrote:

I must be missing some piece of the puzzle here. Is this related to DPI
settings and the possibility for the user to crop in cm/mm/in, rather
than pixels ?


So, are you suggesting to ditch readBB_from_PSFile? I don't know enough 
about its use. But what about the Crop tab in the graphics dialog, do 
you still get sensible values there, so that I don't have to guess the BB?


--
Julien

Re: LyX as of r39805 uncompilable

[Tommaso Cucinotta]

Il 07/10/2011 00:03, Uwe Stöhr ha scritto:

Hi Tommaso,

I get this error:

D:\LyXSVN\lyx-devel\src\frontends\qt4\FileDialog.cpp(99) : error 
C2664: 'QFileDialog::getSaveFileName' : cannot convert parameter 5 
from 'QString' to 'QString *'
No user-defined-conversion operator available that can perform 
this conversion, or the operator cannot be called


r39810 to quick-fix compilation, but more investigation needed (from a 
couple of trials, it seemed to get the selected format right -- let me 
check more thoroughly). On my system the QFileDialog::getSave...() 
method wants a QString* for selectedFilter as well ?!?. But it compiles 
also the other way :-(.


T.

Re: LyX command-line option for output

[Richard Heck]

On 10/06/2011 04:42 PM, Tommaso Cucinotta wrote:
 Il 06/10/2011 21:02, Richard Heck ha scritto:
 On 10/06/2011 02:27 PM, Julien Rioux wrote:
 On 05/10/2011 11:49 PM, Tommaso Cucinotta wrote:
 lyx -c source.svg -o dest.eps # convert arbitrary formats
 (extension-based format detection for output)
 lyx -c -i svg source.svg -e eps -o dest.eps # explicitly set the input
 and output formats

 I haven't been following this closely, but I'm puzzled why LyX should
 act
 as a generic converter. This looks like asking for trouble when people
 don't get the right results.

 It already knows how to make a number of conversions. Just make
 this capability reusable from the outside. Simply Unix. For example,
 this can be used when invoking the external elyxer tool, making it
 capable of all the conversions that LyX can handle.
 If by chance a user wants to waste time creating an amazing
 lyxrc.default configuration that can handle nearly any possible
 conversion that is possible in this world, then drop it on the wiki
 and let users use it.

 I'm sure you have some concrete trouble scenario in your
 mind. Please, explicit it.

The only scenario I have in mind is users complaining when such things fail
and it's got nothing to do with LyX but instead because some external
converter
has failed. Or we start having weird crashes. Or who knows what.

It seems almost anti-Unix to me. Unix is about one tool doing one thing
well.
This is about making LyX do something totally unrelated, like convert svg to
png or whatever.

Richard

Re: LyX as of r39805 uncompilable

[Uwe Stöhr]

Am 07.10.2011 00:23, schrieb Tommaso Cucinotta:


D:\LyXSVN\lyx-devel\src\frontends\qt4\FileDialog.cpp(99) : error C2664:
'QFileDialog::getSaveFileName' : cannot convert parameter 5 from 'QString' to 
'QString *'
No user-defined-conversion operator available that can perform this conversion, 
or the operator
cannot be called


r39810 to quick-fix compilation


Thanks, this compiles. I'm using Qt 4.7.4.

regards Uwe

Re: LyX command-line option for output

[Tommaso Cucinotta]

Il 07/10/2011 00:51, Richard Heck ha scritto:

On 10/06/2011 04:42 PM, Tommaso Cucinotta wrote:

I'm sure you have some concrete trouble scenario in your
mind. Please, explicit it.

The only scenario I have in mind is users complaining when such things fail
and it's got nothing to do with LyX but instead because some external
converter
has failed. Or we start having weird crashes. Or who knows what.

It seems almost anti-Unix to me. Unix is about one tool doing one thing
well.
This is about making LyX do something totally unrelated, like convert svg to
png or whatever.


ok, ok -- you're right. The true Unix approach would require to factor
the whole conversion logic out of LyX into a separate stand-alone tool
(which would still be part of the LyX package). But one more LFUN
and some glue that adds lyx -c seems to me useful and achievable
via an acceptable trade-off for now.

I mean, how many times while writing pure LaTeX papers, I have a colleague
of mine using funny tools and committing over the paper repo some .svg
file (not to mention myself, as I usually commit weird .odg or .dia stuff).
I could just drop in the Makefile a lyx -c invocation to get EPS out of
whatever, instead of replicating the graph logics already embedded
into the powerful LyX :-)! And, AFAICS, yet another reason to persuade
even LaTeX experts to try LyX out at least once :-).

(Not to mention using LyX as a pure LaTeX compiler helper tool, but I'm
not sure that works out of the box, e.g., without the intermediate lyx step)

T.

Re: LyX as of r39805 uncompilable

[Tommaso Cucinotta]

Il 07/10/2011 01:32, Uwe Stöhr ha scritto:

Thanks, this compiles. I'm using Qt 4.7.4.


pls, let me know as well whether the Export-Export As... dialog works 
fine or you have any problems or suggestions.


T.

Re: LyX odg drawings

[Tommaso Cucinotta]

Il 07/10/2011 00:17, Julien Rioux ha scritto:

On 07/10/2011 12:10 AM, Tommaso Cucinotta wrote:

I must be missing some piece of the puzzle here. Is this related to DPI
settings and the possibility for the user to crop in cm/mm/in, rather
than pixels ?


So, are you suggesting to ditch readBB_from_PSFile? I don't know 
enough about its use. But what about the Crop tab in the graphics 
dialog, do you still get sensible values there, so that I don't have 
to guess the BB?


don't know ... need some testing without that function, to see what goes 
wrong.


One thing: I'm proposing, as export format in the related 
Export-Export As... GUI enhancement, any registered format for which 
documentFormat() returns true.


Formats::const_iterator it = formats.begin();
for (; it != formats.end(); ++it)
if (it-documentFormat())
types  toqstr(it-name() +  (*. + it-extension() + ));

However, I'm also getting gnumeric, xls, ods (spreadsheet), csv, R (math 
language) and other stuff in that list. Guess it's too much. Any clue on 
how to filter out only the

*real document* formats ?

T.

Discrimination of "New" in po files

[Jean-Pierre Chrétien]

Hello,

The string "New" appears in po files both for branches and indexes.
In French, the gender of the translation differs, so I need à [[...]] marker to 
be able to distinguish the two occurrences of the string.


Here is a patch implementing this (not tested).
Could you commit and regenerate the po files ?

TIA
Jean-Pierre
--- src/frontends/qt4/ui/BranchesUi.ui.orig	2011-10-06 09:39:56.0 +0200
+++ src/frontends/qt4/ui/BranchesUi.ui	2011-10-06 09:41:23.0 +0200
@@ -22,7 +22,7 @@

 
  
-  New:
+  New:[[branch]]
  
  
   newBranchLE
--- src/frontends/qt4/ui_IndicesUi.h.orig	2011-10-06 09:40:13.0 +0200
+++ src/frontends/qt4/ui_IndicesUi.h	2011-10-06 09:43:18.0 +0200
@@ -202,7 +202,7 @@
 multipleIndicesCB->setToolTip(lyx::qt_("Check if you need multiple indexes (e.g., an Index of Names)", 0));
 #endif // QT_NO_TOOLTIP
 multipleIndicesCB->setText(lyx::qt_(" multiple indexes", 0));
-newIndexLA->setText(lyx::qt_(":", 0));
+newIndexLA->setText(lyx::qt_(":[[index]]", 0));
 #ifndef QT_NO_TOOLTIP
 newIndexLE->setToolTip(lyx::qt_("Enter the name of the desired index (e.g. \"Index of Names\") and hit \"Add\"", 0));
 #endif // QT_NO_TOOLTIP

Re: Using LyX to convert arbitrary files.

[Guenter Milde]

On 2011-10-05, Richard Heck wrote:
> On 10/05/2011 06:09 AM, Guenter Milde wrote:
>> On 2011-10-03, Richard Heck wrote:

>> ...

>>> This behavior is controlled by the copier. The point is that we do not wish
>>> to clutter the file directory with what might be dozens of files.
>>> Another issue
>>> is that exporting two LyX files from the same directory might easily lead to
>>> one's over-writing files exported by the other.
>> But, I think these issues will be (partly?) remedied with the new option
>> allowing to set an explicite export file name and path. So, maybe, with the
>> new -C option, we should revise the policy...

> This would be possible, but only once the same option exists for 
> exporting from within LyX.

Maybe the current discussion can give some momentum to the
long standing issue?

http://www.lyx.org/trac/ticket/3402

http://www.lyx.org/trac/ticket/7246

Günter

Re: #7789: Word count will count words in deleted notes (with change tracking)

[Richard Heck]

On 10/05/2011 06:02 PM, Stephan Witt wrote:
> Am 04.10.2011 um 23:04 schrieb Richard Heck:
>
>> On 10/04/2011 04:22 PM, Stephan Witt wrote:
>>> Am 30.09.2011 um 13:13 schrieb LyX Ticket Tracker:
>>>
 #7789: Word count will count words in deleted notes (with change tracking)
 -+--
 Reporter:  bhelm|   Owner:  rgheck  
Type:  defect   |  Status:  new 
 Priority:  normal   |   Milestone:  
 Component:  changes  | Version:  2.0.Xsvn
 Severity:  normal   |Keywords:  patch   
 -+--
 Changes (by stwitt):

 * cc: stwitt (added)
 * keywords:  => patch
 -- 
 Ticket URL: 
>>> Does anyone has any objection? I'd like to apply the patch.
>>>
>> None here.
>>
>> That said, if possible, I'd prefer if you could separate this patch into
>> two parts:
>> (i) Whatever is actually needed to fix the bug
>> (ii) The unification and code moving stuff
>> That would make it easier for me to see what's happening here.
> The patch to fix the reported bug is attached.
>
> There is one problem: it is incomplete (the word count is fixed,
> the char counts remain wrong). One may fix the char count like I
> did it for word count. Or one may unify the count process and have
> both fixed. This is my final patch.
>
OK, well, the previous one is fine, then, as it seems there are two
bugs, really.

rh

Re: Using LyX to convert arbitrary files.

[Tommaso Cucinotta]

Il 06/10/2011 10:27, Guenter Milde ha scritto:

Maybe the current discussion can give some momentum to the
long standing issue?

http://www.lyx.org/trac/ticket/3402


Please, try the committed version, it should fix the mentioned ticket.

T.

Re: Using LyX to convert arbitrary files.

[Tommaso Cucinotta]

Il 06/10/2011 15:50, Tommaso Cucinotta ha scritto:

Il 06/10/2011 10:27, Guenter Milde ha scritto:

Maybe the current discussion can give some momentum to the
long standing issue?

http://www.lyx.org/trac/ticket/3402


Please, try the committed version, it should fix the mentioned ticket.


forgot to mention: You do "Export->Export As...", and it pops up a dialog
enumerating all formats tagged as "document" in the filter selection box,
plus a match-everything first entry (*.*). If a specific type is chosen, 
then

the corresponding destination format is used, otherwise the format is
inferred from the specified file extension.

Then, an export to that format with the explicit filename is issued.

T.

Re: #7789: Word count will count words in deleted notes (with change tracking)

[Stephan Witt]

Am 06.10.2011 um 15:09 schrieb Richard Heck:

> On 10/05/2011 06:02 PM, Stephan Witt wrote:
>> Am 04.10.2011 um 23:04 schrieb Richard Heck:
>> 
>>> On 10/04/2011 04:22 PM, Stephan Witt wrote:
 Am 30.09.2011 um 13:13 schrieb LyX Ticket Tracker:
 
> #7789: Word count will count words in deleted notes (with change tracking)
> -+--
> Reporter:  bhelm|   Owner:  rgheck  
>   Type:  defect   |  Status:  new 
> Priority:  normal   |   Milestone:  
> Component:  changes  | Version:  2.0.Xsvn
> Severity:  normal   |Keywords:  patch   
> -+--
> Changes (by stwitt):
> 
> * cc: stwitt (added)
> * keywords:  => patch
> -- 
> Ticket URL: 
 Does anyone has any objection? I'd like to apply the patch.
 
>>> None here.
>>> 
>>> That said, if possible, I'd prefer if you could separate this patch into
>>> two parts:
>>> (i) Whatever is actually needed to fix the bug
>>> (ii) The unification and code moving stuff
>>> That would make it easier for me to see what's happening here.
>> The patch to fix the reported bug is attached.
>> 
>> There is one problem: it is incomplete (the word count is fixed,
>> the char counts remain wrong). One may fix the char count like I
>> did it for word count. Or one may unify the count process and have
>> both fixed. This is my final patch.
>> 
> OK, well, the previous one is fine, then, as it seems there are two
> bugs, really.

Yes, and there is a FIXME in countWords: "merge with countChars..."
There was a discussion about that on lyx-devel after r37940...

After this fix is commited one may extend the statistics:
* add more details as Tommaso suggested
* add statistics for child documents, when in parent

Stephan

Re: Memory usage during Advanced Search in math mode.

[Rudi Gaelzer]

Ok.  Give me some days to find the time to compile from the source and do the 
tests.

On Wednesday, October 05, 2011 06:03:44 PM Tommaso Cucinotta wrote:
> Il 05/10/2011 22:54, Tommaso Cucinotta ha scritto:
> > 2) try to recompile LyX from the sources, to check whether the problem
> > still shows up on your system or not in the current trunk. Shortly
> > (but it's going to take half an hour or so):
> > 
> > svn co svn://svn.lyx.org/lyx/lyx-devel/trunk lyx-trunk
> > cd lyx-trunk
> > ./autogen.sh
> > ./configure --prefix=/usr/local/lyx-trunk --enable-debug
> 
> I forgot to mention: please, add also this option to configure:
> 
>--with-version-suffix=-trunk
> 
> to avoid that the trunk lyx version fiddles around you system-wide lyx's
> configuration files.
> 
>  T.

-- 
Rudi Gaelzer
Department of Physics
Institute of Physics and Mathematics
Federal University of Pelotas
BRAZIL
Registered linux user # 153741

Re: [patch] add document-wide bibliography style setting

[Julien Rioux]

On 06/10/2011 6:01 PM, Julien Rioux wrote:

First step of moving the bibliography settings to the document settings
(needed, e.g., for biblatex support). We define a default there. A
BibTeX inset takes the "default" style from the buffer if it doesn't
specify a style of its own. No UI yet, but it's coming. OK?



Sorry, wrong list..

--
Julien

[patch] add document-wide bibliography style setting

[Julien Rioux]

First step of moving the bibliography settings to the document settings 
(needed, e.g., for biblatex support). We define a default there. A 
BibTeX inset takes the "default" style from the buffer if it doesn't 
specify a style of its own. No UI yet, but it's coming. OK?


--
Julien
>From cb7225e511ea0ae8714a7bccc6e0bb94ae0698f6 Mon Sep 17 00:00:00 2001
From: Julien Rioux 
Date: Thu, 6 Oct 2011 17:38:05 +0200
Subject: [PATCH] Add a document-wide default bibliography style \biblio_style.

This holds the name of a BibTeX style file for now. Any BibTeX inset
can set the style to "default" to use the document-wide style.

LyX format incremented to 417.
---
 development/FORMAT |5 
 lib/lyx2lyx/lyx_2_1.py |   52 ---
 src/Buffer.cpp |2 +-
 src/BufferParams.cpp   |   17 ++
 src/BufferParams.h |7 ++
 src/insets/InsetBibtex.cpp |3 ++
 6 files changed, 81 insertions(+), 5 deletions(-)

diff --git a/development/FORMAT b/development/FORMAT
index 10c1d88..577c07c 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -11,6 +11,11 @@ adjustments are made to tex2lyx and bugs are fixed in lyx2lyx.
 
 ---
 
+2011-10-06 Julien Rioux 
+	* Format incremented to 417 (rX)
+	  New buffer param \biblio_style to specify a document-wide
+	  default bibliography style (BibTeX style for the moment).
+
 2011-08-29 Uwe Stöhr 
 	* Format incremented to 416 (r39557)
 	  support for \negmedspace and \negthinspace outside of math
diff --git a/lib/lyx2lyx/lyx_2_1.py b/lib/lyx2lyx/lyx_2_1.py
index 6c6c6fe..ead33f2 100644
--- a/lib/lyx2lyx/lyx_2_1.py
+++ b/lib/lyx2lyx/lyx_2_1.py
@@ -25,7 +25,8 @@ import sys, os
 
 # Uncomment only what you need to import, please.
 
-from parser_tools import find_token, find_end_of_inset, get_value
+from parser_tools import find_token, find_end_of_inset, get_value, \
+get_quoted_value
 
 #from parser_tools import find_token, find_end_of, find_tokens, \
   #find_token_exact, find_end_of_inset, find_end_of_layout, \
@@ -162,17 +163,60 @@ def revert_math_spaces(document):
   i = i + 1
 
 
+def convert_biblio_style(document):
+"Add a sensible default for \\biblio_style based on the citation engine."
+i = find_token(document.header, "\\cite_engine", 0)
+if i != -1:
+engine = get_value(document.header, "\\cite_engine", i).split("_")[0]
+style = {"basic": "plain", "natbib": "plainnat", "jurabib": "jurabib"}
+document.header.insert(i + 1, "\\biblio_style " + style[engine])
+
+
+def revert_biblio_style(document):
+"BibTeX insets with default option use the style defined by \\biblio_style."
+i = find_token(document.header, "\\biblio_style" , 0)
+if i == -1:
+document.warning("No \\biblio_style line. Nothing to do.")
+return
+
+default_style = get_value(document.header, "\\biblio_style", i)
+del document.header[i]
+
+# We are looking for bibtex insets having the default option
+i = 0
+while True:
+i = find_token(document.body, "\\begin_inset CommandInset bibtex", i)
+if i == -1:
+return
+j = find_end_of_inset(document.body, i)
+if j == -1:
+document.warning("Malformed LyX document: Can't find end of bibtex inset at line " + str(i))
+i += 1
+return
+k = find_token(document.body, "options", i, j)
+if k != -1:
+options = get_quoted_value(document.body, "options", k)
+if options.split(",")[0] == "default":
+document.body[k] = 'options "%s"' \
+% options.replace("default", default_style) + '"'
+i = j
+
+
 ##
 # Conversion hub
 #
 
 supported_versions = ["2.1.0","2.1"]
-convert = [[414, []],
+convert = [
+   [414, []],
[415, [convert_undertilde]],
-   [416, []]
+   [416, []],
+   [417, [convert_biblio_style]],
   ]
 
-revert =  [[415, [revert_negative_space,revert_math_spaces]],
+revert =  [
+   [416, [revert_biblio_style]],
+   [415, [revert_negative_space,revert_math_spaces]],
[414, [revert_undertilde]],
[413, [revert_visible_space]]
   ]
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 6aedab2..1b892e5 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -128,7 +128,7 @@ namespace {
 
 // Do not remove the comment below, so we get merge conflict in
 // independent branches. Instead add your own.
-int const LYX_FORMAT = 416; //uwestoehr : support for horizontal spaces (bug 7728)
+int const LYX_FORMAT = 417; //jrioux : document-wide BibTeX style via \biblio_style
 
 typedef map DepClean;
 typedef map RefCache;
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index 4f1edc1..e0f66a0 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ 

Re: Using LyX to convert arbitrary files.

[Julien Rioux]

On 06/10/2011 3:54 PM, Tommaso Cucinotta wrote:

Please, try the committed version, it should fix the mentioned ticket.


forgot to mention: You do "Export->Export As...", and it pops up a dialog
enumerating all formats tagged as "document" in the filter selection box,
plus a match-everything first entry (*.*). If a specific type is chosen,
then
the corresponding destination format is used, otherwise the format is
inferred from the specified file extension.


We have "Export as..." at the top of the menu and "More options..." at 
the bottom, could they be moved together?


In the save dialog, how am I to figure which of the pdf pdf2 pdf3 pdf4 
format do I want?




Then, an export to that format with the explicit filename is issued.

T.




--
Julien

Re: LyX & odg drawings

[Julien Rioux]

On 27/09/2011 3:51 PM, Julien Rioux wrote:

On 20/09/2011 12:05 AM, Tommaso Cucinotta wrote:

Il 19/09/2011 23:15, Julien Rioux ha scritto:

Sorry, not much time. Don't you also get this behavior?


Not of course: for me, it works like a charm! I can insert dia files (as
graphics) and odg files (as graphics), and they show up on the screen,
are properly included in generated DVI, PS, PDF.



You have to click on the figure to open the graphics dialog. Then you
get these error messages. Hint: It occurs in readBB_from_PSFile.



By the way I still get this, and it happens whether I have the converter 
cache enabled or not. Could you please look into it?


--
Julien

Re: Using LyX to convert arbitrary files.

[Tommaso Cucinotta]

Il 06/10/2011 18:58, Julien Rioux ha scritto:
We have "Export as..." at the top of the menu and "More options..." at 
the bottom, could they be moved together?


I struggle at getting the rationale behind the "More Options..." entry. 
You are supposed to enter a custom command that performs the actual 
export ? Isn't this somewhat overlapping with the converters 
configuration in the preferences ? I mean, you can define your own 
format (there's also the preferences GUI for that) along with a 
converter from ps or from pdf to that, and later say you want to export 
to that custom format, can't you ?


In the save dialog, how am I to figure which of the pdf pdf2 pdf3 pdf4 
format do I want?


The formats are listed in the filter selection with their name, for example:

Any supported format (*.*)
They are ps (*.ps)
pdf (*.pdf)
pdf2 (*.pdf)
pdf3 (*.pdf)
...

Now, if you leave the selection to the default entry (first line, i.e., 
*.*), then the format is inferred as formats.getFormatFromExtension(). 
Therefore, for .pdf, I don't know what comes out, probably it is the 
first match. However, if you select either pdf2 or pdf3 etc..., then you 
may get exactly the export format you want (assuming the user 
understands these pdf2, pdf3, etc.. and is capable of discriminating 
among them and picking the right one he/she needs -- guess/hope we have 
something in the manual).


T.

Re: LyX & odg drawings

[Tommaso Cucinotta]

Il 06/10/2011 19:02, Julien Rioux ha scritto:


By the way I still get this, and it happens whether I have the 
converter cache enabled or not. Could you please look into it?


Sure, let's re-make the point. Can you, please, open that "odg.lyx" file 
with "-dbg any", and send the whole output, along with your 
.lyx/lyxrc-default settings ?


Thanks,

 T.

Re: LyX command-line option for output

[Julien Rioux]

On 05/10/2011 11:49 PM, Tommaso Cucinotta wrote:

Independently of how it can be implemented, this is a possible
re-thinking of the syntax (by examples):

lyx myfile.txt # import from TXT
lyx -i latex myfile.txt # explicitly specify the import format
lyx -o dest.txt source.lyx # export from LYX to TXT
lyx -e latex -o dest.txt source.lyx # export to LATEX, output to dest.txt
lyx -e latex source.lyx # export to LATEX, output to source.tex
lyx -e latex -o /path/to/dest.tex source.lyx # Got the point
lyx -c source.svg -o dest.eps # convert arbitrary formats
(extension-based format detection for output)
lyx -c -i svg source.svg -e eps -o dest.eps # explicitly set the input
and output formats

Summarising, a few options would be common to import/export of document
or image formats:

-i fmt specify input/import format
-e fmt specify export format
-o filename specify output filename

If "-e" or "-o" is specified, then assume/imply "--batch" and attempt an
export. If "-c" is present, try to act as batch converter.



IMHO that would be a quite nice and natural way to use LyX from the 
command line.



Also, I'd like to see a help message in response to "lyx -h" or
"--help", the "userdir", "sysdir", "batch" and "version" options should
be prefixed by a double dash "--userdir", "--sysdir", "--batch",
"--version" plus perhaps having an equivalent shorter option (-u, -s,
-b, -v).



Sure, that's more gnu-like. We'll have to keep the one-dash versions 
around, though.


Cheers,
Julien

Re: LyX command-line option for output

[Richard Heck]

On 10/06/2011 02:27 PM, Julien Rioux wrote:
> On 05/10/2011 11:49 PM, Tommaso Cucinotta wrote:
>> lyx -c source.svg -o dest.eps # convert arbitrary formats
>> (extension-based format detection for output)
>> lyx -c -i svg source.svg -e eps -o dest.eps # explicitly set the input
>> and output formats
>>
I haven't been following this closely, but I'm puzzled why LyX should act
as a generic converter. This looks like asking for trouble when people
don't get the right results.

Richard

Re: LyX command-line option for output

[Tommaso Cucinotta]

Il 06/10/2011 21:02, Richard Heck ha scritto:

On 10/06/2011 02:27 PM, Julien Rioux wrote:

On 05/10/2011 11:49 PM, Tommaso Cucinotta wrote:

lyx -c source.svg -o dest.eps # convert arbitrary formats
(extension-based format detection for output)
lyx -c -i svg source.svg -e eps -o dest.eps # explicitly set the input
and output formats


I haven't been following this closely, but I'm puzzled why LyX should act
as a generic converter. This looks like asking for trouble when people
don't get the right results.


It already knows how to make a number of conversions. Just make
this capability reusable from the outside. Simply Unix. For example,
this can be used when invoking the external elyxer tool, making it
capable of all the conversions that LyX can handle.
If by chance a user wants to waste time creating an amazing
lyxrc.default configuration that can handle nearly any possible
conversion that is possible in this world, then drop it on the wiki
and let users use it.

I'm sure you have some concrete "trouble scenario" in your
mind. Please, explicit it.

T.

Re: LyX & odg drawings

[Tommaso Cucinotta]

Il 06/10/2011 19:52, Julien Rioux ha scritto:

On 06/10/2011 7:36 PM, Tommaso Cucinotta wrote:

Il 06/10/2011 19:02, Julien Rioux ha scritto:


By the way I still get this, and it happens whether I have the
converter cache enabled or not. Could you please look into it?


A few questions:
1) what was exactly the visible problem ? (from your log I can't see 
anything
different from what I can see in my own log -- the only problem is 
that it
probably still fails to detect the BoundingBox because there's a 
residual
direct call to FileName::isZipped() that makes it believe (again - 
argh!) that
.odg is a zipped file and needs to be decompressed -- however, I 
get that
error and still the .odg is visible on the screen, and is converted 
right in the

pdf etc.)
2) did you produce this log when your additional patch was applied, or 
on the

current trunk ?
3) did you have anything in the cache when you launched lyx ?
4) did you try "rm ~/.lyx-trunk/cache/*" before launching lyx and 
opening that file ?


Thx,

T.

lyx as an equation editor

[Liviu Andronic]

Dear all
This request comes up every now and then, and was even part of our
aborted GSoC 2011.

But I was wondering whether there was a simple solution to this,
namely re-using the Instant Preview machinery. I am not familiar with
it's internals, but I understand that to display the LaTeX results the
IP uses the 'preview' package to generate images and then embeds these
into the LyX editor window. If I am getting this right, then LyX will
have already generated an image out of a formula.

How difficult would it be to add a 'Save IP' (or similar) to the
c-menu of a math inset and allow users to export the image? Since LyX
already knows how to convert a whole lot of formats, the dialogue
could allow to save to all image formats known to LyX. If the
generated image were in a vector format, then the whole process would
be perfect.

Do you think that this is feasible? Regards
Liviu


-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Re: LyX & odg drawings

[Julien Rioux]

On 06/10/2011 11:05 PM, Tommaso Cucinotta wrote:

Il 06/10/2011 19:52, Julien Rioux ha scritto:

On 06/10/2011 7:36 PM, Tommaso Cucinotta wrote:

Il 06/10/2011 19:02, Julien Rioux ha scritto:


By the way I still get this, and it happens whether I have the
converter cache enabled or not. Could you please look into it?


A few questions:
1) what was exactly the visible problem ? (from your log I can't see
anything
different from what I can see in my own log -- the only problem is that it
probably still fails to detect the BoundingBox because there's a residual
direct call to FileName::isZipped() that makes it believe (again -
argh!)


Ah! so you do see the bug then.


that .odg is a zipped file and needs to be decompressed -- however, I get that
error and still the .odg is visible on the screen, and is converted
right in the
pdf etc.)


There is no visual problem. I never mentioned any visual problem. When 
you open the graphics dialog, from the bounding box calculation there is 
a call to gunzip the odg file, which is wrong. But that's all.



2) did you produce this log when your additional patch was applied, or
on the
current trunk ?


Not a clean trunk, but I'm working on citation stuff at the moment, so 
quite unrelated.



3) did you have anything in the cache when you launched lyx ?


Generally I turn the cache off, but I also tried turning it on and I 
still can see that LyX tries to gunzip the odg file when I open the 
graphics dialog.



4) did you try "rm ~/.lyx-trunk/cache/*" before launching lyx and
opening that file ?



Since I always have the cache off, this folder is already empty (had an 
empty index file in it).



Thx,

T.



No problem,
Cheers,
Julien

Re: LyX & odg drawings

[Tommaso Cucinotta]

Il 06/10/2011 23:21, Julien Rioux ha scritto:

On 06/10/2011 11:05 PM, Tommaso Cucinotta wrote:

A few questions:
1) what was exactly the visible problem ? (from your log I can't see
anything
different from what I can see in my own log -- the only problem is 
that it
probably still fails to detect the BoundingBox because there's a 
residual

direct call to FileName::isZipped() that makes it believe (again -
argh!)


Ah! so you do see the bug then.


I hadn't noticed it before, because I couldn't see any evident 
misbehavior. But now that you forced me to look into the log, I can see it.


My easy fix would be to query formats and not even try to call 
readBB_from_PSFile() unless the file is actually eps or eps.gz. Can I 
ask why is this reading of the bounding box done ? Note that it may also 
imply unzipping the file and searching for the contained BB, which may 
be expensive. So, imagine I have a .odg (or other non-EPS format). 
Should we really convert to EPS, then read the BB ?


Any scenario in which I can see the usefulness of this part of code 
where the BB is needed to be extracted from the eps file ? On a related 
note, this seems all tightly related to EPS. What if we embed a PNG or 
PDF image ?


Thanks,

T.

Re: LyX & odg drawings

[Julien Rioux]

On 06/10/2011 11:46 PM, Tommaso Cucinotta wrote:

Il 06/10/2011 23:21, Julien Rioux ha scritto:

On 06/10/2011 11:05 PM, Tommaso Cucinotta wrote:

A few questions:
1) what was exactly the visible problem ? (from your log I can't see
anything
different from what I can see in my own log -- the only problem is
that it
probably still fails to detect the BoundingBox because there's a
residual
direct call to FileName::isZipped() that makes it believe (again -
argh!)


Ah! so you do see the bug then.


I hadn't noticed it before, because I couldn't see any evident
misbehavior. But now that you forced me to look into the log, I can see it.

My easy fix would be to query formats and not even try to call
readBB_from_PSFile() unless the file is actually eps or eps.gz. Can I
ask why is this reading of the bounding box done ? Note that it may also
imply unzipping the file and searching for the contained BB, which may
be expensive. So, imagine I have a .odg (or other non-EPS format).
Should we really convert to EPS, then read the BB ?

Any scenario in which I can see the usefulness of this part of code
where the BB is needed to be extracted from the eps file ? On a related
note, this seems all tightly related to EPS. What if we embed a PNG or
PDF image ?

Thanks,

T.




Having the BB allows you to crop the image with less guessing. It 
probably has some other use as well. When you load a .png, the 
readBB_from_PSFile fails and the BB is obtained from elsewhere (using 
converters if I recall, from the last time I checked). When you load an 
.odg it also fails, but it tries too hard, even tries to unzip the file 
in case it was a eps.gz. So I think you are right that we should check 
for the format of the included file, and only when it is an eps or ps, 
then we should call readBB_from_PSFile, and when it is not, go to the 
fallback. And when readBB_from_PSfile fails, still go to the fallback.


Cheers,
Julien

LyX as of r39805 uncompilable

[Uwe Stöhr]

Hi Tommaso,

I get this error:

D:\LyXSVN\lyx-devel\src\frontends\qt4\FileDialog.cpp(99) : error C2664: 
'QFileDialog::getSaveFileName' : cannot convert parameter 5 from 'QString' to 'QString *'
No user-defined-conversion operator available that can perform this conversion, or the 
operator cannot be called


regards Uwe

Re: Time to kill lyxrc.default_papersize ?

[Lars Gullik Bjønnes]

Vincent van Ravesteijn  writes:

| Hi all,
>
| Is it time to kill lyxrc.default_papersize ?
>
| Reasons to do so:
| - except for A3 it has absolutely no effect since a few years;
| - it's against the LyX philosophy that the same document looks
| different on a different pc.

Heh. If I remember correctly, that was one of the first things I did when
introduced to LyX. (Or was it some color stuff?)

Re: LyX & odg drawings

[Tommaso Cucinotta]

Il 06/10/2011 23:53, Julien Rioux ha scritto:



My easy fix would be to query formats and not even try to call
readBB_from_PSFile() unless the file is actually eps or eps.gz. Can I
ask why is this reading of the bounding box done ? Note that it may also
imply unzipping the file and searching for the contained BB, which may
be expensive. So, imagine I have a .odg (or other non-EPS format).
Should we really convert to EPS, then read the BB ?

Any scenario in which I can see the usefulness of this part of code
where the BB is needed to be extracted from the eps file ? On a related
note, this seems all tightly related to EPS. What if we embed a PNG or
PDF image ?

Having the BB allows you to crop the image with less guessing. It 
probably has some other use as well. When you load a .png, the 
readBB_from_PSFile fails and the BB is obtained from elsewhere (using 
converters if I recall, from the last time I checked). When you load 
an .odg it also fails, but it tries too hard, even tries to unzip the 
file in case it was a eps.gz. So I think you are right that we should 
check for the format of the included file, and only when it is an eps 
or ps, then we should call readBB_from_PSFile, and when it is not, go 
to the fallback. And when readBB_from_PSfile fails, still go to the 
fallback.


Let's put it in another way:
1) I just added a return string() into the readBB_from_PSFile(), cleaned 
manually the cache, and launched LyX: I can still see on the screen and 
on PDF the included EPS with the correct size (and I can see an included 
.odg as well for what it matters);
2) when we need to display an .eps on the screen, we use some external 
converter to get a bitmap (ImageMagick's convert, I guess); if the 
converter detects a bounding box in the EPS, then it will use it to 
create a bitmap of the proper size.


I must be missing some piece of the puzzle here. Is this related to DPI 
settings and the possibility for the user to crop in cm/mm/in, rather 
than pixels ?


T.

Re: Development for LyX 2.1

[Lars Gullik Bjønnes]

Vincent van Ravesteijn  writes:

>>
>> >> > up to know it was solved via commit hooks on lyx.org server.
>> >> > i guess we could proceed with lyx.org again, but it would be
>> >> > substantialy more work than gitorious. do you feel like working on it?
>> >> > (maybe Lars can help?).
>> >>
>> >> I can. If I am to do anything with this I am more likely to go the
>> >> gitolite way.
>> >
>> > Lars, Are you willing to set up a git repo on our server ? Gitolite seems
>> > interesting indeed. I will have a closer look on it.
>>
>> I can look at it. Pity that the server uses debian, I am a lot less
>> familiar with that.
>
>
| It would be nice if you could try anyway. I'm sure you'll be able to manage.

Before I try, I'd like to do the conversion proper and see if everybody
is comfortable with the result.

Btw. Are still interest in me doing this?
(gitolite and svn -> git conversion)


>
>
>
>> >> You really do not want to have all devvies pushing commits.
>> >> Make a small cabal of people to do this instead.
>>
>
| Hmm.. the LyX devvies are a small cabal of people.. right ?

yeah...

>>> This seems in general to be the policy, but I'm not sure I want to have
>>> too many restrictions. The idea was to let all devvies push into their
>>> own branches
>
>> I don't think that is a good idea. Developers should have their own
>> _repos_, at the server.
>>
>
| That could be a possibility. I didn't want all developers to create a fork
| on github
| or gitorious or the like. However, I don't know how things will be when all
| devvies
| have a repo on the the server.
>
| Another thing I don't want is that we have to depend on one person to do
| the merging. If this person does not have time for a while, other people
| might
| get angry and demotivated if their features are not pulled into trunk-devel
| for
| some time. That's why I proposed that people with svn commit rights would
| be able to push themselves and merge their branch into trunk-devel. A script
| will then easily pick up the branch and will put it in the process which
| will
| eventually get it to merge into trunk-stable.

Note that the general (distributed) git model is a model where every
developers have two trees: one private one, and one public one.

The devloper uses the private one for personal development, branches
etc. And uses the public one for sharing his work. (a developer can of
course orgainize his work in multiple repos.)

In a project there will be a (one or more) special repos. Being the
pristine upstream repo, the master that all others are originally based
on.

>
>> (merging to the main repo will not be any harder because of that, but
>> a lot of cruft can
>> be kept out. (after all deveopers come and go))
>>
>> > and
>> > let them merge it into trunk-devel (which is a temporary branch). I will
>> > then merge
>> > it into trunk-stable.
>>
>> I must admit that I don't see the point in having two trunks. (I see a
>> real danger in one being tested all the time, and the other almost not at
>> all.)
>>
|  The idea is that all features that are well tested and seemed to be ok are
| merged into the trunk-stable branch. In theory, it should not be needed to
| extensively test this branch because all separate features have been tested
| before. Secondly, it will be attractive to much more people to test
| trunk-stable
| as it won't have serious problems from time to time.
>
>> Sure several release branches might be ok, (even if I'd even then
>> would prefere multiple repos)
| The trunk-stable branch will be basically the "release branch".

Well.. no I think. It will be where you can cut releases from, but the
release branch will either have to be a separate repo (eg. linux kernel
stable repos), or a branch.

>> In all things git one really should look hard at the linux kernel
>> development model and see what
>> would fit and would would require modifcations.
>>
>
| I'm looking at the Git development model and adapted it to our needs
| and to the feedback I got on the devel-list.

I think I must revise some of my thoughts. I think that you should
intially do deviate too much from the svn model that your are familiar
with, and rather enhance that model when you get experience with git and
begin to see benefits and opurtunities in useing a more "gitty" model.

Anyhow, I can work on getting this to happen.

Re: LyX & odg drawings

[Julien Rioux]

On 07/10/2011 12:10 AM, Tommaso Cucinotta wrote:

I must be missing some piece of the puzzle here. Is this related to DPI
settings and the possibility for the user to crop in cm/mm/in, rather
than pixels ?


So, are you suggesting to ditch readBB_from_PSFile? I don't know enough 
about its use. But what about the Crop tab in the graphics dialog, do 
you still get sensible values there, so that I don't have to guess the BB?


--
Julien

Re: LyX as of r39805 uncompilable

[Tommaso Cucinotta]

Il 07/10/2011 00:03, Uwe Stöhr ha scritto:

Hi Tommaso,

I get this error:

D:\LyXSVN\lyx-devel\src\frontends\qt4\FileDialog.cpp(99) : error 
C2664: 'QFileDialog::getSaveFileName' : cannot convert parameter 5 
from 'QString' to 'QString *'
No user-defined-conversion operator available that can perform 
this conversion, or the operator cannot be called


r39810 to quick-fix compilation, but more investigation needed (from a 
couple of trials, it seemed to get the selected format right -- let me 
check more thoroughly). On my system the QFileDialog::getSave...() 
method wants a QString* for selectedFilter as well ?!?. But it compiles 
also the other way :-(.


T.

Re: LyX command-line option for output

[Richard Heck]

On 10/06/2011 04:42 PM, Tommaso Cucinotta wrote:
> Il 06/10/2011 21:02, Richard Heck ha scritto:
>> On 10/06/2011 02:27 PM, Julien Rioux wrote:
>>> On 05/10/2011 11:49 PM, Tommaso Cucinotta wrote:
 lyx -c source.svg -o dest.eps # convert arbitrary formats
 (extension-based format detection for output)
 lyx -c -i svg source.svg -e eps -o dest.eps # explicitly set the input
 and output formats

>> I haven't been following this closely, but I'm puzzled why LyX should
>> act
>> as a generic converter. This looks like asking for trouble when people
>> don't get the right results.
>
> It already knows how to make a number of conversions. Just make
> this capability reusable from the outside. Simply Unix. For example,
> this can be used when invoking the external elyxer tool, making it
> capable of all the conversions that LyX can handle.
> If by chance a user wants to waste time creating an amazing
> lyxrc.default configuration that can handle nearly any possible
> conversion that is possible in this world, then drop it on the wiki
> and let users use it.
>
> I'm sure you have some concrete "trouble scenario" in your
> mind. Please, explicit it.
>
The only scenario I have in mind is users complaining when such things fail
and it's got nothing to do with LyX but instead because some external
converter
has failed. Or we start having weird crashes. Or who knows what.

It seems almost anti-Unix to me. Unix is about one tool doing one thing
well.
This is about making LyX do something totally unrelated, like convert svg to
png or whatever.

Richard

Re: LyX as of r39805 uncompilable

[Uwe Stöhr]

Am 07.10.2011 00:23, schrieb Tommaso Cucinotta:


D:\LyXSVN\lyx-devel\src\frontends\qt4\FileDialog.cpp(99) : error C2664:
'QFileDialog::getSaveFileName' : cannot convert parameter 5 from 'QString' to 
'QString *'
No user-defined-conversion operator available that can perform this conversion, 
or the operator
cannot be called


r39810 to quick-fix compilation


Thanks, this compiles. I'm using Qt 4.7.4.

regards Uwe

Re: LyX command-line option for output

[Tommaso Cucinotta]

Il 07/10/2011 00:51, Richard Heck ha scritto:

On 10/06/2011 04:42 PM, Tommaso Cucinotta wrote:

I'm sure you have some concrete "trouble scenario" in your
mind. Please, explicit it.

The only scenario I have in mind is users complaining when such things fail
and it's got nothing to do with LyX but instead because some external
converter
has failed. Or we start having weird crashes. Or who knows what.

It seems almost anti-Unix to me. Unix is about one tool doing one thing
well.
This is about making LyX do something totally unrelated, like convert svg to
png or whatever.


ok, ok -- you're right. The true Unix approach would require to factor
the whole conversion logic out of LyX into a separate stand-alone tool
(which would still be part of the LyX package). But one more LFUN
and some "glue" that adds "lyx -c" seems to me useful and achievable
via an acceptable trade-off for now.

I mean, how many times while writing pure LaTeX papers, I have a colleague
of mine using funny tools and committing over the paper repo some .svg
file (not to mention myself, as I usually commit weird .odg or .dia stuff).
I could just drop in the Makefile a "lyx -c" invocation to get EPS out of
whatever, instead of replicating the graph logics already embedded
into the powerful LyX :-)! And, AFAICS, yet another reason to persuade
even LaTeX experts to try LyX out at least once :-).

(Not to mention using LyX as a pure LaTeX compiler helper tool, but I'm
not sure that works out of the box, e.g., without the intermediate lyx step)

T.

Re: LyX as of r39805 uncompilable

[Tommaso Cucinotta]

Il 07/10/2011 01:32, Uwe Stöhr ha scritto:

Thanks, this compiles. I'm using Qt 4.7.4.


pls, let me know as well whether the Export->Export As... dialog works 
fine or you have any problems or suggestions.


T.

Re: LyX & odg drawings

[Tommaso Cucinotta]

Il 07/10/2011 00:17, Julien Rioux ha scritto:

On 07/10/2011 12:10 AM, Tommaso Cucinotta wrote:

I must be missing some piece of the puzzle here. Is this related to DPI
settings and the possibility for the user to crop in cm/mm/in, rather
than pixels ?


So, are you suggesting to ditch readBB_from_PSFile? I don't know 
enough about its use. But what about the Crop tab in the graphics 
dialog, do you still get sensible values there, so that I don't have 
to guess the BB?


don't know ... need some testing without that function, to see what goes 
wrong.


One thing: I'm proposing, as export format in the related 
"Export->Export As..." GUI enhancement, any registered format for which 
documentFormat() returns true.


Formats::const_iterator it = formats.begin();
for (; it != formats.end(); ++it)
if (it->documentFormat())
types << toqstr(it->name() + " (*." + it->extension() + ")");

However, I'm also getting gnumeric, xls, ods (spreadsheet), csv, R (math 
language) and other stuff in that list. Guess it's too much. Any clue on 
how to filter out only the

*real document* formats ?

T.