Re: The emission of \maketitle

[Guenter Milde]

On 2010-03-05, Manoj Rajagopalan wrote:
 Hi lyx-devel,

What controls the emission of \maketitle when exporting to latex?

There is an intitle (or something like that) keyword for layout
styles. It is explained in the Customization guide.
(Or look at the implementation of the abstract style.)

Günter

RE: Patch: table splitting functionality

[Vincent van Ravesteijn - TNW]

The code update is still within InsetTabular::tabularFeatures().
Vincent
raised a valid issue about an inset creating new insets but here are my
thoughts:

1. This inset is only creating and inserting a subset of itself. It
also correctly
pops the cursor and places it between the two parts. 


I feel it's just not he task of a particular inset to insert other
insets into the main document.

Jmarc ? Do you have an opinion ?

 All this using standard API calls so it is safe.

This makes no sense. You can do a lot of harm using cur.pop() and
friends.

  Please correct me: the lyx code currently doesn't have any place
where insets,
 in general, can be split. It could. For example, split a paragraph. 

What do you mean ? Of course we can split a paragraph.

Seems extraneous till you see that it can be bundled with split-table
or split-equation
into a common LFUN_INSET_SPLIT (say). It would then be simpler to
insert the
table-split code here and maintain Vincent's argument.

Looks like a good idea to me.

Vincent

Re: r33624 - lyx-devel/trunk/src/support

[Abdelrazak Younes]

On 03/05/2010 09:05 AM, sa...@lyx.org wrote:

Author: sanda
Date: Fri Mar  5 09:05:25 2010
New Revision: 33624
URL: http://www.lyx.org/trac/changeset/33624

Log:
next one

Modified:
lyx-devel/trunk/src/support/Makefile.am

Modified: lyx-devel/trunk/src/support/Makefile.am
==
--- lyx-devel/trunk/src/support/Makefile.am Fri Mar  5 09:05:20 2010
(r33623)
+++ lyx-devel/trunk/src/support/Makefile.am Fri Mar  5 09:05:25 2010
(r33624)
@@ -89,6 +89,7 @@
SignalSlot.h \
SignalSlotPrivate.cpp \
SignalSlotPrivate.h \


We should also get rid of the 3 files above as they are not used in the 
code.



+   SystemcallPrivate.h \
textutils.h \
Translator.h \
Timeout.cpp \

RE: r33624 - lyx-devel/trunk/src/support

[Vincent van Ravesteijn - TNW]

Author: sanda
Date: Fri Mar  5 09:05:25 2010
New Revision: 33624
URL: http://www.lyx.org/trac/changeset/33624

Log:
next one



I really like those meaningful logs.

Vincent

c++/compiler question

[Edwin Leuven]

now when looping i write something like this:

row_type const nrows = row_info.size();
for (row_type r = 0; r  nrows; ++r) {

are compilers these days smart enough so that we can simply write:

for (row_type r = 0; r  row_info.size(); ++r) {

?

thanks, ed.

better maxima integration, devel.

[Janek Kozicki]

Hi,

I'm thinking about the possibility of using lyx as my frontend to
maxima. Texmacs doesn't suit me, because I used gvim+latex for years.

Since I used latex for long time it would be logical to start using
lyx in order to interact with maxima. I didn't ever use lyx before,
because gvim was good enough for me. But this time I need a maxima
interface with latex capabilities.

I see now, that such integration would require at least a running
maxima session in the background. 

I'm quite experienced with latex and C++.

I am not sure if I decide to go this path, I want to investigate and
judge the difficulty of writing patches that will scratch my itch.


I don't know what is the current state of lyx+maxima integration, and
I asked for ML archives in order to check this.

best regards
-- 
Janek Kozicki   http://janek.kozicki.pl/  |

Re: trunk crash (missing Addsec*)

[Jürgen Spitzmüller]

Guenter Milde wrote:
  Could you post this file?
 
 Yes.

Please send an attachment (not inline).

Jürgen

Re: Greek text mixed with English

[Jürgen Spitzmüller]

Guenter Milde wrote:
 However, Greek Unicode chars are missing in the output in the
 following example if:
 
 a) babel is included, or
 b) the \setmainfont line is commented
 
 \documentclass[greek]{article}
 \usepackage{fontspec}
 \setmainfont{Gentium}
 
 % \usepackage{babel}
 % \usepackage{polyglossia}
 
 \begin{document}
 
 Me mia mati'a...
 
 Με μια ματιά...
 
 \end{document}
 
 Babel selects a different font (the missing unicode support is a
 consequence of this font change). 

Please file reports for these. I don't think our XeTeX has been thouroughly 
tested yet. I have implemented it (due to user requests), but I do not use 
XeTeX myself at all.

 We must replace babel by polyglossia, as babel is not compatible with
 XeTeX. Selecting XeTeX as output machine is an explicite request for
 full, language-independent Unicode support.

Sure, polyglossia support must follow eventually. But this is more work than 
it seems. You have to dive into our language framework, which is all over the 
place. But of course, patches are welcome.

Jürgen

Re: Release process for LyX-2.0.0

[Jürgen Spitzmüller]

José Matos wrote:
 Hi all,
 after lots of thought and some private conversations with some
 developers (with former and present release managers) I have decided to
 step back from the release management of LyX 2.0.0.

Thanks for all your efforts! I certainly hope your timeframe for LyX will 
widen again soon.

And good luck, Pavel!

Jürgen

Re: r33615 - lyx-devel/trunk/src/insets

[Jürgen Spitzmüller]

uwestoehr wrote:
 Should also go to branch, Jürgen?

OK.

Jürgen

Re: Release process for LyX-2.0.0

[Edwin Leuven]

Jürgen Spitzmüller wrote:

José Matos wrote:

Hi all,
after lots of thought and some private conversations with some
developers (with former and present release managers) I have decided to
step back from the release management of LyX 2.0.0.


Thanks for all your efforts! I certainly hope your timeframe for LyX will 
widen again soon.


hear! hear!


And good luck, Pavel!


yes, we all look forward to flaming you ;-)

Re: c++/compiler question

[Abdelrazak Younes]

On 03/05/2010 11:56 AM, Edwin Leuven wrote:

now when looping i write something like this:

row_type const nrows = row_info.size();
for (row_type r = 0; r  nrows; ++r) {

are compilers these days smart enough so that we can simply write:

for (row_type r = 0; r  row_info.size(); ++r) {


I guess it depends of the constness of row_info...
Best is to not bet on the compiler smartness :-)

Abdel.

Re: c++/compiler question

[Edwin Leuven]

Abdelrazak Younes wrote:

On 03/05/2010 11:56 AM, Edwin Leuven wrote:

now when looping i write something like this:

row_type const nrows = row_info.size();
for (row_type r = 0; r  nrows; ++r) {

are compilers these days smart enough so that we can simply write:

for (row_type r = 0; r  row_info.size(); ++r) {


I guess it depends of the constness of row_info...


it's a non-const std::vector

what if i declared

row_type nrows() const {return row_info.size();}

and then do

for (row_type r = 0; r  nrows(); ++r)

?

Re: LyX ignorant of \listoffloats defined in document-class [Patch]

[rgheck]

On 03/04/2010 08:57 PM, Manoj Rajagopalan wrote:



On Thursday 04 March 2010 08:41:08 am rgheck wrote:
   

Or might it be better to have something
like this:
  ListCommandlistofvideos
in the float definition? Then you could also have:
  ListCommandlistoftables
and
  ListCommandlistoffigures
in the appropriate places, and skip these special checks altogether.

If that seems a good idea, I can create this command. Or, if you'd like
to learn a bit about layout stuff, you can do it. The place to look is
TextClass::readFloat(), and then an appropriate member would need to be
added to Floating.

One other thing: We need to check the other uses of builtin() to make
sure that the code can handle things other than table and figure. If
this routine expects only those two things, then maybe other routines
do, as well. There is such a check in
LaTeXFeatures::getFloatDefinitions(), for example, and I have no idea if
other builtins need similar treatment. Another place is in
InsetFloatList::xhtml(), which was based on the latex output. Whatever
we do for the latex, we can also do here, I suspect.

rh
 

I agree with you in that a new ListCommand (maybe  LaTeXListOfCommand?) is a
better idea - it is not necessary that documentclass creators adhere to this
ad-hoc nomenclature. For example, \listofpotatos could be \listofpotatoes
(notice the penultimate 'e'). Providing such a command will scale in future.
The LaTeX prefix in the optionname disambiguates the intent (command could
very well mean lyx command esp. since the value of this option won't have
a '\' prefix to indicates its latex-ness).

I can work on the patch - I am having fun learning lyx and the pointers you
have given will certainly help.

   
OK. Let me know if you have any questions. Note, by the way, that you'll 
also need (a) to increment the layout format in TextClass.cpp and (b) to 
do trivial work in layout2layout.py. If you look at r33467, you'll see 
what I mean.


FWIW, ListOfCommand or CommandForList is probably good enough. DocBook 
has its own way of handling these things, and the Command part 
disambiguates. Only LaTeX has commands.



About builtin() - the code and documentation must agree. The documentation
(UserGuide appendix on menu items) says built-in is something defined by
the document class but the code doesn't seem to honor this 100%. Since table
and figure are latex fundamentals, maybe it would make sense to
distinguish isLatexPrimitive() from builtin() ? latex-primitive =
built-in but not the other way.

   
My sense, from a brief look, is that the documentation is right and the 
code is wrong. What this really seems to indicate is whether we need to 
use the float package for this float. So it might make more sense to 
have a NeedsFloatPkg tag instead of the Builtin tag. It would 
default to false, so the default wouldn't change, and the only actual 
work would be in layout2layout.py. The rest would be replacing 
Floating::builtin() with Floating::needsFloatPkg().


Richard

Re: The emission of \maketitle

[rgheck]

On 03/05/2010 02:38 AM, Guenter Milde wrote:

On 2010-03-05, Manoj Rajagopalan wrote:
   

Hi lyx-devel,
 
   

What controls the emission of \maketitle when exporting to latex?
 

There is an intitle (or something like that) keyword for layout
styles. It is explained in the Customization guide.
(Or look at the implementation of the abstract style.)

   

And when LyX hits something that isn't intitle, then \maketitle goes.

rh

Re: better maxima integration, devel.

[Helge Hafting]

Janek Kozicki wrote:
[...]

I see now, that such integration would require at least a running
maxima session in the background. 


I'm quite experienced with latex and C++.

I am not sure if I decide to go this path, I want to investigate and
judge the difficulty of writing patches that will scratch my itch.


I don't know what is the current state of lyx+maxima integration, and
I asked for ML archives in order to check this.


Not sure what you want to do, but there is some LyX integration with 
maxima. You can write a formula in LyX, and then use this menu:

Edit-Math-Use Computer algebra system-Maxima

This will do transformations such as:
1+1+x+x  becomes 1+1+x+x=2x+2
Calculus:
\int x^2 dx becomes \int x^2=\frac{x^3}{3}
\int\int\frac{x}{y} turns into \frac{x^2 \log{y}}{2}

\frac{d}{dx}\frac{1+x}{1-x}
turns into
\frac{x+1}{\left(1-x\right)^{2}}+\frac{1}{1-x}

And so on. Apparently, there are many limitations though. Maxima can do
more, the communication between LyX and maxima is limited. You can't do 
matrix multiplication, for example.


Helge Hafting

Re: LyX 2 over Mac OS X Snow Leopard make error

[BH]

On Fri, Mar 5, 2010 at 12:02 AM, Yvon Thoraval yvon.thora...@gmail.com wrote:

 Yes -- that fixes it for me. (Assuming this is the right fix, can
 someone check it in?)


 Unfortunately no ;-)

You're not understanding. To check in the fix is to modify the
official source so that everyone can get the fix by using svn to
update the source code on local machines (by simply entering svn up
-- you don't have to check out the code from the beginning as you
did). So far no one has checked in the fix yet, so testing now won't
change anything for you.

You can either wait for the fix to be checked in, or you can manually
make the change Lase proposed earlier in this thread.

BH

Re: c++/compiler question

[rgheck]

On 03/05/2010 07:16 AM, Edwin Leuven wrote:

Abdelrazak Younes wrote:

On 03/05/2010 11:56 AM, Edwin Leuven wrote:

now when looping i write something like this:

row_type const nrows = row_info.size();
for (row_type r = 0; r  nrows; ++r) {

are compilers these days smart enough so that we can simply write:

for (row_type r = 0; r  row_info.size(); ++r) {


I guess it depends of the constness of row_info...


it's a non-const std::vector

what if i declared

row_type nrows() const {return row_info.size();}

and then do

for (row_type r = 0; r  nrows(); ++r)

?

I think gcc would give you a warning, to the effect of Qualifier on 
return value is ignored. This is because row_type is not of object type.


Moreover, you could perfectly well do:
for (row_type r = 0; r  nrows(); ++r)
row_info.clear();
if row_info is non-const. Then nrows() returns 0 on the second time 
through, and the loop terminates, as it should. This suggests a reason that

for (row_type r = 0; r  row_info.size(); ++r) {
might be a little safer than
row_type const nrows = row_info.size();
for (row_type r = 0; r  nrows; ++r) {
when row_info is non-const.

Richard

Re: better maxima integration, devel.

[rgheck]

On 03/05/2010 07:29 AM, Helge Hafting wrote:

Janek Kozicki wrote:
[...]

I see now, that such integration would require at least a running
maxima session in the background.
I'm quite experienced with latex and C++.

I am not sure if I decide to go this path, I want to investigate and
judge the difficulty of writing patches that will scratch my itch.


I don't know what is the current state of lyx+maxima integration, and
I asked for ML archives in order to check this.


Not sure what you want to do, but there is some LyX integration with 
maxima. You can write a formula in LyX, and then use this menu:

Edit-Math-Use Computer algebra system-Maxima

This will do transformations such as:
1+1+x+x  becomes 1+1+x+x=2x+2
Calculus:
\int x^2 dx becomes \int x^2=\frac{x^3}{3}
\int\int\frac{x}{y} turns into \frac{x^2 \log{y}}{2}

\frac{d}{dx}\frac{1+x}{1-x}
turns into
\frac{x+1}{\left(1-x\right)^{2}}+\frac{1}{1-x}

And so on. Apparently, there are many limitations though. Maxima can do
more, the communication between LyX and maxima is limited. You can't 
do matrix multiplication, for example.


All of this is correct, but the infrastructure for doing more is there. 
Look at src/mathed/MathExtern.cpp and the various maxima() methods.


We'd be very, very happy to have someone work on this.

rh

RE: LyX 2 over Mac OS X Snow Leopard make error

[Vincent van Ravesteijn - TNW]

 Yes -- that fixes it for me. (Assuming this is the right fix, can 
 someone check it in?)


 Unfortunately no ;-)

You're not understanding. To check in the fix is to modify the
official
source so that everyone can get the fix by using svn to update the
source
code on local machines (by simply entering svn up

I checked it in. 

Please try again.

Vincent

P.S. Please stop sending the messages twice to both lyx-users and
lyx-devel.

Re: better maxima integration, devel.

[Liviu Andronic]

On 3/5/10, Janek Kozicki janek_li...@wp.pl wrote:
  I don't know what is the current state of lyx+maxima integration, and
  I asked for ML archives in order to check this.

Some time ago there was a lengthy discussion about CAS support in LyX
[1] (including Maxima), which also contained some design ideas on
possible future development.

Regards
Liviu

[1] http://www.mail-archive.com/lyx-us...@lists.lyx.org/msg77889.html

LyX 2.0 release plan

[Pavel Sanda]

Hi LyXers,

lets start landing towards 2.0.

I respect Jose's choice so the upcoming version is fixed to 2.0 from now on.
Maybe you are not aware, but on autumn we celebrate 15 years of LyX (from the
first releases), so we can join releasing of 2.0 with some public advertisement
and looking back, what has happened during those years ... (if you are looking
for the reason for 2.0 ;)

To make things clear I would like to present plans for release stages
and some outline for dates.

As usual we go for alpha-beta-rc-2.0, with the following meaning of stages:

Alpha - kind of development snapshot. We only want to show new features and
possibly get some feedback and bug reports, we don't expect users 
to actually use it for serious work. From it follows that there are
no high quality demands or special policy to release alphas.

Beta - once we decide that all planned features are in and basically working
   we move to beta. From this point the main focus of developers should
   be cleaning the bugzilla from bugs with 2.0 target we get from users.
   So some small features can happen, but its stopper for any refactoring
   code with some instability period etc ;)
   Users are encouraged to report bugs back.

RC - all critical or very annoying bugs gone, we think its time to release,
 but for quality assurance few rc releases will be done.
 Bold users are encouraged to start using and report bugs back.

2.0 -  all promised beers from bugzilla have been delivered.


Preliminary dates for the stage beginning:
Alpha - next week if possible
Beta - end of May
RC - end of July 
2.0 - end of August

These are no deadlines, but rather live-lines which can change in both
directions ;) Their meaning is to give some course and synchronize us.
The current table can be always found at
http://wiki.lyx.org/Devel/ReleaseSchedule

Any comments/objections?


Alpha 1: I don't have any special requirement, from my POV the most serious
bug in OS X has been fixed by Abdel and I don't see any other showstopper.
Anybody want to have something before alpha in trunk?



Betas
I'll go through the enh bugs with 2.0 target and leave only those which are
really to be included. For this I need somebody create two new milestones in
trac for postponing - 2.1.0  2.0.1.

Secondly we need to collect all things which has been only partly finished
or are still in the pipe. Please take a coffee and help me to fill this
list and comment if possible. Cleaning up the list means we move to the beta
stage. The current version can be always reached at
http://wiki.lyx.org/Devel/LyX20Road
and I fill it once this thread is finished.


* Advanced Search - as far as I can see all wanted features finished, Tommaso?
  I expect lot of bug reports here though, we need to wait on users testing.

* Spellchecking - IIRC all features done or were there something more - I 
remember,
  some proposals like automatic switching off when xx% unrecognized etc.
  There are also already untouched bugs with spellcheck component. Abdel?

  For the packagers we need some summary what are the recommended dependencies.
  Haven't been closely following this stuff - could somebody write some summary
  of all those spellcheck (a/i/hun/spell) and thesaurus deps into RELEASE-NOTES?
  Juergen, Abdel?

* Comparison - IIRC Vincent considered some more work which would use
  words instead of characters to boost up the process. Currently the
  documents which are far from each other will never finish in a reasonable 
time.
  Vincent what are your plans? Also NewInLyx2.0 entry is missing or we wait for
  the finishing?

* HTML export. I remember Richard asked for help with images. Anybody around?
  Some plans to add instant preview snapshots for equations, or external insets
  using preview? Some other plans Richard? NewInLyx2.0 entry is missing.

* Multiple viewers/converters. Juergen asked for some help; how this evolved,
  what is to be done in this area? Juergen, Richard? 

* rc2rc conversion scripts for converting older preferences into new ones.
  Jose promised to come with something. I have worried what happen with users
  which run lyx beta to test and get prefs overwritten for their stable 1.6.x?

* Instant preview. What is the status/plan with the patch. IIRC Vincent was
  unsatisfied with the state of art without being specific.

* Tabular stuff. Edwin, Uwe and Abdel seem to work on it right now.

* There has been some work on dispatch results, but I have no idea whats the
  current status. JMarc? There are already filled bugs around dispatch.

* Connection between VCS and comparison feature. I have idea what to do but
  others weren't happy about the approach, so more discussion is needed.

* Layout groups are hopeless? Richard? Anybody? 
  http://wiki.lyx.org/Devel/LayoutGroup


Other entries?

Pavel

Re: c++/compiler question

[Manoj Rajagopalan]

On Friday 05 March 2010 07:44:22 am rgheck wrote:
 On 03/05/2010 07:16 AM, Edwin Leuven wrote:
  Abdelrazak Younes wrote:
  On 03/05/2010 11:56 AM, Edwin Leuven wrote:
  now when looping i write something like this:
 
  row_type const nrows = row_info.size();
  for (row_type r = 0; r  nrows; ++r) {
 
  are compilers these days smart enough so that we can simply write:
 
  for (row_type r = 0; r  row_info.size(); ++r) {
 
  I guess it depends of the constness of row_info...
 
  it's a non-const std::vector
 
  what if i declared
 
  row_type nrows() const {return row_info.size();}
 
  and then do
 
  for (row_type r = 0; r  nrows(); ++r)
 
  ?

 I think gcc would give you a warning, to the effect of Qualifier on
 return value is ignored. This is because row_type is not of object type.

 Moreover, you could perfectly well do:
  for (row_type r = 0; r  nrows(); ++r)
  row_info.clear();
 if row_info is non-const. Then nrows() returns 0 on the second time
 through, and the loop terminates, as it should. This suggests a reason that
  for (row_type r = 0; r  row_info.size(); ++r) {
 might be a little safer than
  row_type const nrows = row_info.size();
  for (row_type r = 0; r  nrows; ++r) {
 when row_info is non-const.

 Richard

Actually, if row_info is going to change within the loop then r  
row_info.size() is the only correct thing to do. With this we are telling the 
compiler to repeatedly evaluate row_info.size() before make the looping 
decision.

A compiler that caches the value of row_info.size() during its first 
evaluation is buggy. Of course, if this code is part of a const method of the 
same class as row_info then an optimization would be to cache the value on 
first evaluation.

Even if you declare nrows() to be a const method, it can be used within a 
non-const method in the same class without errors or warnings. The const-ness 
of nrows() method only means that at the time it is called, it does nothing 
to change the associated class during the lifetime of its execution during 
that call.

I think your question is about the optimization - does the compiler cache the 
row_info.size() value? Compiler optimizations have come a long way and this 
should happen in commercial compilers even if GCC doesn't recognize the 
optimization opportunity. If you are not sure, then it is best to play it 
safe and introduce a new const variable that you code to cache the container 
size. This also helps with debugging. Most compilers are smart enough to 
optimize out const variables - it is one of the simpler things to achieve. 
GCC does propagate constants.

-- Manoj

Re: better maxima integration, devel.

[Janek Kozicki]

rgheck said: (by the date of Fri, 05 Mar 2010 07:46:39 -0500)

 On 03/05/2010 07:29 AM, Helge Hafting wrote:
  And so on. Apparently, there are many limitations though. Maxima can do
  more, the communication between LyX and maxima is limited. You can't 
  do matrix multiplication, for example.
 
 All of this is correct, but the infrastructure for doing more is there. 
 Look at src/mathed/MathExtern.cpp and the various maxima() methods.
 
 We'd be very, very happy to have someone work on this.

A warm welcome is very encouraging. I'll check that file.

I know nothing about how it is done, yet, but still I have some
simple vision, correct me when I'm wrong:

- to have a working connection with background maxima, we need a
  maxima buffer. This buffer (a list of %inputs) is not a part of
  latex/LyX document, so it should be stored somewhere. I was
  thinking about putting it into .tex (.lyx) file as a comment, with
  some magic keyword, like following:

% LYX+MAXIMA buffer, do not edit by hand, START
%
% * [wxMaxima: input   start ] */
% e1:ellipse : x^2/a^2+y^2/b^2=1;
% e2:line: A*(x-x0)+B*(y-y0)=0;
% /* [wxMaxima: input   end   ] */
%
% LYX+MAXIMA buffer, do not edit by hand, END

the first two characters (the % ) are always stripped, the rest is
treated as-is: the maxima input file format.

- there could be a split-window with just the maxima input buffer.

- interesting parts from the maxima buffer would be copied into
  latex/lyx document, by using some sort of referencing.

- plot2d/3d would generate .ps files, provided correct gnuplot
  parameters to generate .ps files (which I happen to know).
  Pictures generated in this way would be entered into document
  structure in the same manner as the equations.

- compiling lyx+maxima document, would mean to do some preprocessing:
+ first execute the maxima buffer in fresh maxima session. This
  would calculate stuff, and generate .ps files.
+ enter the referenced equations in their latest form (freshly
  calculated) into their proper places in the latex document
+ then continue the normal compilation, like invoking pdflatex
  or others.

my head is bulging with ideas, but the time is really short.
I'll check what you've told me, tell me more. Do not expect me to be fast.

-- 
Janek Kozicki   http://janek.kozicki.pl/  |

Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Pavel Sanda wrote:
 Any comments/objections?

Looks reasonable, AFAICT.

 * Multiple viewers/converters. Juergen asked for some help; how this
 evolved, what is to be done in this area? Juergen, Richard?

I still did not yet find the time to re-address this. I need to clean up the 
tree with my changes (it doesn't compile anymore) and re-ponder the thing. I 
hope I can do this eventually. If not, LyX 2.0 should be released without this 
feature.

Jürgen

Re: Release process for LyX-2.0.0

[Pavel Sanda]

Edwin Leuven wrote:
 And good luck, Pavel!

 yes, we all look forward to flaming you ;-)

my pleasure :D
pavel

RE: LyX 2.0 release plan

[Vincent van Ravesteijn - TNW]

lets start landing towards 2.0.

That's what we call a flying start...

Preliminary dates for the stage beginning:
Alpha - next week if possible

Did we leave the instability period that was expected due to:
- threaded export,
- movements of code in the dispatch machinery,
- insetdialog changes,
- insetTabular changes. 

These were quite intrusive changes not that long ago. I understand the
alpha release doesn't have to be perfect, but there are now a lot of
crashes introduced in recent work, so I don't think it's the time to
'release' anything. There are now a number of very very embarassing bugs
that I don't want to see in the alpha release: 
* 6578, 6564, 6522 ...


Alpha 1: I don't have any special requirement, from my POV the most
serious
bug in OS X has been fixed by Abdel and I don't see any other
showstopper.

I do. As said above.

Anybody want to have something before alpha in trunk?

I've one worthy unfinished feature left. Export to dir/zip including all
dependent files. Don't know what the advantage of being in alpha release
would be.

* Comparison - IIRC Vincent considered some more work which would use
  words instead of characters to boost up the process. Currently the
  documents which are far from each other will never finish in a
reasonable time.
  Vincent what are your plans? Also NewInLyx2.0 entry is missing or we
wait for
  the finishing?

There is an academic question how to limit the time of the algorithm.
There is no such thing as 'the solution', because the real solution is
not the one most useful for the user (and takes quite some time).

I need to do some more work when I have time.

* Instant preview. What is the status/plan with the patch. IIRC Vincent
was
  unsatisfied with the state of art without being specific.

There weren't any enthusiastic responses from other developers than you.
The reason why I made it was that I wanted to be able to use psfrag, but
it appeared that was not supported by dvi2ps. This also holds for tikz I
believe. So, this removed the need for introducing yet another inset.
Moreover, I couldn't think of a way to integrate the existing preview
machinery into the new stuff.

* Layout groups are hopeless? Richard? Anybody? 
  http://wiki.lyx.org/Devel/LayoutGroup

I guess, I launched this site, but I didn't have time to do it as I've
been fixing bugs, bugs, and bugs.

Other entries?

The Export as ZIP feature. I'll try to come up with a prototype asap.

Vincent

Re: LyX 2.0 release plan

[BH]

On Fri, Mar 5, 2010 at 9:10 AM, Pavel Sanda sa...@lyx.org wrote:
 Alpha 1: I don't have any special requirement, from my POV the most serious
 bug in OS X has been fixed by Abdel and I don't see any other showstopper.
 Anybody want to have something before alpha in trunk?

Things are looking reasonably good on Mac. It needs some polish, and I
think we need to make a decision about whether various widgets
(outline, spellchecker, source view, messages) should be docked,
floating, or drawers on Mac. But that, of course, is not needed before
the alpha.

BH

RE: LyX 2.0 release plan

[Vincent van Ravesteijn - TNW]

 
 Alpha 1: I don't have any special requirement, from my POV the most 
 serious bug in OS X has been fixed by Abdel and I don't see any
other showstopper.
 Anybody want to have something before alpha in trunk?

Things are looking reasonably good on Mac. It needs some polish, and I
think we
need to make a decision about whether various widgets (outline,
spellchecker,
source view, messages) should be docked, floating, or drawers on Mac.
But that,
of course, is not needed before the alpha.


As I said before, there are now exceptions made for MacOSX that do
precisely that what you don't want to see. So, we can experiment
somewhat if you tell us how the average mac user likes to see it.

Vincent

Re: better maxima integration, devel.

[rgheck]

On 03/05/2010 09:20 AM, Janek Kozicki wrote:

rgheck said: (by the date of Fri, 05 Mar 2010 07:46:39 -0500)

   

On 03/05/2010 07:29 AM, Helge Hafting wrote:
 

And so on. Apparently, there are many limitations though. Maxima can do
more, the communication between LyX and maxima is limited. You can't
do matrix multiplication, for example.

   

All of this is correct, but the infrastructure for doing more is there.
Look at src/mathed/MathExtern.cpp and the various maxima() methods.

We'd be very, very happy to have someone work on this.
 

A warm welcome is very encouraging. I'll check that file.

I know nothing about how it is done, yet, but still I have some
simple vision, correct me when I'm wrong:

   
Since I don't use maxima etc myself, I don't have a lot of thoughts 
about this. What happens at present is that LaTeX that is entered into a 
math inset gets translated into maxima's input format; LyX calls maxima 
to do the calculation; retrieves the result, which is presumably in 
maxima's output format; and then translates that back into LaTeX, for 
inclusion in the document. Improving this means improving the 
translation mechanisms, mostly, so that LyX is able to formulate more 
complex queries and understand more complex answers.


What you are proposing, I think, is somewhat different and looks almost 
like one of LyX's external insets. Indeed, something very like it 
could surely be implemented using external templates, which define a way 
that LyX can interact with external programs. These insets are inserted 
using InsertFileExternal Material, and we have support for several 
external programs now. The difference from what you are proposing is 
that the information would not be stored in LyX but rather in external 
text files referenced from within the LyX document. These would also be 
edited in an external text editor, but this can be called from within 
LyX, from the context menu. Have a look at lib/external_templates, which 
defines several of these things, and at chapter 6 of the Customization 
manual.


My sense is that, for full maxima integration, this is definitely the 
easiest way to go. The disadvantage, compared to the current system, is 
that there's no integration with the math insets.


rh

Re: better maxima integration, devel.

[Janek Kozicki]

Liviu Andronic said: (by the date of Fri, 5 Mar 2010 14:09:40 +)


 [1] http://www.mail-archive.com/lyx-us...@lists.lyx.org/msg77889.html

thanks, by reading this I see that the maxima buffer must be
seamlessly integrated with document, in order to not confuse people.

But, OTOH, to use any algebra system in efficient way, the user has to
know which one he is using. I am not going to write an interface that
translates every kind of math+lyx input into every kind of
octave/maxima/maple/mathematica input. There's too many different
specific things, and I never used maple/octave/mathematica, I don't
know their formatting.

The simplest way for me is to allow a maxima session in lyx, and add
communication between both. Copying/using/referencing equations in both
directions between maxima buffer - document. Entering equations in
document and pasting them to maxima buffer (for later, more complex
use) for people familiar with entering equation using lyx/latex
commands and the opposite for people who wish to enter them using
maxima input format.
-- 
Janek Kozicki   http://janek.kozicki.pl/  |

Re: better maxima integration, devel.

[Janek Kozicki]

Liviu Andronic said: (by the date of Fri, 5 Mar 2010 14:09:40 +)


 [1] http://www.mail-archive.com/lyx-us...@lists.lyx.org/msg77889.html

thanks, by reading this I see that the maxima buffer must be
seamlessly integrated with document, in order to not confuse people.

But, OTOH, to use any algebra system in efficient way, the user has to
know which one he is using. I am not going to write an interface that
translates every kind of math+lyx input into every kind of
octave/maxima/maple/mathematica input. There's too many different
specific things, and I never used maple/octave/mathematica, I don't
know their formatting.

The simplest way for me is to allow a maxima session in lyx, and add
communication between both. Copying/using/referencing equations in both
directions between maxima buffer - document. Entering equations in
document and pasting them to maxima buffer (for later, more complex
use) for people familiar with entering equation using lyx/latex
commands and the opposite for people who wish to enter them using
maxima input format.
-- 
Janek Kozicki   http://janek.kozicki.pl/  |

Re: better maxima integration, devel.

[Janek Kozicki]

rgheck said: (by the date of Fri, 05 Mar 2010 10:18:35 -0500)

 Since I don't use maxima etc myself, I don't have a lot of thoughts 
 about this. What happens at present is that LaTeX that is entered into a 
 math inset gets translated into maxima's input format; LyX calls maxima 
 to do the calculation; retrieves the result, which is presumably in 
 maxima's output format; and then translates that back into LaTeX, for 
 inclusion in the document. Improving this means improving the 
 translation mechanisms, mostly, so that LyX is able to formulate more 
 complex queries and understand more complex answers.

besides improving that communication, the only missing thing is to
be able to declare variables within maxima, and operate on them
later. It means a running maxima session, instead of
standalone/separate calls for each thing. Those separate calls mean
that everything is forgot after the call to maxima is done.

Ideally I would want to derive calculations within lyx, while
writing comments about it. All with the beauty of latex.

Perhaps I'll start with this communication formatting thing that you
explained, it should be an easy start to get feel of the workings.

 What you are proposing, I think, is somewhat different and looks almost 
 like one of LyX's external insets. Indeed, something very like it 
 could surely be implemented using external templates, which define a way 
 that LyX can interact with external programs. These insets are inserted 
 using InsertFileExternal Material, and we have support for several 
 external programs now. The difference from what you are proposing is 
 that the information would not be stored in LyX but rather in external 
 text files referenced from within the LyX document. These would also be 
 edited in an external text editor, but this can be called from within 
 LyX, from the context menu. Have a look at lib/external_templates, which 
 defines several of these things, and at chapter 6 of the Customization 
 manual.
 
 My sense is that, for full maxima integration, this is definitely the 
 easiest way to go. The disadvantage, compared to the current system, is 
 that there's no integration with the math insets.

I see. I would prefer to stay within lyx boundaries. A split window,
with the maxima buffer or such. I don't know yet. Storing input in
external file is better than putting it into .lyx as comments,
I didn't know this is possible. maxima runs well even in a text
terminal, it should be possible to pipe this somehow.

I should look in the code now, or else it becomes just babbling. The
time limitation allows me to do it only on fridays, only an hour or
two per week, so I hopefully will come with more interesting
questions next week.

-- 
Janek Kozicki   http://janek.kozicki.pl/  |

Re: LyX 2.0 release plan

[rgheck]

On 03/05/2010 09:10 AM, Pavel Sanda wrote:

* HTML export. I remember Richard asked for help with images. Anybody around?
   Some plans to add instant preview snapshots for equations, or external insets
   using preview? Some other plans Richard? NewInLyx2.0 entry is missing.

   
I do need help here.Quite simply, what I need is to be able to have 
access to the preview image from within the xhtml output routine. This 
would let us do image rotation, scaling, cropping, etc, of images; do 
something with external insets, which are at present ignored; and even 
allow the use of little pictures for math when necessary. From what I 
can tell, though, the preview images right now are buried somewhere deep 
within the GUI and so aren't accessible from the output routines. So 
that's it.


The other thing I have left to do is finish the MathML stuff. Most of 
that works, but not all.



* Multiple viewers/converters. Juergen asked for some help; how this evolved,
   what is to be done in this area? Juergen, Richard?

   
I can do the graph work, if I know precisely what needs doing. We had 
some discussions, but then they kind of died, as we both got busy. So 
I'm not quite sure where we stand.



* Layout groups are hopeless? Richard? Anybody?
   http://wiki.lyx.org/Devel/LayoutGroup

   
IIRC, Vincent was thinking about this, but I'm not sure if he got 
anywhere. It's probably too late to make this work for 2.0, which means 
postponing to 2.1, since it's definitely a format change.


rh

Re: LyX ignorant of \listoflt;floatgt;s defined in document-class [Patch]

[Julien Rioux]

rgheck rgh...@... writes:
 My sense, from a brief look, is that the documentation is right and the 
 code is wrong. What this really seems to indicate is whether we need to 
 use the float package for this float. So it might make more sense to 
 have a NeedsFloatPkg tag instead of the Builtin tag. It would 
 default to false, so the default wouldn't change, and the only actual 
 work would be in layout2layout.py. The rest would be replacing 
 Floating::builtin() with Floating::needsFloatPkg().
 

+1 for this

I found builtin confusing when writing custom layouts.  The question is not
really whether it is builtin or not, but whether you want LyX to define the
float for you using the float package.

--
Julien

Re: LyX 2.0 release plan

[rgheck]

On 03/05/2010 09:48 AM, Vincent van Ravesteijn - TNW wrote:



Anybody want to have something before alpha in trunk?
 

I've one worthy unfinished feature left. Export to dir/zip including all
dependent files. Don't know what the advantage of being in alpha release
would be.

   

Excellent.

rh

Mac widgets

[BH]

Moving this to a separate thread

Things are looking reasonably good on Mac. It needs some polish, and I
 think we
need to make a decision about whether various widgets (outline,
 spellchecker,
source view, messages) should be docked, floating, or drawers on Mac.
 But that,
of course, is not needed before the alpha.


 As I said before, there are now exceptions made for MacOSX that do
 precisely that what you don't want to see. So, we can experiment
 somewhat if you tell us how the average mac user likes to see it.

Yes, and I appreciate your offer of help. But how the average mac
user likes it is partly the question. I can say how I'd like to see
it, a view that's largely informed by looking at Apple's applications
(as models for the average mac user?); perhaps others will disagree.

Here's my view:

Drawers are no longer much used, partly because (I think) it's not
possible to have multiple drawers showing up simultaneously on the
same side of the window, which significantly reduces their
flexibility. But on Mac docked widgets are not generally used. So I'd
suggest that most widgets -- outline, spellchecker, advanced find --
be floating windows by default (though I'd like to see them be
dockable). The one (or two) exception(s) here is source view (and
possibly messages), for which a good case can be made for a
bottom-docked widget given their design.

Perhaps the best course of action is to adopt this proposal and see
whether we get any complaints during the pre-release process.

BH

Re: better maxima integration, devel.

[rgheck]

On 03/05/2010 10:23 AM, Janek Kozicki wrote:

Liviu Andronic said: (by the date of Fri, 5 Mar 2010 14:09:40 +)


   

[1] http://www.mail-archive.com/lyx-us...@lists.lyx.org/msg77889.html
 

thanks, by reading this I see that the maxima buffer must be
seamlessly integrated with document, in order to not confuse people.

But, OTOH, to use any algebra system in efficient way, the user has to
know which one he is using. I am not going to write an interface that
translates every kind of math+lyx input into every kind of
octave/maxima/maple/mathematica input. There's too many different
specific things, and I never used maple/octave/mathematica, I don't
know their formatting.

   
These all have their own separate routines, at present. It's all very 
modular. You could improve the maxima interface without touching the 
other stuff.


rh

RE: Mac widgets

[Vincent van Ravesteijn - TNW]

Yes, and I appreciate your offer of help. But how the average mac user
likes it
is partly the question. I can say how I'd like to see it, a view that's
largely informed
by looking at Apple's applications (as models for the average mac
user?);
perhaps others will disagree.

Here's my view:


At least, your view will be much closer to the average mac user than
mine probably.

Drawers are no longer much used, partly because (I think) it's not
possible to
have multiple drawers showing up simultaneously on the same side of the
window, which significantly reduces their flexibility. 

Drawers are gone.

 But on Mac docked widgets are not generally used. So I'd suggest that
 most widgets -- outline, spellchecker, advanced find --
 be floating windows by default (though I'd like to see them be
dockable).

Ok, they are dockable by default. So only the default docked/floating
setting is different.

The one (or two) exception(s) here is source view (and possibly
messages),
for which a good case can be made for a bottom-docked widget given
their design.

This is the same as on the other platforms.

What about Full-screen mode ? There is now an exception that for mac the
outline is docked in full-screen mode, while it is a drawer otherwise.
Do you prefer a docked or floating outline in full-screen mode ?

Perhaps the best course of action is to adopt this proposal and see
whether we
get any complaints during the pre-release process.

I agree.

Vincent

Re: Mac widgets

[BH]

On Fri, Mar 5, 2010 at 11:12 AM, Vincent van Ravesteijn - TNW
v.f.vanraveste...@tudelft.nl wrote:
Yes, and I appreciate your offer of help. But how the average mac user
 likes it
is partly the question. I can say how I'd like to see it, a view that's
 largely informed
by looking at Apple's applications (as models for the average mac
 user?);
perhaps others will disagree.

Here's my view:


 At least, your view will be much closer to the average mac user than
 mine probably.

Drawers are no longer much used, partly because (I think) it's not
 possible to
have multiple drawers showing up simultaneously on the same side of the
window, which significantly reduces their flexibility.

 Drawers are gone.

Good -- thanks.

 But on Mac docked widgets are not generally used. So I'd suggest that
 most widgets -- outline, spellchecker, advanced find --
 be floating windows by default (though I'd like to see them be
 dockable).

 Ok, they are dockable by default. So only the default docked/floating
 setting is different.

Yes.

The one (or two) exception(s) here is source view (and possibly
 messages),
for which a good case can be made for a bottom-docked widget given
 their design.

 This is the same as on the other platforms.

Yes.

 What about Full-screen mode ? There is now an exception that for mac the
 outline is docked in full-screen mode, while it is a drawer otherwise.
 Do you prefer a docked or floating outline in full-screen mode ?

Here I think I'd prefer docked. (Currently, adv. find is floating, and
it seems to work better when I dock it in full-screen mode. When both
outline and adv. find are docked on the same side, there's a tab that
allows switching between them.)

Thanks again!

BH

Perhaps the best course of action is to adopt this proposal and see
 whether we
get any complaints during the pre-release process.

 I agree.

 Vincent

meaningless error message for missing document packages

[Julien Rioux]

Hi list,

This is this bug: http://www.lyx.org/trac/ticket/3686

It has been around for a while, and continuously postponed. I would have 
a hack at this. Here is how I think it can be solved:


- configure.py and chkconfig.ltx are altered so that
  textclass.lst retains the missing package information.
- LayoutFile.cpp reads this information in.
- When a unavailable layout is used, BufferParams.cpp can now
  inform the user of the layout's requirements.

If this is the way to go, this involves a format change for the 
textclass.lst file. Either:


1. An extra field is added to textclass.lst which list:
   a. the requirements, or maybe
   b. only the missing requirements.

2. The true/false field is replaced by an empty/missing field. When 
empty, the class is available, otherwise this field lists the missing 
requirements.


For example, a line in textclass.lst such as

jgrga aguplus article (AGU++ JGR) false

becomes one of:

1a. jgrga aguplus article (AGU++ JGR) false aguplus,jgrga.sty
1b. jgrga aguplus article (AGU++ JGR) false jgrga.sty
2.  jgrga aguplus article (AGU++ JGR) jgrga.sty

Please share your thoughts! Maybe the textclass.lst file format change 
can be avoided altogether?


Julien

Re: Release process for LyX-2.0.0

[José Matos]

On Friday 05 March 2010 11:51:47 Jürgen Spitzmüller wrote:
 Thanks for all your efforts! I certainly hope your timeframe for LyX will 
 widen again soon.

Thank you. :-)

 And good luck, Pavel!

You will need it (FWIW I need it too). ;-)

 Jürgen

-- 
José Abílio

Re: LyX 2.0 release plan

[José Matos]

On Friday 05 March 2010 14:10:47 Pavel Sanda wrote:
 * rc2rc conversion scripts for converting older preferences into new ones.
   Jose promised to come with something. I have worried what happen with
 users which run lyx beta to test and get prefs overwritten for their
 stable 1.6.x?

I propose to copy the old file to a renamed file with the .lyxrc16 suffix.
That way the old configuration file will still be there.

Sure if you go back you will need to rename the files manually but then no 
data is lost.

Actually I propose to do this for all the configuration files. Since all the 
configuration files are small this should mean a small increase in disc space.
-- 
José Abílio

Re: LyX 2.0 release plan

[Bo Peng]

Other entries?

 The Export as ZIP feature. I'll try to come up with a prototype asap.

 Vincent

Is this the final consensus of the embedding/zip/folder/whatever
feature of lyx? I have been forced to use MS Word more and more
because of increased collaboration activities. It becomes clear to me
that lyx/latex is still too complex for most people and is not
suitable for collaboration. For example,

1. Figures are not part of a document which makes a lyx document
difficult to 'maintain'. This means extra work to keep track of
external files (cannot compile if a file is missing), difficulty in
sharing with others (zip to email?). This also means that you can not
safely view/edit/compile/save a lyx file from an email attachment
which we do everyday to any other documents. Of course, if you have a
zip file, one has to save, unzip and open, not mentioning that some
mail clients (such as gmail) does not allow send/receive zip files for
security reasons.

2. There is no guarantee that a lyx file can compile on another
machine. I can immediately think of reasons such as missing external
file, incomplete local latex installation (missing a style file), and
use of absolute path in file inclusion. This is less important because
my collaborators do not have to compile the document.

Being away from the lyx community for quite some time, I am not sure
if any of these problems is being addressed, but an 'export as zip'
feature is certainly not enough. If I am going to re-design an
embedding feature now (very unlikely :-), I would make
self-contentment and portability the top priorities and I hope that
any new lyx format would try to accommodate these.

Cheers,
Bo

Re: LyX 2.0 release plan

[Pavel Sanda]

Vincent van Ravesteijn - TNW wrote:
 lets start landing towards 2.0.
 
 That's what we call a flying start...

i'm not sure who is this we; from the last discussions about release
plans it looked like that more devs thought we are already late and
particularly can't remember anybody claiming we should wait little bit
longer. if its not the case then sorry and lets discuss the stages
a little bit more.

 Preliminary dates for the stage beginning:
 Alpha - next week if possible
 
 Did we leave the instability period that was expected due to:
 - threaded export,
 - movements of code in the dispatch machinery,
 - insetdialog changes,
 - insetTabular changes. 
 
 These were quite intrusive changes not that long ago. I understand the
 alpha release doesn't have to be perfect, but there are now a lot of
 crashes introduced in recent work, so I don't think it's the time to
 'release' anything. There are now a number of very very embarassing bugs
 that I don't want to see in the alpha release: 
 * 6578, 6564, 6522 ...

is it that you are against anything to be released out or that
you are uncomfortable with 'alpha' naming? the problems listed
do not look like showstoppers to me.
alpha usually means exposition to close testing community around,
ie neither to developers themselves nor to normal users.

concerning the fact that the 1.6 criterion for beta-rc 
transit was no dataloss bug, than the crashes above being
stopper for entering alpha state looks way too strict.

anyway would you accept if we call it pre-alpha or only
development snapshot instead?

pavel

Re: meaningless error message for missing document packages

[rgheck]

On 03/05/2010 11:43 AM, Julien Rioux wrote:

Hi list,

This is this bug: http://www.lyx.org/trac/ticket/3686

It has been around for a while, and continuously postponed. I would 
have a hack at this. Here is how I think it can be solved:


- configure.py and chkconfig.ltx are altered so that
  textclass.lst retains the missing package information.
- LayoutFile.cpp reads this information in.
- When a unavailable layout is used, BufferParams.cpp can now
  inform the user of the layout's requirements.

If this is the way to go, this involves a format change for the 
textclass.lst file.


Either:

1. An extra field is added to textclass.lst which list:
   a. the requirements, or maybe
   b. only the missing requirements.

Missing requirements would obviously be better, since then the user 
knows what to do.


2. The true/false field is replaced by an empty/missing field. When 
empty, the class is available, otherwise this field lists the missing 
requirements.



The empty/missing version is probably sufficient.

Please share your thoughts! Maybe the textclass.lst file format change 
can be avoided altogether?


I don't see a sensible way to avoid that. The info we want is originally 
in the layout files, and I don't think we want to get the info from there.


Richard

Re: LyX 2.0 release plan

[Pavel Sanda]

Vincent van Ravesteijn - TNW wrote:
 Anybody want to have something before alpha in trunk?
 
 I've one worthy unfinished feature left. Export to dir/zip including all
 dependent files. Don't know what the advantage of being in alpha release
 would be.

i have feeling that we do not understand the alpha state in the same
way. to me alpha means we are still feature open, just that we start think
about finishing the work. that means list everything we would like to
finish and its doable in reasonable time, e.g. zip export, dispatch
refactoring etc.

so the advantage is that we make devs:
* focused more on bugfixing then refactoring or features inveting
* focused on finishing things left
and
* get some feedback from interested testers while still being able
  to do more drastic changes if some flaw is revealed.

 * Instant preview. What is the status/plan with the patch. IIRC Vincent
 was
   unsatisfied with the state of art without being specific.
 
 There weren't any enthusiastic responses from other developers than you.
 The reason why I made it was that I wanted to be able to use psfrag, but
 it appeared that was not supported by dvi2ps. This also holds for tikz I
 believe. So, this removed the need for introducing yet another inset.
 Moreover,

well, the original bug and regularly reappearing request on list
was to have ert+instant preview. it evolved into new general inset
which is far more then requested.

I couldn't think of a way to integrate the existing preview
 machinery into the new stuff.

but we already have working patch for the original problem, no?
there was missing lyx2lyx part, but i'm willing to finish it if
the general aproach is problematic.

 * Layout groups are hopeless? Richard? Anybody? 
   http://wiki.lyx.org/Devel/LayoutGroup
 
 I guess, I launched this site, but I didn't have time to do it as I've
 been fixing bugs, bugs, and bugs.

ok, not for 2.0 i'll retarget it.

 Other entries?
 
 The Export as ZIP feature. I'll try to come up with a prototype asap.

ok. take your time, if we know this is planned,
we can postopone betas, no problem.

pavel

Re: LyX 2.0 release plan

[rgheck]

On 03/05/2010 01:58 PM, Pavel Sanda wrote:

Vincent van Ravesteijn - TNW wrote:
   

lets start landing towards 2.0.
   

That's what we call a flying start...
 

i'm not sure who is this we; from the last discussions about release
plans it looked like that more devs thought we are already late and
particularly can't remember anybody claiming we should wait little bit
longer. if its not the case then sorry and lets discuss the stages
a little bit more.

   

Preliminary dates for the stage beginning:
Alpha - next week if possible
   

Did we leave the instability period that was expected due to:
- threaded export,
- movements of code in the dispatch machinery,
- insetdialog changes,
- insetTabular changes.

These were quite intrusive changes not that long ago. I understand the
alpha release doesn't have to be perfect, but there are now a lot of
crashes introduced in recent work, so I don't think it's the time to
'release' anything. There are now a number of very very embarassing bugs
that I don't want to see in the alpha release:
* 6578, 6564, 6522 ...
 

is it that you are against anything to be released out or that
you are uncomfortable with 'alpha' naming? the problems listed
do not look like showstoppers to me.

   
I'd like to see 6522 fixed before alpha, but only because it will catch 
a lot of people.


FYI, I see it with Qt 4.6.2, as well, so it's something about the switch 
to 4.6.x.


Richard

Re: #6574: ChkTeX selects entire paragraph, rather than just line where error occurs.

[Tommaso Cucinotta]

John McCabe-Dansted wrote:

I was wondering that too.
I just tried (linelen = 1), and it works pretty well, i.e., it focuses 
on the single issue rather than the entire line :-) but my experience 
with the tool is so poor.

Ideally this would not uncover any bugs as LyX-GC has to deal with
linebreaks. I will try setting the ChkTeX linelen to 1 and seeing what
breaks. This might uncover some bugs in LyX-GC where errors get missed
if they are split onto multiple lines.
  

As of now, I get a stupid

===
Warning 36 in /tmp/lyx_tmpdir.TJ8403/lyx_tmpbuf0/good-bad-ugly.tex line 
102: You should put a space in front of parenthesis.
(see 
^

===

but actually my text reads as writing letters (see section~1). Of 
course, in the temporary export, I have:


===
writing
letters
(see
section~1).
===

So, that's why chktex is complaining about the missing space -- this is 
to be considered as a chktex bug (IMHO) -- however, in the 
View-SourceCode, I just see


those for writing letters (see section~1). This may be misleading for 
people accustomed to applying chktex to latex sources.



===

those for writing letters (see section~1).
===

Probably you have more experience than me in using chktex, so, please, 
comment on this. In the meantime, I'm leaving just the standard linelen 
from the RC file also for chktex.


   T.

Re: Greek text mixed with English

[Guenter Milde]

On 2010-03-05, Jürgen Spitzmüller wrote:
 Guenter Milde wrote:
 However, Greek Unicode chars are missing in the output in the
 following example if:

 a) babel is included, or
 b) the \setmainfont line is commented
...

 Please file reports for these. 

Done. http://www.lyx.org/trac/ticket/6576

 I don't think our XeTeX has been thouroughly 
 tested yet. I have implemented it (due to user requests), but I do not use 
 XeTeX myself at all.

Thanks for the implementation. Hopefully the upcoming alpha release
will get someone with XeTeX experience interested in testing/reporting.

 We must replace babel by polyglossia, as babel is not compatible with
 XeTeX. Selecting XeTeX as output machine is an explicite request for
 full, language-independent Unicode support.

 Sure, polyglossia support must follow eventually. But this is more work
 than it seems. You have to dive into our language framework, which is
 all over the place. But of course, patches are welcome.

I am aware of possible problems. Maybe its time I read the XeTeX docs.
(I hoped LyX would save me this trouble ;-)

Günter

Re: trunk crash (missing Addsec*)

[Guenter Milde]

On 2010-03-05, Jürgen Spitzmüller wrote:
 Guenter Milde wrote:
  Could you post this file?

 Yes.

 Please send an attachment (not inline).

Unfortunately, I can't, as I follow the list via Gmane and my
slrn newsreader does not support attachments (or I did not find the
way how to get this working).

Günter

Re: better maxima integration, devel.

[Guenter Milde]

On 2010-03-05, Janek Kozicki wrote:
 rgheck said: (by the date of Fri, 05 Mar 2010 10:18:35 -0500)

...

 besides improving that communication, the only missing thing is to
 be able to declare variables within maxima, and operate on them
 later. It means a running maxima session, instead of
 standalone/separate calls for each thing. 

 Ideally I would want to derive calculations within lyx, while
 writing comments about it. All with the beauty of latex.

 Perhaps I'll start with this communication formatting thing that you
 explained, it should be an easy start to get feel of the workings.

 What you are proposing, I think, is somewhat different and looks almost 
 like one of LyX's external insets.
...
 My sense is that, for full maxima integration, this is definitely the 
 easiest way to go. The disadvantage, compared to the current system, is 
 that there's no integration with the math insets.

 I see. I would prefer to stay within lyx boundaries. A split window,
 with the maxima buffer or such. I don't know yet. Storing input in
 external file is better than putting it into .lyx as comments,
 I didn't know this is possible. maxima runs well even in a text
 terminal, it should be possible to pipe this somehow.

One more thing to consider is using the lyxserver pipes. E.g. I wrote
some experimental LyX output for swiginac (a Python wrapper of the
ginac C++ library, http://swiginac.berlios.de/) using my LyXServer Python
package (available via the LyX wiki) but the other way is also feasible,
as the lyxserver is bidirectional. 

Günter

Bug 6522 is Much Worse in trunk

[rgheck]

Open any document. Open the Outline. Go anywhere and hit return. Crash!

This is with Qt 4.6.2 and is presumably related to 6522.

The offending line seems to be this one:

QModelIndexList indices = tocTV-model()-match(
tocTV-model()-index(0, 0),
Qt::DisplayRole, *, -1,
Qt::MatchFlags(Qt::MatchWildcard|Qt::MatchRecursive));

rh

===

0lyx::frontend::TocWidget::filterContentsTocWidget.cpp446
0x00b69aa6
1lyx::frontend::TocWidget::updateViewTocWidget.cpp435
0x00b6ba7f
2lyx::frontend::TocWidget::on_typeCO_currentIndexChanged
TocWidget.cpp3170x00b6bb36
3lyx::frontend::TocWidget::qt_metacallmoc_TocWidget.cpp
1090x00b6bc7d
4QMetaObject::activate(QObject*, QMetaObject const*, int, void**)
/usr/lib64/libQtCore.so.400x003a4c56a2af
5QComboBox::currentIndexChanged(int)/usr/lib64/libQtGui.so.4
00x003a4cf43201

6??/usr/lib64/libQtGui.so.400x003a4cf4488c
7??/usr/lib64/libQtGui.so.400x003a4cf477ed
8QComboBox::qt_metacall(QMetaObject::Call, int, void**)
/usr/lib64/libQtGui.so.400x003a4cf4c00f
9QMetaObject::activate(QObject*, QMetaObject const*, int, void**)
/usr/lib64/libQtCore.so.400x003a4c56a2af
10QAbstractItemModel::endResetModel()
/usr/lib64/libQtCore.so.400x003a4c550146

11??/usr/lib64/libQtGui.so.400x003a4d10727d
12QSortFilterProxyModel::qt_metacall(QMetaObject::Call, int, 
void**)/usr/lib64/libQtGui.so.400x003a4d109189
13QMetaObject::activate(QObject*, QMetaObject const*, int, 
void**)/usr/lib64/libQtCore.so.400x003a4c56a2af
14QAbstractItemModel::reset()/usr/lib64/libQtCore.so.40
0x003a4c55033e
15lyx::frontend::TocTypeModel::resetTocModel.cpp50
0x009c08a3
16lyx::frontend::TocModels::resetTocModel.cpp363
0x009c396a
17lyx::frontend::GuiView::structureChangedGuiView.cpp1259
0x00962a45
18lyx::Buffer::structureChangedBuffer.cpp2994
0x0046fce4

19lyx::Buffer::updateBufferBuffer.cpp36220x0048e6d8
20updateBufferBuffer.h5480x00629a41
... More

Re: Feature request: find-and-replace within selection

[Guenter Milde]

On 2010-03-05, Manoj Rajagopalan wrote:

 It would be useful to support this feature because we could perform a 
 replace-all within a selection and quickly achieve the desired result
 without clobbering the rest of the document.

Agreed. 

But maybe better making this even more generic:

My beloved Jed text editor has a generic narrow feature that limits
all editing operations to the current selection until undone by widen.
(I think this originates from Emacs.)

This could be usefull for spell-checking or other operations as well.

Günter

Re: better maxima integration, devel.

[Janek Kozicki]

Guenter Milde said: (by the date of Fri, 5 Mar 2010 20:07:45 + (UTC))

 One more thing to consider is using the lyxserver pipes. E.g. I wrote
 some experimental LyX output for swiginac (a Python wrapper of the
 ginac C++ library, http://swiginac.berlios.de/) using my LyXServer Python
 package (available via the LyX wiki) but the other way is also feasible,
 as the lyxserver is bidirectional. 

wow, the lyx's architecture is impressive! Thanks for another hint.

-- 
Janek Kozicki   http://janek.kozicki.pl/  |

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

[Abdelrazak Younes]

On 05/03/2010 21:47, rgh...@lyx.org wrote:

Author: rgheck
Date: Fri Mar  5 21:47:50 2010
New Revision: 33630
URL: http://www.lyx.org/trac/changeset/33630

Log:
Fix bug 6522 and its relatives in trunk. I am not absolutely sure this
is right, though. Someone please check.


Seems correct.

Abdel.



The problem, in branch, was that (in Qt 4.6.x, anyway) the call to
reset() eventually triggers the on_typeCO_currentIndexChanged() method,
which eventually leads to GuiView::setFocus(), which leads to
GuiWorkArea::focusInEvent(), which tries to start the cursor, whose
position hasn't been updated yet, from what I can see.

The problem in trunk is similar. The crash happens, I think, because,
while we are in the middle of resetting the model, the same method is
triggered, which leads us to try to access the model while we are in the
middle of resetting it.

Modified:
lyx-devel/trunk/src/frontends/qt4/TocModel.cpp

Modified: lyx-devel/trunk/src/frontends/qt4/TocModel.cpp
==
--- lyx-devel/trunk/src/frontends/qt4/TocModel.cpp  Fri Mar  5 21:40:45 
2010(r33629)
+++ lyx-devel/trunk/src/frontends/qt4/TocModel.cpp  Fri Mar  5 21:47:50 
2010(r33630)
@@ -359,8 +359,8 @@
names_-setData(index, gui_name, Qt::DisplayRole);
names_-setData(index, type, Qt::UserRole);
}
-   names_-blockSignals(false);
names_-reset();
+   names_-blockSignals(false);
  }

Re: r33631 - in lyx-devel/trunk/src: . insets

[Abdelrazak Younes]

On 05/03/2010 22:06, rgh...@lyx.org wrote:

Author: rgheck
Date: Fri Mar  5 22:06:22 2010
New Revision: 33631
URL: http://www.lyx.org/trac/changeset/33631

Log:
Let floats decide for themselves what command is used to create a list
of them. This is preparatory for introducing a layout tag that lets us
customize that command for builtin floats.

Modified:
lyx-devel/trunk/src/Floating.cpp
lyx-devel/trunk/src/Floating.h
lyx-devel/trunk/src/insets/InsetFloatList.cpp

Modified: lyx-devel/trunk/src/Floating.cpp
==
--- lyx-devel/trunk/src/Floating.cppFri Mar  5 21:47:50 2010(r33630)
+++ lyx-devel/trunk/src/Floating.cppFri Mar  5 22:06:22 2010(r33631)
@@ -14,7 +14,9 @@

  #include Floating.h

+#include support/docstring.h
  #include support/lstrings.h
+#include support/Messages.h

  using namespace std;

@@ -38,6 +40,26 @@
  {}


+docstring const  Floating::listCommand(string const  lang) const
+{
+   if (listcommand_.empty()) {


if (!listcommand_.empty())
return listcommand_;



+   if (needsFloatPkg())
+   listcommand_ = from_ascii(\\listof{ + floattype_ + 
}{)
+  + getMessages(lang).get(listName()) + };
+   else {
+   if (floattype_ == table)
+   listcommand_ = from_ascii(\\listoftables);
+   else if (floattype_ == figure)
+   listcommand_ = from_ascii(\\listoffigures);
+   else
+   // FIXME We really need a special tag for this.
+   listcommand_ = from_ascii(\\listof + floattype_ + 
s);
+   }
+   }
+   return listcommand_;
+}
+
+
  string const  Floating::htmlAttrib() const
  {
if (html_attrib_.empty())

Modified: lyx-devel/trunk/src/Floating.h
==
--- lyx-devel/trunk/src/Floating.h  Fri Mar  5 21:47:50 2010(r33630)
+++ lyx-devel/trunk/src/Floating.h  Fri Mar  5 22:06:22 2010(r33631)
@@ -12,11 +12,13 @@
  #ifndef FLOATING_H
  #define FLOATING_H

+#include support/strfwd.h
+
  #includestring


  namespace lyx {
-
+   
  /** This is a float layout object. It contains the parameters for how to
   *  handle the different kinds of floats, default ones and user created ones.
   *  Objects of this class is stored in a container in FloatList. The different
@@ -46,8 +48,13 @@
std::string const  style() const { return style_; }
///
std::string const  name() const { return name_; }
-   ///
+   /// the title of a list of this kind of float
std::string const  listName() const { return listname_; }
+   /// the command used to generate that list, in LaTeX
+   /// if needsFloatPkg() is true, then this is
+   ///   \listof{floattype()}
+   /// otherwise it is hardcoded, at present.
+   docstring const  listCommand(std::string const  lang) const;
///
bool needsFloatPkg() const { return needsfloatpkg_; }
/// style information, for preamble
@@ -74,6 +81,8 @@
///
std::string listname_;
///
+   mutable docstring listcommand_;
+   ///
bool needsfloatpkg_;
///
mutable std::string html_tag_;

Modified: lyx-devel/trunk/src/insets/InsetFloatList.cpp
==
--- lyx-devel/trunk/src/insets/InsetFloatList.cpp   Fri Mar  5 21:47:50 
2010(r33630)
+++ lyx-devel/trunk/src/insets/InsetFloatList.cpp   Fri Mar  5 22:06:22 
2010(r33631)
@@ -18,6 +18,7 @@
  #include Floating.h
  #include FloatList.h
  #include FuncRequest.h
+#include Language.h
  #include LaTeXFeatures.h
  #include Lexer.h
  #include MetricsInfo.h
@@ -119,23 +120,10 @@
FloatList::const_iterator cit = floats[to_ascii(getParam(type))];

if (cit != floats.end()) {
-   if (!cit-second.needsFloatPkg()) {
-   // Only two different types allowed here:
-   string const type = cit-second.floattype();
-   if (type == table) {
-   os  \\listoftables\n;
-   } else if (type == figure) {
-   os  \\listoffigures\n;
-   } else {
-   os  %% unknown builtin float\n;
-   }
-   } else {
-   os  \\listof{  getParam(type)  }{
- buffer().B_(cit-second.listName())  }\n;
-   }
+   os  
cit-second.listCommand(buffer().params().language-code());
} else {
os  %%\\listof{  getParam(type)  }{
- bformat(_(List of %1$s), 

Re: r33631 - in lyx-devel/trunk/src: . insets

[rgheck]

On 03/05/2010 05:01 PM, Abdelrazak Younes wrote:


if (!listcommand_.empty())
return listcommand_;


Thanks, but I reverted this code!!

rh

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

[rgheck]

On 03/05/2010 04:59 PM, Abdelrazak Younes wrote:

On 05/03/2010 21:47, rgh...@lyx.org wrote:

Author: rgheck
Date: Fri Mar  5 21:47:50 2010
New Revision: 33630
URL: http://www.lyx.org/trac/changeset/33630

Log:
Fix bug 6522 and its relatives in trunk. I am not absolutely sure this
is right, though. Someone please check.


Seems correct.


In that case, Jurgen, this is for branch.

rh

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

[rgheck]

On 03/05/2010 06:48 PM, rgheck wrote:

On 03/05/2010 04:59 PM, Abdelrazak Younes wrote:

On 05/03/2010 21:47, rgh...@lyx.org wrote:

Author: rgheck
Date: Fri Mar  5 21:47:50 2010
New Revision: 33630
URL: http://www.lyx.org/trac/changeset/33630

Log:
Fix bug 6522 and its relatives in trunk. I am not absolutely sure this
is right, though. Someone please check.


Seems correct.


In that case, Jurgen, this is for branch.

Actually, no, this causes a different problem, namely, that the menu at 
the top of the TOC doesn't get populated. Abdel, can you fix this?


Richard


rh

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

[rgheck]

On 03/05/2010 06:54 PM, rgheck wrote:

On 03/05/2010 06:48 PM, rgheck wrote:

On 03/05/2010 04:59 PM, Abdelrazak Younes wrote:

On 05/03/2010 21:47, rgh...@lyx.org wrote:

Author: rgheck
Date: Fri Mar  5 21:47:50 2010
New Revision: 33630
URL: http://www.lyx.org/trac/changeset/33630

Log:
Fix bug 6522 and its relatives in trunk. I am not absolutely sure this
is right, though. Someone please check.


Seems correct.


In that case, Jurgen, this is for branch.

Actually, no, this causes a different problem, namely, that the menu 
at the top of the TOC doesn't get populated. Abdel, can you fix this?


The problem (I think) is that this also blocks the emission of the 
modelReset() signal, which tells the toc widget that the names stuff has 
been updated.


rh

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

[rgheck]

On 03/05/2010 07:10 PM, rgheck wrote:

On 03/05/2010 06:54 PM, rgheck wrote:

On 03/05/2010 06:48 PM, rgheck wrote:

On 03/05/2010 04:59 PM, Abdelrazak Younes wrote:

On 05/03/2010 21:47, rgh...@lyx.org wrote:

Author: rgheck
Date: Fri Mar  5 21:47:50 2010
New Revision: 33630
URL: http://www.lyx.org/trac/changeset/33630

Log:
Fix bug 6522 and its relatives in trunk. I am not absolutely sure 
this

is right, though. Someone please check.


Seems correct.


In that case, Jurgen, this is for branch.

Actually, no, this causes a different problem, namely, that the menu 
at the top of the TOC doesn't get populated. Abdel, can you fix this?


The problem (I think) is that this also blocks the emission of the 
modelReset() signal, which tells the toc widget that the names stuff 
has been updated.


I'm convinced now that this is wrong. And I just don't understand this 
crash. Why does this call:


QModelIndexList indices = tocTV-model()-match(
tocTV-model()-index(0, 0),
Qt::DisplayRole, *, -1,
Qt::MatchFlags(Qt::MatchWildcard|Qt::MatchRecursive));

lead to a segfault?

rh


rh

Re: LyX 2.0 release plan

[Vincent van Ravesteijn]

i'm not sure who is this we; from the last discussions about release
plans it looked like that more devs thought we are already late and
particularly can't remember anybody claiming we should wait little bit
longer. if its not the case then sorry and lets discuss the stages
a little bit more.
  


No, there is no need for discussion. I welcome the fact that you 
actively step in.
concerning the fact that the 1.6 criterion for beta-rc 
transit was no dataloss bug, than the crashes above being

stopper for entering alpha state looks way too strict.
  
Trunk was pretty stable, and right at the moment that it has become very 
unstable, you propose to release an alpha-version. I wouldn't encourage 
anyone to try trunk right now, even not the closest comunity.

anyway would you accept if we call it pre-alpha or only
development snapshot instead?
  


Or, we just fix those bugs.

pavel
  


Vincent

Re: #6574: ChkTeX selects entire paragraph, rather than just line where error occurs.

[John McCabe-Dansted]

On Sat, Mar 6, 2010 at 3:46 AM, Tommaso Cucinotta tomm...@lyx.org wrote:
 Probably you have more experience than me in using chktex, so, please,
 comment on this. In the meantime, I'm leaving just the standard linelen from
 the RC file also for chktex.

Yes that looks like a chktex bug. May as well leave the default as it
is until I can push fixes upstream.

-- 
John C. McCabe-Dansted

Re: The emission of \maketitle

[Guenter Milde]

On 2010-03-05, Manoj Rajagopalan wrote:
> Hi lyx-devel,

>What controls the emission of \maketitle when exporting to latex?

There is an "intitle" (or something like that) keyword for layout
styles. It is explained in the Customization guide.
(Or look at the implementation of the abstract style.)

Günter

RE: Patch: table splitting functionality

[Vincent van Ravesteijn - TNW]

>The code update is still within InsetTabular::tabularFeatures().
Vincent
>raised a valid issue about an inset creating new insets but here are my
>thoughts:
>
>1. This inset is only creating and inserting a subset of itself. It
also correctly
>pops the cursor and places it between the two parts. 
>

I feel it's just not he task of a particular inset to insert other
insets into the main document.

Jmarc ? Do you have an opinion ?

> All this using standard API calls so it is "safe".

This makes no sense. You can do a lot of harm using cur.pop() and
friends.

>  Please correct me: the lyx code currently doesn't have any place
where insets,
> in general, can be split. It could. For example, split a paragraph. 

What do you mean ? Of course we can split a paragraph.

>Seems extraneous till you see that it can be bundled with split-table
or split-equation
>into a common LFUN_INSET_SPLIT (say). It would then be simpler to
insert the
>table-split code here and maintain Vincent's argument.

Looks like a good idea to me.

Vincent

Re: r33624 - lyx-devel/trunk/src/support

[Abdelrazak Younes]

On 03/05/2010 09:05 AM, sa...@lyx.org wrote:

Author: sanda
Date: Fri Mar  5 09:05:25 2010
New Revision: 33624
URL: http://www.lyx.org/trac/changeset/33624

Log:
next one

Modified:
lyx-devel/trunk/src/support/Makefile.am

Modified: lyx-devel/trunk/src/support/Makefile.am
==
--- lyx-devel/trunk/src/support/Makefile.am Fri Mar  5 09:05:20 2010
(r33623)
+++ lyx-devel/trunk/src/support/Makefile.am Fri Mar  5 09:05:25 2010
(r33624)
@@ -89,6 +89,7 @@
SignalSlot.h \
SignalSlotPrivate.cpp \
SignalSlotPrivate.h \


We should also get rid of the 3 files above as they are not used in the 
code.



+   SystemcallPrivate.h \
textutils.h \
Translator.h \
Timeout.cpp \

RE: r33624 - lyx-devel/trunk/src/support

[Vincent van Ravesteijn - TNW]

>Author: sanda
>Date: Fri Mar  5 09:05:25 2010
>New Revision: 33624
>URL: http://www.lyx.org/trac/changeset/33624
>
>Log:
>next one
>


I really like those meaningful logs.

Vincent

c++/compiler question

[Edwin Leuven]

now when looping i write something like this:

row_type const nrows = row_info.size();
for (row_type r = 0; r < nrows; ++r) {

are compilers these days smart enough so that we can simply write:

for (row_type r = 0; r < row_info.size(); ++r) {

?

thanks, ed.

better maxima integration, devel.

[Janek Kozicki]

Hi,

I'm thinking about the possibility of using lyx as my frontend to
maxima. Texmacs doesn't suit me, because I used gvim+latex for years.

Since I used latex for long time it would be logical to start using
lyx in order to interact with maxima. I didn't ever use lyx before,
because gvim was good enough for me. But this time I need a maxima
interface with latex capabilities.

I see now, that such integration would require at least a running
maxima session in the background. 

I'm quite experienced with latex and C++.

I am not sure if I decide to go this path, I want to investigate and
judge the difficulty of writing patches that will scratch my itch.


I don't know what is the current state of lyx+maxima integration, and
I asked for ML archives in order to check this.

best regards
-- 
Janek Kozicki   http://janek.kozicki.pl/  |

Re: trunk crash (missing Addsec*)

[Jürgen Spitzmüller]

Guenter Milde wrote:
> > Could you post this file?
> 
> Yes.

Please send an attachment (not inline).

Jürgen

Re: Greek text mixed with English

[Jürgen Spitzmüller]

Guenter Milde wrote:
> However, Greek Unicode chars are missing in the output in the
> following example if:
> 
> a) babel is included, or
> b) the \setmainfont line is commented
> 
> \documentclass[greek]{article}
> \usepackage{fontspec}
> \setmainfont{Gentium}
> 
> % \usepackage{babel}
> % \usepackage{polyglossia}
> 
> \begin{document}
> 
> Me mia mati'a...
> 
> Με μια ματιά...
> 
> \end{document}
> 
> Babel selects a different font (the missing unicode support is a
> consequence of this font change). 

Please file reports for these. I don't think our XeTeX has been thouroughly 
tested yet. I have implemented it (due to user requests), but I do not use 
XeTeX myself at all.

> We must replace babel by polyglossia, as babel is not compatible with
> XeTeX. Selecting XeTeX as output machine is an explicite request for
> full, language-independent Unicode support.

Sure, polyglossia support must follow eventually. But this is more work than 
it seems. You have to dive into our language framework, which is all over the 
place. But of course, patches are welcome.

Jürgen

Re: Release process for LyX-2.0.0

[Jürgen Spitzmüller]

José Matos wrote:
> Hi all,
> after lots of thought and some private conversations with some
> developers (with former and present release managers) I have decided to
> step back from the release management of LyX 2.0.0.

Thanks for all your efforts! I certainly hope your timeframe for LyX will 
widen again soon.

And good luck, Pavel!

Jürgen

Re: r33615 - lyx-devel/trunk/src/insets

[Jürgen Spitzmüller]

uwestoehr wrote:
> Should also go to branch, Jürgen?

OK.

Jürgen

Re: Release process for LyX-2.0.0

[Edwin Leuven]

Jürgen Spitzmüller wrote:

José Matos wrote:

Hi all,
after lots of thought and some private conversations with some
developers (with former and present release managers) I have decided to
step back from the release management of LyX 2.0.0.


Thanks for all your efforts! I certainly hope your timeframe for LyX will 
widen again soon.


hear! hear!


And good luck, Pavel!


yes, we all look forward to flaming you ;-)

Re: c++/compiler question

[Abdelrazak Younes]

On 03/05/2010 11:56 AM, Edwin Leuven wrote:

now when looping i write something like this:

row_type const nrows = row_info.size();
for (row_type r = 0; r < nrows; ++r) {

are compilers these days smart enough so that we can simply write:

for (row_type r = 0; r < row_info.size(); ++r) {


I guess it depends of the constness of row_info...
Best is to not bet on the compiler smartness :-)

Abdel.

Re: c++/compiler question

[Edwin Leuven]

Abdelrazak Younes wrote:

On 03/05/2010 11:56 AM, Edwin Leuven wrote:

now when looping i write something like this:

row_type const nrows = row_info.size();
for (row_type r = 0; r < nrows; ++r) {

are compilers these days smart enough so that we can simply write:

for (row_type r = 0; r < row_info.size(); ++r) {


I guess it depends of the constness of row_info...


it's a non-const std::vector

what if i declared

row_type nrows() const {return row_info.size();}

and then do

for (row_type r = 0; r < nrows(); ++r)

?

Re: LyX ignorant of \listofs defined in document-class [Patch]

[rgheck]

On 03/04/2010 08:57 PM, Manoj Rajagopalan wrote:



On Thursday 04 March 2010 08:41:08 am rgheck wrote:
   

Or might it be better to have something
like this:
  ListCommandlistofvideos
in the float definition? Then you could also have:
  ListCommandlistoftables
and
  ListCommandlistoffigures
in the appropriate places, and skip these special checks altogether.

If that seems a good idea, I can create this command. Or, if you'd like
to learn a bit about layout stuff, you can do it. The place to look is
TextClass::readFloat(), and then an appropriate member would need to be
added to Floating.

One other thing: We need to check the other uses of builtin() to make
sure that the code can handle things other than table and figure. If
this routine expects only those two things, then maybe other routines
do, as well. There is such a check in
LaTeXFeatures::getFloatDefinitions(), for example, and I have no idea if
other builtins need similar treatment. Another place is in
InsetFloatList::xhtml(), which was based on the latex output. Whatever
we do for the latex, we can also do here, I suspect.

rh
 

I agree with you in that a new ListCommand (maybe  LaTeXListOfCommand?) is a
better idea - it is not necessary that documentclass creators adhere to this
ad-hoc nomenclature. For example, \listofpotatos could be \listofpotatoes
(notice the penultimate 'e'). Providing such a command will scale in future.
The "LaTeX" prefix in the optionname disambiguates the intent (command could
very well mean lyx command esp. since the value of this option won't have
a '\' prefix to indicates its latex-ness).

I can work on the patch - I am having fun learning lyx and the pointers you
have given will certainly help.

   
OK. Let me know if you have any questions. Note, by the way, that you'll 
also need (a) to increment the layout format in TextClass.cpp and (b) to 
do trivial work in layout2layout.py. If you look at r33467, you'll see 
what I mean.


FWIW, ListOfCommand or CommandForList is probably good enough. DocBook 
has its own way of handling these things, and the "Command" part 
disambiguates. Only LaTeX has commands.



About builtin() - the code and documentation must agree. The documentation
(UserGuide appendix on menu items) says "built-in" is something defined by
the document class but the code doesn't seem to honor this 100%. Since table
and figure are latex fundamentals, maybe it would make sense to
distinguish "isLatexPrimitive()" from "builtin()" ? latex-primitive =>
built-in but not the other way.

   
My sense, from a brief look, is that the documentation is right and the 
code is wrong. What this really seems to indicate is whether we need to 
use the float package for this float. So it might make more sense to 
have a "NeedsFloatPkg" tag instead of the "Builtin" tag. It would 
default to false, so the default wouldn't change, and the only actual 
work would be in layout2layout.py. The rest would be replacing 
Floating::builtin() with Floating::needsFloatPkg().


Richard

Re: The emission of \maketitle

[rgheck]

On 03/05/2010 02:38 AM, Guenter Milde wrote:

On 2010-03-05, Manoj Rajagopalan wrote:
   

Hi lyx-devel,
 
   

What controls the emission of \maketitle when exporting to latex?
 

There is an "intitle" (or something like that) keyword for layout
styles. It is explained in the Customization guide.
(Or look at the implementation of the abstract style.)

   

And when LyX hits something that isn't "intitle", then \maketitle goes.

rh

Re: better maxima integration, devel.

[Helge Hafting]

Janek Kozicki wrote:
[...]

I see now, that such integration would require at least a running
maxima session in the background. 


I'm quite experienced with latex and C++.

I am not sure if I decide to go this path, I want to investigate and
judge the difficulty of writing patches that will scratch my itch.


I don't know what is the current state of lyx+maxima integration, and
I asked for ML archives in order to check this.


Not sure what you want to do, but there is some LyX integration with 
maxima. You can write a formula in LyX, and then use this menu:

Edit->Math->Use Computer algebra system->Maxima

This will do transformations such as:
"1+1+x+x"  becomes "1+1+x+x=2x+2"
Calculus:
"\int x^2 dx" becomes "\int x^2=\frac{x^3}{3}"
"\int\int\frac{x}{y} turns into \frac{x^2 \log{y}}{2}

\frac{d}{dx}\frac{1+x}{1-x}
turns into
\frac{x+1}{\left(1-x\right)^{2}}+\frac{1}{1-x}

And so on. Apparently, there are many limitations though. Maxima can do
more, the communication between LyX and maxima is limited. You can't do 
matrix multiplication, for example.


Helge Hafting

Re: LyX 2 over Mac OS X Snow Leopard make error

[BH]

On Fri, Mar 5, 2010 at 12:02 AM, Yvon Thoraval  wrote:
>>
>> Yes -- that fixes it for me. (Assuming this is the right fix, can
>> someone check it in?)
>>
>
> Unfortunately no ;-)

You're not understanding. To "check in" the fix is to modify the
official source so that everyone can get the fix by using svn to
update the source code on local machines (by simply entering "svn up"
-- you don't have to check out the code from the beginning as you
did). So far no one has checked in the fix yet, so testing now won't
change anything for you.

You can either wait for the fix to be checked in, or you can manually
make the change Lase proposed earlier in this thread.

BH

Re: c++/compiler question

[rgheck]

On 03/05/2010 07:16 AM, Edwin Leuven wrote:

Abdelrazak Younes wrote:

On 03/05/2010 11:56 AM, Edwin Leuven wrote:

now when looping i write something like this:

row_type const nrows = row_info.size();
for (row_type r = 0; r < nrows; ++r) {

are compilers these days smart enough so that we can simply write:

for (row_type r = 0; r < row_info.size(); ++r) {


I guess it depends of the constness of row_info...


it's a non-const std::vector

what if i declared

row_type nrows() const {return row_info.size();}

and then do

for (row_type r = 0; r < nrows(); ++r)

?

I think gcc would give you a warning, to the effect of "Qualifier on 
return value is ignored". This is because row_type is not of object type.


Moreover, you could perfectly well do:
for (row_type r = 0; r < nrows(); ++r)
row_info.clear();
if row_info is non-const. Then nrows() returns 0 on the second time 
through, and the loop terminates, as it should. This suggests a reason that

for (row_type r = 0; r < row_info.size(); ++r) {
might be a little safer than
row_type const nrows = row_info.size();
for (row_type r = 0; r < nrows; ++r) {
when row_info is non-const.

Richard

Re: better maxima integration, devel.

[rgheck]

On 03/05/2010 07:29 AM, Helge Hafting wrote:

Janek Kozicki wrote:
[...]

I see now, that such integration would require at least a running
maxima session in the background.
I'm quite experienced with latex and C++.

I am not sure if I decide to go this path, I want to investigate and
judge the difficulty of writing patches that will scratch my itch.


I don't know what is the current state of lyx+maxima integration, and
I asked for ML archives in order to check this.


Not sure what you want to do, but there is some LyX integration with 
maxima. You can write a formula in LyX, and then use this menu:

Edit->Math->Use Computer algebra system->Maxima

This will do transformations such as:
"1+1+x+x"  becomes "1+1+x+x=2x+2"
Calculus:
"\int x^2 dx" becomes "\int x^2=\frac{x^3}{3}"
"\int\int\frac{x}{y} turns into \frac{x^2 \log{y}}{2}

\frac{d}{dx}\frac{1+x}{1-x}
turns into
\frac{x+1}{\left(1-x\right)^{2}}+\frac{1}{1-x}

And so on. Apparently, there are many limitations though. Maxima can do
more, the communication between LyX and maxima is limited. You can't 
do matrix multiplication, for example.


All of this is correct, but the infrastructure for doing more is there. 
Look at src/mathed/MathExtern.cpp and the various maxima() methods.


We'd be very, very happy to have someone work on this.

rh

RE: LyX 2 over Mac OS X Snow Leopard make error

[Vincent van Ravesteijn - TNW]

>>>
>>> Yes -- that fixes it for me. (Assuming this is the right fix, can 
>>> someone check it in?)
>>>
>>
>> Unfortunately no ;-)
>
>You're not understanding. To "check in" the fix is to modify the
official
>source so that everyone can get the fix by using svn to update the
source
>code on local machines (by simply entering "svn up"

I checked it in. 

Please try again.

Vincent

P.S. Please stop sending the messages twice to both lyx-users and
lyx-devel.

Re: better maxima integration, devel.

[Liviu Andronic]

On 3/5/10, Janek Kozicki  wrote:
>  I don't know what is the current state of lyx+maxima integration, and
>  I asked for ML archives in order to check this.
>
Some time ago there was a lengthy discussion about CAS support in LyX
[1] (including Maxima), which also contained some design ideas on
possible future development.

Regards
Liviu

[1] http://www.mail-archive.com/lyx-us...@lists.lyx.org/msg77889.html

LyX 2.0 release plan

[Pavel Sanda]

Hi LyXers,

lets start landing towards 2.0.

I respect Jose's choice so the upcoming version is fixed to 2.0 from now on.
Maybe you are not aware, but on autumn we celebrate 15 years of LyX (from the
first releases), so we can join releasing of 2.0 with some public advertisement
and looking back, what has happened during those years ... (if you are looking
for the reason for 2.0 ;)

To make things clear I would like to present plans for release stages
and some outline for dates.

As usual we go for alpha->beta->rc->2.0, with the following meaning of stages:

Alpha - kind of development snapshot. We only want to show new features and
possibly get some feedback and bug reports, we don't expect users 
to actually use it for serious work. From it follows that there are
no high quality demands or special policy to release alphas.

Beta - once we decide that all planned features are in and basically working
   we move to beta. From this point the main focus of developers should
   be cleaning the bugzilla from bugs with 2.0 target we get from users.
   So some small features can happen, but its stopper for any refactoring
   code "with some instability period" etc ;)
   Users are encouraged to report bugs back.

RC - all critical or very annoying bugs gone, we think its time to release,
 but for quality assurance few rc releases will be done.
 Bold users are encouraged to start using and report bugs back.

2.0 -  all promised beers from bugzilla have been delivered.


Preliminary dates for the stage beginning:
Alpha - next week if possible
Beta - end of May
RC - end of July 
2.0 - end of August

These are no deadlines, but rather live-lines which can change in both
directions ;) Their meaning is to give some course and synchronize us.
The current table can be always found at
http://wiki.lyx.org/Devel/ReleaseSchedule

Any comments/objections?


Alpha 1: I don't have any special requirement, from my POV the most serious
bug in OS X has been "fixed" by Abdel and I don't see any other showstopper.
Anybody want to have something before alpha in trunk?



Betas
I'll go through the enh bugs with 2.0 target and leave only those which are
really to be included. For this I need somebody create two new milestones in
trac for postponing - 2.1.0 & 2.0.1.

Secondly we need to collect all things which has been only partly finished
or are still in the pipe. Please take a coffee and help me to fill this
list and comment if possible. Cleaning up the list means we move to the beta
stage. The current version can be always reached at
http://wiki.lyx.org/Devel/LyX20Road
and I fill it once this thread is finished.


* Advanced Search - as far as I can see all wanted features finished, Tommaso?
  I expect lot of bug reports here though, we need to wait on users testing.

* Spellchecking - IIRC all features done or were there something more - I 
remember,
  some proposals like automatic switching off when xx% unrecognized etc.
  There are also already untouched bugs with spellcheck component. Abdel?

  For the packagers we need some summary what are the recommended dependencies.
  Haven't been closely following this stuff - could somebody write some summary
  of all those spellcheck (a/i/hun/spell) and thesaurus deps into RELEASE-NOTES?
  Juergen, Abdel?

* Comparison - IIRC Vincent considered some more work which would use
  words instead of characters to boost up the process. Currently the
  documents which are far from each other will never finish in a reasonable 
time.
  Vincent what are your plans? Also NewInLyx2.0 entry is missing or we wait for
  the finishing?

* HTML export. I remember Richard asked for help with images. Anybody around?
  Some plans to add instant preview snapshots for equations, or external insets
  using preview? Some other plans Richard? NewInLyx2.0 entry is missing.

* Multiple viewers/converters. Juergen asked for some help; how this evolved,
  what is to be done in this area? Juergen, Richard? 

* rc2rc conversion scripts for converting older preferences into new ones.
  Jose promised to come with something. I have worried what happen with users
  which run lyx beta to test and get prefs overwritten for their stable 1.6.x?

* Instant preview. What is the status/plan with the patch. IIRC Vincent was
  unsatisfied with the state of art without being specific.

* Tabular stuff. Edwin, Uwe and Abdel seem to work on it right now.

* There has been some work on dispatch results, but I have no idea whats the
  current status. JMarc? There are already filled bugs around dispatch.

* Connection between VCS and comparison feature. I have idea what to do but
  others weren't happy about the approach, so more discussion is needed.

* Layout groups are hopeless? Richard? Anybody? 
  http://wiki.lyx.org/Devel/LayoutGroup


Other entries?

Pavel

Re: c++/compiler question

[Manoj Rajagopalan]

On Friday 05 March 2010 07:44:22 am rgheck wrote:
> On 03/05/2010 07:16 AM, Edwin Leuven wrote:
> > Abdelrazak Younes wrote:
> >> On 03/05/2010 11:56 AM, Edwin Leuven wrote:
> >>> now when looping i write something like this:
> >>>
> >>> row_type const nrows = row_info.size();
> >>> for (row_type r = 0; r < nrows; ++r) {
> >>>
> >>> are compilers these days smart enough so that we can simply write:
> >>>
> >>> for (row_type r = 0; r < row_info.size(); ++r) {
> >>
> >> I guess it depends of the constness of row_info...
> >
> > it's a non-const std::vector
> >
> > what if i declared
> >
> > row_type nrows() const {return row_info.size();}
> >
> > and then do
> >
> > for (row_type r = 0; r < nrows(); ++r)
> >
> > ?
>
> I think gcc would give you a warning, to the effect of "Qualifier on
> return value is ignored". This is because row_type is not of object type.
>
> Moreover, you could perfectly well do:
>  for (row_type r = 0; r < nrows(); ++r)
>  row_info.clear();
> if row_info is non-const. Then nrows() returns 0 on the second time
> through, and the loop terminates, as it should. This suggests a reason that
>  for (row_type r = 0; r < row_info.size(); ++r) {
> might be a little safer than
>  row_type const nrows = row_info.size();
>  for (row_type r = 0; r < nrows; ++r) {
> when row_info is non-const.
>
> Richard

Actually, if row_info is going to change within the loop then r < 
row_info.size() is the only correct thing to do. With this we are telling the 
compiler to repeatedly evaluate row_info.size() before make the looping 
decision.

A compiler that caches the value of row_info.size() during its first 
evaluation is buggy. Of course, if this code is part of a const method of the 
same class as row_info then an optimization would be to cache the value on 
first evaluation.

Even if you declare nrows() to be a const method, it can be used within a 
non-const method in the same class without errors or warnings. The const-ness 
of nrows() method only means that at the time it is called, it does nothing 
to change the associated class during the lifetime of its execution during 
that call.

I think your question is about the optimization - does the compiler cache the 
row_info.size() value? Compiler optimizations have come a long way and this 
should happen in commercial compilers even if GCC doesn't recognize the 
optimization opportunity. If you are not sure, then it is best to play it 
safe and introduce a new const variable that you code to cache the container 
size. This also helps with debugging. Most compilers are smart enough to 
optimize out const "variables" - it is one of the simpler things to achieve. 
GCC does propagate constants.

-- Manoj

Re: better maxima integration, devel.

[Janek Kozicki]

rgheck said: (by the date of Fri, 05 Mar 2010 07:46:39 -0500)

> On 03/05/2010 07:29 AM, Helge Hafting wrote:
> > And so on. Apparently, there are many limitations though. Maxima can do
> > more, the communication between LyX and maxima is limited. You can't 
> > do matrix multiplication, for example.
> >
> All of this is correct, but the infrastructure for doing more is there. 
> Look at src/mathed/MathExtern.cpp and the various maxima() methods.
> 
> We'd be very, very happy to have someone work on this.

A warm welcome is very encouraging. I'll check that file.

I know nothing about how it is done, yet, but still I have some
simple vision, correct me when I'm wrong:

- to have a working connection with background maxima, we need a
  maxima buffer. This buffer (a list of %inputs) is not a part of
  latex/LyX document, so it should be stored somewhere. I was
  thinking about putting it into .tex (.lyx) file as a comment, with
  some magic keyword, like following:

% LYX+MAXIMA buffer, do not edit by hand, START
%
% * [wxMaxima: input   start ] */
% e1:ellipse : x^2/a^2+y^2/b^2=1;
% e2:line: A*(x-x0)+B*(y-y0)=0;
% /* [wxMaxima: input   end   ] */
%
% LYX+MAXIMA buffer, do not edit by hand, END

the first two characters (the "% ") are always stripped, the rest is
treated as-is: the maxima input file format.

- there could be a split-window with just the maxima input buffer.

- interesting parts from the maxima buffer would be copied into
  latex/lyx document, by using some sort of referencing.

- plot2d/3d would generate .ps files, provided correct gnuplot
  parameters to generate .ps files (which I happen to know).
  Pictures generated in this way would be entered into document
  structure in the same manner as the equations.

- compiling lyx+maxima document, would mean to do some preprocessing:
+ first execute the maxima buffer in fresh maxima session. This
  would calculate stuff, and generate .ps files.
+ enter the referenced equations in their latest form (freshly
  calculated) into their proper places in the latex document
+ then continue the normal compilation, like invoking pdflatex
  or others.

my head is bulging with ideas, but the time is really short.
I'll check what you've told me, tell me more. Do not expect me to be fast.

-- 
Janek Kozicki   http://janek.kozicki.pl/  |

Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Pavel Sanda wrote:
> Any comments/objections?

Looks reasonable, AFAICT.

> * Multiple viewers/converters. Juergen asked for some help; how this
> evolved, what is to be done in this area? Juergen, Richard?

I still did not yet find the time to re-address this. I need to clean up the 
tree with my changes (it doesn't compile anymore) and re-ponder the thing. I 
hope I can do this eventually. If not, LyX 2.0 should be released without this 
feature.

Jürgen

Re: Release process for LyX-2.0.0

[Pavel Sanda]

Edwin Leuven wrote:
>> And good luck, Pavel!
>
> yes, we all look forward to flaming you ;-)

my pleasure :D
pavel

RE: LyX 2.0 release plan

[Vincent van Ravesteijn - TNW]

>lets start landing towards 2.0.

That's what we call a "flying start"...

>Preliminary dates for the stage beginning:
>Alpha - next week if possible

Did we leave the instability period that was expected due to:
- threaded export,
- movements of code in the dispatch machinery,
- insetdialog changes,
- insetTabular changes. 

These were quite intrusive changes not that long ago. I understand the
alpha release doesn't have to be perfect, but there are now a lot of
crashes introduced in recent work, so I don't think it's the time to
'release' anything. There are now a number of very very embarassing bugs
that I don't want to see in the alpha release: 
* 6578, 6564, 6522 ...


>Alpha 1: I don't have any special requirement, from my POV the most
serious
>bug in OS X has been "fixed" by Abdel and I don't see any other
showstopper.

I do. As said above.

>Anybody want to have something before alpha in trunk?

I've one worthy unfinished feature left. Export to dir/zip including all
dependent files. Don't know what the advantage of being in alpha release
would be.

>* Comparison - IIRC Vincent considered some more work which would use
>  words instead of characters to boost up the process. Currently the
>  documents which are far from each other will never finish in a
reasonable time.
>  Vincent what are your plans? Also NewInLyx2.0 entry is missing or we
wait for
>  the finishing?

There is an academic question how to limit the time of the algorithm.
There is no such thing as 'the solution', because the real solution is
not the one most useful for the user (and takes quite some time).

I need to do some more work when I have time.

>* Instant preview. What is the status/plan with the patch. IIRC Vincent
was
>  unsatisfied with the state of art without being specific.

There weren't any enthusiastic responses from other developers than you.
The reason why I made it was that I wanted to be able to use psfrag, but
it appeared that was not supported by dvi2ps. This also holds for tikz I
believe. So, this removed the need for introducing yet another inset.
Moreover, I couldn't think of a way to integrate the existing preview
machinery into the new stuff.

>* Layout groups are hopeless? Richard? Anybody? 
>  http://wiki.lyx.org/Devel/LayoutGroup

I guess, I launched this site, but I didn't have time to do it as I've
been fixing bugs, bugs, and bugs.

>Other entries?

The "Export as ZIP" feature. I'll try to come up with a prototype asap.

Vincent

Re: LyX 2.0 release plan

[BH]

On Fri, Mar 5, 2010 at 9:10 AM, Pavel Sanda  wrote:
> Alpha 1: I don't have any special requirement, from my POV the most serious
> bug in OS X has been "fixed" by Abdel and I don't see any other showstopper.
> Anybody want to have something before alpha in trunk?

Things are looking reasonably good on Mac. It needs some polish, and I
think we need to make a decision about whether various widgets
(outline, spellchecker, source view, messages) should be docked,
floating, or drawers on Mac. But that, of course, is not needed before
the alpha.

BH

RE: LyX 2.0 release plan

[Vincent van Ravesteijn - TNW]

 
>> Alpha 1: I don't have any special requirement, from my POV the most 
>> serious bug in OS X has been "fixed" by Abdel and I don't see any
other showstopper.
>> Anybody want to have something before alpha in trunk?
>
>Things are looking reasonably good on Mac. It needs some polish, and I
think we
>need to make a decision about whether various widgets (outline,
spellchecker,
>source view, messages) should be docked, floating, or drawers on Mac.
But that,
>of course, is not needed before the alpha.
>

As I said before, there are now exceptions made for MacOSX that do
precisely that what you don't want to see. So, we can experiment
somewhat if you tell us how the average mac user likes to see it.

Vincent

Re: better maxima integration, devel.

[rgheck]

On 03/05/2010 09:20 AM, Janek Kozicki wrote:

rgheck said: (by the date of Fri, 05 Mar 2010 07:46:39 -0500)

   

On 03/05/2010 07:29 AM, Helge Hafting wrote:
 

And so on. Apparently, there are many limitations though. Maxima can do
more, the communication between LyX and maxima is limited. You can't
do matrix multiplication, for example.

   

All of this is correct, but the infrastructure for doing more is there.
Look at src/mathed/MathExtern.cpp and the various maxima() methods.

We'd be very, very happy to have someone work on this.
 

A warm welcome is very encouraging. I'll check that file.

I know nothing about how it is done, yet, but still I have some
simple vision, correct me when I'm wrong:

   
Since I don't use maxima etc myself, I don't have a lot of thoughts 
about this. What happens at present is that LaTeX that is entered into a 
math inset gets translated into maxima's input format; LyX calls maxima 
to do the calculation; retrieves the result, which is presumably in 
maxima's output format; and then translates that back into LaTeX, for 
inclusion in the document. Improving this means improving the 
translation mechanisms, mostly, so that LyX is able to formulate more 
complex queries and understand more complex answers.


What you are proposing, I think, is somewhat different and looks almost 
like one of LyX's "external" insets. Indeed, something very like it 
could surely be implemented using external templates, which define a way 
that LyX can interact with external programs. These insets are inserted 
using Insert>File>External Material, and we have support for several 
external programs now. The difference from what you are proposing is 
that the information would not be stored in LyX but rather in external 
text files referenced from within the LyX document. These would also be 
edited in an external text editor, but this can be called from within 
LyX, from the context menu. Have a look at lib/external_templates, which 
defines several of these things, and at chapter 6 of the Customization 
manual.


My sense is that, for full maxima integration, this is definitely the 
easiest way to go. The disadvantage, compared to the current system, is 
that there's no integration with the math insets.


rh

Re: better maxima integration, devel.

[Janek Kozicki]

Liviu Andronic said: (by the date of Fri, 5 Mar 2010 14:09:40 +)


> [1] http://www.mail-archive.com/lyx-us...@lists.lyx.org/msg77889.html

thanks, by reading this I see that the maxima buffer must be
seamlessly integrated with document, in order to not confuse people.

But, OTOH, to use any algebra system in efficient way, the user has to
know which one he is using. I am not going to write an interface that
translates every kind of math+lyx input into every kind of
octave/maxima/maple/mathematica input. There's too many different
specific things, and I never used maple/octave/mathematica, I don't
know their formatting.

The simplest way for me is to allow a maxima session in lyx, and add
communication between both. Copying/using/referencing equations in both
directions between maxima buffer <-> document. Entering equations in
document and pasting them to maxima buffer (for later, more complex
use) for people familiar with entering equation using lyx/latex
commands and the opposite for people who wish to enter them using
maxima input format.
-- 
Janek Kozicki   http://janek.kozicki.pl/  |

Re: better maxima integration, devel.

[Janek Kozicki]

Liviu Andronic said: (by the date of Fri, 5 Mar 2010 14:09:40 +)


> [1] http://www.mail-archive.com/lyx-us...@lists.lyx.org/msg77889.html

thanks, by reading this I see that the maxima buffer must be
seamlessly integrated with document, in order to not confuse people.

But, OTOH, to use any algebra system in efficient way, the user has to
know which one he is using. I am not going to write an interface that
translates every kind of math+lyx input into every kind of
octave/maxima/maple/mathematica input. There's too many different
specific things, and I never used maple/octave/mathematica, I don't
know their formatting.

The simplest way for me is to allow a maxima session in lyx, and add
communication between both. Copying/using/referencing equations in both
directions between maxima buffer <-> document. Entering equations in
document and pasting them to maxima buffer (for later, more complex
use) for people familiar with entering equation using lyx/latex
commands and the opposite for people who wish to enter them using
maxima input format.
-- 
Janek Kozicki   http://janek.kozicki.pl/  |

Re: better maxima integration, devel.

[Janek Kozicki]

rgheck said: (by the date of Fri, 05 Mar 2010 10:18:35 -0500)

> Since I don't use maxima etc myself, I don't have a lot of thoughts 
> about this. What happens at present is that LaTeX that is entered into a 
> math inset gets translated into maxima's input format; LyX calls maxima 
> to do the calculation; retrieves the result, which is presumably in 
> maxima's output format; and then translates that back into LaTeX, for 
> inclusion in the document. Improving this means improving the 
> translation mechanisms, mostly, so that LyX is able to formulate more 
> complex queries and understand more complex answers.

besides improving that communication, the "only" missing thing is to
be able to declare variables within maxima, and operate on them
later. It means a running maxima session, instead of
standalone/separate calls for each thing. Those separate calls mean
that everything is forgot after the call to maxima is done.

Ideally I would want to derive calculations within lyx, while
writing comments about it. All with the beauty of latex.

Perhaps I'll start with this communication formatting thing that you
explained, it should be an easy start to get feel of the workings.

> What you are proposing, I think, is somewhat different and looks almost 
> like one of LyX's "external" insets. Indeed, something very like it 
> could surely be implemented using external templates, which define a way 
> that LyX can interact with external programs. These insets are inserted 
> using Insert>File>External Material, and we have support for several 
> external programs now. The difference from what you are proposing is 
> that the information would not be stored in LyX but rather in external 
> text files referenced from within the LyX document. These would also be 
> edited in an external text editor, but this can be called from within 
> LyX, from the context menu. Have a look at lib/external_templates, which 
> defines several of these things, and at chapter 6 of the Customization 
> manual.
> 
> My sense is that, for full maxima integration, this is definitely the 
> easiest way to go. The disadvantage, compared to the current system, is 
> that there's no integration with the math insets.

I see. I would prefer to stay within lyx boundaries. A split window,
with the maxima buffer or such. I don't know yet. Storing input in
external file is better than putting it into .lyx as comments,
I didn't know this is possible. maxima runs well even in a text
terminal, it should be possible to pipe this somehow.

I should look in the code now, or else it becomes just babbling. The
time limitation allows me to do it only on fridays, only an hour or
two per week, so I hopefully will come with more interesting
questions next week.

-- 
Janek Kozicki   http://janek.kozicki.pl/  |

Re: LyX 2.0 release plan

[rgheck]

On 03/05/2010 09:10 AM, Pavel Sanda wrote:

* HTML export. I remember Richard asked for help with images. Anybody around?
   Some plans to add instant preview snapshots for equations, or external insets
   using preview? Some other plans Richard? NewInLyx2.0 entry is missing.

   
I do need help here.Quite simply, what I need is to be able to have 
access to the preview image from within the xhtml output routine. This 
would let us do image rotation, scaling, cropping, etc, of images; do 
something with external insets, which are at present ignored; and even 
allow the use of little pictures for math when necessary. From what I 
can tell, though, the preview images right now are buried somewhere deep 
within the GUI and so aren't accessible from the output routines. So 
that's it.


The other thing I have left to do is finish the MathML stuff. Most of 
that works, but not all.



* Multiple viewers/converters. Juergen asked for some help; how this evolved,
   what is to be done in this area? Juergen, Richard?

   
I can do the graph work, if I know precisely what needs doing. We had 
some discussions, but then they kind of died, as we both got busy. So 
I'm not quite sure where we stand.



* Layout groups are hopeless? Richard? Anybody?
   http://wiki.lyx.org/Devel/LayoutGroup

   
IIRC, Vincent was thinking about this, but I'm not sure if he got 
anywhere. It's probably too late to make this work for 2.0, which means 
postponing to 2.1, since it's definitely a format change.


rh

Re: LyX ignorant of \listoffloats defined in document-class [Patch]

[Julien Rioux]

rgheck  writes:
> My sense, from a brief look, is that the documentation is right and the 
> code is wrong. What this really seems to indicate is whether we need to 
> use the float package for this float. So it might make more sense to 
> have a "NeedsFloatPkg" tag instead of the "Builtin" tag. It would 
> default to false, so the default wouldn't change, and the only actual 
> work would be in layout2layout.py. The rest would be replacing 
> Floating::builtin() with Floating::needsFloatPkg().
> 

+1 for this

I found "builtin" confusing when writing custom layouts.  The question is not
really whether it is builtin or not, but whether you want LyX to define the
float for you using the float package.

--
Julien

Re: LyX 2.0 release plan

[rgheck]

On 03/05/2010 09:48 AM, Vincent van Ravesteijn - TNW wrote:



Anybody want to have something before alpha in trunk?
 

I've one worthy unfinished feature left. Export to dir/zip including all
dependent files. Don't know what the advantage of being in alpha release
would be.

   

Excellent.

rh