Re: HTML Output for LyX: RFC

[cmiramon]

rgheck wrote:

 There are more and less complicated ways to do this. You could have a
 new format, like DocBook, but I think what's really wanted is something
 that would work more like plaintext, so that you can output any document
 as HTML. So we'd have a set of ashtml() routines in the insets, etc,
 pretty much everywhere we have latex() and plaintext(), and the overall
 structure would be the same.
 

I'm sceptical. 

Part of the final formatting is done by the LaTex engine. For example how
are you going to translate \maketitle, the positioning of title, author,
etc... is different in package A than in package B. 

To translate \date, you will need to have a routine saying If language =
German than translate this way, if French, this other way, if English

Globally you will have to recreate in your ashtml() routines part of the
LaTeX package macros and Babel. It is a big endeavour, not to speak the
bibliographical formating engine.

What is the point ? when there is, like I have argued, the simpler way of
using both the lyx file and the pdf file.

But you are marking papers... I'm not; you are coding, I'm not ;-)

Cheers,
Charles  

Re: HTML Output for LyX: RFC

[cmiramon]

rgheck wrote:

> There are more and less complicated ways to do this. You could have a
> new format, like DocBook, but I think what's really wanted is something
> that would work more like plaintext, so that you can output any document
> as HTML. So we'd have a set of ashtml() routines in the insets, etc,
> pretty much everywhere we have latex() and plaintext(), and the overall
> structure would be the same.
> 

I'm sceptical. 

Part of the final formatting is done by the LaTex engine. For example how
are you going to translate \maketitle, the positioning of title, author,
etc... is different in package A than in package B. 

To translate \date, you will need to have a routine saying If language =
German than translate this way, if French, this other way, if English

Globally you will have to recreate in your ashtml() routines part of the
LaTeX package macros and Babel. It is a big endeavour, not to speak the
bibliographical formating engine.

What is the point ? when there is, like I have argued, the simpler way of
using both the lyx file and the pdf file.

But you are marking papers... I'm not; you are coding, I'm not ;-)

Cheers,
Charles  

Re: Some poll about elyxer

[cmiramon]

I vote also for inclusion.

== C++ or Python ==

eLyXer code is easy to understand even for hobbyist programmers like me. 
Hacking exporting is something that could be done by power users or
beginner developers. Embedding it in the C++ maze of LyX code would make it
easier for Abdel and the core developper team but harder for everybody
else.

== LyX layouts or Python ==

Having the translation pair inside the layouts looks like a nice idea but it
would, I think, limit converters to very simple one. It is easy to convert
from \emph{} to i /i but much harder for structure like tables or
crossreferences where the logic between LyX and the target language is
different. Converting from one format to another is certainly more complex
than search and replace.  

But I agree with Richard, that for custom layouts having a possibility to
add conversion information would be nice.

== Math ==

I think that perfect math translation in HTML / MathML cannnot be a
showstopper. Do you wan't really to convert a complex math document to an
HTML page ? Few browsers (basically only Firefox) can read MathML. The
client must have a good math font on his computer to render the math
symbols.

ELyXer could also use LaTeXMathML (http://math.etsu/edu/LaTeXMathML) a
javascript macro that convert on the fly LaTeX formulas to MathML code.

MathML conversion routine can be later added step by step in ELyXer. There
is nothing in the code that prevents it.

== BibTeX ==
 
BibTeX is very hard because of the many bst files, gigantic number of
options in natbib, biblatex... Most LaTeX - HTML converter have very
limited bibtex conversion, generally Plain and the style that the converter 
author is using. The only elegant solution is to extract the formatted
reference from the pdf and translate it in HTML code.

It is not impossible to do. The new synctex framework (included with the
latest pdflatex and xelatex) spits a table that maps the lines of the pdf
file and the latex file. Using the synctex information and some intelligent
text search, you can get the result in the pdf file of \cite{Blabla} and
then convert it to html code. 

Much simpler than creating in LyX code a C++ parser of bbl and aux files...
plus extra code for biblatex that does not work the same way ... plus extra
code for the ibid., op. cit. mechanisms...  

== Maintainability ===

What would be nice is to have a testing suite for elyxer. If the LyX format
change, some tests will fail and it would be easy to correct elyxer.

If LyX goes XML, we will enter in a Golden Age where miraculous XSLT will
transform water to wine, LyX XML to ODF and we will validate all the time
all our files ;-)

Cheers,
Charles

Re: Some poll about elyxer

[cmiramon]

I vote also for inclusion.

== C++ or Python ==

eLyXer code is easy to understand even for hobbyist programmers like me. 
Hacking exporting is something that could be done by power users or
beginner developers. Embedding it in the C++ maze of LyX code would make it
easier for Abdel and the core developper team but harder for everybody
else.

== LyX layouts or Python ==

Having the translation pair inside the layouts looks like a nice idea but it
would, I think, limit converters to very simple one. It is easy to convert
from \emph{} to   but much harder for structure like tables or
crossreferences where the logic between LyX and the target language is
different. Converting from one format to another is certainly more complex
than search and replace.  

But I agree with Richard, that for custom layouts having a possibility to
add conversion information would be nice.

== Math ==

I think that perfect math translation in HTML / MathML cannnot be a
showstopper. Do you wan't really to convert a complex math document to an
HTML page ? Few browsers (basically only Firefox) can read MathML. The
client must have a good math font on his computer to render the math
symbols.

ELyXer could also use LaTeXMathML (http://math.etsu/edu/LaTeXMathML) a
javascript macro that convert on the fly LaTeX formulas to MathML code.

MathML conversion routine can be later added step by step in ELyXer. There
is nothing in the code that prevents it.

== BibTeX ==
 
BibTeX is very hard because of the many bst files, gigantic number of
options in natbib, biblatex... Most LaTeX -> HTML converter have very
limited bibtex conversion, generally Plain and the style that the converter 
author is using. The only elegant solution is to extract the formatted
reference from the pdf and translate it in HTML code.

It is not impossible to do. The new synctex framework (included with the
latest pdflatex and xelatex) spits a table that maps the lines of the pdf
file and the latex file. Using the synctex information and some intelligent
text search, you can get the result in the pdf file of \cite{Blabla} and
then convert it to html code. 

Much simpler than creating in LyX code a C++ parser of bbl and aux files...
plus extra code for biblatex that does not work the same way ... plus extra
code for the ibid., op. cit. mechanisms...  

== Maintainability ===

What would be nice is to have a testing suite for elyxer. If the LyX format
change, some tests will fail and it would be easy to correct elyxer.

If LyX goes XML, we will enter in a Golden Age where miraculous XSLT will
transform water to wine, LyX XML to ODF and we will validate all the time
all our files ;-)

Cheers,
Charles

Re: Interest in using git with lyx svn

[cmiramon]

http://www.tuxfamily.org/en/main

pmwiki
git
svn
mail

but no trac and bugzilla

Cheers,
Charles

Re: Interest in using git with lyx svn

[cmiramon]

http://www.tuxfamily.org/en/main

pmwiki
git
svn
mail

but no trac and bugzilla

Cheers,
Charles

Re: menu structure

[cmiramon]

 Format. Probably at the top.
 
+1

Re: menu structure

[cmiramon]

> Format. Probably at the top.
> 
+1

Re: menu structure

[cmiramon]

John Levon wrote:

 - what the biggest problems are with the current structure

Some statistics : first figure is the number of menu items, the second
number the total menu + sub-menus + sub-sub-menus items

LyX svn blank document with a table

File : 17 ; 53
Edit : 17 ; 79
View : 19 ; 55
Insert : 26 ; 89
Navigate : 5 ; 11
Document : 6 ; 13
Tools : 6
Help : 13

Total menu + sub-menus = 319 items

OOwriter

File : 21 ; 56
Edition : 25 ; 33
View : 14 ; 38
Insert : 24 ; 56
Format : 19 ; 64
Table : 17 ; 36
Tools : 19 ; 63
Windows : 3
Help : 5

Total menu + sub-menus = 318 items

Problems :

1) The number of items is very big. Do we have any room to grow ? Oowriter
interface is a clone of the old Word interface that was considered a
nightmare of complexity. There is somewhere an interesting blog on the
Microsoft site about Office12, with different members of the Microsoft
usability team explaining the problems of the old MsWord interface.

2) Our menu tree is not well balanced we have 25 % of the items in the
Insert menu ; the biggest menus in OOwriter is around 20 % of the total. 

3) There is IMHO useless complexity, like the 7 different preview formats.
If we just drop everything except pdf with a simple parser that would run
it through dvips - ps2pdf if there is pstricks or powerdot in the preamble
we magically eliminate 13 items with no lost functionality (except for DVI
aficionados)
 
4) Mathematics is a big elephant with a gigantic bottom crushing everybody.
I don't have Mathematica, neither Maple, I don't write formulas in Fraktur.
Mathematicians should be able to turn on a mathematician module, like
chemists a chemistry module, etc... but the core of LyX should be left
generic.

5) There is some dead wood. Does Fax works anymore across platforms ?

6) The version control items are for geek. It should be done through macros
and then every geek can choose its favorite version control system. 

 - why a new structure would help

The Web is full of articles investigating how people navigate in a tree. It
shows that if the tree is balanced with not too many levels and items are
structured in a logical way, people find the good item quicker.

 - the guiding principles behind the design of the new structure

1) Recreate a balanced tree by exploding the Insert menu
2) The Edit menu had become something very strange
3) Isolation of a Math menu starts the path towards Activity menus.   

 - what each of the main HIGs have to say about both the old and new
   setup


HIG will only help us for the File, Edit maybe View and Windows menus that
are standardized. After that, it is up to us to find a good structure. 

Cheers,
Charles

Re: menu structure

[cmiramon]

John Levon wrote:

> - what the biggest problems are with the current structure

Some statistics : first figure is the number of menu items, the second
number the total menu + sub-menus + sub-sub-menus items

LyX svn blank document with a table

File : 17 ; 53
Edit : 17 ; 79
View : 19 ; 55
Insert : 26 ; 89
Navigate : 5 ; 11
Document : 6 ; 13
Tools : 6
Help : 13

Total menu + sub-menus = 319 items

OOwriter

File : 21 ; 56
Edition : 25 ; 33
View : 14 ; 38
Insert : 24 ; 56
Format : 19 ; 64
Table : 17 ; 36
Tools : 19 ; 63
Windows : 3
Help : 5

Total menu + sub-menus = 318 items

Problems :

1) The number of items is very big. Do we have any room to grow ? Oowriter
interface is a clone of the old Word interface that was considered a
nightmare of complexity. There is somewhere an interesting blog on the
Microsoft site about Office12, with different members of the Microsoft
usability team explaining the problems of the old MsWord interface.

2) Our menu tree is not well balanced we have 25 % of the items in the
Insert menu ; the biggest menus in OOwriter is around 20 % of the total. 

3) There is IMHO useless complexity, like the 7 different preview formats.
If we just drop everything except pdf with a simple parser that would run
it through dvips -> ps2pdf if there is pstricks or powerdot in the preamble
we magically eliminate 13 items with no lost functionality (except for DVI
aficionados)
 
4) Mathematics is a big elephant with a gigantic bottom crushing everybody.
I don't have Mathematica, neither Maple, I don't write formulas in Fraktur.
Mathematicians should be able to turn on a mathematician module, like
chemists a chemistry module, etc... but the core of LyX should be left
generic.

5) There is some dead wood. Does Fax works anymore across platforms ?

6) The version control items are for geek. It should be done through macros
and then every geek can choose its favorite version control system. 

> - why a new structure would help

The Web is full of articles investigating how people navigate in a tree. It
shows that if the tree is balanced with not too many levels and items are
structured in a logical way, people find the good item quicker.

> - the guiding principles behind the design of the new structure

1) Recreate a balanced tree by exploding the Insert menu
2) The Edit menu had become something very strange
3) Isolation of a Math menu starts the path towards Activity menus.   

> - what each of the main HIGs have to say about both the old and new
>   setup


HIG will only help us for the File, Edit maybe View and Windows menus that
are standardized. After that, it is up to us to find a good structure. 

Cheers,
Charles

Tex2lyx and non-ascii character in the path

[cmiramon]

Hello,

I've found tonight that tex2lyx does not seem to work if you try to convert
a file with a path with a non ascii character (here a French accent).

I'm using LyX 1.5.5. Can you confirm that it is also the case with LyX svn
and I'll file a bug.

Cheers,
Charles

Tex2lyx and non-ascii character in the path

[cmiramon]

Hello,

I've found tonight that tex2lyx does not seem to work if you try to convert
a file with a path with a non ascii character (here a French accent).

I'm using LyX 1.5.5. Can you confirm that it is also the case with LyX svn
and I'll file a bug.

Cheers,
Charles

Re: RCS usage in lyx, git

[cmiramon]

Pavel Sanda wrote:

 
 what do you think about integrating this support to lyx?
 

I think it is a great idea to add a generic RCS framework with a git plugin
for LyX. 

I have never used a RCS with LyX because there is no easy way to have a
visual diff between two versions of the same LyX file. I guess the
difficult part is to create this visual diff part. 

Cheers,
Charles

Re: RCS usage in lyx, git

[cmiramon]

Pavel Sanda wrote:

> 
> what do you think about integrating this support to lyx?
> 

I think it is a great idea to add a generic RCS framework with a git plugin
for LyX. 

I have never used a RCS with LyX because there is no easy way to have a
visual diff between two versions of the same LyX file. I guess the
difficult part is to create this visual diff part. 

Cheers,
Charles

Re: Find Next

[cmiramon]

rgheck wrote:

 
 Could someone do me a big favor implement this? I'm forever hitting F3
 and expecting it to advance me to the next search item.
 
 rh
+1... Grrr

Re: Find Next

[cmiramon]

rgheck wrote:

> 
> Could someone do me a big favor implement this? I'm forever hitting F3
> and expecting it to advance me to the next search item.
> 
> rh
+1... Grrr

Trying the full screen mode

[cmiramon]

Hello,

I've tried the new full screen mode. It is a very nice addition. Thanks
Pavel.

Some observations :
- I would keep the menu bar, and the standard toolbar (with maybe an option
to auto-hide them) 
- I would also keep the status bar (people like to have feedback, like when
they save a file)
- Typing Esc should come back to normal mode
- The width of the text in fullscreen mode should be by default around 65
characters
- There should be a 1 cm pink margin after the text and then the rest of the
screen should be gray.

Maybe in a second version we could have a special menu that combine in one
line the menu (on the left) and on the right the style combo-list.

Cheers,
Charles

Stupid question : Why there is no use of the fullscreen method of Qwidget ?
I guess the main LyX window is not a QWidget...

Trying the full screen mode

[cmiramon]

Hello,

I've tried the new full screen mode. It is a very nice addition. Thanks
Pavel.

Some observations :
- I would keep the menu bar, and the standard toolbar (with maybe an option
to auto-hide them) 
- I would also keep the status bar (people like to have feedback, like when
they save a file)
- Typing Esc should come back to normal mode
- The width of the text in fullscreen mode should be by default around 65
characters
- There should be a 1 cm pink margin after the text and then the rest of the
screen should be gray.

Maybe in a second version we could have a special menu that combine in one
line the menu (on the left) and on the right the style combo-list.

Cheers,
Charles

Stupid question : Why there is no use of the fullscreen method of Qwidget ?
I guess the main LyX window is not a QWidget...

Re: LyX for bilingual editions and literary studies

[cmiramon]

Pavel Sanda wrote:

 Hello,
 
 among others I use LyX for translation work and as I saw on users list I'm
 not the only one. There are few features which would help me a lot,
 namely:
 
 - displaying the appropriate parts of texts in parallel in some sensible
 GUI (I
   had to run two windows or boxes together now)
 - to have the possibility to typeset these texts in bilingual mode, i.e. 
 the
   corresponding parts of text facing on pages to each other with the line
   numbering aparatus around either for proofreads or for the final
   typeseting.
 
 I'd be happy to listen some feedback, whether is this extension desirable/
 acceptable for LyX.
 
 Also I have already put some code effort in both gui paths, but still not
 sure which one is the better so any additional comments to
 advantage/disadvantages below could help me to decide.
 

My opinion would be to split the different texts in different windows with
an anchor system to jump from one paragraph to the corresponding paragraph.
Something similar to the interface of the Classical Text Editor
(http://www.oeaw.ac.at/kvk/cte/tradap3e.gif). If you scroll in one windows,
the other windows scroll also to align the anchors.

If you mix the two languages in the same windows, you screw searchreplace,
for example if you want to searchreplace 'et' in the Latin version but not
in the French translation. Spell checking is also horrible. The translation
workflow is to start to enter totally the original text, then type
paragraph after paragraph your translation. It makes sense to start with
one window and then to add auxiliary windows : translation, critical
apparatus, etc...

Cheers,
Charles

Re: LyX for bilingual editions and literary studies

[cmiramon]

Pavel Sanda wrote:

> Hello,
> 
> among others I use LyX for translation work and as I saw on users list I'm
> not the only one. There are few features which would help me a lot,
> namely:
> 
> - displaying the appropriate parts of texts in parallel in some sensible
> GUI (I
>   had to run two windows or boxes together now)
> - to have the possibility to typeset these texts in bilingual mode, i.e. 
> the
>   corresponding parts of text facing on pages to each other with the line
>   numbering aparatus around either for proofreads or for the final
>   typeseting.
> 
> I'd be happy to listen some feedback, whether is this extension desirable/
> acceptable for LyX.
> 
> Also I have already put some code effort in both gui paths, but still not
> sure which one is the better so any additional comments to
> advantage/disadvantages below could help me to decide.
> 

My opinion would be to split the different texts in different windows with
an anchor system to jump from one paragraph to the corresponding paragraph.
Something similar to the interface of the Classical Text Editor
(http://www.oeaw.ac.at/kvk/cte/tradap3e.gif). If you scroll in one windows,
the other windows scroll also to align the anchors.

If you mix the two languages in the same windows, you screw search,
for example if you want to search 'et' in the Latin version but not
in the French translation. Spell checking is also horrible. The translation
workflow is to start to enter totally the original text, then type
paragraph after paragraph your translation. It makes sense to start with
one window and then to add auxiliary windows : translation, critical
apparatus, etc...

Cheers,
Charles

Re: [Request for Review] Embedding files to .lyx file.

[cmiramon]

Bo Peng wrote:


 2. This does not conflict with our XML transition because no lyx2lyx
 is needed. Actually, the use of manifest (not the ODF one though) and
 zip format makes .lyx closer to ODF.
 
It is a great idea.

Have you considered going even closer to an odt file with the mimetype, the
metadata xml file, etc ?

Cheers,
Charles

Re: [Request for Review] Embedding files to .lyx file.

[cmiramon]

Bo Peng wrote:


> 2. This does not conflict with our XML transition because no lyx2lyx
> is needed. Actually, the use of manifest (not the ODF one though) and
> zip format makes .lyx closer to ODF.
> 
It is a great idea.

Have you considered going even closer to an odt file with the mimetype, the
metadata xml file, etc ?

Cheers,
Charles

Crash with the new TOC widget

[cmiramon]

Hello,

I've compiled LyX 5.0 svn.

1) Open User Guide
2) Tools - outline
3) Document - Next cross-reference
4) Click in the Toc Widget on the second section
5) Boum with this (rather unhelpful message)

/usr/include/c++/4.1.3/debug/safe_iterator.h:130:error: attempt to copy-
construct an iterator from a singular iterator.

Objects involved in the operation:
iterator this @ 0x0xaf918fe0 {
type =
N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPKN3lyx7TocItemEN10__gnu_norm6vectorIS4_SaIS4_EN15__gnu_debug_def6vectorIS4_S9_
(constant iterator);
  state = singular;
}
iterator other @ 0x0x92abed0 {
type =
N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPKN3lyx7TocItemEN10__gnu_norm6vectorIS4_SaIS4_EN15__gnu_debug_def6vectorIS4_S9_
(constant iterator);
  state = singular;
}

Cheers,
Charles

Re: Crash with the new TOC widget

[cmiramon]

Done

#3843

Crash with the new TOC widget

[cmiramon]

Hello,

I've compiled LyX 5.0 svn.

1) Open User Guide
2) Tools -> outline
3) Document -> Next cross-reference
4) Click in the Toc Widget on the second section
5) Boum with this (rather unhelpful message)

/usr/include/c++/4.1.3/debug/safe_iterator.h:130:error: attempt to copy-
construct an iterator from a singular iterator.

Objects involved in the operation:
iterator "this" @ 0x0xaf918fe0 {
type =
N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPKN3lyx7TocItemEN10__gnu_norm6vectorIS4_SaIS4_EN15__gnu_debug_def6vectorIS4_S9_
(constant iterator);
  state = singular;
}
iterator "other" @ 0x0x92abed0 {
type =
N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPKN3lyx7TocItemEN10__gnu_norm6vectorIS4_SaIS4_EN15__gnu_debug_def6vectorIS4_S9_
(constant iterator);
  state = singular;
}

Cheers,
Charles

Re: Crash with the new TOC widget

[cmiramon]

Done

#3843

Re: French quotes

[cmiramon]

 
 Strange. I am on Ubuntu feisty so the differences with SID should be
 minimal. Can you post the latex file correponding ?
 

The file you posted compile cleanly here.

Cheers,
Charles

Re: French quotes

[cmiramon]

 
> Strange. I am on Ubuntu feisty so the differences with SID should be
> minimal. Can you post the latex file correponding ?
> 

The file you posted compile cleanly here.

Cheers,
Charles

Re: French quotes

[cmiramon]

 This is the minimal example I could find.
 
 I have just added frenchb to the document class and the
 \usepackage{babel} to the lyx generated file.
 
 %% LyX 1.5.0svn created this file.  For more info, see
 http://www.lyx.org/. %% Do not edit unless you really know what you are
 doing. \documentclass[11pt,frenchb]{article}
 \usepackage[T1]{fontenc}
 \usepackage{babel}
 \usepackage[utf8]{inputenc}
 \usepackage{geometry}

\geometry{verbose,a4paper,tmargin=2cm,bmargin=2cm,lmargin=1cm,rmargin=1.5cm,headheight=1cm,headsep=1cm,footskip=1cm}
 
 \makeatletter
 \AtBeginDocument{
   \def\labelitemi{\normalfont\bfseries{--}}
   \def\labelitemii{\(\bullet\)}
 }
 
 \makeatother
 \begin{document}
 \og test \fg{}
 \end{document}
 
 Regards,
 
 Alain

I get normal French quotes here with Debian Sid, TeXLive and a relatively
recent LyX 1.5 svn.

Cheers,
Charles

Re: French quotes

[cmiramon]

> This is the minimal example I could find.
> 
> I have just added frenchb to the document class and the
> \usepackage{babel} to the lyx generated file.
> 
> %% LyX 1.5.0svn created this file.  For more info, see
> http://www.lyx.org/. %% Do not edit unless you really know what you are
> doing. \documentclass[11pt,frenchb]{article}
> \usepackage[T1]{fontenc}
> \usepackage{babel}
> \usepackage[utf8]{inputenc}
> \usepackage{geometry}
>
\geometry{verbose,a4paper,tmargin=2cm,bmargin=2cm,lmargin=1cm,rmargin=1.5cm,headheight=1cm,headsep=1cm,footskip=1cm}
> 
> \makeatletter
> \AtBeginDocument{
>   \def\labelitemi{\normalfont\bfseries{--}}
>   \def\labelitemii{\(\bullet\)}
> }
> 
> \makeatother
> \begin{document}
> \og test \fg{}
> \end{document}
> 
> Regards,
> 
> Alain

I get normal French quotes here with Debian Sid, TeXLive and a relatively
recent LyX 1.5 svn.

Cheers,
Charles

No shortcut for the close button

[cmiramon]

Hello,

While everybody is working on the Qt Dialogs, I've spotted that in LyX 1.4
and 1.5 there is no shortcut (Alt-C) for the Close button while if you open
the ui file in Qt Designer it is there.

I've grepped the code and cannot find anything related to redefining
shortcuts.

Strange,
Charles

Re: No shortcut for the close button

[cmiramon]

Jean-Marc Lasgouttes wrote:

 cmiramon == cmiramon 
 [EMAIL PROTECTED] writes:
 
 cmiramon Hello, While everybody is working on the Qt Dialogs, I've
 cmiramon spotted that in LyX 1.4 and 1.5 there is no shortcut (Alt-C)
 cmiramon for the Close button while if you open the ui file in Qt
 cmiramon Designer it is there.
 
 cmiramon I've grepped the code and cannot find anything related to
 cmiramon redefining shortcuts.
 
 It is probably in the button controller. I think the lack of shortcut
 is by design, since there is already the Esc shortcut. Blocking Alt+C
 for this use is a bit strange. What does KDE do?
 
 JMarc

KDE uses Alt-C for the closing button, mapped to Alt-F in the French
translation, Gnome has also a shortcut for the close button. LyX is
peculiar here.  

See the text on KDE HIG wiki :
http://wiki.openusability.org/guidelines/index.php/Design_and_Layout:Controls:Shortcuts

For the layout of Dialogs :
http://wiki.openusability.org/guidelines/index.php/Design_and_Layout:Layout:Dialogs

Cheers,
Charles

No shortcut for the close button

[cmiramon]

Hello,

While everybody is working on the Qt Dialogs, I've spotted that in LyX 1.4
and 1.5 there is no shortcut (Alt-C) for the Close button while if you open
the ui file in Qt Designer it is there.

I've grepped the code and cannot find anything related to redefining
shortcuts.

Strange,
Charles

Re: No shortcut for the close button

[cmiramon]

Jean-Marc Lasgouttes wrote:

>>>>>> "cmiramon" == cmiramon 
>>>>>> <[EMAIL PROTECTED]> writes:
> 
> cmiramon> Hello, While everybody is working on the Qt Dialogs, I've
> cmiramon> spotted that in LyX 1.4 and 1.5 there is no shortcut (Alt-C)
> cmiramon> for the Close button while if you open the ui file in Qt
> cmiramon> Designer it is there.
> 
> cmiramon> I've grepped the code and cannot find anything related to
> cmiramon> redefining shortcuts.
> 
> It is probably in the button controller. I think the lack of shortcut
> is by design, since there is already the Esc shortcut. Blocking Alt+C
> for this use is a bit strange. What does KDE do?
> 
> JMarc

KDE uses Alt-C for the closing button, mapped to Alt-F in the French
translation, Gnome has also a shortcut for the close button. LyX is
peculiar here.  

See the text on KDE HIG wiki :
http://wiki.openusability.org/guidelines/index.php/Design_and_Layout:Controls:Shortcuts

For the layout of Dialogs :
http://wiki.openusability.org/guidelines/index.php/Design_and_Layout:Layout:Dialogs

Cheers,
Charles

Re: [BUG] Frustration with LyX

[cmiramon]

Timothy Reaves wrote:

 There are several classes in the preferences, and I'm sure several
 'features' no one will be able to use unless these third-party files are
 added.  A lot of users that would otherwise use LyX won't; they'll give
 it a try, see something they want to use (the DocBook classes for
 example), try them, and get an error.  They go back to what ever
 application they have been using.

Under Linux, you can add all the LaTeX packages in the dependencies of the
LyX package. Your problem is solved if LyX is correctly packaged by your
distribution.

Cheers,
Charles

Re: [BUG] Frustration with LyX

[cmiramon]

Timothy Reaves wrote:

>> There are several classes in the preferences, and I'm sure several
>> 'features' no one will be able to use unless these third-party files are
>> added.  A lot of users that would otherwise use LyX won't; they'll give
>> it a try, see something they want to use (the DocBook classes for
>> example), try them, and get an error.  They go back to what ever
>> application they have been using.

Under Linux, you can add all the LaTeX packages in the dependencies of the
LyX package. Your problem is solved if LyX is correctly packaged by your
distribution.

Cheers,
Charles

Re: Thought about the file format

[cmiramon]

Andre Poenitz wrote:

 
 Think privacy.
 
 Now try again.
 

You have all this metainformation fields in a pdf file. It is rather
uninformative now then when you create a pdf file from LyX the creator
field in the pdf file is 'TeX 


Metadata repository and search possibilities like Nepomuk are coming on the
Linux Desktop. I think it will be important that LyX files can be easily
indexed in these new systems. Therefore, we should add metadata fields. For
privacy obsessed people maybe we can add an option to include dummy values
for metadata.

Cheers,
Charles 

Re: Thought about the file format

[cmiramon]

Andre Poenitz wrote:

> 
> Think privacy.
> 
> Now try again.
> 

You have all this metainformation fields in a pdf file. It is rather
uninformative now then when you create a pdf file from LyX the creator
field in the pdf file is 'TeX 


Metadata repository and search possibilities like Nepomuk are coming on the
Linux Desktop. I think it will be important that LyX files can be easily
indexed in these new systems. Therefore, we should add metadata fields. For
privacy obsessed people maybe we can add an option to include dummy values
for metadata.

Cheers,
Charles 

Re: Looking for a stable branch maintainer

[cmiramon]

Peter Kümmel wrote:


 
 I don't know what's the best way to go, but we could start a new
 endless discussion. (Have you registered that there wasn't such a
 beast within the last months? There was more coding than
 discussing. LyX is changing.)

Maybe have a schedule like KDE. You have a wiki page with 
- a deadline to register a new feature idea
- a deadline to start coding the feature
- a deadline to finish coding 

That works more or less. Works like a scientific conference : Call for
papers, send the summary, send the paper. 

People have a clearer view of the time left and get less bitter if they miss
the deadline. 

Cheers,
Charles

Re: Looking for a stable branch maintainer

[cmiramon]

Peter Kümmel wrote:


> 
> I don't know what's the best way to go, but we could start a new
> endless discussion. (Have you registered that there wasn't such a
> beast within the last months? There was more coding than
> discussing. LyX is changing.)

Maybe have a schedule like KDE. You have a wiki page with 
- a deadline to register a new feature idea
- a deadline to start coding the feature
- a deadline to finish coding 

That works more or less. Works like a scientific conference : Call for
papers, send the summary, send the paper. 

People have a clearer view of the time left and get less bitter if they miss
the deadline. 

Cheers,
Charles

Re: KCachegrind and LyX

[cmiramon]

Jean-Marc Lasgouttes wrote:


 The few times I tried cachegrind, it was making lyx so slow that any
 testing concerning the GUI was too difficult to do. How do KDE people
 do it? Is there some documentation somewhere?
 
 It seems to me that oprofile is much faster.
 

It is slow but it works. Maybe running lyx with special unit tests files
would be interesting.

I have compiled yesterday svn lyx and ran it through cachegrind (start lyx,
load tutorial, page down twice exit).

You will find here :

http://lyxondebian.free.fr/cachegrind/

a snapshot of kcachegrind and a the cachegrind output that you can load in
kcachegrind to play with it.

Cheers,
Charles

Re: KCachegrind and LyX

[cmiramon]

Jean-Marc Lasgouttes wrote:


> The few times I tried cachegrind, it was making lyx so slow that any
> testing concerning the GUI was too difficult to do. How do KDE people
> do it? Is there some documentation somewhere?
> 
> It seems to me that oprofile is much faster.
> 

It is slow but it works. Maybe running lyx with special unit tests files
would be interesting.

I have compiled yesterday svn lyx and ran it through cachegrind (start lyx,
load tutorial, page down twice exit).

You will find here :

http://lyxondebian.free.fr/cachegrind/

a snapshot of kcachegrind and a the cachegrind output that you can load in
kcachegrind to play with it.

Cheers,
Charles

KCachegrind and LyX

[cmiramon]

Hello,

I'm reading arguments to and fro about the fastness of the new Qt4 frontend. 

Just a question. Has someone tried Valgrind / Cachegrind / KCachegrind on
the Qt4 frontend and the last working Qt3 frontend after the unicode
transition, and a 1.4 version ?

At least, it would give more scientific data where (Qt4, Unicode) LyX has
lost and gained some speed lately.

For KDE, the use of these tools have given good (optimization) results.

Cheers,
Charles 

KCachegrind and LyX

[cmiramon]

Hello,

I'm reading arguments to and fro about the fastness of the new Qt4 frontend. 

Just a question. Has someone tried Valgrind / Cachegrind / KCachegrind on
the Qt4 frontend and the last working Qt3 frontend after the unicode
transition, and a 1.4 version ?

At least, it would give more scientific data where (Qt4, Unicode) LyX has
lost and gained some speed lately.

For KDE, the use of these tools have given good (optimization) results.

Cheers,
Charles 

Re: Compiling LyX 1.5 with scons

[cmiramon]

Hello,

I'm making progress :

- installing libqt4-debug and libqt4-dev-debug
- Running update-alternatives --config moc and update-alternatives --config
uic to point to qt4 version
- changing QTDIR to /usr/share/qt4 (don't know if its necessary)

I'm able to compile lyx-qt4

But when I execute it, it crashes with this message :


[EMAIL PROTECTED]:/usr/local/src/lyx-cvs/lyx-devel/development/scons/debug$ 
./lyx-qt4
Same as entered returned
terminate called after throwing an instance of 'std::bad_cast'
  what():  St8bad_cast
Abandon

I'm again clueless...

Cheers,
Charles

Re: Compiling LyX 1.5 with scons

[cmiramon]

Hello,

I have the same error executing LyX after applying Peter's patch and trying
Georg's workaround.

Trying to go the autotools way leads to an error in the ld phase :

g++ -g -O -o lyx-qt4 main.o Bidi.o BufferView.o BufferView_pimpl.o Bullet.o
BranchList.o Chktex.o Color.o CutAndPaste.
o DepTable.o FloatList.o Floating.o FontIterator.o FuncStatus.o InsetList.o
LColor.o LaTeX.o LaTeXFeatures.o LyXAction
.o MenuBackend.o ParagraphParameters.o PrinterParams.o Spacing.o Thesaurus.o
ToolbarBackend.o author.o boost.o box.o b
uffer.o buffer_funcs.o bufferlist.o bufferparams.o bufferview_funcs.o
changes.o chset.o converter.o counters.o coordca
che.o cursor.o cursor_slice.o debug.o dimension.o dociterator.o encoding.o
errorlist.o exporter.o gettext.o factory.o
format.o funcrequest.o graph.o importer.o intl.o insetiterator.o kbmap.o
kbsequence.o language.o session.o lengthcommo
n.o lyx_cb.o lyx_main.o lyx_sty.o lyxfont.o lyxfind.o lyxfunc.o
lyxgluelength.o lyxlayout.o lyxlength.o lyxlex.o lyxle
x_pimpl.o lyxrc.o lyxrow.o lyxrow_funcs.o lyxserver.o lyxsocket.o
lyxtextclass.o lyxtextclasslist.o lyxvc.o messages.o
 metricsinfo.o mover.o output.o outputparams.o output_docbook.o
output_latex.o output_plaintext.o paragraph.o paragrap 
h_funcs.o paragraph_pimpl.o pariterator.o ispell.o SpellBase.o rowpainter.o
sgml.o tabular.o tex-accent.o tex-strings.o texrow.o text.o text2.o text3.o
TocBackend.o toc.o trans.o trans_mgr.o undo.o vc-backend.o version.o
vspace.o  -L/usr/lib/qt4 mathed/.libs/libmathed.a insets/.libs/libinsets.a
frontends/.libs/libfrontends.a frontends/qt4/.libs/libqt4. 
a -L/home/sesse/nmu/qt4-x11-4.1.4/lib -L/usr/X11R6/lib -lQtGui -laudio -lXt 
-lpng -lQtCore -lpthread -lXi -lXrender -l 
Xrandr -lXcursor -lXinerama /usr/lib/libfreetype.so -lfontconfig -lXext -ldl
frontends/controllers/.libs/libcontrollers.a graphics/.libs/libgraphics.a
support/.libs/libsupport.a ../boost/libs/regex/src/.libs/libboost_regex.a 
../boost/li 
bs/signals/src/.libs/libboost_signals.a 
../boost/libs/filesystem/src/.libs/libboost_filesystem.a ../boost/libs/iostrea  
   
ms/src/.libs/libboost_iostreams.a /usr/lib/libAiksaurus.so -lSM -lICE -lc -lm 
-lX11 -lz

insets/.libs/libinsets.a(insetwrap.o): In function
`__gnu_cxx::new_allocatorCursorSlice::deallocate(CursorSlice*, un 

signed int)':
/usr/local/src/lyx-cvs/lyx-devel/src/insets/insetwrap.C:49: multiple
definition of `(anonymous namespace)::floatname(s 
td::basic_stringchar, std::char_traitschar, std::allocatorchar 
const, BufferParams const)'
insets/.libs/libinsets.a(insetfloat.o):/usr/local/src/lyx-cvs/lyx-devel/src/insets/insetfloat.C:119:
first defined here
/usr/bin/ld: Warning: size of symbol `(anonymous
namespace)::floatname(std::basic_stringchar, std::char_traitschar,   
   
std::allocatorchar  const, BufferParams const)' changed from 2850 in
insets/.libs/libinsets.a(insetfloat.o) to 3717 in
insets/.libs/libinsets.a(insetwrap.o)
collect2: ld returned 1 exit status

Re: Compiling LyX 1.5 with scons

[cmiramon]

Hello,

I'm making progress :

- installing libqt4-debug and libqt4-dev-debug
- Running update-alternatives --config moc and update-alternatives --config
uic to point to qt4 version
- changing QTDIR to /usr/share/qt4 (don't know if its necessary)

I'm able to compile lyx-qt4

But when I execute it, it crashes with this message :


[EMAIL PROTECTED]:/usr/local/src/lyx-cvs/lyx-devel/development/scons/debug$ 
./lyx-qt4
Same as entered returned
terminate called after throwing an instance of 'std::bad_cast'
  what():  St8bad_cast
Abandon

I'm again clueless...

Cheers,
Charles

Re: Compiling LyX 1.5 with scons

[cmiramon]

Hello,

I have the same error executing LyX after applying Peter's patch and trying
Georg's workaround.

Trying to go the autotools way leads to an error in the ld phase :

g++ -g -O -o lyx-qt4 main.o Bidi.o BufferView.o BufferView_pimpl.o Bullet.o
BranchList.o Chktex.o Color.o CutAndPaste.
o DepTable.o FloatList.o Floating.o FontIterator.o FuncStatus.o InsetList.o
LColor.o LaTeX.o LaTeXFeatures.o LyXAction
.o MenuBackend.o ParagraphParameters.o PrinterParams.o Spacing.o Thesaurus.o
ToolbarBackend.o author.o boost.o box.o b
uffer.o buffer_funcs.o bufferlist.o bufferparams.o bufferview_funcs.o
changes.o chset.o converter.o counters.o coordca
che.o cursor.o cursor_slice.o debug.o dimension.o dociterator.o encoding.o
errorlist.o exporter.o gettext.o factory.o
format.o funcrequest.o graph.o importer.o intl.o insetiterator.o kbmap.o
kbsequence.o language.o session.o lengthcommo
n.o lyx_cb.o lyx_main.o lyx_sty.o lyxfont.o lyxfind.o lyxfunc.o
lyxgluelength.o lyxlayout.o lyxlength.o lyxlex.o lyxle
x_pimpl.o lyxrc.o lyxrow.o lyxrow_funcs.o lyxserver.o lyxsocket.o
lyxtextclass.o lyxtextclasslist.o lyxvc.o messages.o
 metricsinfo.o mover.o output.o outputparams.o output_docbook.o
output_latex.o output_plaintext.o paragraph.o paragrap 
h_funcs.o paragraph_pimpl.o pariterator.o ispell.o SpellBase.o rowpainter.o
sgml.o tabular.o tex-accent.o tex-strings.o texrow.o text.o text2.o text3.o
TocBackend.o toc.o trans.o trans_mgr.o undo.o vc-backend.o version.o
vspace.o  -L/usr/lib/qt4 mathed/.libs/libmathed.a insets/.libs/libinsets.a
frontends/.libs/libfrontends.a frontends/qt4/.libs/libqt4. 
a -L/home/sesse/nmu/qt4-x11-4.1.4/lib -L/usr/X11R6/lib -lQtGui -laudio -lXt 
-lpng -lQtCore -lpthread -lXi -lXrender -l 
Xrandr -lXcursor -lXinerama /usr/lib/libfreetype.so -lfontconfig -lXext -ldl
frontends/controllers/.libs/libcontrollers.a graphics/.libs/libgraphics.a
support/.libs/libsupport.a ../boost/libs/regex/src/.libs/libboost_regex.a 
../boost/li 
bs/signals/src/.libs/libboost_signals.a 
../boost/libs/filesystem/src/.libs/libboost_filesystem.a ../boost/libs/iostrea  
   
ms/src/.libs/libboost_iostreams.a /usr/lib/libAiksaurus.so -lSM -lICE -lc -lm 
-lX11 -lz

insets/.libs/libinsets.a(insetwrap.o): In function
`__gnu_cxx::new_allocator::deallocate(CursorSlice*, un 

signed int)':
/usr/local/src/lyx-cvs/lyx-devel/src/insets/insetwrap.C:49: multiple
definition of `(anonymous namespace)::floatname(s 
td::basic_string
const&, BufferParams const&)'
insets/.libs/libinsets.a(insetfloat.o):/usr/local/src/lyx-cvs/lyx-devel/src/insets/insetfloat.C:119:
first defined here
/usr/bin/ld: Warning: size of symbol `(anonymous
namespace)::floatname(std::basic_string const&, BufferParams const&)' changed from 2850 in
insets/.libs/libinsets.a(insetfloat.o) to 3717 in
insets/.libs/libinsets.a(insetwrap.o)
collect2: ld returned 1 exit status

Re: Compiling LyX 1.5 with scons

[cmiramon]

With your patch, it compiles but stops with the qt4 frontend :
scons frontend=qt4 qt_dir=/usr/share/qt4 qt_lib_path=/usr/lib/qt4 -j3 lyx   


g++ -o
debug/common/frontends/qt4/Action.o -c -g -O -DHAVE_CONFIG_H 
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_GUI_LIB 
-Idebug/common -I/usr/local/src/lyx-cvs/lyx-devel/src 
-I/usr/local/src/lyx-cvs/lyx-devel/src -I/usr/local/src/lyx-cvs/lyx-devel/boost 
-Idebug/intl -I/usr/local/src/lyx-cvs/lyx-devel/intl -I/usr/share/qt4/include 
-Idebug/common/images -I/usr/local/src/lyx-cvs/lyx-devel/src/images 
-Idebug/common/frontends -I/usr/local/src/lyx-cvs/lyx-devel/src/frontends 
-Idebug/common/frontends/qt4 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4 
-Idebug/common/frontends/controllers 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/controllers -I/usr/include/qt4 
/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4/Action.C
g++ -o
debug/common/frontends/qt4/Alert_pimpl.o -c -g -O -DHAVE_CONFIG_H 
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_GUI_LIB 
-Idebug/common -I/usr/local/src/lyx-cvs/lyx-devel/src 
-I/usr/local/src/lyx-cvs/lyx-devel/src -I/usr/local/src/lyx-cvs/lyx-devel/boost 
-Idebug/intl -I/usr/local/src/lyx-cvs/lyx-devel/intl -I/usr/share/qt4/include 
-Idebug/common/images -I/usr/local/src/lyx-cvs/lyx-devel/src/images 
-Idebug/common/frontends -I/usr/local/src/lyx-cvs/lyx-devel/src/frontends 
-Idebug/common/frontends/qt4 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4 
-Idebug/common/frontends/controllers 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/controllers -I/usr/include/qt4 
/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4/Alert_pimpl.C
g++ -o
debug/common/frontends/qt4/Application.o -c -g -O -DHAVE_CONFIG_H 
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_GUI_LIB 
-Idebug/common -I/usr/local/src/lyx-cvs/lyx-devel/src 
-I/usr/local/src/lyx-cvs/lyx-devel/src -I/usr/local/src/lyx-cvs/lyx-devel/boost 
-Idebug/intl -I/usr/local/src/lyx-cvs/lyx-devel/intl -I/usr/share/qt4/include 
-Idebug/common/images -I/usr/local/src/lyx-cvs/lyx-devel/src/images 
-Idebug/common/frontends -I/usr/local/src/lyx-cvs/lyx-devel/src/frontends 
-Idebug/common/frontends/qt4 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4 
-Idebug/common/frontends/controllers 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/controllers -I/usr/include/qt4 
/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4/Application.C
In file included
from /usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4/Action.C:13:

I'm wondering if it does not pick the wrong moc. On Debian, moc is called
moc-qt4

Cheers,
Charles

Re: Compiling LyX 1.5 with scons

[cmiramon]

With your patch, it compiles but stops with the qt4 frontend :
scons frontend=qt4 qt_dir=/usr/share/qt4 qt_lib_path=/usr/lib/qt4 -j3 lyx   


g++ -o
debug/common/frontends/qt4/Action.o -c -g -O -DHAVE_CONFIG_H 
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_GUI_LIB 
-Idebug/common -I/usr/local/src/lyx-cvs/lyx-devel/src 
-I/usr/local/src/lyx-cvs/lyx-devel/src -I/usr/local/src/lyx-cvs/lyx-devel/boost 
-Idebug/intl -I/usr/local/src/lyx-cvs/lyx-devel/intl -I/usr/share/qt4/include 
-Idebug/common/images -I/usr/local/src/lyx-cvs/lyx-devel/src/images 
-Idebug/common/frontends -I/usr/local/src/lyx-cvs/lyx-devel/src/frontends 
-Idebug/common/frontends/qt4 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4 
-Idebug/common/frontends/controllers 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/controllers -I/usr/include/qt4 
/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4/Action.C
g++ -o
debug/common/frontends/qt4/Alert_pimpl.o -c -g -O -DHAVE_CONFIG_H 
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_GUI_LIB 
-Idebug/common -I/usr/local/src/lyx-cvs/lyx-devel/src 
-I/usr/local/src/lyx-cvs/lyx-devel/src -I/usr/local/src/lyx-cvs/lyx-devel/boost 
-Idebug/intl -I/usr/local/src/lyx-cvs/lyx-devel/intl -I/usr/share/qt4/include 
-Idebug/common/images -I/usr/local/src/lyx-cvs/lyx-devel/src/images 
-Idebug/common/frontends -I/usr/local/src/lyx-cvs/lyx-devel/src/frontends 
-Idebug/common/frontends/qt4 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4 
-Idebug/common/frontends/controllers 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/controllers -I/usr/include/qt4 
/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4/Alert_pimpl.C
g++ -o
debug/common/frontends/qt4/Application.o -c -g -O -DHAVE_CONFIG_H 
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_GUI_LIB 
-Idebug/common -I/usr/local/src/lyx-cvs/lyx-devel/src 
-I/usr/local/src/lyx-cvs/lyx-devel/src -I/usr/local/src/lyx-cvs/lyx-devel/boost 
-Idebug/intl -I/usr/local/src/lyx-cvs/lyx-devel/intl -I/usr/share/qt4/include 
-Idebug/common/images -I/usr/local/src/lyx-cvs/lyx-devel/src/images 
-Idebug/common/frontends -I/usr/local/src/lyx-cvs/lyx-devel/src/frontends 
-Idebug/common/frontends/qt4 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4 
-Idebug/common/frontends/controllers 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/controllers -I/usr/include/qt4 
/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4/Application.C
In file included
from /usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4/Action.C:13:

I'm wondering if it does not pick the wrong moc. On Debian, moc is called
moc-qt4

Cheers,
Charles

Re: Thanks for lyx developers and users

[cmiramon]

Jose' Matos wrote:
 I have today officially delivered my thesis. It

Congratulations. Finishing a thesis is like lifting a heavy weight from your
stomach.

Cheers,
Charles

Re: Thanks for lyx developers and users

[cmiramon]

Jose' Matos wrote:
> I have today officially delivered my thesis. It

Congratulations. Finishing a thesis is like lifting a heavy weight from your
stomach.

Cheers,
Charles