Re: [patch] Re: \textvisiblespace

[Stephan Witt]

Am 19.07.2011 um 01:05 schrieb Uwe Stöhr:

 Am 19.07.2011 00:05, schrieb Jean-Marc Lasgouttes:
 
 Le 15/07/11 22:30, Uwe Stöhr a écrit :
 I don't agree that implementing it as part of the space inset is a good
 idea. \textvisiblespace is not a space in the sense of the meaning but a
 special character. It does not create a space, but a character. I would
 therefore like to implement this as special character like an ellipsis.

...

 + case VISIBLE_SPACE:
 + os  \\textvisiblespace{};
 + break;
 
 For LaTeX output, can't we just output the unicode character and let our 
 stream sort out the right
 output? We may want unicode to output natively (maybe also for other special 
 characters, actually).
 
 I can do this, but what is the benefit? I know users looking at the LyX file 
 directly with a text editor, and on Windows they would only see a square.
 
 + case VISIBLE_SPACE:
 + os  |_|;
 + return 3;
 
 I do not think it makes much sense to use this ascii-art output here. I 
 would use a plain space or
 an underscore. Or even the unicode character, since we output to utf8 (Hmmm, 
 do we?)
 
 The problem is that when you use the Unicode character and the user open the 
 result e.g. in Windows standard editor Notepad he sees a black square 
 instead because the Windows standard fonts (Arial, times new Roman, etc.) 
 don't have a representation for this character (at least here on my XP).

Sorry, I cannot resist... Notepad is not an editor. It's an excuse for not 
having one.
Every time I have to view a file on stock windows I get an attack of windows 
hate.
It's the same with the never ending newline story.
One should at least use Wordpad instead.

Stephan

Re: [patch] Re: \textvisiblespace

[Jürgen Spitzmüller]

Uwe Stöhr wrote:
  I still think it is wrong, but I am not going to fight forever on that
  (what is there a space in foo bar and not foo_bar???).
 
 The internal behaviour of a space and a character is different. LaTeX can
 change the width of spaces  to e.g. fit a line into the column margins.

That's not true for all spaces. Non-break spaces are of fixed width as well. 
And so is \thinspace.

 Spaces are something completely different than characters.
 \textvisiblespace is nothing more than a character built out of 3 strokes.
 Many fonts not even have a real glyph for it. This character only
 represents a space, but technically it is nothing else like any other
 character. So you could also simply use _ to visualize a space in e.g. a
 code. 

And this is exactly why it makes sense. It's a possibility to represent a 
space. Why shouldn't InsetSpace allow for that possibility?

The discussion about glyph classification (technical symbol vs. space) is 
completely irrelevant for most users. They might just want to make a space 
visible, and that's what \textvisible space is useful for.

Jürgen

Re: SV: Towards RC4/final release

[Jürgen Spitzmüller]

Uwe Stöhr wrote:
  There is the ideal, and there is what we have. The ideal way would be
  to ensure that the extra paragraph types for running headers appear if
  and only if page layout fancy is checked. Currently, that can't be
  done with modules.  But at least we have the running headers now, which
  is nice.
 
 Well spoken. We were aware of that issue but what we have now is much better
 than before and the  header/footer issue came up very often in the user
 mailing list.

The problem is that we begin to weaken the module concept. I fear we end up 
with modules being a wastebin category, where we put everything we are to 
lazy to develop a decent GUI for.

That would be a pity, since the module concept is very valuable in itself.

Jürgen

Re: build error with trunk on openSUSE

[Cor Blom]

Op dinsdag 19 juli 2011 00:06:55 schreef Jean-Marc Lasgouttes:
 Le 18/07/11 23:58, Cor Blom a écrit :
  Adding bc to BuildRequires solved the problem. Thanks for the help.
 
 Interesting, but what does bc stand for?
 

bc: GNU Command Line Calculator

After your last remark I looked again through the log and noticed that the 
shell complained that bc could not be found. This complaint was not there in 
the buildlog for branch, so I added it as a requirement.

On my system (i.e. my desktop system, not the buildservice) bc is installed by 
default and has a manpage.

Cor

I am moving to Switzerland

[Abdelrazak Younes]

Hi there,

I see that there's a lot of request to help for me in Trac; I would be 
very happy to but I am very busy these days...
I am starting a new job in August in Switzerland and I am preparing my 
moving to there with the family. So don't expect much from me in the 
coming weeks.


Cheers,
Abdel.

Re: Missing features in Flex insets and style definition question

[Jean-Marc Lasgouttes]

Le 19/07/2011 03:21, Uwe Stöhr a écrit :

This doesn't help, because in some cases you need the feature that LyX
does not add nothing, no par break and also no newline but to continue
with the code right after the command.


Looks like a very badly coded macro, then. It might be easier to fix the 
problem there.



Richard is right that InsetLayout
is designed for this, but this is only usable if InsetLayout supports
also arguments. It is not yet clear to me why this is not supported. I'm
not familiar with the layout code but I assumed that it should not be
very hard to implement. Would at least be a very valuable feature for
LyX 2.1.


Yes, it should be done eventually, and it is not very difficult. 
However, I think it would be better to factor in the two cases, rather 
then duplicating code (with subtly different bugs :)


JMarc

Re: changeset/39333

[Jean-Marc Lasgouttes]

Le 19/07/2011 03:34, Uwe Stöhr a écrit :

Great news!
However, can we please for the future use usernames that are
self-explanatory? I mean when I read sanda I know that it is you,
reading cmd is quite meaningless.


It is the privilege of the new developer to pick a user name. cmd is not 
weirder than gmatht, after all :)


JMarc

Re: [PATCH] Cleaner windows title

[Jean-Marc Lasgouttes]

Le 19/07/2011 05:54, BH a écrit :

Works well for me -- I use the title bar icon all the time (which can
also be used to reveal the complete path to the file and navigate to
any folder in the path).


Unfortunately, I cannot have only this part, since Qt does not do the 
icon thing if I set the windows title by hand. So we need a home for 
version control and read only.


JMarc

Re: build error with trunk on openSUSE

[Pavel Sanda]

Cor Blom wrote:
 bc: GNU Command Line Calculator
 
 After your last remark I looked again through the log and noticed that the 
 shell complained that bc could not be found. This complaint was not there 
 in 
 the buildlog for branch, so I added it as a requirement.

please can you paste the relevant part of log? i have hard time to understand 
why we need bc.

pavel

Re: changeset/39333

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 Le 19/07/2011 03:34, Uwe Stöhr a écrit :
 Great news!
 However, can we please for the future use usernames that are
 self-explanatory? I mean when I read sanda I know that it is you,
 reading cmd is quite meaningless.

 It is the privilege of the new developer to pick a user name. cmd is not 
 weirder than gmatht, after all :)

nobody asked me !?@$%!~ ;p

Re: build error with trunk on openSUSE

[Stephan Witt]

Am 19.07.2011 um 10:47 schrieb Pavel Sanda:

 Cor Blom wrote:
 bc: GNU Command Line Calculator
 
 After your last remark I looked again through the log and noticed that the 
 shell complained that bc could not be found. This complaint was not there 
 in 
 the buildlog for branch, so I added it as a requirement.
 
 please can you paste the relevant part of log? i have hard time to understand 
 why we need bc.

I think because of the conversion of the Qt version number from e.g. hex 4.6.3 
to decimal value.
Unfortunately, this has to be passed to moc explicitly.
Perhaps this can be solved in some other way...

Stephan

Re: [patch] Re: \textvisiblespace

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 Attached is a patch that does this.

 The advantage is that we avoid confusions. If we would implement it as
 InsetSpace, it is hard for the user to distinguish it within LyX from
 the other spaces.

 Just output it in black instead of blue.

this is already implemented in my 2nd patch and works fine.

 + case VISIBLE_SPACE:
 + os  |_|;
 + return 3;

 I do not think it makes much sense to use this ascii-art output here. I 
 would use a plain space or an underscore. Or even the unicode character, 
 since we output to utf8 (Hmmm, do we?)

not tested but iirc i saw some complaint that we dont use utf8 as an
output. anyway we should use just plain ' '. using |_| is just crazy
when you understand it can be part of C++ code output ;)

i didnt checked carefully, but isn't this patch missing fileformat bump?
pavel

Re: [patch] Re: \textvisiblespace

[Pavel Sanda]

Jürgen Spitzmüller wrote:
 And this is exactly why it makes sense. It's a possibility to represent a 
 space. Why shouldn't InsetSpace allow for that possibility?
 
 The discussion about glyph classification (technical symbol vs. space) is 
 completely irrelevant for most users. They might just want to make a space 
 visible, and that's what \textvisible space is useful for.

the border of technical symbol vs. space is fuzzy to me and i don't
have hard opinion to dicuss it.

but to sum up as the time passed we have 3 patches:
1. special symbol - simple unicode char
2. part of insetspace
3. special symbol - specific drawing

if my counting is right than
1 - Guenter
2 - Juergen, JMarc
3 - Uwe

correct?

my vote can go to any solution which also have change tracking painting
correct. i didn't tested it for all solutions yet (busy atm), but it was
the real cause why i started the whole thread.

don't need space in the code block (we have listings after all - they already
know this) but need to typeset and see colorized(corrected) whitespace typos in
the proofread of book, so CT is the critical point for me.

pavel

Re: [patch] Re: \textvisiblespace

[Jürgen Spitzmüller]

Pavel Sanda wrote:
 the border of technical symbol vs. space is fuzzy to me and i don't
 have hard opinion to dicuss it.
 
 but to sum up as the time passed we have 3 patches:
 1. special symbol - simple unicode char
 2. part of insetspace
 3. special symbol - specific drawing
 
 if my counting is right than
 1 - Guenter
 2 - Juergen, JMarc
 3 - Uwe
 
 correct?

My vote is to both integrate it to InsetSpace and to support it via 
unicodesymbols (if not already the case). Both approaches have different uses, 
and as already pointed out in an earlier mail to this thread, we cover many 
glyphs via unicodesymbols that are also available via specific insets or 
otherwise (think NO_BREAK_SPACE, think ENDASH, f.ex.).

Jürgen

Re: about the initials module

[Pavel Sanda]

Uwe Stöhr wrote:
 Hi Pavel,

 in the page http://wiki.lyx.org/LyX/NewInLyX20 there was the icon that the 
 initial module is documented. Where is it, I cannot find it?

i put the tickmark of documented feature when the module description inside 
settings
dialog is enough to grab all information needed. 

as sidecomment i dont think that adding specific features which pull extra
packages into our manuals is a healthy thing. they are not compilable on
various situations then and produce strange errors like when we added mchem
notion into math manual and instant preview stop to work or even compile
for some users.

i will review your current changes soon.
pavel

Re: [patch] Re: \textvisiblespace

[Jean-Marc Lasgouttes]

Le 19/07/2011 08:41, Jürgen Spitzmüller a écrit :

That's not true for all spaces. Non-break spaces are of fixed width as well.
And so is \thinspace.

[...]


And this is exactly why it makes sense. It's a possibility to represent a
space. Why shouldn't InsetSpace allow for that possibility?

The discussion about glyph classification (technical symbol vs. space) is
completely irrelevant for most users. They might just want to make a space
visible, and that's what \textvisible space is useful for.


Even better than AI: Jürgen Spitzmüller! You write my message even 
before I have begun to formulate it properly in my head. That's great.


JMarc

Re: about the initials module

[Jean-Marc Lasgouttes]

Le 19/07/2011 11:55, Pavel Sanda a écrit :

as sidecomment i dont think that adding specific features which pull extra
packages into our manuals is a healthy thing. they are not compilable on
various situations then and produce strange errors like when we added mchem
notion into math manual and instant preview stop to work or even compile
for some users.


Indeed.

JMarc

PS: BTW Uwe, did you see my messages about the \LyX macro? Since r37164 
it is robust under hyperref and it is not necessary to redefine it in 
preamble.

Re: I am moving to Switzerland

[Jean-Marc Lasgouttes]

Le 19/07/2011 10:08, Abdelrazak Younes a écrit :

Hi there,

I see that there's a lot of request to help for me in Trac; I would be
very happy to but I am very busy these days...
I am starting a new job in August in Switzerland and I am preparing my
moving to there with the family. So don't expect much from me in the
coming weeks.


And eventually, does this mean less or more time to hack on LyX?

Have a nice trip.

JMarc

Re: changeset/39333

[Jean-Marc Lasgouttes]

Le 19/07/2011 10:52, Pavel Sanda a écrit :

It is the privilege of the new developer to pick a user name. cmd is not
weirder than gmatht, after all :)


nobody asked me !?@$%!~ ;p


Hmm, maybe at the time the privilege did not exist, then.

Re: I am moving to Switzerland

[José Matos]

On 07/19/2011 11:13 AM, Jean-Marc Lasgouttes wrote:

Have a nice trip.

JMarc 


+1 :-)

--
José Matos

Re: I am moving to Switzerland

[Abdelrazak Younes]

On 19/07/2011 12:13, Jean-Marc Lasgouttes wrote:

Le 19/07/2011 10:08, Abdelrazak Younes a écrit :

Hi there,

I see that there's a lot of request to help for me in Trac; I would be
very happy to but I am very busy these days...
I am starting a new job in August in Switzerland and I am preparing my
moving to there with the family. So don't expect much from me in the
coming weeks.


And eventually, does this mean less or more time to hack on LyX?


Compared to what? I haven't been very active last two years :-)

My new job will be very challenging, a lot of new things to learn. But 
the good news is that I will do even more Software development so I will 
definitely try to keep track of LyX.




Have a nice trip.


Thanks,
Abdel.

LyX meeting? (Re: I am moving to Switzerland)

[Abdelrazak Younes]

On 19/07/2011 12:13, Jean-Marc Lasgouttes wrote:

Le 19/07/2011 10:08, Abdelrazak Younes a écrit :

Hi there,

I see that there's a lot of request to help for me in Trac; I would be
very happy to but I am very busy these days...
I am starting a new job in August in Switzerland and I am preparing my
moving to there with the family. So don't expect much from me in the
coming weeks.


And eventually, does this mean less or more time to hack on LyX?


Thinking about it, my family will be on holidays between the 5th and the 
12th of August. So my new appartment will be empty (except for the still 
unpacked stuff of course).


Is there interest in a LyX meeting during the week-end between the 5th 
and the 7th? I will leave in a very nice area close to Lausanne 5 
minutes walk to the Léman lake.


Abdel.

Re: build error with trunk on openSUSE

[Cor Blom]

Op dinsdag 19 juli 2011 10:47:50 schreef Pavel Sanda:
 please can you paste the relevant part of log? i have hard time to
 understand why we need bc.

Here it is:

[...]
  GENui_TocUi.h
  GENui_ToggleWarningUi.h
  GENui_VSpaceUi.h
  GENui_ViewSourceUi.h
  GENui_WrapUi.h
/bin/sh: bc: command not found
  GENmoc_Action.cpp
/bin/sh: bc: command not found
  GENmoc_BulletsModule.cpp
/bin/sh: bc: command not found
  GENmoc_CustomizedWidgets.cpp
/bin/sh: bc: command not found
  GENmoc_EmptyTable.cpp
/bin/sh: bc: command not found
  GENmoc_FancyLineEdit.cpp
/bin/sh: bc: command not found
  GENmoc_FindAndReplace.cpp
/bin/sh: bc: command not found
  GENmoc_FloatPlacement.cpp
/bin/sh: bc: command not found
  GENmoc_GuiAbout.cpp
/bin/sh: bc: command not found
  GENmoc_GuiApplication.cpp
/bin/sh: bc: command not found
  GENmoc_GuiBibitem.cpp
/bin/sh: bc: command not found
  GENmoc_GuiBibtex.cpp
/bin/sh: bc: command not found
  GENmoc_GuiBox.cpp
/bin/sh: bc: command not found
  GENmoc_GuiBranches.cpp
/bin/sh: bc: command not found
  GENmoc_GuiBranch.cpp
/bin/sh: bc: command not found
  GENmoc_GuiChanges.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCharacter.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCitation.cpp
/bin/sh: bc: command not found
  GENmoc_GuiClipboard.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCommandBuffer.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCommandEdit.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCompare.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCompareHistory.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCompleter.cpp
/bin/sh: bc: command not found
  GENmoc_GuiDelimiter.cpp
/bin/sh: bc: command not found
  GENmoc_GuiDialog.cpp
/bin/sh: bc: command not found
  GENmoc_GuiDocument.cpp
/bin/sh: bc: command not found
  GENmoc_GuiErrorList.cpp
/bin/sh: bc: command not found
  GENmoc_GuiERT.cpp
/bin/sh: bc: command not found
  GENmoc_GuiExternal.cpp
/bin/sh: bc: command not found
  GENmoc_GuiGraphics.cpp
/bin/sh: bc: command not found
  GENmoc_GuiHSpace.cpp
/bin/sh: bc: command not found
  GENmoc_GuiHyperlink.cpp
/bin/sh: bc: command not found
  GENmoc_GuiInclude.cpp
/bin/sh: bc: command not found
  GENmoc_GuiIndex.cpp
/bin/sh: bc: command not found
  GENmoc_GuiIndices.cpp
/bin/sh: bc: command not found
  GENmoc_GuiInfo.cpp
/bin/sh: bc: command not found
  GENmoc_GuiLabel.cpp
/bin/sh: bc: command not found
  GENmoc_GuiLine.cpp
/bin/sh: bc: command not found
  GENmoc_GuiListings.cpp
/bin/sh: bc: command not found
  GENmoc_GuiLog.cpp
/bin/sh: bc: command not found
  GENmoc_GuiMathMatrix.cpp
/bin/sh: bc: command not found
  GENmoc_GuiNomenclature.cpp
/bin/sh: bc: command not found
  GENmoc_GuiNote.cpp
/bin/sh: bc: command not found
  GENmoc_GuiParagraph.cpp
/bin/sh: bc: command not found
  GENmoc_GuiPhantom.cpp
/bin/sh: bc: command not found
  GENmoc_GuiPrefs.cpp
/bin/sh: bc: command not found
  GENmoc_GuiPrint.cpp
/bin/sh: bc: command not found
  GENmoc_GuiPrintindex.cpp
/bin/sh: bc: command not found
  GENmoc_GuiPrintNomencl.cpp
/bin/sh: bc: command not found
  GENmoc_GuiProgress.cpp
/bin/sh: bc: command not found
  GENmoc_GuiProgressView.cpp
/bin/sh: bc: command not found
  GENmoc_GuiRef.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSearch.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSelection.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSelectionManager.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSendto.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSetBorder.cpp
/bin/sh: bc: command not found
  GENmoc_GuiShowFile.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSpellchecker.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSymbols.cpp
/bin/sh: bc: command not found
  GENmoc_GuiTabularCreate.cpp
/bin/sh: bc: command not found
  GENmoc_GuiTabular.cpp
/bin/sh: bc: command not found
  GENmoc_GuiTexinfo.cpp
/bin/sh: bc: command not found
  GENmoc_GuiThesaurus.cpp
/bin/sh: bc: command not found
  GENmoc_GuiToc.cpp
/bin/sh: bc: command not found
  GENmoc_GuiToolbar.cpp
/bin/sh: bc: command not found
  GENmoc_GuiView.cpp
/bin/sh: bc: command not found
  GENmoc_GuiViewSource.cpp
/bin/sh: bc: command not found
  GENmoc_GuiVSpace.cpp
/bin/sh: bc: command not found
  GENmoc_GuiWorkArea.cpp
/bin/sh: bc: command not found
  GENmoc_GuiWrap.cpp
/bin/sh: bc: command not found
  GENmoc_IconPalette.cpp
/bin/sh: bc: command not found
  GENmoc_InGuiThread.cpp
/bin/sh: bc: command not found
  GENmoc_InsertTableWidget.cpp
/bin/sh: bc: command not found
  GENmoc_InsetParamsDialog.cpp
/bin/sh: bc: command not found
  GENmoc_InsetParamsWidget.cpp
/bin/sh: bc: command not found
  GENmoc_LayoutBox.cpp
/bin/sh: bc: command not found
  GENmoc_LengthCombo.cpp
/bin/sh: bc: command 

Re: LyX meeting? (Re: I am moving to Switzerland)

[Abdelrazak Younes]

On 19/07/2011 13:22, Abdelrazak Younes wrote:

On 19/07/2011 12:13, Jean-Marc Lasgouttes wrote:

Le 19/07/2011 10:08, Abdelrazak Younes a écrit :

Hi there,

I see that there's a lot of request to help for me in Trac; I would be
very happy to but I am very busy these days...
I am starting a new job in August in Switzerland and I am preparing my
moving to there with the family. So don't expect much from me in the
coming weeks.


And eventually, does this mean less or more time to hack on LyX?


Thinking about it, my family will be on holidays between the 5th and 
the 12th of August. So my new appartment will be empty (except for the 
still unpacked stuff of course).


Is there interest in a LyX meeting during the week-end between the 5th 
and the 7th? I will leave in a very nice area close to Lausanne 5 
minutes walk to the Léman lake.


I will _live_ in a nice area...

Abdel.

Re: Missing features in Flex insets and style definition question

[Uwe Stöhr]

Am 19.07.2011 10:15, schrieb Jean-Marc Lasgouttes:


This doesn't help, because in some cases you need the feature that LyX
does not add nothing, no par break and also no newline but to continue
with the code right after the command.


Looks like a very badly coded macro, then.


No, these cases occur often. They are also not badly coded but standard and valid LaTeX that 
commands affect the paragraph they are in.


As said, we already support such LaTeX commands via InsetLayout, but we need to add for InsetLayout 
also the support of arguments.



Richard is right that InsetLayout
is designed for this, but this is only usable if InsetLayout supports
also arguments. It is not yet clear to me why this is not supported. I'm
not familiar with the layout code but I assumed that it should not be
very hard to implement. Would at least be a very valuable feature for
LyX 2.1.


Yes, it should be done eventually, and it is not very difficult. However, I 
think it would be better
to factor in the two cases, rather then duplicating code (with subtly different 
bugs :)


Will you do this or is this something for Richard? Should I open an enhancement 
bug report?

regards Uwe

Re: about the initials module

[Uwe Stöhr]

Am 19.07.2011 11:55, schrieb Pavel Sanda:


in the page http://wiki.lyx.org/LyX/NewInLyX20 there was the icon that the
initial module is documented. Where is it, I cannot find it?


i put the tickmark of documented feature when the module description inside 
settings
dialog is enough to grab all information needed.


Sorry, but

Define character style for initials. Hint: try to use math and its artistic font styles like 
Fractur or the Calligraphic one.


is no documentation. With this info the module is useless. Where should I use what, insert what? 
Where comes the math, what has math to do with an initial? And what about the arguments one needs 
for initials?



as sidecomment i dont think that adding specific features which pull extra
packages into our manuals is a healthy thing.  they are not compilable on
various situations then and produce strange errors like when we added mchem
notion into math manual and instant preview stop to work or even compile
for some users.


Our manuals have to describe what you can do with LyX. There is no other way. It might always be 
possible that our docs are uncompilable. We cannot control what LaTeX-packages are installed on a 
system. Or where do you want to set the line? For example wrapfig might not be installed, should we 
therefore not document wrapped floats? booktabs might not be installed should we therefore not 
document all our table features so that the user might ask his self What is this booktabs option in 
the table dialog about, I cannot find it in the docs?.


In general the basic rule applies: An undocumented feature is an unused feature. So we have to 
document it somewhere. I use the EmbeddedObjects manual to document the more trickery package 
support and some tips and tricks. If a package is really exotic or interferes potentially with 
others, I put it into an extra file.


In case of packages that seem to be not widely used and might probably not be installed, I added 
notes to the docs which package is needed for what sections. For some features I even use a 
construct that you get a special section content if the package is not available. So the document is 
still compilable.


regards Uwe

Re: LyX meeting? (Re: I am moving to Switzerland)

[Jean-Marc Lasgouttes]

Le 19/07/2011 13:22, Abdelrazak Younes a écrit :

Thinking about it, my family will be on holidays between the 5th and the
12th of August. So my new appartment will be empty (except for the still
unpacked stuff of course).

Is there interest in a LyX meeting during the week-end between the 5th
and the 7th? I will leave in a very nice area close to Lausanne 5
minutes walk to the Léman lake.


That's very tempting, but I will be on vacation with the family.

JMarc

Re: Missing features in Flex insets and style definition question

[Jean-Marc Lasgouttes]

Le 19/07/2011 13:47, Uwe Stöhr a écrit :

No, these cases occur often. They are also not badly coded but
standard and valid LaTeX that commands affect the paragraph they are in.


What typical examples do you have in mind?

JMarc

Re: Missing features in Flex insets and style definition question

[Jean-Marc Lasgouttes]

Le 19/07/2011 13:47, Uwe Stöhr a écrit :

Yes, it should be done eventually, and it is not very difficult.
However, I think it would be better
to factor in the two cases, rather then duplicating code (with subtly
different bugs :)


Will you do this or is this something for Richard? Should I open an
enhancement bug report?


I do not think I will have time to do it, unfortunately.

JMarc

Re: Missing features in Flex insets and style definition question

[Uwe Stöhr]

Am 19.07.2011 14:23, schrieb Jean-Marc Lasgouttes:


Le 19/07/2011 13:47, Uwe Stöhr a écrit :

No, these cases occur often. They are also not badly coded but
standard and valid LaTeX that commands affect the paragraph they are in.


What typical examples do you have in mind?


Pictures in paragraphs (e.g. via picins, picinpar), wrapped floats, initials, email commands, 
address formatting commands, various scientific paper titling commands, ...


regards Uwe

Re: Missing features in Flex insets and style definition question

[Jean-Marc Lasgouttes]

Le 19/07/2011 14:28, Uwe Stöhr a écrit :

Pictures in paragraphs (e.g. via picins, picinpar), wrapped floats,
initials, email commands, address formatting commands, various
scientific paper titling commands, ...


Most of these are indeed part of a paragraph an thus should be handled 
by custom insets. There is no point to change normal layouts for them.


JMarc

Re: Missing features in Flex insets and style definition question

[Uwe Stöhr]

Am 19.07.2011 14:38, schrieb Jean-Marc Lasgouttes:


Most of these are indeed part of a paragraph an thus should be handled by 
custom insets. There is no
point to change normal layouts for them.


Yes, we already agree here. The only pint is that InsetLayout (a.k.a. flex inset) does not yet 
support arguments, but we need this for many cases. For example many paper titling commands support 
optional arguments (for second authors, reviewers, editors), and some of our templates/example files 
look currently a bit ugly in LyX with some TeX code because of the missing argument support.


regards Uwe

Re: build error with trunk on openSUSE

[Stephan Witt]

Am 19.07.2011 um 11:05 schrieb Stephan Witt:

 Am 19.07.2011 um 10:47 schrieb Pavel Sanda:
 
 Cor Blom wrote:
 bc: GNU Command Line Calculator
 
 After your last remark I looked again through the log and noticed that the 
 shell complained that bc could not be found. This complaint was not there 
 in 
 the buildlog for branch, so I added it as a requirement.
 
 please can you paste the relevant part of log? i have hard time to 
 understand 
 why we need bc.
 
 I think because of the conversion of the Qt version number from e.g. hex 
 4.6.3 to decimal value.

Vice versa of course.

 Unfortunately, this has to be passed to moc explicitly.
 Perhaps this can be solved in some other way...
 

In case of interest

QT_VERSION=4.10.3 sh -c 'v=0x0; for i in ${QT_VERSION//./ } ; do case $i in 
10) v=$v0a ;; 11) v=$v0b ;; 12) v=$v0c ;; 13) v=$v0d ;; 14) v=$v0e ;; 
15) v=$v0f ;; *) v=$v0$i ;; esac ; done; echo $v'

prints 0x0040a03

Stephan

Re: changeset 39344

[Richard Heck]

On 07/19/2011 01:17 AM, Uwe Stöhr wrote:
 Richard,

 am I allowed to remove the file enumitem.lyx from branch too? Its
 content is now in the UserGuide.
 My goal was to merge all these infos into one place because before we
 described customized lists in the Additional manual and the enumitem
 example file.

That's fine.

rh

Re: Missing features in Flex insets and style definition question

[Richard Heck]

On 07/19/2011 08:25 AM, Jean-Marc Lasgouttes wrote:
 Le 19/07/2011 13:47, Uwe Stöhr a écrit :
 Yes, it should be done eventually, and it is not very difficult.
 However, I think it would be better
 to factor in the two cases, rather then duplicating code (with subtly
 different bugs :)

 Will you do this or is this something for Richard? Should I open an
 enhancement bug report?

 I do not think I will have time to do it, unfortunately.

I'm still hoping to do some major reworking of how arguments are
handled, i.e., get rid of that inset. It should be easy to include this
for InsetLayout.

Richard

Re: Fwd: Additional manual

[Jean-Pierre Chrétien]

Le 17/07/2011 12:02, Pavel Sanda a écrit :

Uwe Stöhr wrote:

section 7.2.1: sentence

Before you begin to use the version control features in LyX, you should
be
familiar with RCS/CVS/SVN usage before start using it under LyX.


Indeed. I removed this now.


the wording maybe wrong in terms of style but this information should be there.
VCS support is not robust at all, so the moment something goes wrong user
must be capable to fix it by himself without help of lyx. without being familiar
of RCS/CVS/SVN this is impossible and we should warn about this.


I wanted to stress the fact that the phrase was redundant, i.e, supressing 
before start using it under LyX was OK.


--
Jean-Pierre

Re: Missing features in Flex insets and style definition question

[Uwe Stöhr]

Am 19.07.2011 15:08, schrieb Richard Heck:


I'm still hoping to do some major reworking of how arguments are
handled, i.e., get rid of that inset.


What do you have in mind instead? I have now a lot of experience with it and find the current 
implementation acceptable, except of these 2 things:


- the menu entry must read optional Argument, not short title (this is misleading and this 
appears often at the users list that people are confused, a short title is only ONE occurrence of 
optional arguments
- If there is a mandatory argument, the inset should appear directly when using the style and it 
must not be allowed to delete this inset; this inset should have the label req (for required) and 
not opt.


Should I store thesesuggestions in an enhancement request?

regards Uwe

Re: Missing features in Flex insets and style definition question

[Richard Heck]

On 07/19/2011 09:58 AM, Uwe Stöhr wrote:
 Am 19.07.2011 15:08, schrieb Richard Heck:

 I'm still hoping to do some major reworking of how arguments are
 handled, i.e., get rid of that inset.

 What do you have in mind instead? I have now a lot of experience with
 it and find the current implementation acceptable, except of these 2
 things:

 - the menu entry must read optional Argument, not short title (this
 is misleading and this appears often at the users list that people are
 confused, a short title is only ONE occurrence of optional arguments

It's much less clear how you can label different insets differently.
E.g., if there is one required argument and one optional one. Now what?

 - If there is a mandatory argument, the inset should appear directly
 when using the style and it must not be allowed to delete this inset;
 this inset should have the label req (for required) and not opt.

This is bigger the problem. It's like with Bibitems, which are a mess.
You have to make sure no one deletes it, or moves it, or tries to type
in front of it. It's just not an inset.

The idea is to let arguments be typed into some sort of dialog, e.g., in
a new Arguments pane of the paragraph settings dialog. This is easy,
except for the fact that we want people to be able to type LyX, not
LaTeX, which means using the sort of embedded buffer that's used in the
advanced FR dialog. That will take more work.

Richard

Re: Missing features in Flex insets and style definition question

[Jürgen Spitzmüller]

Richard Heck wrote:
  - the menu entry must read optional Argument, not short title (this
  is misleading and this appears often at the users list that people are
  confused, a short title is only ONE occurrence of optional arguments
 
 It's much less clear how you can label different insets differently.
 E.g., if there is one required argument and one optional one. Now what?

And that's why it should not be labelled optional or required argument, 
but it should be semantically precise. Short title is (for the case the 
inset was initially developed). Longest label is as well. LyX should tell 
the user what this argument does, not just that it is an optional argument. 
This is possible with some extended argument definition in the layout file. 
Instead of

OptionalArgs 2

do something like

Argument
Type   optional
   Order  1
   Label  Short title in TOC
EndArgument

Argument
Type   optional
   Order  2
   Label  Short title in header
EndArgument

  - If there is a mandatory argument, the inset should appear directly
  when using the style and it must not be allowed to delete this inset;
  this inset should have the label req (for required) and not opt.
 
 This is bigger the problem. It's like with Bibitems, which are a mess.
 You have to make sure no one deletes it, or moves it, or tries to type
 in front of it. It's just not an inset.

Yes, this is not possible in a sane way with a collapsable inset.

 The idea is to let arguments be typed into some sort of dialog, e.g., in
 a new Arguments pane of the paragraph settings dialog. 

Also consider that we already have this. Longest label in the paragraph 
dialog is just another implementation of a specific (required) argument. We 
just need to extend this concept.

 This is easy,
 except for the fact that we want people to be able to type LyX, not
 LaTeX, which means using the sort of embedded buffer that's used in the
 advanced FR dialog. That will take more work.

Yes, but it's possible.

Jürgen

Re: LyX meeting? (Re: I am moving to Switzerland)

[Pavel Sanda]

Abdelrazak Younes wrote:
 Is there interest in a LyX meeting during the week-end between the 5th and 
 the 7th? I will leave in a very nice area close to Lausanne 5 minutes walk 

very unprobable i will have spare time during this summer...

isn't Juergen the swiss layman now as well?
pavel

Re: LyX meeting? (Re: I am moving to Switzerland)

[Jürgen Spitzmüller]

Pavel Sanda wrote:
  Is there interest in a LyX meeting during the week-end between the 5th
  and  the 7th? I will leave in a very nice area close to Lausanne 5
  minutes walk
 
 very unprobable i will have spare time during this summer...
 
 isn't Juergen the swiss layman now as well?

Yep (in the German part, though), but I'm also on vacation at that time.

Jürgen

Re: Missing features in Flex insets and style definition question

[Uwe Stöhr]

Am 19.07.2011 16:38, schrieb Richard Heck:


- the menu entry must read optional Argument, not short title (this
is misleading and this appears often at the users list that people are
confused, a short title is only ONE occurrence of optional arguments


It's much less clear how you can label different insets differently.
E.g., if there is one required argument and one optional one. Now what?


This is my second suggestion. To sum it up here in better words:

- When a style has a mandatory argument and th user use it, its argument appears automatically. This 
inset can but must not be collapsible. The important thing is that is appears automatically and that 
the user cannot delete it. As there is no choice to use it or not, we don't need a menu entry or not.

When a style has 2 or more mandatory arguments, the defined number of mandatory 
insets appears.

- the optional argument can sty as it is, only its menu entry in the Insert 
menu must be changed.


So assuming we have a command

\blahblub[alignment]{number of line}{width}

we define the style for it as follows in the layout file (in pseudo code):

Style
 LatexNameblahblub
 Labelstring  BlaBlah: 
 RequiredArgs 2
 OptionalArgs 1
 DefaultReqValue1 1
 DefaultReqValue2 1cm
 DefaultOptValue1 

When the style is used in a document you get this:

BlaBlah: |1||1cm|

where | | represents a required argument inset.

It is important that we can define a default value or mandatory arguments because some commands 
don't like when there is no content in them. We therefore make a proposal to prevent that the user 
forgets to insert something there. But the user can delete the default content when he like to keep 
it empty for some reason.



I hope this is now clearer to understand what I have in mind.



The idea is to let arguments be typed into some sort of dialog, e.g., in
a new Arguments pane of the paragraph settings dialog.


This won't work because one must be able to insert all stuff to arguments. For example it must be 
possible to use an equation, a figure or whatever as argument. There are commend who require this 
(for example the package picinpar provides commands whost mandatory arguments are tables or figures).
Therefore the current implementation of the optional argument is already perfect (and one use TeX 
Code with them too). So we only need a second inset for mandatory arguments with the same 
possibilities in inserting stuff to it, but with the additional features I described above.


regards Uwe

Re: Missing features in Flex insets and style definition question

[Richard Heck]

On 07/19/2011 12:54 PM, Uwe Stöhr wrote:
 Am 19.07.2011 16:38, schrieb Richard Heck:

 - the menu entry must read optional Argument, not short title (this
 is misleading and this appears often at the users list that people are
 confused, a short title is only ONE occurrence of optional arguments

 It's much less clear how you can label different insets differently.
 E.g., if there is one required argument and one optional one. Now what?

 This is my second suggestion. To sum it up here in better words:

 - When a style has a mandatory argument and th user use it, its
 argument appears automatically. This inset can but must not be
 collapsible. The important thing is that is appears automatically and
 that the user cannot delete it. As there is no choice to use it or
 not, we don't need a menu entry or not.
 When a style has 2 or more mandatory arguments, the defined number of
 mandatory insets appears.

I understand the idea, but it would make the Bibitem mess look neat.

 - the optional argument can sty as it is, only its menu entry in the
 Insert menu must be changed.

There can be more than one optional argument. Think about beamer.

 The idea is to let arguments be typed into some sort of dialog, e.g., in
 a new Arguments pane of the paragraph settings dialog.

 This won't work because one must be able to insert all stuff to
 arguments. For example it must be possible to use an equation, a
 figure or whatever as argument. There are commend who require this
 (for example the package picinpar provides commands whost mandatory
 arguments are tables or figures).

This is why you use an embedded Buffer, like with FR.

 Therefore the current implementation of the optional argument is
 already perfect (and one use TeX Code with them too). So we only need
 a second inset for mandatory arguments with the same possibilities in
 inserting stuff to it, but with the additional features I described
 above.

As I said, I understand what you want, but it is not practical to do it
with insets.

Here's another idea I had, though I don't know how hard it would be to
implement. The idea would be to have fake insets. They would get drawn
like insets, but they would actually be attached to the paragraph and
wouldn't correspond to characters. You might think of them as existing
in the paragraph's margin.

Richard

Re: Missing features in Flex insets and style definition question

[Uwe Stöhr]

Am 19.07.2011 19:33, schrieb Richard Heck:


I understand the idea, but it would make the Bibitem mess look neat.


What do you mean?


- the optional argument can sty as it is, only its menu entry in the
Insert menu must be changed.


There can be more than one optional argument. Think about beamer.


Sure and it is no problem of allowing to insert more then one optional argument to a style. We 
already have the infrastructure. What is missing is the layout code that allows to define more than 
one optional argument. I would implement this the same way as in my example for 2 mandatory arguments.



The idea is to let arguments be typed into some sort of dialog, e.g., in
a new Arguments pane of the paragraph settings dialog.


This won't work because one must be able to insert all stuff to
arguments. For example it must be possible to use an equation, a
figure or whatever as argument. There are commend who require this
(for example the package picinpar provides commands whost mandatory
arguments are tables or figures).


This is why you use an embedded Buffer, like with FR.


But why not usig what we already have as optional argument inset. It allwas to insert there 
everything the LyX way. And it is more intuitive than a dialog. Moreover a dialog would be a 
restriction you don't see at one sight the different arguments and we need arguments for everything, 
styles as well as InsetLayouts and LaTeX commands can be used for so many things we can not even 
imagine.



Therefore the current implementation of the optional argument is
already perfect (and one use TeX Code with them too). So we only need
a second inset for mandatory arguments with the same possibilities in
inserting stuff to it, but with the additional features I described
above.


As I said, I understand what you want, but it is not practical to do it
with insets.


Why not?


Here's another idea I had, though I don't know how hard it would be to
implement. The idea would be to have fake insets. They would get drawn
like insets, but they would actually be attached to the paragraph and
wouldn't correspond to characters.


It seems we are talking about different things. I want to have an implementation where I can define 
styles for every sort of LaTeX commands with several optional and mandatory arguments. And no matter 
if the LaTeX command represents a paragraph or not.


I do not need a special hack to attach something to a paragraph. This was a special issue I stumbled 
over and why I started this thread. I think we already came yet to the conclusion that we only need 
the same features for InsetLayouts as for styles. In the case which I started the discussion, the 
problem would already be solved, if InsetLayout supports arguments like styles already do.


So my last two posts were about how to further improve the argument support.

regards Uwe

Re: about the initials module

[Uwe Stöhr]

Am 19.07.2011 12:11, schrieb Jean-Marc Lasgouttes:


PS: BTW Uwe, did you see my messages about the \LyX macro? Since r37164 it is 
robust under hyperref
and it is not necessary to redefine it in preamble.


Not yes. Thanks for the hint, I'll remove the corresponding preamble code now.

regards Uwe

Re: [patch] Re: \textvisiblespace

[Uwe Stöhr]

Am 19.07.2011 08:14, schrieb Stephan Witt:


Sorry, I cannot resist... Notepad is not an editor. It's an excuse for not 
having one.
Every time I have to view a file on stock windows I get an attack of windows 
hate.
It's the same with the never ending newline story.
One should at least use Wordpad instead.


This won't help because it is using the same Windows standard fonts which display \textvisiblespace 
as the square that indicates an unknown character.


regards Uwe

Re: [patch] Re: \textvisiblespace

[Uwe Stöhr]

Am 19.07.2011 08:41, schrieb Jürgen Spitzmüller:


And this is exactly why it makes sense. It's a possibility to represent a
space. Why shouldn't InsetSpace allow for that possibility?


 It is totally confusing that we have the menu Insert-Special character that already provides the 
char. OK, this doesn't work on windows because the Windows standard fonts don't support to display 
this character and one therefore cannot even see it in the special character dialog.

But we also have the menu for special formatting characters and that is what 
\textvisiblespace is.

Inserting it as a space is illogical. I mean with a character I can really do something, with a 
space not. So I can paint it red, I can emphasize it, I can scale and rotate it - all because it is 
a character. All this cannot be done with a space. Or do you ant to extend the space insert that it 
is possible to apply character styles and font formattings to it.

So yes, the concept of spaces and characters is important here.


The discussion about glyph classification (technical symbol vs. space) is
completely irrelevant for most users. They might just want to make a space
visible, and that's what \textvisible space is useful for.


They can already do this in listings and when I want a character to visualize it is logical to me 
that I insert an appropriate character for it.
But it is illogical that I can transform a real space to a character with all the consequences in an 
inset that is designed for spaced and not characters.


 but to sum up as the time passed we have 3 patches:
 1. special symbol - simple Unicode char
 2. part of insetspace
 3. special symbol - specific drawing

regards Uwe

Re: Missing features in Flex insets and style definition question

[Richard Heck]

On 07/19/2011 01:49 PM, Uwe Stöhr wrote:
 Am 19.07.2011 19:33, schrieb Richard Heck:

 I understand the idea, but it would make the Bibitem mess look neat.

 What do you mean?

The InsetBibitem code is a complete disaster. There are all kinds of
bugs associated with it, because we are trying to use an inset to do
something an inset shouldn't really be doing. You have all the same
problems: Don't delete it; keep it at the beginning; etc, etc. There's
all kinds of fragile, special purpose code to deal with this issue.
Trying to manage more than one of these things would be a nightmare, and
we don't even do it correctly for the optional argument inset we have.
Are you aware that these insets can appear anywhere in a paragraph? You
can even paste them into paragraphs that don't allow them, and you can
paste in extra ones, if you wish. Of course, they won't do anything then
but clutter your screen. To deal with this problem, you'd need the same
sort of bug-ridden code we have with InsetBibitem.

Even independent of the issues you're raising, the optional argument
inset should go.

 - the optional argument can sty as it is, only its menu entry in the
 Insert menu must be changed.

 There can be more than one optional argument. Think about beamer.

 Sure and it is no problem of allowing to insert more then one optional
 argument to a style. We already have the infrastructure. What is
 missing is the layout code that allows to define more than one
 optional argument. I would implement this the same way as in my
 example for 2 mandatory arguments.

You can define as many optional arguments as you want now. Of course,
they're all called Short Title, which we agree is a problem.

 The idea is to let arguments be typed into some sort of dialog,
 e.g., in
 a new Arguments pane of the paragraph settings dialog.

 This won't work because one must be able to insert all stuff to
 arguments. For example it must be possible to use an equation, a
 figure or whatever as argument. There are commend who require this
 (for example the package picinpar provides commands whost mandatory
 arguments are tables or figures).

 This is why you use an embedded Buffer, like with FR.

 But why not usig what we already have as optional argument inset. It
 allwas to insert there everything the LyX way. And it is more
 intuitive than a dialog. Moreover a dialog would be a restriction you
 don't see at one sight the different arguments and we need arguments
 for everything, styles as well as InsetLayouts and LaTeX commands can
 be used for so many things we can not even imagine.

A dialog keeps everything in one place, and could even allow the use,
say, of our length combo when the argument expects a length, and who
knows what else. The problem of the arguments not being visible is one
that can be addressed.

 Therefore the current implementation of the optional argument is
 already perfect (and one use TeX Code with them too). So we only need
 a second inset for mandatory arguments with the same possibilities in
 inserting stuff to it, but with the additional features I described
 above.

 As I said, I understand what you want, but it is not practical to do it
 with insets.

 Why not?

See above.

 Here's another idea I had, though I don't know how hard it would be to
 implement. The idea would be to have fake insets. They would get drawn
 like insets, but they would actually be attached to the paragraph and
 wouldn't correspond to characters.

 It seems we are talking about different things. I want to have an
 implementation where I can define styles for every sort of LaTeX
 commands with several optional and mandatory arguments. And no matter
 if the LaTeX command represents a paragraph or not.

Yes, of course. The same sort of thing can be done with other insets.

Richard

Re: about the initials module

[Jean-Marc Lasgouttes]

Le 19/07/11 19:57, Uwe Stöhr a écrit :

PS: BTW Uwe, did you see my messages about the \LyX macro? Since
r37164 it is robust under hyperref
and it is not necessary to redefine it in preamble.


Not yes. Thanks for the hint, I'll remove the corresponding preamble
code now.


Of course don't forget to doublecheck that it works (it is in 2.0 too).

JMarc

Re: about the initials module

[Uwe Stöhr]

Am 20.07.2011 00:02, schrieb Jean-Marc Lasgouttes:


Of course don't forget to doublecheck that it works (it is in 2.0 too).


I always compile every file as PDF before committing. This should btw. the 
default procedure.
(The only exception are the Japanese files because I don't have ptex.)

regards Uwe

Re: [patch] Re: \textvisiblespace

[Pavel Sanda]

Jürgen Spitzmüller wrote:
 Pavel Sanda wrote:
  the border of technical symbol vs. space is fuzzy to me and i don't
  have hard opinion to dicuss it.
  
  but to sum up as the time passed we have 3 patches:
  1. special symbol - simple unicode char
  2. part of insetspace
  3. special symbol - specific drawing
  
  if my counting is right than
  1 - Guenter
  2 - Juergen, JMarc
  3 - Uwe
  
  correct?
 
 My vote is to both integrate it to InsetSpace

yes that means your vote goes to 2

and to support it via  unicodesymbols (if not already the case).

thats already the case and the way i'm using it in 1.6.
its actually part of solution 1 and it is a pity this symbol is not properly 
rendered
with windows fonts. the patch would be uninvasive, backportable to 2.0 and with 
correct
change track rendering.

2,3 are slightly worse as far CT is concerned but both can work (3 needs that
the color is changed to standard font color as JMarc pointed out, but thats
trivial).

pavel

Re: build error with trunk on openSUSE

[Pavel Sanda]

Stephan Witt wrote:
 In case of interest
 
 QT_VERSION=4.10.3 sh -c 'v=0x0; for i in ${QT_VERSION//./ } ; do case $i 
 in 10) v=$v0a ;; 11) v=$v0b ;; 12) v=$v0c ;; 13) v=$v0d ;; 14) 
 v=$v0e ;; 15) v=$v0f ;; *) v=$v0$i ;; esac ; done; echo $v'
 
 prints 0x0040a03

how do cmake people solve this in windows? pavel

Re: Fwd: Additional manual

[Pavel Sanda]

Jean-Pierre Chrétien wrote:
 Le 17/07/2011 12:02, Pavel Sanda a écrit :
 Uwe Stöhr wrote:
 section 7.2.1: sentence

 Before you begin to use the version control features in LyX, you should
 be
 familiar with RCS/CVS/SVN usage before start using it under LyX.

 Indeed. I removed this now.

 the wording maybe wrong in terms of style but this information should be 
 there.
 VCS support is not robust at all, so the moment something goes wrong user
 must be capable to fix it by himself without help of lyx. without being 
 familiar
 of RCS/CVS/SVN this is impossible and we should warn about this.

 I wanted to stress the fact that the phrase was redundant, i.e, supressing 
 before start using it under LyX was OK.

i see, but now the whole sentence was killed, which is worse than before ;) 
pavel

Re: [PATCH] Cleaner windows title

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 (and I'd prefer SVN/CVS/RCS to Version Control),

then perhaps Version Control(SVN/CVS/RCS) in order to know what you are running.
also readonly flag is needed to be displayed somewhere.

pavel

Re: about the initials module

[Pavel Sanda]

... so i returned to this ...

Uwe Stöhr wrote:
 I now wrote its documentation from scratch and saw that your module did not 
 work.

it depends what you mean by works. if you just insert charstyle push character
there and start writing after charstyle inset it 'just works' (at least here).
you get big two lines initial character and paragraph of text around it.

unfortunately it is fixed for this usage and most of lettrine advanced
features are unused since we don have machinery how to push more arguments
there (at least i'm not aware of it). thats nothing strikingly new
and we have already thread with Hartmut exactly about this some time ago
here on devel list.

for more advanced usage you need to go for ERT. i looked at the new style
and its not solving things completely - you still need various ERTs or opt 
insets.
moreover there is no intuitive way how to typeset big initial without
reading manual where special construct needs to be learned.

the charstyle path is not clean, but for the basic usage works without any need
to read manual pages. you are probably right that when you use combinations of
lettrine with weird stuff around, weird things can happen. like with many other
insets in lyx.

 For compatibility reasons I left your style definition

first of all - as far as compatibility reasons is concerned - your last changes
will cause lyx 2.0.0 not being able to compile some 2.0.x0 files due to
missing style

its not fileformat issue though and i don't remember whether we used to make
such changes in 1.6.x.

but I think we should remove it.

in branch? then some files produced by lyx 2.0.x1 wont be compilable with
lyx 2.0.0.

It is not usable and users who use it, would get LaTeX 
 troubles. We should also add a note in the release notes that people should 
 switch to the initials style. What do you think?

i'm not convinced yet. but that can change if you show me some realistic
example how the lettrine charstyle is unusable. for the few random examples
i tried myself it worked as it should.

pavel

Re: about the initials module

[Pavel Sanda]

Uwe Stöhr wrote:
 Our manuals have to describe what you can do with LyX. There is no other 
 way. It might always be possible that our docs are uncompilable. We cannot 
 control what LaTeX-packages are installed on a system. Or where do you want 
 to set the line?

i dont have any fixed rule but there are latex packages which are basic
and those which are more advanced. seeing your last additions my bell
starts ringing that the border line was crossed.

on many linux distros latex is divided on the basic packages and extra
sets for advanced usage only - not installed by default and without
any automatical setup on request like miktex on windows do.

for example by simply checking
$ texmfind lettrine.sty
dev-texlive/texlive-latexextra [1 file]
lettrine.sty
Found 1 texmf file in 1 ebuild.

one sees that extra set of latex packages is needed on my distro.
it sounds wrong that building basic lyx manuals should require
this and example file looks like better place.

pavel

Re: changeset/39333

[John CMD]

On Tue, Jul 19, 2011 at 6:13 PM, Jean-Marc Lasgouttes lasgout...@lyx.orgwrote:

 Le 19/07/2011 10:52, Pavel Sanda a écrit :

 It is the privilege of the new developer to pick a user name. cmd is not
 weirder than gmatht, after all :)


 nobody asked me !?@$%!~ ;p


 Hmm, maybe at the time the privilege did not exist, then.


Lets at least keep the usernames alphanumeric; no !?@$%!~ or Little Bobby
Drop Tables. ;)

Perhaps if I present my name as John CMD in the email address, it would make
things easier.

-- John C McCabe-Dansted

Re: about the initials module

[Uwe Stöhr]

Am 20.07.2011 03:32, schrieb Pavel Sanda:


I now wrote its documentation from scratch and saw that your module did not
work.


it depends what you mean by works. if you just insert charstyle push character
there and start writing after charstyle inset it 'just works' (at least here).


By chance. As I said, you forgot the mandatory argument. So if the user e.g. uses a formatting in 
the paragraph, you will get troubles. LaTeX is looking for the missing brace pair for the argument 
and tries to take the next one it finds. But this can be a brace pair of another LaTeX command. 
Attached is an example where you get a LaTeX error.
It is very important that the LaTeX code that is produced by LyX is correct, otherwise you will have 
side effects that could harm to the maximum.



you get big two lines initial character and paragraph of text around it.

unfortunately it is fixed for this usage and most of lettrine advanced
features are unused since we don have machinery how to push more arguments
there (at least i'm not aware of it).


We already have the feature to add as many arguments as you like, mandatory and 
optional ones.


for more advanced usage you need to go for ERT. i looked at the new style
and its not solving things completely - you still need various ERTs or opt 
insets.


The argument insets are intended - that is our current UI to handle arguments. Today we discussed 
how to improve this UI. The two TeX code braces are only necessary because LyX does for an unknown 
reason not support arguments in InsetLayout. (Must have been forgotten when InsetLayout was 
implemented, but Richard is now aware if that.) When LyX has this feature, they can go.


However, the two TeX code braces are acceptable, because previously one had to do everything as TeX 
code and thus needed to know the names of the commands.



moreover there is no intuitive way how to typeset big initial without
reading manual where special construct needs to be learned.
the charstyle path is not clean, but for the basic usage works without any need
to read manual pages.


What do you expect? No style is self-explanatory. Of course one needs to read first how it works. I 
don't like the attitude to accept a lower quality just because it doesn't need to be documented. Our 
aim should be to provide features that do work in all cases and don't interfere with other ones, or 
even lead to LaTeX errors.


In general I don't understand your intention. What was the benefit of your module? It was designed 
to work only for one special case and only worked by chance. As a user I will surely sooner or later 
have the case were the predefined layout is not suitable for me (I for example need an inital over 3 
lines. Then I had to use TeX code and to do this, I had to read the lettrine manual and learn LaTeX. 
So in the end I had to read and learn much more than with the current version.



you are probably right that when you use combinations of
lettrine with weird stuff around, weird things can happen. like with many other
insets in lyx.


Sorry, but I cannot agree to this. We worked hard that this doesn't happen otherwise LyX would be 
quite useless for real life documents like a thesis or a business report. Where do you see that 
problems? If there is one it is a bug we need to fix.



For compatibility reasons I left your style definition


first of all - as far as compatibility reasons is concerned - your last changes
will cause lyx 2.0.0 not being able to compile some 2.0.x0 files due to
missing style


You mean because I added a style? Yes, LyX 2.0.0 will tell you that a style is unknown when loading 
a file made with LyX 2.0.1 that usess my new style. But this cannot be avoided. Take for example the 
various layout files we need to update from time to time when there are new versions. Especially for 
example the scientific paper classes we have to add new styles or rename some LaTeX commands all the 
time.



but I think we should remove it.


in branch? then some files produced by lyx 2.0.x1 wont be compilable with
lyx 2.0.0.


As I said, better we get rid of the buggy code right now than to wait longer. Currently the 
probability that people use the feature is relatively low because there was no documentation and LyX 
2.0.0 is still quites new (many users I know wait for the 0.1 release before they switch from 1.6 to 
2.0). And we cannot wait until LyX 2.1 because this might be a year and it is in my opinion not 
acceptable to provide a style that could lead to LaTeX errors.


regards Uwe

Re: about the initials module

[Uwe Stöhr]

Am 20.07.2011 03:45, schrieb Pavel Sanda:

Uwe Stöhr wrote:



Our manuals have to describe what you can do with LyX. There is no other
way. It might always be possible that our docs are uncompilable. We cannot
control what LaTeX-packages are installed on a system. Or where do you want
to set the line?


i dont have any fixed rule but there are latex packages which are basic
and those which are more advanced. seeing your last additions my bell
starts ringing that the border line was crossed.

on many linux distros latex is divided on the basic packages and extra
sets for advanced usage only - not installed by default and without
any automatical setup on request like miktex on windows do.


It is impossible to take care about every OS. For MiKTeX, MacTeX/TeXLive there is no problem and 
TeXLive works on all platforms.


In your Linux distro, the package might be tricky to install in another distro it is not tricky. 
What is a common package in your distro might be a non- standard package in another distro. There 
are too many distros available and LyX doesn't need to take care about the spacial packaging of your 
OS. But it needs to describe its features.


In general installing a LateX package is not difficult and LateX tells you which package it misses. 
On many platforms it even works automatically as long as you have an Internet connection. On Windows 
all module packages are even installed automatically together with LyX when LyX is started the first 
time. This will hopefully also be the case in TeXLive 2011.



and example file looks like better place.


I'm trying not to have a file for every feature. This would increase the maintaining a lot and users 
won't find it. For example I recently found the enumitem example file by chance because I do not 
look into all our currently 50 example files. An average user would also not know from the 
meaningless name enumitem what this might be about and that this provides list features. But 
within the UserGuide he can look for lists and read that for some special features he can load a 
module named enumitem and sees it in the context of a well indexed document describing other list 
features and thus is suitable to print it if one likes.


As average user of other programs I open its UserGuide and expect to find everything. (This works 
for most of the programs I'm using.) For the special things like initials we have the 
EmbeddedObjects and the Additional manual which are referenced at the beginning of the corresponding 
sections in the UserGuide. These manuals also clearly state at the beginning what packages are 
needed to see all their sections in the output.


For those who are e.g. offline and therefore cannot install any LaTeX package, I provide PDF 
versions of the manual in the Wiki (the link given at the beginning of the documentation files).


regards Uwe

Re: about the initials module

[Uwe Stöhr]

Am 20.07.2011 06:06, schrieb Uwe Stöhr:


Attached is an example where you get a LaTeX error.


Here it is.

regards Uwe



newfile1.lyx
Description: application/lyx

Re: [patch] Re: \textvisiblespace

[Stephan Witt]

Am 19.07.2011 um 01:05 schrieb Uwe Stöhr:

> Am 19.07.2011 00:05, schrieb Jean-Marc Lasgouttes:
> 
>> Le 15/07/11 22:30, Uwe Stöhr a écrit :
>>> I don't agree that implementing it as part of the space inset is a good
>>> idea. \textvisiblespace is not a space in the sense of the meaning but a
>>> special character. It does not create a space, but a character. I would
>>> therefore like to implement this as special character like an ellipsis.

...

>> + case VISIBLE_SPACE:
>> + os << "\\textvisiblespace{}";
>> + break;
>> 
>> For LaTeX output, can't we just output the unicode character and let our 
>> stream sort out the right
>> output? We may want unicode to output natively (maybe also for other special 
>> characters, actually).
> 
> I can do this, but what is the benefit? I know users looking at the LyX file 
> directly with a text editor, and on Windows they would only see a square.
> 
>> + case VISIBLE_SPACE:
>> + os << "|_|";
>> + return 3;
>> 
>> I do not think it makes much sense to use this ascii-art output here. I 
>> would use a plain space or
>> an underscore. Or even the unicode character, since we output to utf8 (Hmmm, 
>> do we?)
> 
> The problem is that when you use the Unicode character and the user open the 
> result e.g. in Windows standard editor "Notepad" he sees a black square 
> instead because the Windows standard fonts (Arial, times new Roman, etc.) 
> don't have a representation for this character (at least here on my XP).

Sorry, I cannot resist... Notepad is not an editor. It's an excuse for not 
having one.
Every time I have to view a file on stock windows I get an attack of windows 
hate.
It's the same with the never ending newline story.
One should at least use Wordpad instead.

Stephan

Re: [patch] Re: \textvisiblespace

[Jürgen Spitzmüller]

Uwe Stöhr wrote:
> > I still think it is wrong, but I am not going to fight forever on that
> > (what is there a space in "foo bar" and not "foo_bar"???).
> 
> The internal behaviour of a space and a character is different. LaTeX can
> change the width of spaces  to e.g. fit a line into the column margins.

That's not true for all spaces. Non-break spaces are of fixed width as well. 
And so is \thinspace.

> Spaces are something completely different than characters.
> \textvisiblespace is nothing more than a character built out of 3 strokes.
> Many fonts not even have a real glyph for it. This character only
> represents a space, but technically it is nothing else like any other
> character. So you could also simply use "_" to visualize a space in e.g. a
> code. 

And this is exactly why it makes sense. It's a possibility to represent a 
space. Why shouldn't InsetSpace allow for that possibility?

The discussion about glyph classification ("technical symbol" vs. "space") is 
completely irrelevant for most users. They might just want to "make a space 
visible", and that's what \textvisible space is useful for.

Jürgen

Re: SV: Towards RC4/final release

[Jürgen Spitzmüller]

Uwe Stöhr wrote:
> > There is the ideal, and there is what we have. The "ideal" way would be
> > to ensure that the extra paragraph types for running headers appear if
> > and only if page layout "fancy" is checked. Currently, that can't be
> > done with modules.  But at least we have the running headers now, which
> > is nice.
> 
> Well spoken. We were aware of that issue but what we have now is much better
> than before and the  header/footer issue came up very often in the user
> mailing list.

The problem is that we begin to weaken the module concept. I fear we end up 
with modules being a "wastebin" category, where we put everything we are to 
lazy to develop a decent GUI for.

That would be a pity, since the module concept is very valuable in itself.

Jürgen

Re: build error with trunk on openSUSE

[Cor Blom]

Op dinsdag 19 juli 2011 00:06:55 schreef Jean-Marc Lasgouttes:
> Le 18/07/11 23:58, Cor Blom a écrit :
> > Adding bc to BuildRequires solved the problem. Thanks for the help.
> 
> Interesting, but what does bc stand for?
> 

bc: GNU Command Line Calculator

After your last remark I looked again through the log and noticed that the 
shell complained that "bc" could not be found. This complaint was not there in 
the buildlog for branch, so I added it as a requirement.

On my system (i.e. my desktop system, not the buildservice) bc is installed by 
default and has a manpage.

Cor

I am moving to Switzerland

[Abdelrazak Younes]

Hi there,

I see that there's a lot of request to help for me in Trac; I would be 
very happy to but I am very busy these days...
I am starting a new job in August in Switzerland and I am preparing my 
moving to there with the family. So don't expect much from me in the 
coming weeks.


Cheers,
Abdel.

Re: Missing features in Flex insets and style definition question

[Jean-Marc Lasgouttes]

Le 19/07/2011 03:21, Uwe Stöhr a écrit :

This doesn't help, because in some cases you need the feature that LyX
does not add nothing, no par break and also no newline but to continue
with the code right after the command.


Looks like a very badly coded macro, then. It might be easier to fix the 
problem there.



Richard is right that InsetLayout
is designed for this, but this is only usable if InsetLayout supports
also arguments. It is not yet clear to me why this is not supported. I'm
not familiar with the layout code but I assumed that it should not be
very hard to implement. Would at least be a very valuable feature for
LyX 2.1.


Yes, it should be done eventually, and it is not very difficult. 
However, I think it would be better to factor in the two cases, rather 
then duplicating code (with subtly different bugs :)


JMarc

Re: changeset/39333

[Jean-Marc Lasgouttes]

Le 19/07/2011 03:34, Uwe Stöhr a écrit :

Great news!
However, can we please for the future use usernames that are
self-explanatory? I mean when I read "sanda" I know that it is you,
reading "cmd" is quite meaningless.


It is the privilege of the new developer to pick a user name. cmd is not 
weirder than gmatht, after all :)


JMarc

Re: [PATCH] Cleaner windows title

[Jean-Marc Lasgouttes]

Le 19/07/2011 05:54, BH a écrit :

Works well for me -- I use the title bar icon all the time (which can
also be used to reveal the complete path to the file and navigate to
any folder in the path).


Unfortunately, I cannot have only this part, since Qt does not do the 
icon thing if I set the windows title by hand. So we need a home for 
version control and read only.


JMarc

Re: build error with trunk on openSUSE

[Pavel Sanda]

Cor Blom wrote:
> bc: GNU Command Line Calculator
> 
> After your last remark I looked again through the log and noticed that the 
> shell complained that "bc" could not be found. This complaint was not there 
> in 
> the buildlog for branch, so I added it as a requirement.

please can you paste the relevant part of log? i have hard time to understand 
why we need bc.

pavel

Re: changeset/39333

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 19/07/2011 03:34, Uwe Stöhr a écrit :
>> Great news!
>> However, can we please for the future use usernames that are
>> self-explanatory? I mean when I read "sanda" I know that it is you,
>> reading "cmd" is quite meaningless.
>
> It is the privilege of the new developer to pick a user name. cmd is not 
> weirder than gmatht, after all :)

nobody asked me !?@$%!~ ;p

Re: build error with trunk on openSUSE

[Stephan Witt]

Am 19.07.2011 um 10:47 schrieb Pavel Sanda:

> Cor Blom wrote:
>> bc: GNU Command Line Calculator
>> 
>> After your last remark I looked again through the log and noticed that the 
>> shell complained that "bc" could not be found. This complaint was not there 
>> in 
>> the buildlog for branch, so I added it as a requirement.
> 
> please can you paste the relevant part of log? i have hard time to understand 
> why we need bc.

I think because of the conversion of the Qt version number from e.g. hex 4.6.3 
to decimal value.
Unfortunately, this has to be passed to moc explicitly.
Perhaps this can be solved in some other way...

Stephan

Re: [patch] Re: \textvisiblespace

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
>> Attached is a patch that does this.
>>
>> The advantage is that we avoid confusions. If we would implement it as
>> InsetSpace, it is hard for the user to distinguish it within LyX from
>> the other spaces.
>
> Just output it in black instead of blue.

this is already implemented in my 2nd patch and works fine.

> + case VISIBLE_SPACE:
> + os << "|_|";
> + return 3;
>
> I do not think it makes much sense to use this ascii-art output here. I 
> would use a plain space or an underscore. Or even the unicode character, 
> since we output to utf8 (Hmmm, do we?)

not tested but iirc i saw some complaint that we dont use utf8 as an
output. anyway we should use just plain ' '. using "|_|" is just crazy
when you understand it can be part of C++ code output ;)

i didnt checked carefully, but isn't this patch missing fileformat bump?
pavel

Re: [patch] Re: \textvisiblespace

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> And this is exactly why it makes sense. It's a possibility to represent a 
> space. Why shouldn't InsetSpace allow for that possibility?
> 
> The discussion about glyph classification ("technical symbol" vs. "space") is 
> completely irrelevant for most users. They might just want to "make a space 
> visible", and that's what \textvisible space is useful for.

the border of "technical symbol" vs. "space" is fuzzy to me and i don't
have hard opinion to dicuss it.

but to sum up as the time passed we have 3 patches:
1. special symbol - simple unicode char
2. part of insetspace
3. special symbol - specific drawing

if my counting is right than
1 - Guenter
2 - Juergen, JMarc
3 - Uwe

correct?

my vote can go to any solution which also have change tracking painting
correct. i didn't tested it for all solutions yet (busy atm), but it was
the real cause why i started the whole thread.

don't need space in the code block (we have listings after all - they already
know this) but need to typeset and see colorized(corrected) whitespace typos in
the proofread of book, so CT is the critical point for me.

pavel

Re: [patch] Re: \textvisiblespace

[Jürgen Spitzmüller]

Pavel Sanda wrote:
> the border of "technical symbol" vs. "space" is fuzzy to me and i don't
> have hard opinion to dicuss it.
> 
> but to sum up as the time passed we have 3 patches:
> 1. special symbol - simple unicode char
> 2. part of insetspace
> 3. special symbol - specific drawing
> 
> if my counting is right than
> 1 - Guenter
> 2 - Juergen, JMarc
> 3 - Uwe
> 
> correct?

My vote is to both integrate it to InsetSpace and to support it via 
unicodesymbols (if not already the case). Both approaches have different uses, 
and as already pointed out in an earlier mail to this thread, we cover many 
glyphs via unicodesymbols that are also available via specific insets or 
otherwise (think NO_BREAK_SPACE, think ENDASH, f.ex.).

Jürgen

Re: about the initials module

[Pavel Sanda]

Uwe Stöhr wrote:
> Hi Pavel,
>
> in the page http://wiki.lyx.org/LyX/NewInLyX20 there was the icon that the 
> initial module is documented. Where is it, I cannot find it?

i put the tickmark of documented feature when the module description inside 
settings
dialog is enough to grab all information needed. 

as sidecomment i dont think that adding specific features which pull extra
packages into our manuals is a healthy thing. they are not compilable on
various situations then and produce strange errors like when we added mchem
notion into math manual and instant preview stop to work or even compile
for some users.

i will review your current changes soon.
pavel

Re: [patch] Re: \textvisiblespace

[Jean-Marc Lasgouttes]

Le 19/07/2011 08:41, Jürgen Spitzmüller a écrit :

That's not true for all spaces. Non-break spaces are of fixed width as well.
And so is \thinspace.

[...]


And this is exactly why it makes sense. It's a possibility to represent a
space. Why shouldn't InsetSpace allow for that possibility?

The discussion about glyph classification ("technical symbol" vs. "space") is
completely irrelevant for most users. They might just want to "make a space
visible", and that's what \textvisible space is useful for.


Even better than AI: Jürgen Spitzmüller! You write my message even 
before I have begun to formulate it properly in my head. That's great.


JMarc

Re: about the initials module

[Jean-Marc Lasgouttes]

Le 19/07/2011 11:55, Pavel Sanda a écrit :

as sidecomment i dont think that adding specific features which pull extra
packages into our manuals is a healthy thing. they are not compilable on
various situations then and produce strange errors like when we added mchem
notion into math manual and instant preview stop to work or even compile
for some users.


Indeed.

JMarc

PS: BTW Uwe, did you see my messages about the \LyX macro? Since r37164 
it is robust under hyperref and it is not necessary to redefine it in 
preamble.

Re: I am moving to Switzerland

[Jean-Marc Lasgouttes]

Le 19/07/2011 10:08, Abdelrazak Younes a écrit :

Hi there,

I see that there's a lot of request to help for me in Trac; I would be
very happy to but I am very busy these days...
I am starting a new job in August in Switzerland and I am preparing my
moving to there with the family. So don't expect much from me in the
coming weeks.


And eventually, does this mean less or more time to hack on LyX?

Have a nice trip.

JMarc

Re: changeset/39333

[Jean-Marc Lasgouttes]

Le 19/07/2011 10:52, Pavel Sanda a écrit :

It is the privilege of the new developer to pick a user name. cmd is not
weirder than gmatht, after all :)


nobody asked me !?@$%!~ ;p


Hmm, maybe at the time the privilege did not exist, then.

Re: I am moving to Switzerland

[José Matos]

On 07/19/2011 11:13 AM, Jean-Marc Lasgouttes wrote:

Have a nice trip.

JMarc 


+1 :-)

--
José Matos

Re: I am moving to Switzerland

[Abdelrazak Younes]

On 19/07/2011 12:13, Jean-Marc Lasgouttes wrote:

Le 19/07/2011 10:08, Abdelrazak Younes a écrit :

Hi there,

I see that there's a lot of request to help for me in Trac; I would be
very happy to but I am very busy these days...
I am starting a new job in August in Switzerland and I am preparing my
moving to there with the family. So don't expect much from me in the
coming weeks.


And eventually, does this mean less or more time to hack on LyX?


Compared to what? I haven't been very active last two years :-)

My new job will be very challenging, a lot of new things to learn. But 
the good news is that I will do even more Software development so I will 
definitely try to keep track of LyX.




Have a nice trip.


Thanks,
Abdel.

LyX meeting? (Re: I am moving to Switzerland)

[Abdelrazak Younes]

On 19/07/2011 12:13, Jean-Marc Lasgouttes wrote:

Le 19/07/2011 10:08, Abdelrazak Younes a écrit :

Hi there,

I see that there's a lot of request to help for me in Trac; I would be
very happy to but I am very busy these days...
I am starting a new job in August in Switzerland and I am preparing my
moving to there with the family. So don't expect much from me in the
coming weeks.


And eventually, does this mean less or more time to hack on LyX?


Thinking about it, my family will be on holidays between the 5th and the 
12th of August. So my new appartment will be empty (except for the still 
unpacked stuff of course).


Is there interest in a LyX meeting during the week-end between the 5th 
and the 7th? I will leave in a very nice area close to Lausanne 5 
minutes walk to the Léman lake.


Abdel.

Re: build error with trunk on openSUSE

[Cor Blom]

Op dinsdag 19 juli 2011 10:47:50 schreef Pavel Sanda:
> please can you paste the relevant part of log? i have hard time to
> understand why we need bc.

Here it is:

[...]
  GENui_TocUi.h
  GENui_ToggleWarningUi.h
  GENui_VSpaceUi.h
  GENui_ViewSourceUi.h
  GENui_WrapUi.h
/bin/sh: bc: command not found
  GENmoc_Action.cpp
/bin/sh: bc: command not found
  GENmoc_BulletsModule.cpp
/bin/sh: bc: command not found
  GENmoc_CustomizedWidgets.cpp
/bin/sh: bc: command not found
  GENmoc_EmptyTable.cpp
/bin/sh: bc: command not found
  GENmoc_FancyLineEdit.cpp
/bin/sh: bc: command not found
  GENmoc_FindAndReplace.cpp
/bin/sh: bc: command not found
  GENmoc_FloatPlacement.cpp
/bin/sh: bc: command not found
  GENmoc_GuiAbout.cpp
/bin/sh: bc: command not found
  GENmoc_GuiApplication.cpp
/bin/sh: bc: command not found
  GENmoc_GuiBibitem.cpp
/bin/sh: bc: command not found
  GENmoc_GuiBibtex.cpp
/bin/sh: bc: command not found
  GENmoc_GuiBox.cpp
/bin/sh: bc: command not found
  GENmoc_GuiBranches.cpp
/bin/sh: bc: command not found
  GENmoc_GuiBranch.cpp
/bin/sh: bc: command not found
  GENmoc_GuiChanges.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCharacter.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCitation.cpp
/bin/sh: bc: command not found
  GENmoc_GuiClipboard.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCommandBuffer.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCommandEdit.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCompare.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCompareHistory.cpp
/bin/sh: bc: command not found
  GENmoc_GuiCompleter.cpp
/bin/sh: bc: command not found
  GENmoc_GuiDelimiter.cpp
/bin/sh: bc: command not found
  GENmoc_GuiDialog.cpp
/bin/sh: bc: command not found
  GENmoc_GuiDocument.cpp
/bin/sh: bc: command not found
  GENmoc_GuiErrorList.cpp
/bin/sh: bc: command not found
  GENmoc_GuiERT.cpp
/bin/sh: bc: command not found
  GENmoc_GuiExternal.cpp
/bin/sh: bc: command not found
  GENmoc_GuiGraphics.cpp
/bin/sh: bc: command not found
  GENmoc_GuiHSpace.cpp
/bin/sh: bc: command not found
  GENmoc_GuiHyperlink.cpp
/bin/sh: bc: command not found
  GENmoc_GuiInclude.cpp
/bin/sh: bc: command not found
  GENmoc_GuiIndex.cpp
/bin/sh: bc: command not found
  GENmoc_GuiIndices.cpp
/bin/sh: bc: command not found
  GENmoc_GuiInfo.cpp
/bin/sh: bc: command not found
  GENmoc_GuiLabel.cpp
/bin/sh: bc: command not found
  GENmoc_GuiLine.cpp
/bin/sh: bc: command not found
  GENmoc_GuiListings.cpp
/bin/sh: bc: command not found
  GENmoc_GuiLog.cpp
/bin/sh: bc: command not found
  GENmoc_GuiMathMatrix.cpp
/bin/sh: bc: command not found
  GENmoc_GuiNomenclature.cpp
/bin/sh: bc: command not found
  GENmoc_GuiNote.cpp
/bin/sh: bc: command not found
  GENmoc_GuiParagraph.cpp
/bin/sh: bc: command not found
  GENmoc_GuiPhantom.cpp
/bin/sh: bc: command not found
  GENmoc_GuiPrefs.cpp
/bin/sh: bc: command not found
  GENmoc_GuiPrint.cpp
/bin/sh: bc: command not found
  GENmoc_GuiPrintindex.cpp
/bin/sh: bc: command not found
  GENmoc_GuiPrintNomencl.cpp
/bin/sh: bc: command not found
  GENmoc_GuiProgress.cpp
/bin/sh: bc: command not found
  GENmoc_GuiProgressView.cpp
/bin/sh: bc: command not found
  GENmoc_GuiRef.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSearch.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSelection.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSelectionManager.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSendto.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSetBorder.cpp
/bin/sh: bc: command not found
  GENmoc_GuiShowFile.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSpellchecker.cpp
/bin/sh: bc: command not found
  GENmoc_GuiSymbols.cpp
/bin/sh: bc: command not found
  GENmoc_GuiTabularCreate.cpp
/bin/sh: bc: command not found
  GENmoc_GuiTabular.cpp
/bin/sh: bc: command not found
  GENmoc_GuiTexinfo.cpp
/bin/sh: bc: command not found
  GENmoc_GuiThesaurus.cpp
/bin/sh: bc: command not found
  GENmoc_GuiToc.cpp
/bin/sh: bc: command not found
  GENmoc_GuiToolbar.cpp
/bin/sh: bc: command not found
  GENmoc_GuiView.cpp
/bin/sh: bc: command not found
  GENmoc_GuiViewSource.cpp
/bin/sh: bc: command not found
  GENmoc_GuiVSpace.cpp
/bin/sh: bc: command not found
  GENmoc_GuiWorkArea.cpp
/bin/sh: bc: command not found
  GENmoc_GuiWrap.cpp
/bin/sh: bc: command not found
  GENmoc_IconPalette.cpp
/bin/sh: bc: command not found
  GENmoc_InGuiThread.cpp
/bin/sh: bc: command not found
  GENmoc_InsertTableWidget.cpp
/bin/sh: bc: command not found
  GENmoc_InsetParamsDialog.cpp
/bin/sh: bc: command not found
  GENmoc_InsetParamsWidget.cpp
/bin/sh: bc: command not found
  GENmoc_LayoutBox.cpp
/bin/sh: bc: command not found
  GENmoc_LengthCombo.cpp
/bin/sh: bc: command 

Re: LyX meeting? (Re: I am moving to Switzerland)

[Abdelrazak Younes]

On 19/07/2011 13:22, Abdelrazak Younes wrote:

On 19/07/2011 12:13, Jean-Marc Lasgouttes wrote:

Le 19/07/2011 10:08, Abdelrazak Younes a écrit :

Hi there,

I see that there's a lot of request to help for me in Trac; I would be
very happy to but I am very busy these days...
I am starting a new job in August in Switzerland and I am preparing my
moving to there with the family. So don't expect much from me in the
coming weeks.


And eventually, does this mean less or more time to hack on LyX?


Thinking about it, my family will be on holidays between the 5th and 
the 12th of August. So my new appartment will be empty (except for the 
still unpacked stuff of course).


Is there interest in a LyX meeting during the week-end between the 5th 
and the 7th? I will leave in a very nice area close to Lausanne 5 
minutes walk to the Léman lake.


I will _live_ in a nice area...

Abdel.

Re: Missing features in Flex insets and style definition question

[Uwe Stöhr]

Am 19.07.2011 10:15, schrieb Jean-Marc Lasgouttes:


This doesn't help, because in some cases you need the feature that LyX
does not add nothing, no par break and also no newline but to continue
with the code right after the command.


Looks like a very badly coded macro, then.


No, these cases occur often. They are also not "badly coded" but standard and valid LaTeX that 
commands affect the paragraph they are in.


As said, we already support such LaTeX commands via InsetLayout, but we need to add for InsetLayout 
also the support of arguments.



Richard is right that InsetLayout
is designed for this, but this is only usable if InsetLayout supports
also arguments. It is not yet clear to me why this is not supported. I'm
not familiar with the layout code but I assumed that it should not be
very hard to implement. Would at least be a very valuable feature for
LyX 2.1.


Yes, it should be done eventually, and it is not very difficult. However, I 
think it would be better
to factor in the two cases, rather then duplicating code (with subtly different 
bugs :)


Will you do this or is this something for Richard? Should I open an enhancement 
bug report?

regards Uwe

Re: about the initials module

[Uwe Stöhr]

Am 19.07.2011 11:55, schrieb Pavel Sanda:


in the page http://wiki.lyx.org/LyX/NewInLyX20 there was the icon that the
initial module is documented. Where is it, I cannot find it?


i put the tickmark of documented feature when the module description inside 
settings
dialog is enough to grab all information needed.


Sorry, but

"Define character style for initials. Hint: try to use math and its artistic font styles like 
Fractur or the Calligraphic one."


is no documentation. With this info the module is useless. Where should I use what, insert what? 
Where comes the math, what has math to do with an initial? And what about the arguments one needs 
for initials?



as sidecomment i dont think that adding specific features which pull extra
packages into our manuals is a healthy thing.  they are not compilable on
various situations then and produce strange errors like when we added mchem
notion into math manual and instant preview stop to work or even compile
for some users.


Our manuals have to describe what you can do with LyX. There is no other way. It might always be 
possible that our docs are uncompilable. We cannot control what LaTeX-packages are installed on a 
system. Or where do you want to set the line? For example wrapfig might not be installed, should we 
therefore not document wrapped floats? booktabs might not be installed should we therefore not 
document all our table features so that the user might ask his self "What is this booktabs option in 
the table dialog about, I cannot find it in the docs?".


In general the basic rule applies: "An undocumented feature is an unused feature." So we have to 
document it somewhere. I use the EmbeddedObjects manual to document the more trickery package 
support and some tips and tricks. If a package is really exotic or interferes potentially with 
others, I put it into an extra file.


In case of packages that seem to be not widely used and might probably not be installed, I added 
notes to the docs which package is needed for what sections. For some features I even use a 
construct that you get a special section content if the package is not available. So the document is 
still compilable.


regards Uwe

Re: LyX meeting? (Re: I am moving to Switzerland)

[Jean-Marc Lasgouttes]

Le 19/07/2011 13:22, Abdelrazak Younes a écrit :

Thinking about it, my family will be on holidays between the 5th and the
12th of August. So my new appartment will be empty (except for the still
unpacked stuff of course).

Is there interest in a LyX meeting during the week-end between the 5th
and the 7th? I will leave in a very nice area close to Lausanne 5
minutes walk to the Léman lake.


That's very tempting, but I will be on vacation with the family.

JMarc

Re: Missing features in Flex insets and style definition question

[Jean-Marc Lasgouttes]

Le 19/07/2011 13:47, Uwe Stöhr a écrit :

No, these cases occur often. They are also not "badly coded" but
standard and valid LaTeX that commands affect the paragraph they are in.


What typical examples do you have in mind?

JMarc

Re: Missing features in Flex insets and style definition question

[Jean-Marc Lasgouttes]

Le 19/07/2011 13:47, Uwe Stöhr a écrit :

Yes, it should be done eventually, and it is not very difficult.
However, I think it would be better
to factor in the two cases, rather then duplicating code (with subtly
different bugs :)


Will you do this or is this something for Richard? Should I open an
enhancement bug report?


I do not think I will have time to do it, unfortunately.

JMarc

Re: Missing features in Flex insets and style definition question

[Uwe Stöhr]

Am 19.07.2011 14:23, schrieb Jean-Marc Lasgouttes:


Le 19/07/2011 13:47, Uwe Stöhr a écrit :

No, these cases occur often. They are also not "badly coded" but
standard and valid LaTeX that commands affect the paragraph they are in.


What typical examples do you have in mind?


Pictures in paragraphs (e.g. via picins, picinpar), wrapped floats, initials, email commands, 
address formatting commands, various scientific paper titling commands, ...


regards Uwe

Re: Missing features in Flex insets and style definition question

[Jean-Marc Lasgouttes]

Le 19/07/2011 14:28, Uwe Stöhr a écrit :

Pictures in paragraphs (e.g. via picins, picinpar), wrapped floats,
initials, email commands, address formatting commands, various
scientific paper titling commands, ...


Most of these are indeed part of a paragraph an thus should be handled 
by custom insets. There is no point to change normal layouts for them.


JMarc

Re: Missing features in Flex insets and style definition question

[Uwe Stöhr]

Am 19.07.2011 14:38, schrieb Jean-Marc Lasgouttes:


Most of these are indeed part of a paragraph an thus should be handled by 
custom insets. There is no
point to change normal layouts for them.


Yes, we already agree here. The only pint is that InsetLayout (a.k.a. flex inset) does not yet 
support arguments, but we need this for many cases. For example many paper titling commands support 
optional arguments (for second authors, reviewers, editors), and some of our templates/example files 
look currently a bit ugly in LyX with some TeX code because of the missing argument support.


regards Uwe

Re: build error with trunk on openSUSE

[Stephan Witt]

Am 19.07.2011 um 11:05 schrieb Stephan Witt:

> Am 19.07.2011 um 10:47 schrieb Pavel Sanda:
> 
>> Cor Blom wrote:
>>> bc: GNU Command Line Calculator
>>> 
>>> After your last remark I looked again through the log and noticed that the 
>>> shell complained that "bc" could not be found. This complaint was not there 
>>> in 
>>> the buildlog for branch, so I added it as a requirement.
>> 
>> please can you paste the relevant part of log? i have hard time to 
>> understand 
>> why we need bc.
> 
> I think because of the conversion of the Qt version number from e.g. hex 
> 4.6.3 to decimal value.

Vice versa of course.

> Unfortunately, this has to be passed to moc explicitly.
> Perhaps this can be solved in some other way...
> 

In case of interest

QT_VERSION="4.10.3" sh -c 'v="0x0"; for i in ${QT_VERSION//./ } ; do case $i in 
10) v=$v"0a" ;; 11) v=$v"0b" ;; 12) v=$v"0c" ;; 13) v=$v"0d" ;; 14) v=$v"0e" ;; 
15) v=$v"0f" ;; *) v=$v"0"$i ;; esac ; done; echo $v'

prints 0x0040a03

Stephan

Re: changeset 39344

[Richard Heck]

On 07/19/2011 01:17 AM, Uwe Stöhr wrote:
> Richard,
>
> am I allowed to remove the file enumitem.lyx from branch too? Its
> content is now in the UserGuide.
> My goal was to merge all these infos into one place because before we
> described customized lists in the Additional manual and the enumitem
> example file.
>
That's fine.

rh

Re: Missing features in Flex insets and style definition question

[Richard Heck]

On 07/19/2011 08:25 AM, Jean-Marc Lasgouttes wrote:
> Le 19/07/2011 13:47, Uwe Stöhr a écrit :
>>> Yes, it should be done eventually, and it is not very difficult.
>>> However, I think it would be better
>>> to factor in the two cases, rather then duplicating code (with subtly
>>> different bugs :)
>>
>> Will you do this or is this something for Richard? Should I open an
>> enhancement bug report?
>
> I do not think I will have time to do it, unfortunately.
>
I'm still hoping to do some major reworking of how arguments are
handled, i.e., get rid of that inset. It should be easy to include this
for InsetLayout.

Richard

Re: Fwd: Additional manual

[Jean-Pierre Chrétien]

Le 17/07/2011 12:02, Pavel Sanda a écrit :

Uwe Stöhr wrote:

section 7.2.1: sentence

"Before you begin to use the version control features in LyX, you should
be
familiar with RCS/CVS/SVN usage before start using it under LyX."


Indeed. I removed this now.


the wording maybe wrong in terms of style but this information should be there.
VCS support is not robust at all, so the moment something goes wrong user
must be capable to fix it by himself without help of lyx. without being familiar
of RCS/CVS/SVN this is impossible and we should warn about this.


I wanted to stress the fact that the phrase was redundant, i.e, supressing 
"before start using it under LyX" was OK.


--
Jean-Pierre

Re: Missing features in Flex insets and style definition question

[Uwe Stöhr]

Am 19.07.2011 15:08, schrieb Richard Heck:


I'm still hoping to do some major reworking of how arguments are
handled, i.e., get rid of that inset.


What do you have in mind instead? I have now a lot of experience with it and find the current 
implementation acceptable, except of these 2 things:


- the menu entry must read "optional Argument, not "short title" (this is misleading and this 
appears often at the users list that people are confused, a short title is only ONE occurrence of 
optional arguments
- If there is a mandatory argument, the inset should appear directly when using the style and it 
must not be allowed to delete this inset; this inset should have the label "req" (for required) and 
not "opt".


Should I store thesesuggestions in an enhancement request?

regards Uwe

Re: Missing features in Flex insets and style definition question

[Richard Heck]

On 07/19/2011 09:58 AM, Uwe Stöhr wrote:
> Am 19.07.2011 15:08, schrieb Richard Heck:
>
>> I'm still hoping to do some major reworking of how arguments are
>> handled, i.e., get rid of that inset.
>
> What do you have in mind instead? I have now a lot of experience with
> it and find the current implementation acceptable, except of these 2
> things:
>
> - the menu entry must read "optional Argument, not "short title" (this
> is misleading and this appears often at the users list that people are
> confused, a short title is only ONE occurrence of optional arguments
>
It's much less clear how you can label different insets differently.
E.g., if there is one required argument and one optional one. Now what?

> - If there is a mandatory argument, the inset should appear directly
> when using the style and it must not be allowed to delete this inset;
> this inset should have the label "req" (for required) and not "opt".
>
This is bigger the problem. It's like with Bibitems, which are a mess.
You have to make sure no one deletes it, or moves it, or tries to type
in front of it. It's just not an inset.

The idea is to let arguments be typed into some sort of dialog, e.g., in
a new Arguments pane of the paragraph settings dialog. This is easy,
except for the fact that we want people to be able to type LyX, not
LaTeX, which means using the sort of embedded buffer that's used in the
advanced F dialog. That will take more work.

Richard

Re: Missing features in Flex insets and style definition question

[Jürgen Spitzmüller]

Richard Heck wrote:
> > - the menu entry must read "optional Argument, not "short title" (this
> > is misleading and this appears often at the users list that people are
> > confused, a short title is only ONE occurrence of optional arguments
> 
> It's much less clear how you can label different insets differently.
> E.g., if there is one required argument and one optional one. Now what?

And that's why it should not be labelled "optional" or "required argument", 
but it should be semantically precise. "Short title" is (for the case the 
inset was initially developed). "Longest label" is as well. LyX should tell 
the user what this argument does, not just that it is an optional argument. 
This is possible with some extended argument definition in the layout file. 
Instead of

OptionalArgs 2

do something like

Argument
Type   optional
   Order  1
   Label  "Short title in TOC"
EndArgument

Argument
Type   optional
   Order  2
   Label  "Short title in header"
EndArgument

> > - If there is a mandatory argument, the inset should appear directly
> > when using the style and it must not be allowed to delete this inset;
> > this inset should have the label "req" (for required) and not "opt".
> 
> This is bigger the problem. It's like with Bibitems, which are a mess.
> You have to make sure no one deletes it, or moves it, or tries to type
> in front of it. It's just not an inset.

Yes, this is not possible in a sane way with a collapsable inset.

> The idea is to let arguments be typed into some sort of dialog, e.g., in
> a new Arguments pane of the paragraph settings dialog. 

Also consider that we already have this. "Longest label" in the paragraph 
dialog is just another implementation of a specific (required) argument. We 
just need to extend this concept.

> This is easy,
> except for the fact that we want people to be able to type LyX, not
> LaTeX, which means using the sort of embedded buffer that's used in the
> advanced F dialog. That will take more work.

Yes, but it's possible.

Jürgen

Re: LyX meeting? (Re: I am moving to Switzerland)

[Pavel Sanda]

Abdelrazak Younes wrote:
> Is there interest in a LyX meeting during the week-end between the 5th and 
> the 7th? I will leave in a very nice area close to Lausanne 5 minutes walk 

very unprobable i will have spare time during this summer...

isn't Juergen the swiss layman now as well?
pavel