date:20091020

Lizardo H.C.M.Nunes wrote:
 Is it possible to set icons for the command-sequence items in a  
 toolbar?

http://marc.info/?l=lyx-usersm=125570348223153w=2

Jürgen

Re: r31680 - lyx-devel/trunk/src/mathed

Enrico Forestieri wrote:
 Jürgen?

OK.

Jürgen

Re: [PATCHes] LyX and Snow Leopard, going forward

On Mon, Oct 19, 2009 at 10:30 AM, Jean-Marc Lasgouttes
jean-marc.lasgout...@inria.fr wrote:

 Hello,

 It seems that nothing is happening on the snow leopard front. This is
 something that has to be solved ASAP (1.6.4.2?)

Sorry ... I've been swamped and will be for the foreseeable future.

BH

Re: Compiling on Mac OSX 10.6 (Snow Leopard)

On Mon, Oct 19, 2009 at 4:43 PM, Pavel Sanda sa...@lyx.org wrote:
 Anders Ekberg wrote:
 (most notably --enable-optimization=-O2  --disable-debug
 are good for non debuging purposes).

 pavel

 Could something like this work?

 looks good, except the --enable-optimization=-Os part. firstly O2 is better
 imho, secondly you already request O2 by calling --enable-build-type=rel and
 maybe some other switches too. i can commit it if there are no objection from
 other mac people around.

Sorry -- as I said in another thread, I've been swamped and unable to
follow snow leopard problems/developments. So don't wait on me

BH

Re: [PATCHes] LyX and Snow Leopard, going forward

BH bewih...@gmail.com writes:

 On Mon, Oct 19, 2009 at 10:30 AM, Jean-Marc Lasgouttes
 jean-marc.lasgout...@inria.fr wrote:

 Hello,

 It seems that nothing is happening on the snow leopard front. This is
 something that has to be solved ASAP (1.6.4.2?)

 Sorry ... I've been swamped and will be for the foreseeable future.

No problem. I am trying to get other people to stand up :) Personnally,
I do not care much (yet) about snow leopard !

JMarc

Re: r31440 - lyx-devel/trunk/src/tex2lyx

Uwe Stöhr uwesto...@web.de writes:
 Now I found the time. I improved your patch because I found two other
 bugs in the document language handling:
  - when languages are given in the documentclass options _and_ the
 babel options, babel takes the last language option of the \usepackage
 call

OK. Note that the real mechanism is the following:
- each \usepackage considers the global documentclass options and then
the options passed to the usepackage call. We should try to emulate this
generally, but there are some problems related to which options should
be kept in the .lyx file
- babel uses the last given language as main language

The combination of the two mechanisms give the behaviour you describe.

JMarc

Re: tex2lyx [patch] for branch

Uwe Stöhr uwesto...@web.de writes:
 OK JMarc and Jürgen?

Now that I see the entire patch, I notice that the following change
(from me) is not necessary anymore. Right?

JMarc


 -void handle_opt(vectorstring  opts, char const * const * what, string  
 target)
 +// returns true if at least one of the options in what has been found
 +bool handle_opt(vectorstring  opts, char const * const * what, string  
 target)
  {
   if (opts.empty())
 - return;
 + return false;
  
 + bool found = false;
   // the last language option is the document language (for babel and LyX)
   // the last size option is the document font size
   vectorstring::iterator it;
 @@ -153,13 +151,14 @@
   for (; *what; ++what) {
   it = find(opts.begin(), opts.end(), *what);
   if (it != opts.end()) {
 - documentclass_language = true;
   if (it = position) {
 + found = true;
   target = *what;
   position = it;
   }
   }
   }
 + return found;
  }

Re: configure.py [patch] for branch

Alex Fernandez wrote:
 The switch is there. What I see is that with the patch LyX is going to
 look for two executables in the path: elyxer.py or elyxer:
 +path, elyxer = checkProg('a LyX - HTML converter', ['elyxer.py',
 'elyxer'],
 and then it is going to execute a different elyxer.py from the scripts
 directory anyway, ignoring those in the path:
 +  rc_entry = [ r'\converter lyx  html   python -tt
 $$s/scripts/elyxer.py --directory $$r $$i $$o  ' ])
 This copy of elyxer.py in the scripts directory has to be distributed
 along with LyX, either standalone or in the installer.
 
 This is going to result in strange behavior for people who have
 already downloaded eLyXer from a different source (not many of them,
 granted). 

Right, this is bad. The detection should work whether eLyXer is in the scripts 
directory or not.

 The recommended way of running eLyXer is as a module; I sent a patch
 to the list that tried to first detect the module and then the
 executable. Sadly, I then failed to come through with the suggested
 improvements (I guess I was too busy with childish preemptive
 trolling):
   http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg154797.html
 Please find enclosed elyxer-module2.diff, a finished version of that
 patch. It will work with eLyXer as a module or as an executable in the
 path, and should address those concerns raised at the time.

I do not understand Python enough to evaluate the module idea, but the 
approach strikes me sensible (whereas I do not like the unconditional 
patch).

Uwe, could you check this patch works for you?

Jürgen

Re: tex2lyx [patch] for branch

Uwe Stöhr wrote:
 OK JMarc and Jürgen?

You can put this if Jean-Marc agrees.

Jürgen

Re: tex2lyx [patch] for branch


Jean-Marc Lasgouttes schrieb:


Now that I see the entire patch, I notice that the following change
(from me) is not necessary anymore. Right?


I would leave this change since it might be useful for the future.

regards Uwe

Re: r31440 - lyx-devel/trunk/src/tex2lyx


Jean-Marc Lasgouttes schrieb:


OK. Note that the real mechanism is the following:
- each \usepackage considers the global documentclass options and then
the options passed to the usepackage call. We should try to emulate this
generally, but there are some problems related to which options should
be kept in the .lyx file
- babel uses the last given language as main language

The combination of the two mechanisms give the behaviour you describe.


Yesterday I stumbled over this code:

 \documentclass[english,brazilian, 11pt]{article}
 \usepackage[french, ngerman]{babel}

This code is stupid but valid. The document language taken by babel is in this case ngerman. The 
patch takes care of this.


regards Uwe

Re: tex2lyx [patch] for branch


Uwe Stöhr schrieb:


Now that I see the entire patch, I notice that the following change
(from me) is not necessary anymore. Right?


I would leave this change since it might be useful for the future.


I omitted this change in the patch I applied for branch but would keep it in 
trunk? Is this OK with you?

regards Uwe

Re: configure.py [patch] for branch

The switch is there. What I see is that with the patch LyX is going to
look for two executables in the path: elyxer.py or elyxer:
+path, elyxer = checkProg('a LyX - HTML converter',
['elyxer.py','elyxer'],
and then it is going to execute a different elyxer.py from the scripts
directory anyway, ignoring those in the path:
+ rc_entry = [ r'\converter lyx html python -tt
$$s/scripts/elyxer.py --directory $$r $$i $$o ' ])

This is not correct. The code looks for a file named elyxer.py. This can only be found when it is in
a path known by LyX. That means that it has to be somewhere in LyX's subfolders. Other folders
aren't possible since the installer can only detect paths given in the registry. So when eLyXer
would be a standalone program it would have been written its installation path in the registry. The
LyX installer could then check if eLyXer is installed and add its path to the known LyX paths.
Therefore I was forced to use a certain location for the file and have chosen the directory where we
store all other python scripts. So you can see eLyXer as a plugin and the scripts folder is LyX
folder for plugins.

This copy of elyxer.py in the scripts directory has to be distributed
along with LyX, either standalone or in the installer.

This is intended. When elyxer.py is in the scripts folder, the user wants to use it as HTML
converter, if not then tex4ht will be used.

This is going to result in strange behavior for people who have
already downloaded eLyXer from a different source (not many of them,
granted).

I don't agree. Those few users can copy the elyxer.py file to the scripts folder and everything will
work. Spending time for backward compatibility of a script that has not yet been released together
with LyX is not worth the time in my opinion. Note the eLyXer don't work properly with LyX 1.6.4
because we fixed the image file and ext_copy.py issues afterwards. Forcing the users to copy a
single file shouldn't be a too hard task.

The recommended way of running eLyXer is as a module; I sent a patch
to the list that tried to first detect the module and then the
executable.

This requires a full Python installation. A full LyX installation already needs about 500 MB on your
harddisk and has a download size of about 120MB. To save further 50 MB on the harddisk and 30 MB
download size, my (and also Joost's installer) bundle a stripped down version of Python. This
version includes all necessary files to run our python scripts and works well with elyxer.py.
Being forced to install Python completely is no option just for one script with a filesize of only a
few kB.

- install eLyXer in the path,

What do you mean with path?

Finally. as I often stated: eLyXer can only work together with LyX and I will therefore never
understand what it cannot just be another python script in our SVN. When it would be in our SVN,
everybody could fix bugs in the file in case you are not available. It would be part of every new
LyX release and users can report bugs with this script to our bugtracker.

regards Uwe

online again

2009-10-20 Thread Christian Ridderström


Hi everybody

Just thought I'd give a little sign of life... .-)  I'm busy doing stuff, 
which combined with a troublesome laptop keyboard has kept me off internet 
rather thoroughly. Without 'b', 'n' and the arrow keys it's really not 
that fun doing stuff on the computer. Especially as I use 'n' in some of 
my passwords... *LOL*


So if you ever feel you spend to much time with the computer, just screw 
up some of the keys on the keyboard...


Anyway, now I'll try to monitor the list much more frequently, but in case 
something needs my attention, please just email me directly.


Totally off topic. Any of you using Wave?

cheers
/Christian

PS. I've done some attempts at trying to find a new laptop, but the ones 
I've looked at so far either require you to use a Function key to access 
some of pgup/pgdn/insert/delete/end, or they've placed the keys in a 
really stupid place! :-(


In addition, I guess laptop keyboards in general will find it difficult to 
compete with a specific keyboard type I've been using for close to a 
decade...


So I'd be happy to get tips on laptops with good keyboards for 
typing/coding. The laptop is just going to stay in my living room, being 
connected through remote desktop to a virtual machine. So primarily it 
just needs a good keyboard/screen/touchpad...


For your amusement, I'm writing this text in the following manner:

I'm typing on a wireless keyboard with a touchpad that I just bought. The 
data goes to a server in another room, which is running 'synergy', which 
then sends the typing data to my laptop. The laptop in turn is connected 
via remote desktop to a virtual machine on the server, where I'm running 
alpine.


Synergy is quite nice, it allows me to drag the mouse pointer to the edge 
of my TV, which is connected to the server, and the mouse pointer pops up 
on the laptop screen. And vice versa to shift the focus back to the 
server/TV. I can really recommend synergy if you want to control muliple 
computers from one keyboard/mouse.


--
Christian Ridderström

Re: configure.py [patch] for branch

Hi Uwe,

On Tue, Oct 20, 2009 at 10:47 PM, Uwe Stöhr uwesto...@web.de wrote:
 This is not correct. The code looks for a file named elyxer.py. This can
 only be found when it is in a path known by LyX. That means that it has to
 be somewhere in LyX's subfolders. Other folders aren't possible since the
 installer can only detect paths given in the registry. So when eLyXer would
 be a standalone program it would have been written its installation path in
 the registry. The LyX installer could then check if eLyXer is installed and
 add its path to the known LyX paths.

This is not what I understand from the code. It seems to look for
elyxer.py in all execution paths known to Python, not to LyX. On
Windows these include all Windows execution paths (the %PATH%
variable).

 Therefore I was forced to use a certain location for the file and have
 chosen the directory where we store all other python scripts. So you can see
 eLyXer as a plugin and the scripts folder is LyX folder for plugins.

The problem is that it doesn't work as you think it does, at least on
Linux. On my trusty Debian I have just tried removing the elyxer
package, placing elyxer.py in the LyX scripts folder, and LyX is not
able to find it. I would bet that on Windows it will be the same:
remove elyxer.py from the execution path and try to see if LyX
reconfigure can find the copy in the scripts folder. With the current
patch (the one in svn right now) Linux users (and Windows users
probably too) will never be able to use eLyXer, even if it is included
in the LyX scripts folder, unless there is an additional copy in the
execution path (which will not be used apart from detection).

 This copy of elyxer.py in the scripts directory has to be distributed
 along with LyX, either standalone or in the installer.

 This is intended. When elyxer.py is in the scripts folder, the user wants to
 use it as HTML converter, if not then tex4ht will be used.

But as I explained above, when elyxer.py is in the scripts folder the
configure.py script is not able to locate it. Another option would be
to place elyxer.py in the same folder as the LyX executable file;
according to some user reports this might work fine.

 I don't agree. Those few users can copy the elyxer.py file to the scripts
 folder and everything will work. Spending time for backward compatibility of
 a script that has not yet been released together with LyX is not worth the
 time in my opinion. Note the eLyXer don't work properly with LyX 1.6.4
 because we fixed the image file and ext_copy.py issues afterwards. Forcing
 the users to copy a single file shouldn't be a too hard task.

It would not be too hard -- the first time. Making users copy it back
every time they update LyX (on Mac OS X), or for every LyX
installation, is not so nice for users. Specially when the check can
be done for them in a few lines.

 The recommended way of running eLyXer is as a module; I sent a patch
 to the list that tried to first detect the module and then the
 executable.

 This requires a full Python installation. A full LyX installation already
 needs about 500 MB on your harddisk and has a download size of about 120MB.
 To save further 50 MB on the harddisk and 30 MB download size, my (and also
 Joost's installer) bundle a stripped down version of Python. This version
 includes all necessary files to run our python scripts and works well with
 elyxer.py.
 Being forced to install Python completely is no option just for one script
 with a filesize of only a few kB.

I did not know this; you are right, it is quite impractical. Anyway
the patch can be used on Linux where Python is probably already
installed, or by advanced users; it also detects elyxer (or elyxer.py)
in the execution path, so everyone is happy.

  - install eLyXer in the path,

 What do you mean with path?

Execution path. The same folder as LyX.exe would be enough, on
Windows. On Linux /usr/bin is fine.

 Finally. as I often stated: eLyXer can only work together with LyX and I
 will therefore never understand what it cannot just be another python script
 in our SVN. When it would be in our SVN, everybody could fix bugs in the
 file in case you are not available. It would be part of every new LyX
 release and users can report bugs with this script to our bugtracker.

That is not my decision to make. In any case I maintain that eLyXer is
useful as a standalone tool even for people that do not use LyX,
increasing at the same time the usefulness of LyX itself. People who
have been given a LyX document can use a little script to translate
it, instead of having to download the whole LyX package with all its
dependencies. eLyXer can be used on a server to check a LyX document
and maybe serve it as an HTML file. And so on.

Alex.

Re: configure.py [patch] for branch

Alex Fernandez schrieb:

This is not what I understand from the code. It seems to look for
elyxer.py in all execution paths known to Python, not to LyX. On
Windows these include all Windows execution paths (the %PATH%
variable).

It first looks at the paths known by LyX and then at the paths listed in the PATH variable. Python
is independent of this. But as said, eLyXer is no standalone program with its own installer and thus
its path is not known.

Therefore I was forced to use a certain location for the file and have
chosen the directory where we store all other python scripts. So you can see
eLyXer as a plugin and the scripts folder is LyX folder for plugins.

The problem is that it doesn't work as you think it does, at least on
Linux. On my trusty Debian I have just tried removing the elyxer
package, placing elyxer.py in the LyX scripts folder, and LyX is not
able to find it. I would bet that on Windows it will be the same:
remove elyxer.py from the execution path and try to see if LyX
reconfigure can find the copy in the scripts folder.

This works. I never had elyxer.py in another folder. configure.py also finds the other scripts in
the scripts folder, so why shouldn't it find elyxer.py? Can you please recheck because it must work.

Forcing
the users to copy a single file shouldn't be a too hard task.

It would not be too hard -- the first time. Making users copy it back
every time they update LyX (on Mac OS X), or for every LyX
installation, is not so nice for users. Specially when the check can
be done for them in a few lines.

Why do you then don't agree to include eLyXer to LyX?

- install eLyXer in the path,

What do you mean with path?

Execution path. The same folder as LyX.exe would be enough, on
Windows. On Linux /usr/bin is fine.

I can move the file location from the scripts folder to the bin folder but this doesn't change
anything. eLyXer still needs to be copied there.

Finally. as I often stated: eLyXer can only work together with LyX and I
will therefore never understand what it cannot just be another python script
in our SVN. When it would be in our SVN, everybody could fix bugs in the
file in case you are not available. It would be part of every new LyX
release and users can report bugs with this script to our bugtracker.

That is not my decision to make. In any case I maintain that eLyXer is
useful as a standalone tool even for people that do not use LyX,
increasing at the same time the usefulness of LyX itself. People who
have been given a LyX document can use a little script to translate
it, instead of having to download the whole LyX package with all its
dependencies.

But you can already use every Python script that is part of LyX as standalone script. Just download
it from here:

http://www.lyx.org/trac/browser/lyx-devel/branches/BRANCH_1_6_X/lib/scripts
or here:
http://www.lyx.org/trac/browser/lyx-devel/trunk/lib/scripts

You also can provide eLyXer as standalone program, no matter that it is
included in LyX.

regards Uwe

Re: configure.py [patch] for branch

Hi again,

On Wed, Oct 21, 2009 at 12:26 AM, Uwe Stöhr uwesto...@web.de wrote:
 This works. I never had elyxer.py in another folder. configure.py also finds
 the other scripts in the scripts folder, so why shouldn't it find elyxer.py?

As a matter of fact, configure.py does not _find_ the other scripts;
it merely writes them to the configuration file lyxrc.defaults, so
that LyX can later execute them. As in your version, these scripts are
preceded by $$s/scripts, which allows LyX to find them.

 Can you please recheck because it must work.

I just did that, on Debian and on a Windows machine. On both instances
it works as expected: if elyxer.py is in the scripts folder but not in
the execution path, then LyX does not find eLyXer. I am sure that you
must have some copy of elyxer or elyxer.py lying around from previous
tries; it might be in c:\win32, or in the same folder as lyx.exe.
Could you check that typing elyxer.py in a console does not execute
anything?

 Why do you then don't agree to include eLyXer to LyX?

No matter what I may have said before, I would love eLyXer to be
included in LyX. There are some practical problems but nothing that
could not probably be solved.

 Execution path. The same folder as LyX.exe would be enough, on
 Windows. On Linux /usr/bin is fine.

 I can move the file location from the scripts folder to the bin folder but
 this doesn't change anything. eLyXer still needs to be copied there.

Only on Windows, I think; and your installer can take care of that.
Just consider that on Linux (e.g. Debian) package installation is
completely different: each package places a binary in /usr/bin, and
they are all supposed to work together without making any copies
anywhere. That is why the execution path is so important on Linux.

 You also can provide eLyXer as standalone program, no matter that it is
 included in LyX.

Sure. This would be fine with me.

Alex.

Re: AquaLyX screenshots

Lizardo H.C.M.Nunes wrote:
> Is it possible to set icons for the "command-sequence" items in a  
> toolbar?

http://marc.info/?l=lyx-users=125570348223153=2

Jürgen

Re: r31680 - lyx-devel/trunk/src/mathed

Enrico Forestieri wrote:
> Jürgen?

OK.

Jürgen

Re: [PATCHes] LyX and Snow Leopard, going forward

On Mon, Oct 19, 2009 at 10:30 AM, Jean-Marc Lasgouttes
 wrote:
>
> Hello,
>
> It seems that nothing is happening on the snow leopard front. This is
> something that has to be solved ASAP (1.6.4.2?)

Sorry ... I've been swamped and will be for the foreseeable future.

BH

Re: Compiling on Mac OSX 10.6 (Snow Leopard)

On Mon, Oct 19, 2009 at 4:43 PM, Pavel Sanda  wrote:
> Anders Ekberg wrote:
>>> (most notably --enable-optimization=-O2  --disable-debug
>>> are good for non debuging purposes).
>>>
>>> pavel
>>
>> Could something like this work?
>
> looks good, except the --enable-optimization=-Os part. firstly O2 is better
> imho, secondly you already request O2 by calling --enable-build-type=rel and
> maybe some other switches too. i can commit it if there are no objection from
> other mac people around.

Sorry -- as I said in another thread, I've been swamped and unable to
follow snow leopard problems/developments. So don't wait on me

BH

Re: [PATCHes] LyX and Snow Leopard, going forward

BH  writes:

> On Mon, Oct 19, 2009 at 10:30 AM, Jean-Marc Lasgouttes
>  wrote:
>>
>> Hello,
>>
>> It seems that nothing is happening on the snow leopard front. This is
>> something that has to be solved ASAP (1.6.4.2?)
>
> Sorry ... I've been swamped and will be for the foreseeable future.

No problem. I am trying to get other people to stand up :) Personnally,
I do not care much (yet) about snow leopard !

JMarc

Re: r31440 - lyx-devel/trunk/src/tex2lyx

Uwe Stöhr  writes:
> Now I found the time. I improved your patch because I found two other
> bugs in the document language handling:
>  - when languages are given in the documentclass options _and_ the
> babel options, babel takes the last language option of the \usepackage
> call

OK. Note that the real mechanism is the following:
- each \usepackage considers the global documentclass options and then
the options passed to the usepackage call. We should try to emulate this
generally, but there are some problems related to which options should
be kept in the .lyx file
- babel uses the last given language as main language

The combination of the two mechanisms give the behaviour you describe.

JMarc

Re: tex2lyx [patch] for branch

Uwe Stöhr  writes:
> OK JMarc and Jürgen?

Now that I see the entire patch, I notice that the following change
(from me) is not necessary anymore. Right?

JMarc

>
> -void handle_opt(vector & opts, char const * const * what, string & 
> target)
> +// returns true if at least one of the options in what has been found
> +bool handle_opt(vector & opts, char const * const * what, string & 
> target)
>  {
>   if (opts.empty())
> - return;
> + return false;
>  
> + bool found = false;
>   // the last language option is the document language (for babel and LyX)
>   // the last size option is the document font size
>   vector::iterator it;
> @@ -153,13 +151,14 @@
>   for (; *what; ++what) {
>   it = find(opts.begin(), opts.end(), *what);
>   if (it != opts.end()) {
> - documentclass_language = true;
>   if (it >= position) {
> + found = true;
>   target = *what;
>   position = it;
>   }
>   }
>   }
> + return found;
>  }
>

Re: configure.py [patch] for branch

Alex Fernandez wrote:
> The switch is there. What I see is that with the patch LyX is going to
> look for two executables in the path: elyxer.py or elyxer:
> +path, elyxer = checkProg('a LyX -> HTML converter', ['elyxer.py',
> 'elyxer'],
> and then it is going to execute a different elyxer.py from the scripts
> directory anyway, ignoring those in the path:
> +  rc_entry = [ r'\converter lyx  html   "python -tt
> $$s/scripts/elyxer.py --directory $$r $$i $$o"  ""' ])
> This copy of elyxer.py in the scripts directory has to be distributed
> along with LyX, either standalone or in the installer.
> 
> This is going to result in strange behavior for people who have
> already downloaded eLyXer from a different source (not many of them,
> granted). 

Right, this is bad. The detection should work whether eLyXer is in the scripts 
directory or not.

> The recommended way of running eLyXer is as a module; I sent a patch
> to the list that tried to first detect the module and then the
> executable. Sadly, I then failed to come through with the suggested
> improvements (I guess I was too busy with childish preemptive
> trolling):
>   http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg154797.html
> Please find enclosed elyxer-module2.diff, a finished version of that
> patch. It will work with eLyXer as a module or as an executable in the
> path, and should address those concerns raised at the time.

I do not understand Python enough to evaluate the module idea, but the 
approach strikes me sensible (whereas I do not like the "unconditional" 
patch).

Uwe, could you check this patch works for you?

Jürgen

Re: tex2lyx [patch] for branch

Uwe Stöhr wrote:
> OK JMarc and Jürgen?

You can put this if Jean-Marc agrees.

Jürgen

Re: tex2lyx [patch] for branch


Jean-Marc Lasgouttes schrieb:


Now that I see the entire patch, I notice that the following change
(from me) is not necessary anymore. Right?


I would leave this change since it might be useful for the future.

regards Uwe

Re: r31440 - lyx-devel/trunk/src/tex2lyx


Jean-Marc Lasgouttes schrieb:


OK. Note that the real mechanism is the following:
- each \usepackage considers the global documentclass options and then
the options passed to the usepackage call. We should try to emulate this
generally, but there are some problems related to which options should
be kept in the .lyx file
- babel uses the last given language as main language

The combination of the two mechanisms give the behaviour you describe.


Yesterday I stumbled over this code:

 \documentclass[english,brazilian, 11pt]{article}
 \usepackage[french, ngerman]{babel}

This code is stupid but valid. The document language taken by babel is in this case "ngerman". The 
patch takes care of this.


regards Uwe

Re: tex2lyx [patch] for branch


Uwe Stöhr schrieb:


Now that I see the entire patch, I notice that the following change
(from me) is not necessary anymore. Right?


I would leave this change since it might be useful for the future.


I omitted this change in the patch I applied for branch but would keep it in 
trunk? Is this OK with you?

regards Uwe

Re: configure.py [patch] for branch


> The switch is there. What I see is that with the patch LyX is going to
> look for two executables in the path: elyxer.py or elyxer:
> +path, elyxer = checkProg('a LyX -> HTML converter', 
['elyxer.py','elyxer'],
> and then it is going to execute a different elyxer.py from the scripts
> directory anyway, ignoring those in the path:
> +  rc_entry = [ r'\converter lyx  html   "python -tt
> $$s/scripts/elyxer.py --directory $$r $$i $$o"  ""' ])

This is not correct. The code looks for a file named elyxer.py. This can only be found when it is in 
a path known by LyX. That means that it has to be somewhere in LyX's subfolders. Other folders 
aren't possible since the installer can only detect paths given in the registry. So when eLyXer 
would be a standalone program it would have been written its installation path in the registry. The 
LyX installer could then check if eLyXer is installed and add its path to the known LyX paths.
Therefore I was forced to use a certain location for the file and have chosen the directory where we 
store all other python scripts. So you can see eLyXer as a plugin and the scripts folder is LyX 
folder for plugins.


> This copy of elyxer.py in the scripts directory has to be distributed
> along with LyX, either standalone or in the installer.

This is intended. When elyxer.py is in the scripts folder, the user wants to use it as HTML 
converter, if not then tex4ht will be used.


> This is going to result in strange behavior for people who have
> already downloaded eLyXer from a different source (not many of them,
> granted).

I don't agree. Those few users can copy the elyxer.py file to the scripts folder and everything will 
work. Spending time for backward compatibility of a script that has not yet been released together 
with LyX is not worth the time in my opinion. Note the eLyXer don't work properly with LyX 1.6.4 
because we fixed the image file and ext_copy.py issues afterwards. Forcing the users to copy a 
single file shouldn't be a too hard task.


> The recommended way of running eLyXer is as a module; I sent a patch
> to the list that tried to first detect the module and then the
> executable.

This requires a full Python installation. A full LyX installation already needs about 500 MB on your 
harddisk and has a download size of about 120MB. To save further 50 MB on the harddisk and 30 MB 
download size, my (and also Joost's installer) bundle a stripped down version of Python. This 
version includes all necessary files to run our python scripts and works well with elyxer.py.
Being forced to install Python completely is no option just for one script with a filesize of only a 
few kB.


>  - install eLyXer in the path,

What do you mean with "path"?

Finally. as I often stated: eLyXer can only work together with LyX and I will therefore never 
understand what it cannot just be another python script in our SVN. When it would be in our SVN, 
everybody could fix bugs in the file in case you are not available. It would be part of every new 
LyX release and users can report bugs with this script to our bugtracker.


regards Uwe

"online" again

2009-10-20 Thread Christian Ridderström


Hi everybody

Just thought I'd give a little sign of life... .-)  I'm busy doing stuff, 
which combined with a troublesome laptop keyboard has kept me off internet 
rather thoroughly. Without 'b', 'n' and the arrow keys it's really not 
that fun doing stuff on the computer. Especially as I use 'n' in some of 
my passwords... *LOL*


So if you ever feel you spend to much time with the computer, just screw 
up some of the keys on the keyboard...


Anyway, now I'll try to monitor the list much more frequently, but in case 
something needs my attention, please just email me directly.


Totally off topic. Any of you using Wave?

cheers
/Christian

PS. I've done some attempts at trying to find a new laptop, but the ones 
I've looked at so far either require you to use a Function key to access 
some of pgup/pgdn/insert/delete/end, or they've placed the keys in a 
really stupid place! :-(


In addition, I guess laptop keyboards in general will find it difficult to 
compete with a specific keyboard type I've been using for close to a 
decade...


So I'd be happy to get tips on laptops with good keyboards for 
typing/coding. The laptop is just going to stay in my living room, being 
connected through remote desktop to a virtual machine. So primarily it 
just needs a good keyboard/screen/touchpad...


For your amusement, I'm writing this text in the following manner:

I'm typing on a wireless keyboard with a touchpad that I just bought. The 
data goes to a server in another room, which is running 'synergy', which 
then sends the typing data to my laptop. The laptop in turn is connected 
via remote desktop to a virtual machine on the server, where I'm running 
alpine.


Synergy is quite nice, it allows me to drag the mouse pointer to the edge 
of my TV, which is connected to the server, and the mouse pointer pops up 
on the laptop screen. And vice versa to shift the focus back to the 
server/TV. I can really recommend synergy if you want to control muliple 
computers from one keyboard/mouse.


--
Christian Ridderström

Re: configure.py [patch] for branch

Hi Uwe,

On Tue, Oct 20, 2009 at 10:47 PM, Uwe Stöhr  wrote:
> This is not correct. The code looks for a file named elyxer.py. This can
> only be found when it is in a path known by LyX. That means that it has to
> be somewhere in LyX's subfolders. Other folders aren't possible since the
> installer can only detect paths given in the registry. So when eLyXer would
> be a standalone program it would have been written its installation path in
> the registry. The LyX installer could then check if eLyXer is installed and
> add its path to the known LyX paths.

This is not what I understand from the code. It seems to look for
elyxer.py in all execution paths known to Python, not to LyX. On
Windows these include all Windows execution paths (the %PATH%
variable).

> Therefore I was forced to use a certain location for the file and have
> chosen the directory where we store all other python scripts. So you can see
> eLyXer as a plugin and the scripts folder is LyX folder for plugins.

The problem is that it doesn't work as you think it does, at least on
Linux. On my trusty Debian I have just tried removing the elyxer
package, placing elyxer.py in the LyX scripts folder, and LyX is not
able to find it. I would bet that on Windows it will be the same:
remove elyxer.py from the execution path and try to see if LyX
reconfigure can find the copy in the scripts folder. With the current
patch (the one in svn right now) Linux users (and Windows users
probably too) will never be able to use eLyXer, even if it is included
in the LyX scripts folder, unless there is an additional copy in the
execution path (which will not be used apart from detection).

>> This copy of elyxer.py in the scripts directory has to be distributed
>> along with LyX, either standalone or in the installer.
>
> This is intended. When elyxer.py is in the scripts folder, the user wants to
> use it as HTML converter, if not then tex4ht will be used.

But as I explained above, when elyxer.py is in the scripts folder the
configure.py script is not able to locate it. Another option would be
to place elyxer.py in the same folder as the LyX executable file;
according to some user reports this might work fine.

> I don't agree. Those few users can copy the elyxer.py file to the scripts
> folder and everything will work. Spending time for backward compatibility of
> a script that has not yet been released together with LyX is not worth the
> time in my opinion. Note the eLyXer don't work properly with LyX 1.6.4
> because we fixed the image file and ext_copy.py issues afterwards. Forcing
> the users to copy a single file shouldn't be a too hard task.

It would not be too hard -- the first time. Making users copy it back
every time they update LyX (on Mac OS X), or for every LyX
installation, is not so nice for users. Specially when the check can
be done for them in a few lines.

>> The recommended way of running eLyXer is as a module; I sent a patch
>> to the list that tried to first detect the module and then the
>> executable.
>
> This requires a full Python installation. A full LyX installation already
> needs about 500 MB on your harddisk and has a download size of about 120MB.
> To save further 50 MB on the harddisk and 30 MB download size, my (and also
> Joost's installer) bundle a stripped down version of Python. This version
> includes all necessary files to run our python scripts and works well with
> elyxer.py.
> Being forced to install Python completely is no option just for one script
> with a filesize of only a few kB.

I did not know this; you are right, it is quite impractical. Anyway
the patch can be used on Linux where Python is probably already
installed, or by advanced users; it also detects elyxer (or elyxer.py)
in the execution path, so everyone is happy.

>>  - install eLyXer in the path,
>
> What do you mean with "path"?

Execution path. The same folder as LyX.exe would be enough, on
Windows. On Linux /usr/bin is fine.

> Finally. as I often stated: eLyXer can only work together with LyX and I
> will therefore never understand what it cannot just be another python script
> in our SVN. When it would be in our SVN, everybody could fix bugs in the
> file in case you are not available. It would be part of every new LyX
> release and users can report bugs with this script to our bugtracker.

That is not my decision to make. In any case I maintain that eLyXer is
useful as a standalone tool even for people that do not use LyX,
increasing at the same time the usefulness of LyX itself. People who
have been given a LyX document can use a little script to translate
it, instead of having to download the whole LyX package with all its
dependencies. eLyXer can be used on a server to check a LyX document
and maybe serve it as an HTML file. And so on.

Alex.

Re: configure.py [patch] for branch

Alex Fernandez schrieb:

This works. I never had elyxer.py in another folder. configure.py also finds the other scripts in
the scripts folder, so why shouldn't it find elyxer.py? Can you please recheck because it must work.

Forcing
the users to copy a single file shouldn't be a too hard task.

Why do you then don't agree to include eLyXer to LyX?

- install eLyXer in the path,

What do you mean with "path"?

Execution path. The same folder as LyX.exe would be enough, on
Windows. On Linux /usr/bin is fine.

I can move the file location from the scripts folder to the bin folder but this doesn't change
anything. eLyXer still needs to be copied there.

Finally. as I often stated: eLyXer can only work together with LyX and I
will therefore never understand what it cannot just be another python script
in our SVN. When it would be in our SVN, everybody could fix bugs in the
file in case you are not available. It would be part of every new LyX
release and users can report bugs with this script to our bugtracker.

But you can already use every Python script that is part of LyX as standalone script. Just download
it from here:

http://www.lyx.org/trac/browser/lyx-devel/branches/BRANCH_1_6_X/lib/scripts
or here:
http://www.lyx.org/trac/browser/lyx-devel/trunk/lib/scripts

You also can provide eLyXer as standalone program, no matter that it is
included in LyX.

regards Uwe

Re: configure.py [patch] for branch