RE: r33962 - in lyx-devel/trunk: development lib/layouts lib/lyx2lyx src src/frontends/qt4 src/frontends/qt4/ui

[Vincent van Ravesteijn - TNW]

 
 i understand the problem but this is really ugly. we must find
another way.
 either shortcuting a-la 'Greyedout color' and the rest in tooltip  
 or use something else then label.

Why is having a label over 2 lines ugly? Qt supports this and
also many other applications have this. Moreover the font dialog
look OK to me. In fact it's only a matter of taste, isn't it?
What do others think?


It's ugly, and I don't want HTML as the label. 

How could you even add this HMTL stuff and things like font-family:'MS
Shell Dlg 2 to the ui files in the first place ?

regards Uwe

Vincent

Re: edit ERT insets with external editor?

[Abdelrazak Younes]

On 03/31/2010 05:53 PM, Liviu Andronic wrote:

Dear LyX developers
Would it be a good idea to allow users to edit ERT insets with an
external editor? I am thinking of something similar to:
1. Have a Edit with external editor entry to the ERT inset context menu
2. When activated, LyX would export the current contents of the ERT
inset to a temporary file, and open it with a (pre-defined) text
editor
3. When the user finishes editing the ERT code externally, saves the
temporary file and closes the editor, LyX automatically imports the
contents of the file in the ERT inset (if feasible) or the user
manually activates a Refresh inset context-menu entry

Such a feature should be useful to users that make heavy use of LaTeX
code in their documents. Personally I would use it for editing R code
in Sweave documents: when the code gets too complex, it is unbearable
to edit it in the ERT insets (no syntax highlighting, matching braces,
easy indentation, etc.). What do you think?
   


It is a good idea but it sounds a bit complicated to implement for the 
communication of the child process; but it doable.


Another good option would be to use QScintilla:

  http://www.riverbankcomputing.com/software/qscintilla/intro

Abdel.

Re: r33993 - lyx-devel/trunk/lib/ui

[Abdelrazak Younes]

On 03/31/2010 11:37 PM, Pavel Sanda wrote:

Vincent van Ravesteijn wrote:
   

By the way, the git repository seems to be sleeping since oktober or so ?
 

yes, its not under our control and maintainer doesn't respond.
other possibility would be to have it on our server, but Christian
didn't look to be interested.
   


What about http://gitorious.org/ ? I used that for a project 
(http://gitorious.org/sgt in case you're interested) and it works just 
fine and reliably.


Abdel.

Re: Branch Patch: LyxBlogger Config

[Jürgen Spitzmüller]

Jack Desert wrote:

 Here is a patch to configure LyxBlogger in 1.6.x.
 
 Jurgen, are you the approval committee for branch patches?

Yes, although comittee sound a bit exaggerated ;-)

As to the patch: I am fine with it in general. However, as for 1.6.6, we are 
almost finished, and I'd like to stick with critical bug fixes for now. So 
if no one urges me to reconsider, I propose to postpone this to 1.6.7 (and 
put it in as soon as 1.6.6 is released).

Is this OK?

Jürgen

Re: r33993 - lyx-devel/trunk/lib/ui

[Pavel Sanda]

Abdelrazak Younes wrote:
 What about http://gitorious.org/ ? I used that for a project 
 (http://gitorious.org/sgt in case you're interested) and it works just fine 
 and reliably.

are you able to setup it? (we would need full history and all branches 
included).

pavel

Re: r33993 - lyx-devel/trunk/lib/ui

[Abdelrazak Younes]

On 04/01/2010 12:34 PM, Pavel Sanda wrote:

Abdelrazak Younes wrote:
   

What about http://gitorious.org/ ? I used that for a project
(http://gitorious.org/sgt in case you're interested) and it works just fine
and reliably.
 

are you able to setup it? (we would need full history and all branches 
included).
   


If you mean create a project for it with one or more users with pushing 
rigth, yes. If you mean svn2git migration, no.


Abdel.

Re: r33993 - lyx-devel/trunk/lib/ui

[Pavel Sanda]

Abdelrazak Younes wrote:
 If you mean create a project for it with one or more users with pushing 
 rigth, yes. If you mean svn2git migration, no.

yes i meant the migration ;)
pavel

Re: ANNOUNCE: LyX version 2.0.0 (alpha 1)

[Sebastian Rockel]

Am 31.03.2010 um 19:31 schrieb Micha Feigin:

 On Wed, 31 Mar 2010 15:35:42 +0200
 Sebastian Rockel sebastianroc...@googlemail.com wrote:
 
 Am 31.03.2010 um 14:47 schrieb Pavel Sanda:
 
 Sebastian Rockel wrote:
 Here in the mac version I cannot enable it due to everything on that pref 
 pane is grayed out:-/
 
 normal spellcheck works?
 
 Also the menu item is grayed out (F7 doesn't do it either).
 I just double checked Lyx 1.6.5 with aspell 0.60.6 (MacPorts) and it works 
 fine.
 Running on Mac OSX 10.6.3.
 
 Sebastian
 
 Sounds to me like you didn't have the aspell development libraries (or other
 spell developement libraries) when configuring. I also had that problem under
 linux (debian). I installed libaspell-dev and now spelling is working. Not 
 sure
 what the right package is under OsX or how to install it though.

Thanks for the hint, did use the pre-build .dmg version though (see below).

 
 
 pavel



Am 01.04.2010 um 00:37 schrieb Stephan Witt:

 Am 31.03.2010 um 15:35 schrieb Sebastian Rockel:
 
 Am 31.03.2010 um 14:47 schrieb Pavel Sanda:
 
 Sebastian Rockel wrote:
 Here in the mac version I cannot enable it due to everything on that pref 
 pane is grayed out:-/
 
 normal spellcheck works?
 
 Also the menu item is grayed out (F7 doesn't do it either).
 I just double checked Lyx 1.6.5 with aspell 0.60.6 (MacPorts) and it works 
 fine.
 Running on Mac OSX 10.6.3.
 
 I guess you're using the LyX-2.0.0alpha1.dmg I build on Snow Leopard.
 
 You're right, no aspell support :(
 I didn't read carefully enough this part of configure output:
 
 checking aspell.h usability... yes
 checking aspell.h presence... yes
 checking for aspell.h... yes
 checking for new_aspell_config in -laspell... no
 checking whether to use aspell... no
 
 So I looked for the reason and found that configure detected the headers of 
 aspell but did not find the library.

Thanks for this clarification and for the build anyway.

Sebastian

 When trying to improve the situation I learned that my universal aspell 
 library from macports is like that:
 
 % file /opt/local/lib/libaspell.dylib 
 /opt/local/lib/libaspell.dylib: Mach-O universal binary with 2 architectures
 /opt/local/lib/libaspell.dylib (for architecture x86_64): Mach-O 64-bit 
 dynamically linked shared library x86_64
 /opt/local/lib/libaspell.dylib (for architecture i386):   Mach-O 
 dynamically linked shared library i386
 
 So in fact I cannot build a ppc version of LyX with aspell now. I'll see what 
 I can do...
 
 Stephan
 

Re: Warning

[rgheck]

On 03/31/2010 04:21 PM, Pavel Sanda wrote:

1. new file
2. insert child doc, eg Additional.lyx
3. console output:
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem

   
I think this is expected behavior, at present. The theorem module is not 
loaded into the master document.


rh

Re: edit ERT insets with external editor?

[rgheck]

On 04/01/2010 04:41 AM, Abdelrazak Younes wrote:

On 03/31/2010 05:53 PM, Liviu Andronic wrote:

Dear LyX developers
Would it be a good idea to allow users to edit ERT insets with an
external editor? [snip]


It is a good idea but it sounds a bit complicated to implement for the 
communication of the child process; but it doable.


Another good option would be to use QScintilla:

  http://www.riverbankcomputing.com/software/qscintilla/intro

Couldn't we do this internally, fairly easily? We already have LaTeX 
highlighting in the preamble.


rh

Re: Branch Patch: LyxBlogger Config

[rgheck]

On 04/01/2010 05:59 AM, Jürgen Spitzmüller wrote:

Jack Desert wrote:

   

Here is a patch to configure LyxBlogger in 1.6.x.

Jurgen, are you the approval committee for branch patches?
 

Yes, although comittee sound a bit exaggerated ;-)

As to the patch: I am fine with it in general. However, as for 1.6.6, we are
almost finished, and I'd like to stick with critical bug fixes for now. So
if no one urges me to reconsider, I propose to postpone this to 1.6.7 (and
put it in as soon as 1.6.6 is released).

Is this OK?

   

OK by me.

rh

RE: r34005 - in lyx-devel/trunk: . lib/scripts src

[Vincent van Ravesteijn - TNW]

Log:
Move command line arg --batch to -batch.
Things are still bit inconsistent due to the existence of additional --
switches, but the correct fix is not so easy.


Aren't you now destroying the backward compatibility for all the scripts
that people might have made ?

Isn't it the 'normal' way of operation to have 2 dashes before a 'long'
parameter. I don't really see the need of changing this for no apparent
reason.

If you want to be consistent, maybe you can add a '-b' parameter in
addition to the '--batch' parameter. This seems to be fairly normal.

Vincent

Fantastic branches!

[minime]

Just wanted to pop by to give a well earned praise to the developers  
of Lyx.


I am currently using Lyx to compose a two language minutes of meeting,  
and a agenda thereof. With at few touches I am able to retain true  
tracking and editing in all languages. With branches within tables.


True magic, and most people dont

Most people cannot understand how quick I am able to compose these  
mom' s.


Regards and happy easter to all!

Ronald Ryland

Sendt fra min iPhone

Re: r34005 - in lyx-devel/trunk: . lib/scripts src

[Pavel Sanda]

Vincent van Ravesteijn - TNW wrote:
 Log:
 Move command line arg --batch to -batch.
 Things are still bit inconsistent due to the existence of additional --
 switches, but the correct fix is not so easy.
 
 
 Aren't you now destroying the backward compatibility for all the scripts
 that people might have made ?

this has been introduced in 2.0 so no backward compatibility issue exists.

 Isn't it the 'normal' way of operation to have 2 dashes before a 'long'
 parameter. I don't really see the need of changing this for no apparent
 reason.

there is old unix way of using -arg.

newer way is -c value and allowing of mixing chars without args to be mixed
together like -cXrGt or --long-option=value (note this =).

lyx started the old way.
the inconsitency started when somebody added --execute, --export, --import
and adding 1 char synonyms, while
1) leaving old single dashes opts
2) not distinguishing seperate way of args specification.

adding --batch makes things even worse. because now there is even no
single dash way.

 If you want to be consistent, maybe you can add a '-b' parameter in
 addition to the '--batch' parameter. This seems to be fairly normal.

there is no consistency in our current pars handling.
the consitency could be done via
either killing additional --options (or at least hide them from man pages).
or rewriting the handling to be done correctly the new way. just adding
-b won't do.

in either way adding just --batch made things worse.

pavel

Re: edit ERT insets with external editor?

[Abdelrazak Younes]

On 04/01/2010 05:32 PM, rgheck wrote:

On 04/01/2010 04:41 AM, Abdelrazak Younes wrote:

On 03/31/2010 05:53 PM, Liviu Andronic wrote:

Dear LyX developers
Would it be a good idea to allow users to edit ERT insets with an
external editor? [snip]


It is a good idea but it sounds a bit complicated to implement for 
the communication of the child process; but it doable.


Another good option would be to use QScintilla:

  http://www.riverbankcomputing.com/software/qscintilla/intro

Couldn't we do this internally, fairly easily? We already have LaTeX 
highlighting in the preamble.


Sure, we can and that would already be a very good first step. But only 
we can only highlight LaTeX.


Abdel.

Re: r33962 - in lyx-devel/trunk: development lib/layouts lib/lyx2lyx src src/frontends/qt4 src/frontends/qt4/ui

[Uwe Stöhr]

Vincent van Ravesteijn - TNW schrieb:


i understand the problem but this is really ugly. we must find

another way.
either shortcuting a-la 'Greyedout color' and the rest in tooltip  
or use something else then label.



Why is having a label over 2 lines ugly? Qt supports this and
also many other applications have this. Moreover the font dialog
look OK to me. In fact it's only a matter of taste, isn't it?
What do others think?



It's ugly, and I don't want HTML as the label. 


Why not?


How could you even add this HMTL stuff and things like font-family:'MS
Shell Dlg 2 to the ui files in the first place ?


I don't understand. All I have done was to add a label. I set the label 
text using Qt 4.6 designer. So the code was added by designer, not me.
I cannot comment on the font-family: issue because this was also 
automatically added by designer. (I cannot remember to have used such a 
font purposely - it must be a designer-specific Windows default font.)

I'll have a look at this.

regards Uwe

Re: r33962 - in lyx-devel/trunk: development lib/layouts lib/lyx2lyx src src/frontends/qt4 src/frontends/qt4/ui

[Pavel Sanda]

Uwe Stöhr wrote:
 I don't understand. All I have done was to add a label. I set the label 
 text using Qt 4.6 designer. So the code was added by designer, not me.
 I cannot comment on the font-family: issue because this was also 
 automatically added by designer. (I cannot remember to have used such a 
 font purposely - it must be a designer-specific Windows default font.)
 I'll have a look at this.

its perhaps some 4.6 feature. anyway the text itself in the ui file
must be something trivial like Font color for greyed-out notes or
add \n newline character if you really need this.

but by no way something like:
 quot;http://www.w3.org/TR/REC-html40/strict.dtdquot;gt;
 +lt;htmlgt;lt;headgt;lt;meta name=quot;qrichtextquot; 
 content=quot;1quot; /gt;lt;style type=quot;text/cssquot;gt;
 +p, li { white-space: pre-wrap; }
 +lt;/stylegt;lt;/headgt;lt;body style=quot; font-family:'MS Shell Dlg 
 2'; font-size:8.25pt; font-weight:400; font-style:normal;quot;gt;
 +lt;p style=quot; margin-top:0px; margin-bottom:0px; margin-left:0px; 
 margin-right:0px; -qt-block-indent:0; text-indent:0px;quot;gt;lt;span 
 style=quot; font-size:8pt;quot;gt;Font color forlt;/spangt;lt;/pgt;
 +lt;p style=quot; margin-top:0px; margin-bottom:0px; margin-left:0px; 
 margin-right:0px; -qt-block-indent:0; text-indent:0px;quot;gt;lt;span 
 style=quot; font-size:8pt;quot;gt;greyed-out 
 notes:lt;/spangt;lt;/pgt;lt;/bodygt;lt;/htmlgt;/string

the ugliness should be self evident, but even without esthetical judgements
this will break string translations - no string would be generated
in .po files.

pavel

Re: r34002 - lyx-devel/trunk

[Jean-Marc Lasgouttes]

Le 01/04/2010 13:21, sa...@lyx.org a écrit :

Log:
Lets make tarballs via lzma instead of bzip2 from now on.
Ratios for alpha1:
tgz   16M
bzip2 12M
lzma 8.7M


That's a good gain indeed. What compression is used for windows
installers, BTW?

Two remarks:

1/ this means that we require automake 1.11 and autoconf 2.62. We should 
make this clear.


2/ lzma is deprecated by the almost equivalent but gnu .xz format.

JMarc

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Le 31/03/2010 13:07, Guenter Milde a écrit :

On 2010-03-30, Jean-Marc Lasgouttes wrote:

Pavel Sandasa...@lyx.org  writes:

last call for 2.0 feature requests we have reported.



- currently, Sweave reads the files in the encoding of the current
   locale. This fails as soon as the locale is UTF-8 and the document is
   8bit (because the characters themselves are ruined). We need to find a
   way to pass the encoding to the function.
http://www.lyx.org/trac/ticket/6625


I wonder if we could use utf-8 as default latex source encoding for most
(all) languages if the locale is UTF-8.


AFAIK, UTF8 support is too weak in LaTeX right now. And people should be 
able to chose the encoding they want.


Note that a good workaround for this bug is to use ascii encoding.

JMarc

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Le 30/03/2010 14:01, Jean-Marc Lasgouttes a écrit :

- pass the noae option to Sweave to make sure it does not ruin our
   font settings.
http://www.lyx.org/trac/ticket/6624


This one is fixed now.

JMarc

Re: r34002 - lyx-devel/trunk

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 1/ this means that we require automake 1.11 and autoconf 2.62. We should 
 make this clear.

you mean to add it to release notes?

 2/ lzma is deprecated by the almost equivalent but gnu .xz format.

i know and tried both. there was no difference in compression ratio
and xz didn't looked to be supported by autotools yet. also except
arch, distros seems to accept lzma better.

pavel

Re: r34002 - lyx-devel/trunk

[Jean-Marc Lasgouttes]

Le 01/04/2010 23:46, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

1/ this means that we require automake 1.11 and autoconf 2.62. We should
make this clear.


you mean to add it to release notes?


No, in autogen.sh and INSTALL. Also in the INIT_AUTOMAKE call.




2/ lzma is deprecated by the almost equivalent but gnu .xz format.


i know and tried both. there was no difference in compression ratio
and xz didn't looked to be supported by autotools yet. also except
arch, distros seems to accept lzma better.


Support for xz and lzma have been added at the same time in automake. 
Actually, you should use 1.11.1, since there is a security bug in make 
dist in older autimake versions.


Recent GNU software is distributed as xz now.

JMarc

Re: r34002 - lyx-devel/trunk

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 2/ lzma is deprecated by the almost equivalent but gnu .xz format.

 i know and tried both. there was no difference in compression ratio
 and xz didn't looked to be supported by autotools yet. also except
 arch, distros seems to accept lzma better.

 Support for xz and lzma have been added at the same time in automake. 

are you sure? my 1.10.3 generated makefile knows dist-lzma, but not dist-xz
target. after hard fight i forced gentoo automake wrapper to choose 1.11.1 and
dist-xz appeared.

 Recent GNU software is distributed as xz now.

requiring 1.11 is not too much? i belive people start to scream
and we need this only for people wanting make dist, which is me
and Juergen later on...

and finally - hold your hat - when using the attached patch for xz
i got tarball half mega bigger then lzma, because autotools set
-9 compression level for lzma, but not for xz :/
any way how to set it up?

pavel
diff --git a/autogen.sh b/autogen.sh
index da8b6aa..49eebdb 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -15,13 +15,14 @@ test $automake_version !=   {
 exit 1
 }
 
+echo $automake_version
 case $automake_version in
-*' '1.[8-9]*|*' '1.1[01]*)
+*' '1.11*)
 	;;
 *)
 
 	echo This automake version is not supported by LyX.
-	echo LyX only supports automake 1.8 to 1.11.
+	echo LyX only supports automake 1.11(.1)
 	exit 1
 	;;
 esac
diff --git a/configure.ac b/configure.ac
index 76c87bd..b9d01b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -26,7 +26,7 @@ fi
 AM_MAINTAINER_MODE
 
 save_PACKAGE=$PACKAGE
-AM_INIT_AUTOMAKE([foreign dist-lzma no-define 1.8])
+AM_INIT_AUTOMAKE([foreign dist-xz no-define 1.11])
 m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])])
 PACKAGE=$save_PACKAGE
 

Re: Branch Patch: LyxBlogger Config

[Jack Desert]

El Thu, 01 Apr 2010 11:59:55 +0200
Jürgen Spitzmüller sp...@lyx.org escribió:
 Jack Desert wrote:
 
  Here is a patch to configure LyxBlogger in 1.6.x.
  
  Jurgen, are you the approval committee for branch patches?
 
 Yes, although comittee sound a bit exaggerated ;-)
 
 As to the patch: I am fine with it in general. However, as for 1.6.6, we are 
 almost finished, and I'd like to stick with critical bug fixes for now. So 
 if no one urges me to reconsider, I propose to postpone this to 1.6.7 (and 
 put it in as soon as 1.6.6 is released).
 
 Is this OK?
 
 Jürgen
 

Works for me. That will give me a chance to iron out whether to call it as a 
python module, an executable, or both. 

-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~

RE: r33962 - in lyx-devel/trunk: development lib/layouts lib/lyx2lyx src src/frontends/qt4 src/frontends/qt4/ui

[Vincent van Ravesteijn - TNW]

 
>> i understand the problem but this is really ugly. we must find
another way.
>> either shortcuting a-la 'Greyedout color' and the rest in tooltip  
>> or use something else then label.
>
>Why is having a label over 2 lines ugly? Qt supports this and
>also many other applications have this. Moreover the font dialog
>look OK to me. In fact it's only a matter of taste, isn't it?
>What do others think?
>

It's ugly, and I don't want HTML as the label. 

How could you even add this HMTL stuff and things like "font-family:'MS
Shell Dlg 2" to the ui files in the first place ?

>regards Uwe

Vincent

Re: edit ERT insets with external editor?

[Abdelrazak Younes]

On 03/31/2010 05:53 PM, Liviu Andronic wrote:

Dear LyX developers
Would it be a good idea to allow users to edit ERT insets with an
external editor? I am thinking of something similar to:
1. Have a "Edit with external editor" entry to the ERT inset context menu
2. When activated, LyX would export the current contents of the ERT
inset to a temporary file, and open it with a (pre-defined) text
editor
3. When the user finishes editing the ERT code externally, saves the
temporary file and closes the editor, LyX automatically imports the
contents of the file in the ERT inset (if feasible) or the user
manually activates a "Refresh inset" context-menu entry

Such a feature should be useful to users that make heavy use of LaTeX
code in their documents. Personally I would use it for editing R code
in Sweave documents: when the code gets too complex, it is unbearable
to edit it in the ERT insets (no syntax highlighting, matching braces,
easy indentation, etc.). What do you think?
   


It is a good idea but it sounds a bit complicated to implement for the 
communication of the child process; but it doable.


Another good option would be to use QScintilla:

  http://www.riverbankcomputing.com/software/qscintilla/intro

Abdel.

Re: r33993 - lyx-devel/trunk/lib/ui

[Abdelrazak Younes]

On 03/31/2010 11:37 PM, Pavel Sanda wrote:

Vincent van Ravesteijn wrote:
   

By the way, the git repository seems to be sleeping since oktober or so ?
 

yes, its not under our control and maintainer doesn't respond.
other possibility would be to have it on our server, but Christian
didn't look to be interested.
   


What about http://gitorious.org/ ? I used that for a project 
(http://gitorious.org/sgt in case you're interested) and it works just 
fine and reliably.


Abdel.

Re: Branch Patch: LyxBlogger Config

[Jürgen Spitzmüller]

Jack Desert wrote:

> Here is a patch to configure LyxBlogger in 1.6.x.
> 
> Jurgen, are you the approval committee for branch patches?

Yes, although "comittee" sound a bit exaggerated ;-)

As to the patch: I am fine with it in general. However, as for 1.6.6, we are 
almost finished, and I'd like to stick with critical bug fixes for now. So 
if no one urges me to reconsider, I propose to postpone this to 1.6.7 (and 
put it in as soon as 1.6.6 is released).

Is this OK?

Jürgen

Re: r33993 - lyx-devel/trunk/lib/ui

[Pavel Sanda]

Abdelrazak Younes wrote:
> What about http://gitorious.org/ ? I used that for a project 
> (http://gitorious.org/sgt in case you're interested) and it works just fine 
> and reliably.

are you able to setup it? (we would need full history and all branches 
included).

pavel

Re: r33993 - lyx-devel/trunk/lib/ui

[Abdelrazak Younes]

On 04/01/2010 12:34 PM, Pavel Sanda wrote:

Abdelrazak Younes wrote:
   

What about http://gitorious.org/ ? I used that for a project
(http://gitorious.org/sgt in case you're interested) and it works just fine
and reliably.
 

are you able to setup it? (we would need full history and all branches 
included).
   


If you mean create a project for it with one or more users with pushing 
rigth, yes. If you mean svn2git migration, no.


Abdel.

Re: r33993 - lyx-devel/trunk/lib/ui

[Pavel Sanda]

Abdelrazak Younes wrote:
> If you mean create a project for it with one or more users with pushing 
> rigth, yes. If you mean svn2git migration, no.

yes i meant the migration ;)
pavel

Re: ANNOUNCE: LyX version 2.0.0 (alpha 1)

[Sebastian Rockel]

Am 31.03.2010 um 19:31 schrieb Micha Feigin:

> On Wed, 31 Mar 2010 15:35:42 +0200
> Sebastian Rockel  wrote:
> 
>> Am 31.03.2010 um 14:47 schrieb Pavel Sanda:
>> 
>>> Sebastian Rockel wrote:
 Here in the mac version I cannot enable it due to everything on that pref 
 pane is grayed out:-/
>>> 
>>> normal spellcheck works?
>> 
>> Also the menu item is grayed out (F7 doesn't do it either).
>> I just double checked Lyx 1.6.5 with aspell 0.60.6 (MacPorts) and it works 
>> fine.
>> Running on Mac OSX 10.6.3.
>> 
>> Sebastian
> 
> Sounds to me like you didn't have the aspell development libraries (or other
> spell developement libraries) when configuring. I also had that problem under
> linux (debian). I installed libaspell-dev and now spelling is working. Not 
> sure
> what the right package is under OsX or how to install it though.

Thanks for the hint, did use the pre-build .dmg version though (see below).

> 
>> 
>>> pavel



Am 01.04.2010 um 00:37 schrieb Stephan Witt:

> Am 31.03.2010 um 15:35 schrieb Sebastian Rockel:
> 
>> Am 31.03.2010 um 14:47 schrieb Pavel Sanda:
>> 
>>> Sebastian Rockel wrote:
 Here in the mac version I cannot enable it due to everything on that pref 
 pane is grayed out:-/
>>> 
>>> normal spellcheck works?
>> 
>> Also the menu item is grayed out (F7 doesn't do it either).
>> I just double checked Lyx 1.6.5 with aspell 0.60.6 (MacPorts) and it works 
>> fine.
>> Running on Mac OSX 10.6.3.
> 
> I guess you're using the LyX-2.0.0alpha1.dmg I build on Snow Leopard.
> 
> You're right, no aspell support :(
> I didn't read carefully enough this part of configure output:
> 
> checking aspell.h usability... yes
> checking aspell.h presence... yes
> checking for aspell.h... yes
> checking for new_aspell_config in -laspell... no
> checking whether to use aspell... no
> 
> So I looked for the reason and found that configure detected the headers of 
> aspell but did not find the library.

Thanks for this clarification and for the build anyway.

Sebastian

> When trying to improve the situation I learned that my "universal" aspell 
> library from macports is like that:
> 
> % file /opt/local/lib/libaspell.dylib 
> /opt/local/lib/libaspell.dylib: Mach-O universal binary with 2 architectures
> /opt/local/lib/libaspell.dylib (for architecture x86_64): Mach-O 64-bit 
> dynamically linked shared library x86_64
> /opt/local/lib/libaspell.dylib (for architecture i386):   Mach-O 
> dynamically linked shared library i386
> 
> So in fact I cannot build a ppc version of LyX with aspell now. I'll see what 
> I can do...
> 
> Stephan
> 

Re: Warning

[rgheck]

On 03/31/2010 04:21 PM, Pavel Sanda wrote:

1. new file
2. insert child doc, eg Additional.lyx
3. console output:
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem
step: Counter does not exist: theorem

   
I think this is expected behavior, at present. The theorem module is not 
loaded into the master document.


rh

Re: edit ERT insets with external editor?

[rgheck]

On 04/01/2010 04:41 AM, Abdelrazak Younes wrote:

On 03/31/2010 05:53 PM, Liviu Andronic wrote:

Dear LyX developers
Would it be a good idea to allow users to edit ERT insets with an
external editor? [snip]


It is a good idea but it sounds a bit complicated to implement for the 
communication of the child process; but it doable.


Another good option would be to use QScintilla:

  http://www.riverbankcomputing.com/software/qscintilla/intro

Couldn't we do this internally, fairly easily? We already have LaTeX 
highlighting in the preamble.


rh

Re: Branch Patch: LyxBlogger Config

[rgheck]

On 04/01/2010 05:59 AM, Jürgen Spitzmüller wrote:

Jack Desert wrote:

   

Here is a patch to configure LyxBlogger in 1.6.x.

Jurgen, are you the approval committee for branch patches?
 

Yes, although "comittee" sound a bit exaggerated ;-)

As to the patch: I am fine with it in general. However, as for 1.6.6, we are
almost finished, and I'd like to stick with critical bug fixes for now. So
if no one urges me to reconsider, I propose to postpone this to 1.6.7 (and
put it in as soon as 1.6.6 is released).

Is this OK?

   

OK by me.

rh

RE: r34005 - in lyx-devel/trunk: . lib/scripts src

[Vincent van Ravesteijn - TNW]

>Log:
>Move command line arg --batch to -batch.
>Things are still bit inconsistent due to the existence of additional --
switches, but the correct fix is not so easy.
>

Aren't you now destroying the backward compatibility for all the scripts
that people might have made ?

Isn't it the 'normal' way of operation to have 2 dashes before a 'long'
parameter. I don't really see the need of changing this for no apparent
reason.

If you want to be consistent, maybe you can add a '-b' parameter in
addition to the '--batch' parameter. This seems to be fairly normal.

Vincent

Fantastic branches!

[minime]

Just wanted to pop by to give a well earned praise to the developers  
of Lyx.


I am currently using Lyx to compose a two language minutes of meeting,  
and a agenda thereof. With at few touches I am able to retain true  
tracking and editing in all languages. With branches within tables.


True magic, and most people dont

Most people cannot understand how quick I am able to compose these  
mom' s.


Regards and happy easter to all!

Ronald Ryland

Sendt fra min iPhone

Re: r34005 - in lyx-devel/trunk: . lib/scripts src

[Pavel Sanda]

Vincent van Ravesteijn - TNW wrote:
> >Log:
> >Move command line arg --batch to -batch.
> >Things are still bit inconsistent due to the existence of additional --
> switches, but the correct fix is not so easy.
> >
> 
> Aren't you now destroying the backward compatibility for all the scripts
> that people might have made ?

this has been introduced in 2.0 so no backward compatibility issue exists.

> Isn't it the 'normal' way of operation to have 2 dashes before a 'long'
> parameter. I don't really see the need of changing this for no apparent
> reason.

there is old unix way of using "-arg".

newer way is "-c value" and allowing of mixing chars without args to be mixed
together like -cXrGt or --long-option=value (note this "=").

lyx started the old way.
the inconsitency started when somebody added --execute, --export, --import
and adding 1 char synonyms, while
1) leaving old single dashes opts
2) not distinguishing seperate way of args specification.

adding --batch makes things even worse. because now there is even no
single dash way.

> If you want to be consistent, maybe you can add a '-b' parameter in
> addition to the '--batch' parameter. This seems to be fairly normal.

there is no consistency in our current pars handling.
the consitency could be done via
either killing additional --options (or at least hide them from man pages).
or rewriting the handling to be done correctly the "new way". just adding
"-b" won't do.

in either way adding just --batch made things worse.

pavel

Re: edit ERT insets with external editor?

[Abdelrazak Younes]

On 04/01/2010 05:32 PM, rgheck wrote:

On 04/01/2010 04:41 AM, Abdelrazak Younes wrote:

On 03/31/2010 05:53 PM, Liviu Andronic wrote:

Dear LyX developers
Would it be a good idea to allow users to edit ERT insets with an
external editor? [snip]


It is a good idea but it sounds a bit complicated to implement for 
the communication of the child process; but it doable.


Another good option would be to use QScintilla:

  http://www.riverbankcomputing.com/software/qscintilla/intro

Couldn't we do this internally, fairly easily? We already have LaTeX 
highlighting in the preamble.


Sure, we can and that would already be a very good first step. But only 
we can only highlight LaTeX.


Abdel.

Re: r33962 - in lyx-devel/trunk: development lib/layouts lib/lyx2lyx src src/frontends/qt4 src/frontends/qt4/ui

[Uwe Stöhr]

Vincent van Ravesteijn - TNW schrieb:


i understand the problem but this is really ugly. we must find

another way.
either shortcuting a-la 'Greyedout color' and the rest in tooltip  
or use something else then label.

>>

Why is having a label over 2 lines ugly? Qt supports this and
also many other applications have this. Moreover the font dialog
look OK to me. In fact it's only a matter of taste, isn't it?
What do others think?



It's ugly, and I don't want HTML as the label. 


Why not?


How could you even add this HMTL stuff and things like "font-family:'MS
Shell Dlg 2" to the ui files in the first place ?


I don't understand. All I have done was to add a label. I set the label 
text using Qt 4.6 designer. So the code was added by designer, not me.
I cannot comment on the "font-family:" issue because this was also 
automatically added by designer. (I cannot remember to have used such a 
font purposely - it must be a designer-specific Windows default font.)

I'll have a look at this.

regards Uwe

Re: r33962 - in lyx-devel/trunk: development lib/layouts lib/lyx2lyx src src/frontends/qt4 src/frontends/qt4/ui

[Pavel Sanda]

Uwe Stöhr wrote:
> I don't understand. All I have done was to add a label. I set the label 
> text using Qt 4.6 designer. So the code was added by designer, not me.
> I cannot comment on the "font-family:" issue because this was also 
> automatically added by designer. (I cannot remember to have used such a 
> font purposely - it must be a designer-specific Windows default font.)
> I'll have a look at this.

its perhaps some 4.6 feature. anyway the text itself in the ui file
must be something trivial like "Font color for greyed-out notes" or
add "\n" newline character if you really need this.

but by no way something like:
> http://www.w3.org/TR/REC-html40/strict.dtd;
> +htmlheadmeta name=qrichtext 
> content=1 /style type=text/css
> +p, li { white-space: pre-wrap; }
> +/style/headbody style= font-family:'MS Shell Dlg 
> 2'; font-size:8.25pt; font-weight:400; font-style:normal;
> +p style= margin-top:0px; margin-bottom:0px; margin-left:0px; 
> margin-right:0px; -qt-block-indent:0; text-indent:0px;span 
> style= font-size:8pt;Font color for/span/p
> +p style= margin-top:0px; margin-bottom:0px; margin-left:0px; 
> margin-right:0px; -qt-block-indent:0; text-indent:0px;span 
> style= font-size:8pt;greyed-out 
> notes:/span/p/body/html

the ugliness should be self evident, but even without esthetical judgements
this will break string translations - no string would be generated
in .po files.

pavel

Re: r34002 - lyx-devel/trunk

[Jean-Marc Lasgouttes]

Le 01/04/2010 13:21, sa...@lyx.org a écrit :

Log:
Lets make tarballs via lzma instead of bzip2 from now on.
Ratios for alpha1:
tgz   16M
bzip2 12M
lzma 8.7M


That's a good gain indeed. What compression is used for windows
installers, BTW?

Two remarks:

1/ this means that we require automake 1.11 and autoconf 2.62. We should 
make this clear.


2/ lzma is deprecated by the almost equivalent but gnu .xz format.

JMarc

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Le 31/03/2010 13:07, Guenter Milde a écrit :

On 2010-03-30, Jean-Marc Lasgouttes wrote:

Pavel Sanda  writes:

last call for 2.0 feature requests we have reported.



- currently, Sweave reads the files in the encoding of the current
   locale. This fails as soon as the locale is UTF-8 and the document is
   8bit (because the characters themselves are ruined). We need to find a
   way to pass the encoding to the function.
http://www.lyx.org/trac/ticket/6625


I wonder if we could use utf-8 as default latex source encoding for most
(all) languages if the locale is UTF-8.


AFAIK, UTF8 support is too weak in LaTeX right now. And people should be 
able to chose the encoding they want.


Note that a good workaround for this bug is to use ascii encoding.

JMarc

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Le 30/03/2010 14:01, Jean-Marc Lasgouttes a écrit :

- pass the "noae" option to Sweave to make sure it does not ruin our
   font settings.
http://www.lyx.org/trac/ticket/6624


This one is fixed now.

JMarc

Re: r34002 - lyx-devel/trunk

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> 1/ this means that we require automake 1.11 and autoconf 2.62. We should 
> make this clear.

you mean to add it to release notes?

> 2/ lzma is deprecated by the almost equivalent but gnu .xz format.

i know and tried both. there was no difference in compression ratio
and xz didn't looked to be supported by autotools yet. also except
arch, distros seems to accept lzma better.

pavel

Re: r34002 - lyx-devel/trunk

[Jean-Marc Lasgouttes]

Le 01/04/2010 23:46, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

1/ this means that we require automake 1.11 and autoconf 2.62. We should
make this clear.


you mean to add it to release notes?


No, in autogen.sh and INSTALL. Also in the INIT_AUTOMAKE call.




2/ lzma is deprecated by the almost equivalent but gnu .xz format.


i know and tried both. there was no difference in compression ratio
and xz didn't looked to be supported by autotools yet. also except
arch, distros seems to accept lzma better.


Support for xz and lzma have been added at the same time in automake. 
Actually, you should use 1.11.1, since there is a security bug in "make 
dist" in older autimake versions.


Recent GNU software is distributed as xz now.

JMarc

Re: r34002 - lyx-devel/trunk

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
>>> 2/ lzma is deprecated by the almost equivalent but gnu .xz format.
>>
>> i know and tried both. there was no difference in compression ratio
>> and xz didn't looked to be supported by autotools yet. also except
>> arch, distros seems to accept lzma better.
>
> Support for xz and lzma have been added at the same time in automake. 

are you sure? my 1.10.3 generated makefile knows dist-lzma, but not dist-xz
target. after hard fight i forced gentoo automake wrapper to choose 1.11.1 and
dist-xz appeared.

> Recent GNU software is distributed as xz now.

requiring 1.11 is not too much? i belive people start to scream
and we need this only for people wanting make dist, which is me
and Juergen later on...

and finally - hold your hat - when using the attached patch for xz
i got tarball half mega bigger then lzma, because autotools set
-9 compression level for lzma, but not for xz :/
any way how to set it up?

pavel
diff --git a/autogen.sh b/autogen.sh
index da8b6aa..49eebdb 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -15,13 +15,14 @@ test "$automake_version" != "" && {
 exit 1
 }
 
+echo $automake_version
 case $automake_version in
-*' '1.[8-9]*|*' '1.1[01]*)
+*' '1.11*)
 	;;
 *)
 
 	echo "This automake version is not supported by LyX."
-	echo "LyX only supports automake 1.8 to 1.11."
+	echo "LyX only supports automake 1.11(.1)"
 	exit 1
 	;;
 esac
diff --git a/configure.ac b/configure.ac
index 76c87bd..b9d01b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -26,7 +26,7 @@ fi
 AM_MAINTAINER_MODE
 
 save_PACKAGE=$PACKAGE
-AM_INIT_AUTOMAKE([foreign dist-lzma no-define 1.8])
+AM_INIT_AUTOMAKE([foreign dist-xz no-define 1.11])
 m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])])
 PACKAGE=$save_PACKAGE
 

Re: Branch Patch: LyxBlogger Config

[Jack Desert]

El Thu, 01 Apr 2010 11:59:55 +0200
Jürgen Spitzmüller  escribió:
> Jack Desert wrote:
> 
> > Here is a patch to configure LyxBlogger in 1.6.x.
> > 
> > Jurgen, are you the approval committee for branch patches?
> 
> Yes, although "comittee" sound a bit exaggerated ;-)
> 
> As to the patch: I am fine with it in general. However, as for 1.6.6, we are 
> almost finished, and I'd like to stick with critical bug fixes for now. So 
> if no one urges me to reconsider, I propose to postpone this to 1.6.7 (and 
> put it in as soon as 1.6.6 is released).
> 
> Is this OK?
> 
> Jürgen
> 

Works for me. That will give me a chance to iron out whether to call it as a 
python module, an executable, or both. 

-- 
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.com
Software Developer:   http://GrooveTask.org
Email: jackdesert...@gmail.com
~~~