Re: problem with bibliography

2009-07-31 Thread Manveru
2009/7/30 Sam Liddicott s...@liddicott.com:
 * Beny Spira wrote, On 29/07/09 22:05:
 Thanks to all that replied

 It turned out the problem was in some references that contained URL with
 special characteres. I deleted the URLs and the problem vanished.


 So... is that a Tex bug? Will you get a cheque for $655.36 ?

In the worst case here this is a bug in one of LaTeX packages, not a TeX itself.

-- 
Manveru
jabber: manv...@manveru.pl
 gg: 1624001
   http://www.manveru.pl


Text wrap figure fails in a Hebrew document

2009-07-31 Thread Yosef Meller

Hi,

I am trying to create a wrap figure in LyX. In an English document it 
works, but in a Hebrew document, inserting a wrap figure causes the DVI 
or PDF creation to fail with the following error in the LaTeX errors 
dialog:


Argument of \everypar has an extra }.
inserted text
\par
l.44 \end{wrapfigure}

Previously latex would stall indefinitely too, but that seems to be 
solved by installing the package tetex-lang-hebrew from Ubuntu 
repositories.


I'm attaching a sample LyX document that recreates this behavior.

Thanks in advance for any help on this,
Yosef.



newfile2.lyx
Description: application/lyx


Re: Drag and Drop

2009-07-31 Thread Marcelo Acuña

 Hello,
 
 Maybe a stupid question:
 But I realized that I can select/mark a sentence with the
 mouse, but I cannot drag this selected sentence around in
 Lyx, e.g. placing it in the paragraph above. Everytime I try
 this the sentence is deselected.

 With alt + arrow up (arrow down) you get to move the paragraph.
 Marcelo

__
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar


Lyx 1.6.3 Can I ditch the pointNclick list of open files below the toolbars???

2009-07-31 Thread Joe(theWordy)Philbrook

I'm using lyx 1.6.3 on Sabayon Linux 4.2. Which is fairly impressive BTW.
I like most of the user interface. Well that is except that As a
keyboard-centric user with very poor mouse coordination I always resent
screen space taken up by point n' click specific tools such as most
toolbars. For example if alt+p[space] worked without that
scrollbox attached to the standard toolbar the .ui file would say

= Toolbars
= standard off,top
= extra off,top
= table off,bottom
= math off,bottom
= minibuffer off,bottom
= End

As it is the only one I leave on is standard. And that to keep the
viability of the  3-key,2-stroke keybinding alt+p[space]. Thus
I put up with wasting a whole line of screen space on mostly useless
stuff I would never ever click on.

Likewise, If I want to switch to another open document with lyx 1.6.3
I'd use alt+D[2] to switch to the second open document, via the
pull down menu. Though I'll admit my fingers usually start with the old
alt+v[2] that isn't in the view menu anymore before I realise
that the functionality was moved to the Documents pull-down menu.

BUT I would never ever wrestle with my mouse to get that (expletive
deleted) pointer on the name of the document displayed with an [x]
just under the toolbars... And that would be so, even if I wasn't just
as likely to accidentally click on one of the [x]s...

Is there any way to get them off my screen???

-- 
|  ~^~   ~^~
|  ?   ? Joe (theWordy) Philbrook
|  ^  J(tWdy)P
|\___/ jtw...@ttlc.net



RE: Lyx 1.6.3 Can I ditch the pointNclick list of open files below the toolbars???

2009-07-31 Thread Vincent van Ravesteijn - TNW
 
 Is there any way to get them off my screen???

Tools-Preferences-Look  Feel-Open Document in Tabs

Vincent


Re: Text wrap figure fails in a Hebrew document

2009-07-31 Thread Sam Liddicott
* Yosef Meller wrote, On 31/07/09 09:47:
 Hi,
 
 I am trying to create a wrap figure in LyX. In an English document it
 works, but in a Hebrew document, inserting a wrap figure causes the DVI
 or PDF creation to fail with the following error in the LaTeX errors
 dialog:
 
 Argument of \everypar has an extra }.
 inserted text
 \par
 l.44 \end{wrapfigure}
 
 Previously latex would stall indefinitely too, but that seems to be
 solved by installing the package tetex-lang-hebrew from Ubuntu
 repositories.


Stall indefinitely is usually because latex/tex is trying to read from
stdin.

If you run lyx from a console window then you can type ctrl-d and finish
the stall.

I generally run lyx /dev/null to avoid the problem.

Sam


Re: Drag and Drop

2009-07-31 Thread Nikos Alexandris
On Fri, 2009-07-31 at 06:12 -0700, Marcelo Acuña wrote:
  Hello,
  
  Maybe a stupid question:
  But I realized that I can select/mark a sentence with the
  mouse, but I cannot drag this selected sentence around in
  Lyx, e.g. placing it in the paragraph above. Everytime I try
  this the sentence is deselected.
 
  With alt + arrow up (arrow down) you get to move the paragraph.
  Marcelo

Wouldn't it be useful to extend this functionality to move around a
selection (selected environments) as well?

Nikos



Re: Drag and Drop

2009-07-31 Thread Michael Joyner ᏩᏯ
Drag and drop text is one the most annoying things I have found with
word processors.
It is too easy to do it by accident, not notice, and output garbage for
people to read.
Nikos Alexandris wrote:
 On Fri, 2009-07-31 at 06:12 -0700, Marcelo Acuña wrote:
   
 Hello,

 Maybe a stupid question:
 But I realized that I can select/mark a sentence with the
 mouse, but I cannot drag this selected sentence around in
 Lyx, e.g. placing it in the paragraph above. Everytime I try
 this the sentence is deselected.
   
  With alt + arrow up (arrow down) you get to move the paragraph.
  Marcelo
 

 Wouldn't it be useful to extend this functionality to move around a
 selection (selected environments) as well?

 Nikos

   


-- 
LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/
GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/



signature.asc
Description: OpenPGP digital signature


Re: Drag and Drop

2009-07-31 Thread Nikos Alexandris

On Fri, 2009-07-31 at 11:43 -0400, Michael Joyner:

 Drag and drop text is one the most annoying things I have found with
 word processors.
 It is too easy to do it by accident, not notice, and output garbage
 for people to read.


I don't mean drag-n-drop with the mouse. I mean select 2 lines (say
title and it's text) and move it with Alt + arrow.

Nikos


 Nikos Alexandris wrote: 
  On Fri, 2009-07-31 at 06:12 -0700, Marcelo Acuña wrote:

Hello,

Maybe a stupid question:
But I realized that I can select/mark a sentence with the
mouse, but I cannot drag this selected sentence around in
Lyx, e.g. placing it in the paragraph above. Everytime I try
this the sentence is deselected.
  
   With alt + arrow up (arrow down) you get to move the paragraph.
Marcelo
   
  
  Wouldn't it be useful to extend this functionality to move around a
  selection (selected environments) as well?
  
  Nikos



Re: Drag and Drop

2009-07-31 Thread Abdelrazak Younes

Nikos Alexandris wrote:

On Fri, 2009-07-31 at 11:43 -0400, Michael Joyner:


Drag and drop text is one the most annoying things I have found with
word processors.
It is too easy to do it by accident, not notice, and output garbage
for people to read.



I don't mean drag-n-drop with the mouse. I mean select 2 lines (say
title and it's text) and move it with Alt + arrow.


Doesn't look any simpler than select 2 lines, Ctr+X, move the cursor 
with arrows or mouse and Ctrl+V...


Abdel.



Re: The case for human parsable LyX native format

2009-07-31 Thread Hellmut Weber

Steve Litt schrieb:

Hi all,

I just solved two very difficult LyX problems using Vim, and it reminded me just 
how lucky we are that the current LyX native format is easily readable and 
parsable by a normally intelligent human.


In the first case, LyX would crash about 3 seconds after opening a document in 
1.6.3. For various reasons I suspected it was the overly large .eps cover art, 
but I encountered a buried shovel. If only I could get LyX to work, I could 
change the cover art, and if only I could change the cover art, I could get 
LyX to work. Vim to the rescue: I changed cover.eps to cover.pdf to work 
around the problem (which I suspect is a LyX ungraceful handling of a too 
large graphic).


In the second case, I had an indexing problem preventing making the PDF. Using 
diagnostics like the ilg, ind and idx files, I narrowed it down to five possible 
culprit index entries. I got it down to one error, but the .ind file was 
showing a backslash that didn't exist in the LyX index entry. When I opened 
the LyX file in Vim, the problem stuck out like a sore thumb -- there was an 
extra inset and some other garbage within the index structure. I removed it 
with Vim and bang, the document compiled perfectly to PDF.


There have been a lot of discussions about changing the LyX native formula. 
I'd like to ask that whatever the new format turns out to be, it be at least 
as easy for a normal intelligence human to manually edit, parse and modify as 
the current format.


XML has been discussed, and the point has been made that if XML is done with 
an eye toward manual parsing and editing, it can be as easy to parse and edit 
in Vim as the current native format. While that's obviously true, we all know 
that from a human parsing viewpoint, XML can quickly get out of control. One 
look at any OpenOffice file confirms this. XML has the capability to make one 
paragraph depend on several different XML subtrees. If authored that way, for 
all practical purposes human manual parsability and editability is destroyed.


Also, the XML spec itself does not recognize lines, so it would be up to the 
LyX tools to properly assign lines to nodes and vice versa. Otherwise it would 
be impossible to write LyX creation and modification scripts, at least without 
a big, ugly XML parser.


I'm pretty sure all the current developers understand all this because you 
regularly tweak LyX from editors yourselves. I am concerned, however, that 
future LyX developers will say Hey, LyX is XML and to do our jobs correctly 
we need to just worry about valid XML, not linefeeds. On that day, a great 
deal of user power is lost.


So, as usual, Im pleading that as you decide on future native formats, you 
make the new formats as human parsable and editable as the current version.


Thanks

SteveT




Hi LyX developpers,
I would like to strongly support Steve's point of view !

Quite often I have to create documents which contain mostly images and 
nearly no text at all.
So I put in one of the images manually using the GUI, give it a look and 
the rest is done using gvim and/or bash scripting and the like.


For me this is a great gain in productivity compared to the inclusion of 
maybe 80 images via the GUI.


And this procedure is possible exactly because the actual LyX internal 
format is very readable (even rather suggestive ;-)


So, me too I would like to beg you all:

Keep this in mind when deciding on any change of the internal format.


For the rest LyX is THE mosdt important tool for all my work with a 
computer, working (still at 66) as management consultant.



Best regards

Hellmut


--
Dr. Hellmut Weber m...@hellmutweber.de
Degenfeldstraße 2 tel   +49-89-3081172
D-80803 München-Schwabing mobil +49-172-8450321
please: No DOCs, no PPTs. why: tinyurl.com/cbgq



Re: The case for human parsable LyX native format

2009-07-31 Thread Abdelrazak Younes

Hellmut Weber wrote:

Steve Litt schrieb:
So, as usual, Im pleading that as you decide on future native 
formats, you make the new formats as human parsable and editable as 
the current version.


Thanks

SteveT




Hi LyX developpers,
I would like to strongly support Steve's point of view !


Don't worry, as was explained many times to Steve, this point is well 
understood and this opinion is shared among the majority of developpers 
if not all of them. The switch to XML, if that ever happens, will 
*never* be at the  expense of readability. So there is actually no need 
to do any lobbying on that front :-)


Abdel.



Re: Drag and Drop

2009-07-31 Thread Johannes Knaus
First of all, I simply didn't realize that mouse drag'n'drop did not  
work in Lyx and thought this could maybe a platform specific issue,  
not a general one.



On Fri, 2009-07-31 at 11:43 -0400, Michael Joyner:
Drag and drop text is one the most annoying things I have found  
with

word processors.
It is too easy to do it by accident, not notice, and output garbage
for people to read.



I can't imagine how one could mark some text with the mouse hold-and- 
click it and drag it around by accident.


I think the discussion on going on here is somewhat dogmatic. Many  
people use Ctrl+X and then Ctrl+V to shift textparts around. That's  
o.k. and that's what I do as I have no other chance in Lyx to do this.
My point is: Drag and drop is something many Mac Users (I am one) and  
Windows users may be very used to in everyday work. So implementing  
this feature would make Lyx a little easier to work with when you are  
new to Lyx.
Those who don't like drag and drop are not forced to use it, it would  
be just another editing option (maybe to be activated or deactivated  
via GUI). Still, I don't see the problem in having this feature – if  
you want to use it, use it, if not, don't. I don't think this can  
create any trouble by accident.


It certainly would be a problem, if implementing this feature really  
costs a lot of time. I simply don't know this as I'm not a programmer.


Another thing is that is maybe not the most urgent feature on the Lyx- 
feature-wish-list. That's o.k. It was only a question.

Still, voting for it is legitimate.




Re: Drag and Drop

2009-07-31 Thread Abdelrazak Younes

Johannes Knaus wrote:
It certainly would be a problem, if implementing this feature really 
costs a lot of time. I simply don't know this as I'm not a programmer.


To answer your question, this feature is straight forward to implement 
as we have developed own text work area and do not rely on a given text 
widget from Qt.




Another thing is that is maybe not the most urgent feature on the 
Lyx-feature-wish-list. That's o.k. It was only a question.

Still, voting for it is legitimate.


The feature request is very legitimate indeed. A generalized dragdrop 
feature (including from external application) would be welcome.


Abdel.



Re: Drag and Drop

2009-07-31 Thread Abdelrazak Younes

Abdelrazak Younes wrote:

Johannes Knaus wrote:
It certainly would be a problem, if implementing this feature really 
costs a lot of time. I simply don't know this as I'm not a programmer.


To answer your question, this feature is straight forward to implement 


Hum... this feature is *not* straight forward to implement...

Abdel.



Re: Drag and Drop

2009-07-31 Thread Steve Litt
On Friday 31 July 2009 12:20:27 Abdelrazak Younes wrote:
 Nikos Alexandris wrote:
  On Fri, 2009-07-31 at 11:43 -0400, Michael Joyner:
  Drag and drop text is one the most annoying things I have found with
  word processors.
  It is too easy to do it by accident, not notice, and output garbage
  for people to read.
 
  I don't mean drag-n-drop with the mouse. I mean select 2 lines (say
  title and it's text) and move it with Alt + arrow.

 Doesn't look any simpler than select 2 lines, Ctr+X, move the cursor
 with arrows or mouse and Ctrl+V...

 Abdel.

Agreed. It's easy as all getout to move text around the current program, with 
Ctrl+X and Ctrl+V, or even the outlining feature (thanks for adding that). I'd 
prioritize a lot of things more than another way to move text around. I'd love 
to have a log of how layouts get loaded (I gave an overview of that in another 
message), and a /usr/share/lyx/configure.py that EXACTLY matches the action of 
Tools-Reconfigure in the LyX environment.

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt




Re: The case for human parsable LyX native format

2009-07-31 Thread Michael Joyner ᏩᏯ
Abdelrazak Younes wrote:
 Hellmut Weber wrote:
 Steve Litt schrieb:
 So, as usual, Im pleading that as you decide on future native
 formats, you make the new formats as human parsable and editable as
 the current version.

 Thanks

 SteveT



 Hi LyX developpers,
 I would like to strongly support Steve's point of view !

 Don't worry, as was explained many times to Steve, this point is well
 understood and this opinion is shared among the majority of
 developpers if not all of them. The switch to XML, if that ever
 happens, will *never* be at the  expense of readability. So there is
 actually no need to do any lobbying on that front :-)

 Abdel.

Good, now I can sleep better. Script creation of LyX documents from sql
database exports using PHP and Bash is very important to me. RAD for
computer generated documents is LyX.

-- 
LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/
GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/



signature.asc
Description: OpenPGP digital signature


RE: Lyx 1.6.3 Can I ditch the pointNclick list of open files below the toolbars???

2009-07-31 Thread Joe(theWordy)Philbrook

It would appear that on Jul 31, Vincent van Ravesteijn - TNW did say:

  Is there any way to get them off my screen???
 
 Tools-Preferences-Look  Feel-Open Document in Tabs
 

Thanks. But when I tried that the results were less than ideal.

I don't know why I didn't realize I was talking about tabs until
you identified the toggle. {Unless it has to do with the fact that
when I use LyX I'm always either opening just one document (in which
case there isn't one) Or I'm opening a half dozen documents with a
script where the average filename length is about 30 characters long.
(in which case the row of tabs don't all fit} and so I never discerned
the pattern of a tab beside a spot without one...}

But in any case the results are that several separate LyX windows open.
which in itself isn't bad, but since the filenames are so long it's
hard to determine which doc is which switching via the alt+tab
global shortcut. And if I try to use the alt+D[$number] method,
the tabs in that particular document window turn themselves back on...

It might be nice for keyboard centric users who switch documents via
the menu, rather than by clicking on the tab,  if they added an
additional check box or .ui file item, that toggled the graphic display
of the tabs like it was a toolbar full of tabs, while still allowing
ONE document window to switch between several [virtual tab]
documents via the pull down menu... But as feature requests go, I
doubt this would ever be considered a high priority...

So I'm thinking that I'll just have to live with the durned tabs.

Thanks anyway!

-- 
|^^^   ^^^
|o   o   Joe (theWordy) Philbrook
|^J(tWdy)P
|   ___jtw...@ttlc.net
|   
|  sigh



Re: Drag and Drop

2009-07-31 Thread Joe(theWordy)Philbrook

It would appear that on Jul 31, Johannes Knaus did say:

 I can't imagine how one could mark some text with the mouse hold-and-click it
 and drag it around by accident.

You have never seen *ME* try to use the mouse... Though it is
frequently the easiest way to copy/paste text between applications
when one or more of the source/destination applications do NOT
support  ^C ^V and shifted arrows for marking... I for one would
find it umm frustrating if some text automatically relocated because
I was being a klutz while attempting to drag the the mouse pointer
across a range of text to copy to the (gpm?) buffer some text I
wanted to paste into an xterm.
 
 I think the discussion on going on here is somewhat dogmatic. Many people use
 Ctrl+X and then Ctrl+V to shift textparts around. That's o.k. and that's what
 I do as I have no other chance in Lyx to do this.

I for one am glad many people use that technique, It means it's
unlikely that LyX's keyboard control methods will be phased out any
time soon.

 Those who don't like drag and drop are not forced to use it, it would be just
 another editing option (maybe to be activated or deactivated via GUI). Still,
# --- --- -- -- ^^ ^^ ^ ^^ ^^^ ^^^ ^^^-- --

When you said this however you got my vote. Just as long as the
feature *CAN* be deactivated by the user... 

[rant-mode]
I might be a keyboard centric computer user who is always having
difficulty dealing with the point N click style dogma that seems
to say that if you make it easy for mouse centric users to click
instead of keypunching, then it's OK if you can't do something
anymore without resorting to that {many paragraphs of expletives
deleted} rodent...

But that doesn't mean that I think mouse centric users should be
denied point n click methods I just don't want them pushed on me.
[/rant-mode]

-- 
|   ---   ___
|   0   -  Joe (theWordy) Philbrook
|   ^   J(tWdy)P
|~\___/~ jtw...@ttlc.net



Re: problem with bibliography

2009-07-31 Thread Manveru
2009/7/30 Sam Liddicott s...@liddicott.com:
 * Beny Spira wrote, On 29/07/09 22:05:
 Thanks to all that replied

 It turned out the problem was in some references that contained URL with
 special characteres. I deleted the URLs and the problem vanished.


 So... is that a Tex bug? Will you get a cheque for $655.36 ?

In the worst case here this is a bug in one of LaTeX packages, not a TeX itself.

-- 
Manveru
jabber: manv...@manveru.pl
 gg: 1624001
   http://www.manveru.pl


Text wrap figure fails in a Hebrew document

2009-07-31 Thread Yosef Meller

Hi,

I am trying to create a wrap figure in LyX. In an English document it 
works, but in a Hebrew document, inserting a wrap figure causes the DVI 
or PDF creation to fail with the following error in the LaTeX errors 
dialog:


Argument of \everypar has an extra }.
inserted text
\par
l.44 \end{wrapfigure}

Previously latex would stall indefinitely too, but that seems to be 
solved by installing the package tetex-lang-hebrew from Ubuntu 
repositories.


I'm attaching a sample LyX document that recreates this behavior.

Thanks in advance for any help on this,
Yosef.



newfile2.lyx
Description: application/lyx


Re: Drag and Drop

2009-07-31 Thread Marcelo Acuña

 Hello,
 
 Maybe a stupid question:
 But I realized that I can select/mark a sentence with the
 mouse, but I cannot drag this selected sentence around in
 Lyx, e.g. placing it in the paragraph above. Everytime I try
 this the sentence is deselected.

 With alt + arrow up (arrow down) you get to move the paragraph.
 Marcelo

__
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar


Lyx 1.6.3 Can I ditch the pointNclick list of open files below the toolbars???

2009-07-31 Thread Joe(theWordy)Philbrook

I'm using lyx 1.6.3 on Sabayon Linux 4.2. Which is fairly impressive BTW.
I like most of the user interface. Well that is except that As a
keyboard-centric user with very poor mouse coordination I always resent
screen space taken up by point n' click specific tools such as most
toolbars. For example if alt+p[space] worked without that
scrollbox attached to the standard toolbar the .ui file would say

= Toolbars
= standard off,top
= extra off,top
= table off,bottom
= math off,bottom
= minibuffer off,bottom
= End

As it is the only one I leave on is standard. And that to keep the
viability of the  3-key,2-stroke keybinding alt+p[space]. Thus
I put up with wasting a whole line of screen space on mostly useless
stuff I would never ever click on.

Likewise, If I want to switch to another open document with lyx 1.6.3
I'd use alt+D[2] to switch to the second open document, via the
pull down menu. Though I'll admit my fingers usually start with the old
alt+v[2] that isn't in the view menu anymore before I realise
that the functionality was moved to the Documents pull-down menu.

BUT I would never ever wrestle with my mouse to get that (expletive
deleted) pointer on the name of the document displayed with an [x]
just under the toolbars... And that would be so, even if I wasn't just
as likely to accidentally click on one of the [x]s...

Is there any way to get them off my screen???

-- 
|  ~^~   ~^~
|  ?   ? Joe (theWordy) Philbrook
|  ^  J(tWdy)P
|\___/ jtw...@ttlc.net



RE: Lyx 1.6.3 Can I ditch the pointNclick list of open files below the toolbars???

2009-07-31 Thread Vincent van Ravesteijn - TNW
 
 Is there any way to get them off my screen???

Tools-Preferences-Look  Feel-Open Document in Tabs

Vincent


Re: Text wrap figure fails in a Hebrew document

2009-07-31 Thread Sam Liddicott
* Yosef Meller wrote, On 31/07/09 09:47:
 Hi,
 
 I am trying to create a wrap figure in LyX. In an English document it
 works, but in a Hebrew document, inserting a wrap figure causes the DVI
 or PDF creation to fail with the following error in the LaTeX errors
 dialog:
 
 Argument of \everypar has an extra }.
 inserted text
 \par
 l.44 \end{wrapfigure}
 
 Previously latex would stall indefinitely too, but that seems to be
 solved by installing the package tetex-lang-hebrew from Ubuntu
 repositories.


Stall indefinitely is usually because latex/tex is trying to read from
stdin.

If you run lyx from a console window then you can type ctrl-d and finish
the stall.

I generally run lyx /dev/null to avoid the problem.

Sam


Re: Drag and Drop

2009-07-31 Thread Nikos Alexandris
On Fri, 2009-07-31 at 06:12 -0700, Marcelo Acuña wrote:
  Hello,
  
  Maybe a stupid question:
  But I realized that I can select/mark a sentence with the
  mouse, but I cannot drag this selected sentence around in
  Lyx, e.g. placing it in the paragraph above. Everytime I try
  this the sentence is deselected.
 
  With alt + arrow up (arrow down) you get to move the paragraph.
  Marcelo

Wouldn't it be useful to extend this functionality to move around a
selection (selected environments) as well?

Nikos



Re: Drag and Drop

2009-07-31 Thread Michael Joyner ᏩᏯ
Drag and drop text is one the most annoying things I have found with
word processors.
It is too easy to do it by accident, not notice, and output garbage for
people to read.
Nikos Alexandris wrote:
 On Fri, 2009-07-31 at 06:12 -0700, Marcelo Acuña wrote:
   
 Hello,

 Maybe a stupid question:
 But I realized that I can select/mark a sentence with the
 mouse, but I cannot drag this selected sentence around in
 Lyx, e.g. placing it in the paragraph above. Everytime I try
 this the sentence is deselected.
   
  With alt + arrow up (arrow down) you get to move the paragraph.
  Marcelo
 

 Wouldn't it be useful to extend this functionality to move around a
 selection (selected environments) as well?

 Nikos

   


-- 
LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/
GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/



signature.asc
Description: OpenPGP digital signature


Re: Drag and Drop

2009-07-31 Thread Nikos Alexandris

On Fri, 2009-07-31 at 11:43 -0400, Michael Joyner:

 Drag and drop text is one the most annoying things I have found with
 word processors.
 It is too easy to do it by accident, not notice, and output garbage
 for people to read.


I don't mean drag-n-drop with the mouse. I mean select 2 lines (say
title and it's text) and move it with Alt + arrow.

Nikos


 Nikos Alexandris wrote: 
  On Fri, 2009-07-31 at 06:12 -0700, Marcelo Acuña wrote:

Hello,

Maybe a stupid question:
But I realized that I can select/mark a sentence with the
mouse, but I cannot drag this selected sentence around in
Lyx, e.g. placing it in the paragraph above. Everytime I try
this the sentence is deselected.
  
   With alt + arrow up (arrow down) you get to move the paragraph.
Marcelo
   
  
  Wouldn't it be useful to extend this functionality to move around a
  selection (selected environments) as well?
  
  Nikos



Re: Drag and Drop

2009-07-31 Thread Abdelrazak Younes

Nikos Alexandris wrote:

On Fri, 2009-07-31 at 11:43 -0400, Michael Joyner:


Drag and drop text is one the most annoying things I have found with
word processors.
It is too easy to do it by accident, not notice, and output garbage
for people to read.



I don't mean drag-n-drop with the mouse. I mean select 2 lines (say
title and it's text) and move it with Alt + arrow.


Doesn't look any simpler than select 2 lines, Ctr+X, move the cursor 
with arrows or mouse and Ctrl+V...


Abdel.



Re: The case for human parsable LyX native format

2009-07-31 Thread Hellmut Weber

Steve Litt schrieb:

Hi all,

I just solved two very difficult LyX problems using Vim, and it reminded me just 
how lucky we are that the current LyX native format is easily readable and 
parsable by a normally intelligent human.


In the first case, LyX would crash about 3 seconds after opening a document in 
1.6.3. For various reasons I suspected it was the overly large .eps cover art, 
but I encountered a buried shovel. If only I could get LyX to work, I could 
change the cover art, and if only I could change the cover art, I could get 
LyX to work. Vim to the rescue: I changed cover.eps to cover.pdf to work 
around the problem (which I suspect is a LyX ungraceful handling of a too 
large graphic).


In the second case, I had an indexing problem preventing making the PDF. Using 
diagnostics like the ilg, ind and idx files, I narrowed it down to five possible 
culprit index entries. I got it down to one error, but the .ind file was 
showing a backslash that didn't exist in the LyX index entry. When I opened 
the LyX file in Vim, the problem stuck out like a sore thumb -- there was an 
extra inset and some other garbage within the index structure. I removed it 
with Vim and bang, the document compiled perfectly to PDF.


There have been a lot of discussions about changing the LyX native formula. 
I'd like to ask that whatever the new format turns out to be, it be at least 
as easy for a normal intelligence human to manually edit, parse and modify as 
the current format.


XML has been discussed, and the point has been made that if XML is done with 
an eye toward manual parsing and editing, it can be as easy to parse and edit 
in Vim as the current native format. While that's obviously true, we all know 
that from a human parsing viewpoint, XML can quickly get out of control. One 
look at any OpenOffice file confirms this. XML has the capability to make one 
paragraph depend on several different XML subtrees. If authored that way, for 
all practical purposes human manual parsability and editability is destroyed.


Also, the XML spec itself does not recognize lines, so it would be up to the 
LyX tools to properly assign lines to nodes and vice versa. Otherwise it would 
be impossible to write LyX creation and modification scripts, at least without 
a big, ugly XML parser.


I'm pretty sure all the current developers understand all this because you 
regularly tweak LyX from editors yourselves. I am concerned, however, that 
future LyX developers will say Hey, LyX is XML and to do our jobs correctly 
we need to just worry about valid XML, not linefeeds. On that day, a great 
deal of user power is lost.


So, as usual, Im pleading that as you decide on future native formats, you 
make the new formats as human parsable and editable as the current version.


Thanks

SteveT




Hi LyX developpers,
I would like to strongly support Steve's point of view !

Quite often I have to create documents which contain mostly images and 
nearly no text at all.
So I put in one of the images manually using the GUI, give it a look and 
the rest is done using gvim and/or bash scripting and the like.


For me this is a great gain in productivity compared to the inclusion of 
maybe 80 images via the GUI.


And this procedure is possible exactly because the actual LyX internal 
format is very readable (even rather suggestive ;-)


So, me too I would like to beg you all:

Keep this in mind when deciding on any change of the internal format.


For the rest LyX is THE mosdt important tool for all my work with a 
computer, working (still at 66) as management consultant.



Best regards

Hellmut


--
Dr. Hellmut Weber m...@hellmutweber.de
Degenfeldstraße 2 tel   +49-89-3081172
D-80803 München-Schwabing mobil +49-172-8450321
please: No DOCs, no PPTs. why: tinyurl.com/cbgq



Re: The case for human parsable LyX native format

2009-07-31 Thread Abdelrazak Younes

Hellmut Weber wrote:

Steve Litt schrieb:
So, as usual, Im pleading that as you decide on future native 
formats, you make the new formats as human parsable and editable as 
the current version.


Thanks

SteveT




Hi LyX developpers,
I would like to strongly support Steve's point of view !


Don't worry, as was explained many times to Steve, this point is well 
understood and this opinion is shared among the majority of developpers 
if not all of them. The switch to XML, if that ever happens, will 
*never* be at the  expense of readability. So there is actually no need 
to do any lobbying on that front :-)


Abdel.



Re: Drag and Drop

2009-07-31 Thread Johannes Knaus
First of all, I simply didn't realize that mouse drag'n'drop did not  
work in Lyx and thought this could maybe a platform specific issue,  
not a general one.



On Fri, 2009-07-31 at 11:43 -0400, Michael Joyner:
Drag and drop text is one the most annoying things I have found  
with

word processors.
It is too easy to do it by accident, not notice, and output garbage
for people to read.



I can't imagine how one could mark some text with the mouse hold-and- 
click it and drag it around by accident.


I think the discussion on going on here is somewhat dogmatic. Many  
people use Ctrl+X and then Ctrl+V to shift textparts around. That's  
o.k. and that's what I do as I have no other chance in Lyx to do this.
My point is: Drag and drop is something many Mac Users (I am one) and  
Windows users may be very used to in everyday work. So implementing  
this feature would make Lyx a little easier to work with when you are  
new to Lyx.
Those who don't like drag and drop are not forced to use it, it would  
be just another editing option (maybe to be activated or deactivated  
via GUI). Still, I don't see the problem in having this feature – if  
you want to use it, use it, if not, don't. I don't think this can  
create any trouble by accident.


It certainly would be a problem, if implementing this feature really  
costs a lot of time. I simply don't know this as I'm not a programmer.


Another thing is that is maybe not the most urgent feature on the Lyx- 
feature-wish-list. That's o.k. It was only a question.

Still, voting for it is legitimate.




Re: Drag and Drop

2009-07-31 Thread Abdelrazak Younes

Johannes Knaus wrote:
It certainly would be a problem, if implementing this feature really 
costs a lot of time. I simply don't know this as I'm not a programmer.


To answer your question, this feature is straight forward to implement 
as we have developed own text work area and do not rely on a given text 
widget from Qt.




Another thing is that is maybe not the most urgent feature on the 
Lyx-feature-wish-list. That's o.k. It was only a question.

Still, voting for it is legitimate.


The feature request is very legitimate indeed. A generalized dragdrop 
feature (including from external application) would be welcome.


Abdel.



Re: Drag and Drop

2009-07-31 Thread Abdelrazak Younes

Abdelrazak Younes wrote:

Johannes Knaus wrote:
It certainly would be a problem, if implementing this feature really 
costs a lot of time. I simply don't know this as I'm not a programmer.


To answer your question, this feature is straight forward to implement 


Hum... this feature is *not* straight forward to implement...

Abdel.



Re: Drag and Drop

2009-07-31 Thread Steve Litt
On Friday 31 July 2009 12:20:27 Abdelrazak Younes wrote:
 Nikos Alexandris wrote:
  On Fri, 2009-07-31 at 11:43 -0400, Michael Joyner:
  Drag and drop text is one the most annoying things I have found with
  word processors.
  It is too easy to do it by accident, not notice, and output garbage
  for people to read.
 
  I don't mean drag-n-drop with the mouse. I mean select 2 lines (say
  title and it's text) and move it with Alt + arrow.

 Doesn't look any simpler than select 2 lines, Ctr+X, move the cursor
 with arrows or mouse and Ctrl+V...

 Abdel.

Agreed. It's easy as all getout to move text around the current program, with 
Ctrl+X and Ctrl+V, or even the outlining feature (thanks for adding that). I'd 
prioritize a lot of things more than another way to move text around. I'd love 
to have a log of how layouts get loaded (I gave an overview of that in another 
message), and a /usr/share/lyx/configure.py that EXACTLY matches the action of 
Tools-Reconfigure in the LyX environment.

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt




Re: The case for human parsable LyX native format

2009-07-31 Thread Michael Joyner ᏩᏯ
Abdelrazak Younes wrote:
 Hellmut Weber wrote:
 Steve Litt schrieb:
 So, as usual, Im pleading that as you decide on future native
 formats, you make the new formats as human parsable and editable as
 the current version.

 Thanks

 SteveT



 Hi LyX developpers,
 I would like to strongly support Steve's point of view !

 Don't worry, as was explained many times to Steve, this point is well
 understood and this opinion is shared among the majority of
 developpers if not all of them. The switch to XML, if that ever
 happens, will *never* be at the  expense of readability. So there is
 actually no need to do any lobbying on that front :-)

 Abdel.

Good, now I can sleep better. Script creation of LyX documents from sql
database exports using PHP and Bash is very important to me. RAD for
computer generated documents is LyX.

-- 
LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/
GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/



signature.asc
Description: OpenPGP digital signature


RE: Lyx 1.6.3 Can I ditch the pointNclick list of open files below the toolbars???

2009-07-31 Thread Joe(theWordy)Philbrook

It would appear that on Jul 31, Vincent van Ravesteijn - TNW did say:

  Is there any way to get them off my screen???
 
 Tools-Preferences-Look  Feel-Open Document in Tabs
 

Thanks. But when I tried that the results were less than ideal.

I don't know why I didn't realize I was talking about tabs until
you identified the toggle. {Unless it has to do with the fact that
when I use LyX I'm always either opening just one document (in which
case there isn't one) Or I'm opening a half dozen documents with a
script where the average filename length is about 30 characters long.
(in which case the row of tabs don't all fit} and so I never discerned
the pattern of a tab beside a spot without one...}

But in any case the results are that several separate LyX windows open.
which in itself isn't bad, but since the filenames are so long it's
hard to determine which doc is which switching via the alt+tab
global shortcut. And if I try to use the alt+D[$number] method,
the tabs in that particular document window turn themselves back on...

It might be nice for keyboard centric users who switch documents via
the menu, rather than by clicking on the tab,  if they added an
additional check box or .ui file item, that toggled the graphic display
of the tabs like it was a toolbar full of tabs, while still allowing
ONE document window to switch between several [virtual tab]
documents via the pull down menu... But as feature requests go, I
doubt this would ever be considered a high priority...

So I'm thinking that I'll just have to live with the durned tabs.

Thanks anyway!

-- 
|^^^   ^^^
|o   o   Joe (theWordy) Philbrook
|^J(tWdy)P
|   ___jtw...@ttlc.net
|   
|  sigh



Re: Drag and Drop

2009-07-31 Thread Joe(theWordy)Philbrook

It would appear that on Jul 31, Johannes Knaus did say:

 I can't imagine how one could mark some text with the mouse hold-and-click it
 and drag it around by accident.

You have never seen *ME* try to use the mouse... Though it is
frequently the easiest way to copy/paste text between applications
when one or more of the source/destination applications do NOT
support  ^C ^V and shifted arrows for marking... I for one would
find it umm frustrating if some text automatically relocated because
I was being a klutz while attempting to drag the the mouse pointer
across a range of text to copy to the (gpm?) buffer some text I
wanted to paste into an xterm.
 
 I think the discussion on going on here is somewhat dogmatic. Many people use
 Ctrl+X and then Ctrl+V to shift textparts around. That's o.k. and that's what
 I do as I have no other chance in Lyx to do this.

I for one am glad many people use that technique, It means it's
unlikely that LyX's keyboard control methods will be phased out any
time soon.

 Those who don't like drag and drop are not forced to use it, it would be just
 another editing option (maybe to be activated or deactivated via GUI). Still,
# --- --- -- -- ^^ ^^ ^ ^^ ^^^ ^^^ ^^^-- --

When you said this however you got my vote. Just as long as the
feature *CAN* be deactivated by the user... 

[rant-mode]
I might be a keyboard centric computer user who is always having
difficulty dealing with the point N click style dogma that seems
to say that if you make it easy for mouse centric users to click
instead of keypunching, then it's OK if you can't do something
anymore without resorting to that {many paragraphs of expletives
deleted} rodent...

But that doesn't mean that I think mouse centric users should be
denied point n click methods I just don't want them pushed on me.
[/rant-mode]

-- 
|   ---   ___
|   0   -  Joe (theWordy) Philbrook
|   ^   J(tWdy)P
|~\___/~ jtw...@ttlc.net



Re: problem with bibliography

2009-07-31 Thread Manveru
2009/7/30 Sam Liddicott :
> * Beny Spira wrote, On 29/07/09 22:05:
>> Thanks to all that replied
>>
>> It turned out the problem was in some references that contained URL with
>> special characteres. I deleted the URLs and the problem vanished.
>
>
> So... is that a Tex bug? Will you get a cheque for $655.36 ?

In the worst case here this is a bug in one of LaTeX packages, not a TeX itself.

-- 
Manveru
jabber: manv...@manveru.pl
 gg: 1624001
   http://www.manveru.pl


Text wrap figure fails in a Hebrew document

2009-07-31 Thread Yosef Meller

Hi,

I am trying to create a wrap figure in LyX. In an English document it 
works, but in a Hebrew document, inserting a wrap figure causes the DVI 
or PDF creation to fail with the following error in the LaTeX errors 
dialog:


Argument of \everypar has an extra }.

\par
l.44 \end{wrapfigure}

Previously latex would stall indefinitely too, but that seems to be 
solved by installing the package "tetex-lang-hebrew" from Ubuntu 
repositories.


I'm attaching a sample LyX document that recreates this behavior.

Thanks in advance for any help on this,
Yosef.



newfile2.lyx
Description: application/lyx


Re: Drag and Drop

2009-07-31 Thread Marcelo Acuña

> Hello,
> 
> Maybe a stupid question:
> But I realized that I can select/mark a sentence with the
> mouse, but I cannot drag this selected sentence around in
> Lyx, e.g. placing it in the paragraph above. Everytime I try
> this the sentence is deselected.

 With alt + arrow up (arrow down) you get to move the paragraph.
 Marcelo

__
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar


Lyx 1.6.3 Can I ditch the pointNclick list of open files below the toolbars???

2009-07-31 Thread Joe(theWordy)Philbrook

I'm using lyx 1.6.3 on Sabayon Linux 4.2. Which is fairly impressive BTW.
I like most of the user interface. Well that is except that As a
keyboard-centric user with very poor mouse coordination I always resent
screen space taken up by point n' click specific tools such as most
toolbars. For example if "+[space]" worked without that
scrollbox attached to the "standard" toolbar the .ui file would say

=> Toolbars
=> "standard" "off,top"
=> "extra" "off,top"
=> "table" "off,bottom"
=> "math" "off,bottom"
=> "minibuffer" "off,bottom"
=> End

As it is the only one I leave on is "standard". And that to keep the
viability of the  "3-key,2-stroke" keybinding "+[space]". Thus
I put up with wasting a whole line of screen space on mostly useless
stuff I would never ever "click" on.

Likewise, If I want to switch to another open document with lyx 1.6.3
I'd use "+[2]" to switch to the second open document, via the
pull down menu. Though I'll admit my fingers usually start with the old
"+[2]" that isn't in the view menu anymore before I realise
that the functionality was moved to the Documents pull-down menu.

BUT I would never ever wrestle with my mouse to get that (expletive
deleted) pointer on the name of the document displayed with an [x]
just under the toolbars... And that would be so, even if I wasn't just
as likely to accidentally click on one of the [x]s...

Is there any way to get them off my screen???

-- 
|  ~^~   ~^~
|  Joe (theWordy) Philbrook
|  ^  J(tWdy)P
|\___/ <>



RE: Lyx 1.6.3 Can I ditch the pointNclick list of open files below the toolbars???

2009-07-31 Thread Vincent van Ravesteijn - TNW
 
> Is there any way to get them off my screen???

Tools->Preferences->Look & Feel->Open Document in Tabs

Vincent


Re: Text wrap figure fails in a Hebrew document

2009-07-31 Thread Sam Liddicott
* Yosef Meller wrote, On 31/07/09 09:47:
> Hi,
> 
> I am trying to create a wrap figure in LyX. In an English document it
> works, but in a Hebrew document, inserting a wrap figure causes the DVI
> or PDF creation to fail with the following error in the LaTeX errors
> dialog:
> 
> Argument of \everypar has an extra }.
> 
> \par
> l.44 \end{wrapfigure}
> 
> Previously latex would stall indefinitely too, but that seems to be
> solved by installing the package "tetex-lang-hebrew" from Ubuntu
> repositories.


Stall indefinitely is usually because latex/tex is trying to read from
stdin.

If you run lyx from a console window then you can type ctrl-d and finish
the stall.

I generally run lyx 

Re: Drag and Drop

2009-07-31 Thread Nikos Alexandris
On Fri, 2009-07-31 at 06:12 -0700, Marcelo Acuña wrote:
> > Hello,
> > 
> > Maybe a stupid question:
> > But I realized that I can select/mark a sentence with the
> > mouse, but I cannot drag this selected sentence around in
> > Lyx, e.g. placing it in the paragraph above. Everytime I try
> > this the sentence is deselected.
> 
>  With alt + arrow up (arrow down) you get to move the paragraph.
>  Marcelo

Wouldn't it be useful to extend this functionality to move around a
selection (selected environments) as well?

Nikos



Re: Drag and Drop

2009-07-31 Thread Michael Joyner ᏩᏯ
"Drag and drop" text is one the most annoying things I have found with
word processors.
It is too easy to do it by accident, not notice, and output garbage for
people to read.
Nikos Alexandris wrote:
> On Fri, 2009-07-31 at 06:12 -0700, Marcelo Acuña wrote:
>   
>>> Hello,
>>>
>>> Maybe a stupid question:
>>> But I realized that I can select/mark a sentence with the
>>> mouse, but I cannot drag this selected sentence around in
>>> Lyx, e.g. placing it in the paragraph above. Everytime I try
>>> this the sentence is deselected.
>>>   
>>  With alt + arrow up (arrow down) you get to move the paragraph.
>>  Marcelo
>> 
>
> Wouldn't it be useful to extend this functionality to move around a
> selection (selected environments) as well?
>
> Nikos
>
>   


-- 
LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/
GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/



signature.asc
Description: OpenPGP digital signature


Re: Drag and Drop

2009-07-31 Thread Nikos Alexandris

On Fri, 2009-07-31 at 11:43 -0400, Michael Joyner:

> "Drag and drop" text is one the most annoying things I have found with
> word processors.
> It is too easy to do it by accident, not notice, and output garbage
> for people to read.


I don't mean drag-n-drop with the mouse. I mean select 2 lines (say
title and it's text) and move it with Alt + arrow.

Nikos


> Nikos Alexandris wrote: 
> > On Fri, 2009-07-31 at 06:12 -0700, Marcelo Acuña wrote:
> >   
> > > > Hello,
> > > > 
> > > > Maybe a stupid question:
> > > > But I realized that I can select/mark a sentence with the
> > > > mouse, but I cannot drag this selected sentence around in
> > > > Lyx, e.g. placing it in the paragraph above. Everytime I try
> > > > this the sentence is deselected.
> > > >   
> > > With alt + arrow up (arrow down) you get to move the paragraph.
> > >  Marcelo
> > > 
> > 
> > Wouldn't it be useful to extend this functionality to move around a
> > selection (selected environments) as well?
> > 
> > Nikos



Re: Drag and Drop

2009-07-31 Thread Abdelrazak Younes

Nikos Alexandris wrote:

On Fri, 2009-07-31 at 11:43 -0400, Michael Joyner:


"Drag and drop" text is one the most annoying things I have found with
word processors.
It is too easy to do it by accident, not notice, and output garbage
for people to read.



I don't mean drag-n-drop with the mouse. I mean select 2 lines (say
title and it's text) and move it with Alt + arrow.


Doesn't look any simpler than "select 2 lines, Ctr+X, move the cursor 
with arrows or mouse and Ctrl+V"...


Abdel.



Re: The case for human parsable LyX native format

2009-07-31 Thread Hellmut Weber

Steve Litt schrieb:

Hi all,

I just solved two very difficult LyX problems using Vim, and it reminded me just 
how lucky we are that the current LyX native format is easily readable and 
parsable by a normally intelligent human.


In the first case, LyX would crash about 3 seconds after opening a document in 
1.6.3. For various reasons I suspected it was the overly large .eps cover art, 
but I encountered a buried shovel. If only I could get LyX to work, I could 
change the cover art, and if only I could change the cover art, I could get 
LyX to work. Vim to the rescue: I changed cover.eps to cover.pdf to work 
around the problem (which I suspect is a LyX ungraceful handling of a too 
large graphic).


In the second case, I had an indexing problem preventing making the PDF. Using 
diagnostics like the ilg, ind and idx files, I narrowed it down to five possible 
culprit index entries. I got it down to one error, but the .ind file was 
showing a backslash that didn't exist in the LyX index entry. When I opened 
the LyX file in Vim, the problem stuck out like a sore thumb -- there was an 
extra inset and some other garbage within the index structure. I removed it 
with Vim and bang, the document compiled perfectly to PDF.


There have been a lot of discussions about changing the LyX native formula. 
I'd like to ask that whatever the new format turns out to be, it be at least 
as easy for a normal intelligence human to manually edit, parse and modify as 
the current format.


XML has been discussed, and the point has been made that if XML is done with 
an eye toward manual parsing and editing, it can be as easy to parse and edit 
in Vim as the current native format. While that's obviously true, we all know 
that from a human parsing viewpoint, XML can quickly get out of control. One 
look at any OpenOffice file confirms this. XML has the capability to make one 
paragraph depend on several different XML subtrees. If authored that way, for 
all practical purposes human manual parsability and editability is destroyed.


Also, the XML spec itself does not recognize lines, so it would be up to the 
LyX tools to properly assign lines to nodes and vice versa. Otherwise it would 
be impossible to write LyX creation and modification scripts, at least without 
a big, ugly XML parser.


I'm pretty sure all the current developers understand all this because you 
regularly tweak LyX from editors yourselves. I am concerned, however, that 
future LyX developers will say "Hey, LyX is XML and to do our jobs correctly 
we need to just worry about valid XML, not linefeeds. On that day, a great 
deal of user power is lost.


So, as usual, I"m pleading that as you decide on future native formats, you 
make the new formats as human parsable and editable as the current version.


Thanks

SteveT




Hi LyX developpers,
I would like to strongly support Steve's point of view !

Quite often I have to create documents which contain mostly images and 
nearly no text at all.
So I put in one of the images manually using the GUI, give it a look and 
the rest is done using gvim and/or bash scripting and the like.


For me this is a great gain in productivity compared to the inclusion of 
maybe 80 images via the GUI.


And this procedure is possible exactly because the actual LyX internal 
format is very readable (even rather suggestive ;-)


So, me too I would like to beg you all:

Keep this in mind when deciding on any change of the internal format.


For the rest LyX is THE mosdt important tool for all my work with a 
computer, working (still at 66) as management consultant.



Best regards

Hellmut


--
Dr. Hellmut Weber m...@hellmutweber.de
Degenfeldstraße 2 tel   +49-89-3081172
D-80803 München-Schwabing mobil +49-172-8450321
please: No DOCs, no PPTs. why: tinyurl.com/cbgq



Re: The case for human parsable LyX native format

2009-07-31 Thread Abdelrazak Younes

Hellmut Weber wrote:

Steve Litt schrieb:
So, as usual, I"m pleading that as you decide on future native 
formats, you make the new formats as human parsable and editable as 
the current version.


Thanks

SteveT




Hi LyX developpers,
I would like to strongly support Steve's point of view !


Don't worry, as was explained many times to Steve, this point is well 
understood and this opinion is shared among the majority of developpers 
if not all of them. The switch to XML, if that ever happens, will 
*never* be at the  expense of readability. So there is actually no need 
to do any lobbying on that front :-)


Abdel.



Re: Drag and Drop

2009-07-31 Thread Johannes Knaus
First of all, I simply didn't realize that mouse drag'n'drop did not  
work in Lyx and thought this could maybe a platform specific issue,  
not a general one.



On Fri, 2009-07-31 at 11:43 -0400, Michael Joyner:
"Drag and drop" text is one the most annoying things I have found  
with

word processors.
It is too easy to do it by accident, not notice, and output garbage
for people to read.



I can't imagine how one could mark some text with the mouse hold-and- 
click it and drag it around by accident.


I think the discussion on going on here is somewhat dogmatic. Many  
people use Ctrl+X and then Ctrl+V to shift textparts around. That's  
o.k. and that's what I do as I have no other chance in Lyx to do this.
My point is: Drag and drop is something many Mac Users (I am one) and  
Windows users may be very used to in everyday work. So implementing  
this feature would make Lyx a little easier to work with when you are  
new to Lyx.
Those who don't like drag and drop are not forced to use it, it would  
be just another editing option (maybe to be activated or deactivated  
via GUI). Still, I don't see the problem in having this feature – if  
you want to use it, use it, if not, don't. I don't think this can  
create any trouble by accident.


It certainly would be a problem, if implementing this feature really  
costs a lot of time. I simply don't know this as I'm not a programmer.


Another thing is that is maybe not the most urgent feature on the Lyx- 
feature-wish-list. That's o.k. It was only a question.

Still, voting for it is legitimate.




Re: Drag and Drop

2009-07-31 Thread Abdelrazak Younes

Johannes Knaus wrote:
It certainly would be a problem, if implementing this feature really 
costs a lot of time. I simply don't know this as I'm not a programmer.


To answer your question, this feature is straight forward to implement 
as we have developed own text work area and do not rely on a given text 
widget from Qt.




Another thing is that is maybe not the most urgent feature on the 
Lyx-feature-wish-list. That's o.k. It was only a question.

Still, voting for it is legitimate.


The feature request is very legitimate indeed. A generalized drag 
feature (including from external application) would be welcome.


Abdel.



Re: Drag and Drop

2009-07-31 Thread Abdelrazak Younes

Abdelrazak Younes wrote:

Johannes Knaus wrote:
It certainly would be a problem, if implementing this feature really 
costs a lot of time. I simply don't know this as I'm not a programmer.


To answer your question, this feature is straight forward to implement 


Hum... "this feature is *not* straight forward to implement"...

Abdel.



Re: Drag and Drop

2009-07-31 Thread Steve Litt
On Friday 31 July 2009 12:20:27 Abdelrazak Younes wrote:
> Nikos Alexandris wrote:
> > On Fri, 2009-07-31 at 11:43 -0400, Michael Joyner:
> >> "Drag and drop" text is one the most annoying things I have found with
> >> word processors.
> >> It is too easy to do it by accident, not notice, and output garbage
> >> for people to read.
> >
> > I don't mean drag-n-drop with the mouse. I mean select 2 lines (say
> > title and it's text) and move it with Alt + arrow.
>
> Doesn't look any simpler than "select 2 lines, Ctr+X, move the cursor
> with arrows or mouse and Ctrl+V"...
>
> Abdel.

Agreed. It's easy as all getout to move text around the current program, with 
Ctrl+X and Ctrl+V, or even the outlining feature (thanks for adding that). I'd 
prioritize a lot of things more than another way to move text around. I'd love 
to have a log of how layouts get loaded (I gave an overview of that in another 
message), and a /usr/share/lyx/configure.py that EXACTLY matches the action of 
Tools->Reconfigure in the LyX environment.

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt




Re: The case for human parsable LyX native format

2009-07-31 Thread Michael Joyner ᏩᏯ
Abdelrazak Younes wrote:
> Hellmut Weber wrote:
>> Steve Litt schrieb:
>>> So, as usual, I"m pleading that as you decide on future native
>>> formats, you make the new formats as human parsable and editable as
>>> the current version.
>>>
>>> Thanks
>>>
>>> SteveT
>>>
>>>
>>
>> Hi LyX developpers,
>> I would like to strongly support Steve's point of view !
>
> Don't worry, as was explained many times to Steve, this point is well
> understood and this opinion is shared among the majority of
> developpers if not all of them. The switch to XML, if that ever
> happens, will *never* be at the  expense of readability. So there is
> actually no need to do any lobbying on that front :-)
>
> Abdel.
>
Good, now I can sleep better. Script creation of LyX documents from sql
database exports using PHP and Bash is very important to me. RAD for
computer generated documents is LyX.

-- 
LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/
GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/



signature.asc
Description: OpenPGP digital signature


RE: Lyx 1.6.3 Can I ditch the pointNclick list of open files below the toolbars???

2009-07-31 Thread Joe(theWordy)Philbrook

It would appear that on Jul 31, Vincent van Ravesteijn - TNW did say:

> > Is there any way to get them off my screen???
> 
> Tools->Preferences->Look & Feel->Open Document in Tabs
> 

Thanks. But when I tried that the results were less than ideal.

I don't know why I didn't realize I was talking about "tabs" until
you identified the toggle. {Unless it has to do with the fact that
when I use LyX I'm always either opening just one document (in which
case there isn't one) Or I'm opening a half dozen documents with a
script where the average filename length is about 30 characters long.
(in which case the row of tabs don't all fit} and so I never discerned
the pattern of a tab beside a spot without one...}

But in any case the results are that several separate LyX windows open.
which in itself isn't bad, but since the filenames are so long it's
hard to determine which doc is which switching via the +
global shortcut. And if I try to use the +[$number] method,
the tabs in that particular document window turn themselves back on...

It might be nice for keyboard centric users who switch documents via
the menu, rather than by clicking on the tab,  if they added an
additional check box or .ui file item, that toggled the graphic display
of the tabs like it was a toolbar full of tabs, while still allowing
ONE document window to switch between several [virtual tab]
documents via the pull down menu... But as feature requests go, I
doubt this would ever be considered a high priority...

So I'm thinking that I'll just have to live with the durned tabs.

Thanks anyway!

-- 
|^^^   ^^^
|  Joe (theWordy) Philbrook
|^J(tWdy)P
|   ___<>
|   
|  



Re: Drag and Drop

2009-07-31 Thread Joe(theWordy)Philbrook

It would appear that on Jul 31, Johannes Knaus did say:

> I can't imagine how one could mark some text with the mouse hold-and-click it
> and drag it around by accident.

You have never seen *ME* try to use the mouse... Though it is
frequently the easiest way to copy/paste text between applications
when one or more of the source/destination applications do NOT
support  ^C ^V and shifted arrows for marking... I for one would
find it umm frustrating if some text automatically relocated because
I was being a klutz while attempting to drag the the mouse pointer
across a range of text to copy to the (gpm?) buffer some text I
wanted to paste into an xterm.
 
> I think the discussion on going on here is somewhat dogmatic. Many people use
> Ctrl+X and then Ctrl+V to shift textparts around. That's o.k. and that's what
> I do as I have no other chance in Lyx to do this.

I for one am glad many people use that technique, It means it's
unlikely that LyX's keyboard control methods will be phased out any
time soon.

> Those who don't like drag and drop are not forced to use it, it would be just
> another editing option (maybe to be activated or deactivated via GUI). Still,
# --- --- -- -- ^^ ^^ ^ ^^ ^^^ ^^^ ^^^-- --

When you said this however you got my vote. Just as long as the
feature *CAN* be deactivated by the user... 

[rant-mode]
I might be a keyboard centric computer user who is always having
difficulty dealing with the point N click style "dogma" that seems
to say that if you make it easy for mouse centric users to click
instead of keypunching, then it's OK if you can't do something
anymore without resorting to that {many paragraphs of expletives
deleted} rodent...

But that doesn't mean that I think mouse centric users should be
denied point n click methods I just don't want them pushed on me.
[/rant-mode]

-- 
|   ---   ___
|   <0>   <->  Joe (theWordy) Philbrook
|   ^   J(tWdy)P
|~\___/~ <>