Re: Wishlist for future LyX

[Richard Heck]

On 06/07/2016 12:27 PM, Edwin Leuven wrote:
> On 03 Jun 2016, at 18:35, Helge Hafting  wrote:
>> here are some wishes for the future:
> Hide changes (in lyx)

Some work was done on this a few years ago by me and Vincent. I think
all of it is in his features/HideChanges branch. If I remember right, we
weren't all that far from having it working. But I don't know how easy
it would be to remerge it now.

Richard

Re: Wishlist for future LyX

[Edwin Leuven]

On 03 Jun 2016, at 18:35, Helge Hafting  wrote:
> 
> Now that we have 2.2.0,

I love the new shiny lyx on my retina screen

congrats on a great job!

> here are some wishes for the future:

Hide changes (in lyx)

...

Fwiw ;-)

Wishlist for future LyX

[Helge Hafting]

Now that we have 2.2.0, here are some wishes for the future:


Enumeration style document setting

==

GUI for setting the numbering style, similiar to what we already have 
for bullet lists. I.e. the default for the 4 levels are "1.", "(a)", 
"i.", "A."


The gui would change that. Perhaps I want "a)" [not "(a)"] on the first 
level, and uppercase roman numerals on the second level. The LaTeX code 
to achieve this is easy enough. And of course the main window would 
change to reflect this setting too.


This, (and \thispagestyle), is what usually forces me to use LaTeX in 
LyX these days.



Bullet lists displaying correct symbols

==

We already have a GUI for selecting different symbols. It'd be nice if 
the bullet lists in the main window respected this, and showed the 
selected bullet instead of a hardcoded default. (Except when the user 
sets a custom bullet. Well, even that could be attempted rendered via 
the preview mechanism. If this result in latex failure or a blank image, 
fall back on a hardcoded default symbol.)



Case-respecting search/replace



A case-following search/replace. So if I replace “zeppeliner” with 
“balloon”, it will understand that “Zeppeliner” is to be replaced by 
“Balloon”. (And ZEPPELINER->BALLOON)


Some characters (dotless i, double.-dot i, german ss) does not exist in 
both cases. Not replacing those is ok, the common case is good enough here.



Box alignments that works "the way I mean"

==

You align boxes vertically by top, bottom or center. And it doesn't 
necessarily work. What you get, does not line up as specified – 
depending on box content. (table & image side-by-side being a nasty 
common case.)


The manuals tells us how to fix this by putting in protected spaces or 
other latex constructs first/last inside the box. This is due to obscure 
limitations of latex, but I don't see why LyX, as a WYSIWYM tool, should 
reproduce such oddities. If I say the boxes is to be aligned by their 
bottom, then they should - regardless of content.


When LyX exports a box to latex, it could export the necessary 
zero-width/height latex constructs to make the box align as the user 
specified in the dialog – no matter what content the box may have.


This would remove a recurring question/frustration from the user's list. 
A well-written latex construct should not create trouble. A weird user 
who wants a figure & table side by side that does not line up well, can 
go and write his box with TeX code instead of Insert->Frame. (Or if this 
really pains anyone, add a checkbox for “not correcting alignment” in 
the box settings dialog. But I have a hard time imagining a use case for 
this.)



Helge Hafting

Re: Wishlist item: Copy as reference use the previously used reference format?

[John McCabe-Dansted]

On Wed, Mar 24, 2010 at 7:12 PM, Helge Hafting helge.haft...@hist.no wrote:
 Copy as reference is very useful - the writer avoids dialog boxes
 completely.

 But the reference format is always reference.

 Some documents use mostly reference on page page, or  maybe only
 page

 It'd be very nice if LyX could use the last reference format used, instead
 of just defaulting to reference. So, if the writer sets some
 other format, then this stays in effect thereafter. Then the writer is no
 longer forced to open dialogs to correct every reference.

 This shouldn't create any problems for those that prefer just reference
 either.

This seems like a good idea to me. I prefer to always just use
FrmtRef. (And manually add stuff like
\newrefformat{defn}{Definition~\ref{#1}} to my preamble so that
prettyref supports all the theorem types LyX supports, which I
understand won't be needed when the new improved RefStyle patch is
merged).

Actually I'd probably prefer to set it so that it always used FrmtRef,
as I'd find this simpler and faster since I'd rather not have to set
the default back to FrmtRef each time I use a plain reference, so
there is an argument to make this e.g. a lyxrc setting. It would be
simpler to use the last setting both in terms of implementation
(except that we have to consider what to do if the user hasn't chosen
any reference styles since LyX has last opened) and also that it is
one less configuration option the user has to set. So I don't have
strong feelings either way.

Perhaps the ideal would be to always default to FrmtRef and also have
FrmtRef satisfy the people who currently use plain reference. Why do
some people prefer the plain reference? Could the RefStyle patch
provide whatever they are missing in the current PrettyRef
implementation?

-- 
John C. McCabe-Dansted

Re: Wishlist item: "Copy as reference" use the previously used reference format?

[John McCabe-Dansted]

On Wed, Mar 24, 2010 at 7:12 PM, Helge Hafting  wrote:
> "Copy as reference" is very useful - the writer avoids dialog boxes
> completely.
>
> But the reference format is always "".
>
> Some documents use mostly " on page ", or  maybe only
> ""
>
> It'd be very nice if LyX could use the "last reference format used", instead
> of just defaulting to . So, if the writer sets some
> other format, then this stays in effect thereafter. Then the writer is no
> longer forced to open dialogs to correct every reference.
>
> This shouldn't create any problems for those that prefer just 
> either.

This seems like a good idea to me. I prefer to always just use
FrmtRef. (And manually add stuff like
\newrefformat{defn}{Definition~\ref{#1}} to my preamble so that
prettyref supports all the theorem types LyX supports, which I
understand won't be needed when the new improved RefStyle patch is
merged).

Actually I'd probably prefer to set it so that it always used FrmtRef,
as I'd find this simpler and faster since I'd rather not have to set
the default back to FrmtRef each time I use a plain , so
there is an argument to make this e.g. a lyxrc setting. It would be
simpler to use the last setting both in terms of implementation
(except that we have to consider what to do if the user hasn't chosen
any reference styles since LyX has last opened) and also that it is
one less configuration option the user has to set. So I don't have
strong feelings either way.

Perhaps the ideal would be to always default to FrmtRef and also have
FrmtRef satisfy the people who currently use plain . Why do
some people prefer the plain ? Could the RefStyle patch
provide whatever they are missing in the current PrettyRef
implementation?

-- 
John C. McCabe-Dansted

Wishlist item: Copy as reference use the previously used reference format?

[Helge Hafting]

Copy as reference is very useful - the writer avoids dialog boxes 
completely.


But the reference format is always reference.

Some documents use mostly reference on page page, or  maybe only 
page


It'd be very nice if LyX could use the last reference format used, 
instead of just defaulting to reference. So, if the writer sets some
other format, then this stays in effect thereafter. Then the writer is 
no longer forced to open dialogs to correct every reference.


This shouldn't create any problems for those that prefer just 
reference either.


Helge Hafting

Wishlist item: "Copy as reference" use the previously used reference format?

[Helge Hafting]

"Copy as reference" is very useful - the writer avoids dialog boxes 
completely.


But the reference format is always "".

Some documents use mostly " on page ", or  maybe only 
""


It'd be very nice if LyX could use the "last reference format used", 
instead of just defaulting to . So, if the writer sets some
other format, then this stays in effect thereafter. Then the writer is 
no longer forced to open dialogs to correct every reference.


This shouldn't create any problems for those that prefer just 
 either.


Helge Hafting

Re: Wishlist: groups for program listings similiar to graphics groups

[Bo Peng]

 After applying lots of such settings over and over, a grouping would
 be useful, in the same manner as for graphics. When several listings belong
 to the same group, changing settings for one changes the settings for all in
 that group. And new code snippets just need to be added to the correct
 group, so the user won't have to re-apply several settings each time.

Can you just set global listings parameters in the document settings dialog?

Cheers,
Bo

Re: Wishlist: groups for "program listings" similiar to "graphics groups"

[Bo Peng]

> After applying lots of such settings over and over, a grouping would
> be useful, in the same manner as for graphics. When several listings belong
> to the same group, changing settings for one changes the settings for all in
> that group. And new code snippets just need to be added to the correct
> group, so the user won't have to re-apply several settings each time.

Can you just set global listings parameters in the document settings dialog?

Cheers,
Bo

Re: Wishlist items - document templates

[Guenter Milde]

On 2010-02-04, Helge Hafting wrote:
 File-New from Template currently shows only templates in 
 /usr/share/lyx/templates.

 The dialog ought to have a couple of shortcut buttons: system 
 templates and private templates that goes directly to these two 
 directories.

Seconded.

 The reason is to have easy access to both the templates that comes with
 lyx, as well as self-made templates. Navigating the filesystem from one 
 place to another is too cumbersome. 

For the time beeing, I use the following workaround:

* Set the template directory to my private templates
  (LYXHOME/templates) in ToolsSettingsPaths.

* Place a symlink to the system templates in my private templates

Günter

Wishlist: assignment of graphichs groups

[Helge Hafting]

The graphic groups in lyx is a nice timesaver, no need to apply the 
same settings over and over. Just put the images in the same group.


My wish for a slight improvement:

Whenever a new graphic is created, put it in the same group as the
previous graphic object the user dealt with.

Currently, the default is no group. But anyone who actually use
graphic groups tend to see a common case: They insert many graphics, and 
 set them all to the same group. Even more work is saved, if the group 
defaults to the last group used.


And there is not much of a penalty for those who need to insert some no 
group pictures, for after they insert the first one, the rest will
default to no group (since no group then becomes the last group 
setting used.)


Helge Hafting

Wishlist: groups for program listings similiar to graphics groups

[Helge Hafting]

When writing a text about programming, there are tons of program code 
examples. And they usually have similiar settings. I.e. all are the same 
programming language and the same dialect with the same font options.


After applying lots of such settings over and over, a grouping would
be useful, in the same manner as for graphics. When several listings 
belong to the same group, changing settings for one changes the settings 
for all in that group. And new code snippets just need to be added to 
the correct group, so the user won't have to re-apply several settings 
each time.


These listing groups should ideally work both for code snippets in the 
document, as well as code included from external files. In lyx 1.6 they 
don't have the same settings dialog, which is is unfortunate. (For code 
from a file, I need to type language=C, for code inside the document, 
I can select C from a pulldown menu.)



I understand that this might be some work. It'd be nice if the lyx 2.0 
file format includes this change - even if it doesn't get implemented in 
the user interface. That way, the user interface can come when someone 
finds the time, because the file format is in place. (Just a group 
setting for internal and external code listings.)


Helge Hafting

Re: Wishlist items - document templates

[Guenter Milde]

On 2010-02-04, Helge Hafting wrote:
> "File->New from Template" currently shows only templates in 
> /usr/share/lyx/templates.

> The dialog ought to have a couple of shortcut buttons: "system 
> templates" and "private templates" that goes directly to these two 
> directories.

Seconded.

> The reason is to have easy access to both the templates that comes with
> lyx, as well as self-made templates. Navigating the filesystem from one 
> place to another is too cumbersome. 

For the time beeing, I use the following workaround:

* Set the template directory to my private templates
  (/templates) in Tools>Settings>Paths.

* Place a symlink to the "system templates" in my "private templates"

Günter

Wishlist: assignment of graphichs groups

[Helge Hafting]

The "graphic groups" in lyx is a nice timesaver, no need to apply the 
same settings over and over. Just put the images in the same group.


My wish for a slight improvement:

Whenever a new graphic is created, put it in the same group as the
previous graphic object the user dealt with.

Currently, the default is "no group". But anyone who actually use
graphic groups tend to see a common case: They insert many graphics, and 
 set them all to the same group. Even more work is saved, if the group 
defaults to the last group used.


And there is not much of a penalty for those who need to insert some "no 
group" pictures, for after they insert the first one, the rest will
default to "no group" (since "no group" then becomes the last group 
setting used.)


Helge Hafting

Wishlist: groups for "program listings" similiar to "graphics groups"

[Helge Hafting]

When writing a text about programming, there are tons of program code 
examples. And they usually have similiar settings. I.e. all are the same 
programming language and the same dialect with the same font options.


After applying lots of such settings over and over, a grouping would
be useful, in the same manner as for graphics. When several listings 
belong to the same group, changing settings for one changes the settings 
for all in that group. And new code snippets just need to be added to 
the correct group, so the user won't have to re-apply several settings 
each time.


These "listing groups" should ideally work both for code snippets in the 
document, as well as code included from external files. In lyx 1.6 they 
don't have the same settings dialog, which is is unfortunate. (For code 
from a file, I need to type "language=C", for code inside the document, 
I can select "C" from a pulldown menu.)



I understand that this might be some work. It'd be nice if the lyx 2.0 
file format includes this change - even if it doesn't get implemented in 
the user interface. That way, the user interface can come when someone 
finds the time, because the file format is in place. (Just a group 
setting for internal and external code listings.)


Helge Hafting

Wishlist items - document templates

[Helge Hafting]

File-New from Template currently shows only templates in 
/usr/share/lyx/templates.


The dialog ought to have a couple of shortcut buttons: system 
templates and private templates that goes directly to these two 
directories.


The reason is to have easy access to both the templates that comes with
lyx, as well as self-made templates. Navigating the filesystem from one 
place to another is too cumbersome. I guess some users don't even know 
about the private template directory. :-/


Putting all templates in a single directory is not a solution either:

* /usr/share/lyx/templates is normally not writeable for users, and
  it should not be either. But this makes it hard to add templates
  there. Especially for someone who isn't also a sysadmin.
* Copying the system templates is not a good solution either. Several
  users doing that wastes space, and you never know when some system
  upgrade adds/changes the official templates.

There is already a button that goes to the distributed templates,
having one that goes to the private templates would be very helpful.

Also, having a save as template menu would be nice. It would bring up 
the save as dialog, showing the user template directory by default.


Saving as a template should automatically remove stuff not wanted in a 
template, i.e. the \fontscheme and \papersize mentioned in section 5.4 
in the customization manual. (Those who want a template with a 
particular papersize can of course save a ordinary document instead.)


Helge Hafting

Wishlist items - document templates

[Helge Hafting]

"File->New from Template" currently shows only templates in 
/usr/share/lyx/templates.


The dialog ought to have a couple of shortcut buttons: "system 
templates" and "private templates" that goes directly to these two 
directories.


The reason is to have easy access to both the templates that comes with
lyx, as well as self-made templates. Navigating the filesystem from one 
place to another is too cumbersome. I guess some users don't even know 
about the private template directory. :-/


Putting all templates in a single directory is not a solution either:

* /usr/share/lyx/templates is normally not writeable for users, and
  it should not be either. But this makes it hard to add templates
  there. Especially for someone who isn't also a sysadmin.
* Copying the system templates is not a good solution either. Several
  users doing that wastes space, and you never know when some system
  upgrade adds/changes the official templates.

There is already a button that goes to the distributed templates,
having one that goes to the private templates would be very helpful.

Also, having a "save as template" menu would be nice. It would bring up 
the "save as" dialog, showing the user template directory by default.


Saving as a template should automatically remove stuff not wanted in a 
template, i.e. the \fontscheme and \papersize mentioned in section 5.4 
in the customization manual. (Those who want a template with a 
particular papersize can of course save a ordinary document instead.)


Helge Hafting

Re: Wishlist: let active branches add to the exported filename

[Christian Ridderström]

On Fri, 3 Jul 2009, Helge Hafting wrote:

If it seems like nothing happened UI-wise, then have the status area 
proudly display something like document.pdf successfully exported!.


+1

This kind of feedback is ideal, because the user is _not_ forced to 
dismiss some stupid dialog box. So the experienced user is not bothered, 
and the novice can read the status to be sure.


/C

--
Christian Ridderström   Mobile: +46-8 768 39 44

Re: Wishlist: let active branches add to the exported filename

[Christian Ridderström]

On Fri, 3 Jul 2009, Helge Hafting wrote:

If it seems like "nothing happened" UI-wise, then have the status area 
proudly display something like "document.pdf successfully exported!".


+1

This kind of feedback is ideal, because the user is _not_ forced to 
dismiss some stupid dialog box. So the experienced user is not bothered, 
and the novice can read the status to be sure.


/C

--
Christian Ridderström   Mobile: +46-8 768 39 44

Re: Wishlist: let active branches add to the exported filename

[Helge Hafting]

Jean-Marc Lasgouttes wrote:

Enrico Forestieri for...@lyx.org writes:

I think that the simplest and best way to handle this is allowing to
change name (and location) of the exported file through a file dialog.
Not everybody knows that, when exporting, the file will be located next
to the lyx file and, UI wise, it is bad that nothing seems to have
happened.


For the kind of uses I have in mind, automatic naming through branches
would be much more convenient.

The fact that Export As... would be useful is a separate problem.


A separate problem indeed!

If it seems like nothing happened UI-wise, then have the status
area proudly display something like document.pdf successfully exported!.

This kind of feedback is ideal, because the user is _not_ forced to
dismiss some stupid dialog box. So the experienced user is not bothered,
and the novice can read the status to be sure.

Many users get more feedback anyway, because the (re-)exported file
shows up as the pdf viewer reloads it, or they have a filesystem view
open that shows the new file appearing.

Having the ordinary export hampered by an extra dialog is not the way to 
go. A good GUI only throws a dialog at you when you request it, or
when the software cannot proceed without input. Mere notification should 
never need user intervention.


Instead, we could clean up and get rid of unnecessary dialogs. The 
dialog that appear after a spellcheck xx word(s) checked could become 
a status line message instead. One click less. Assuming the current 
spellcheck doesn't disappear completely when the continous spellcheck is 
implemented.


Helge Hafting

Re: Wishlist: let active branches add to the exported filename

[Helge Hafting]

Jean-Marc Lasgouttes wrote:

Enrico Forestieri  writes:

I think that the simplest and best way to handle this is allowing to
change name (and location) of the exported file through a file dialog.
Not everybody knows that, when exporting, the file will be located next
to the lyx file and, UI wise, it is bad that nothing seems to have
happened.


For the kind of uses I have in mind, automatic naming through branches
would be much more convenient.

The fact that Export As... would be useful is a separate problem.


A separate problem indeed!

If it seems like "nothing happened" UI-wise, then have the status
area proudly display something like "document.pdf successfully exported!".

This kind of feedback is ideal, because the user is _not_ forced to
dismiss some stupid dialog box. So the experienced user is not bothered,
and the novice can read the status to be sure.

Many users get more feedback anyway, because the (re-)exported file
shows up as the pdf viewer reloads it, or they have a filesystem view
open that shows the new file appearing.

Having the ordinary export hampered by an extra dialog is not the way to 
go. A good GUI only throws a dialog at you when you request it, or
when the software cannot proceed without input. Mere notification should 
never need user intervention.


Instead, we could clean up and get rid of unnecessary dialogs. The 
dialog that appear after a spellcheck "xx word(s) checked" could become 
a status line message instead. One click less. Assuming the current 
spellcheck doesn't disappear completely when the continous spellcheck is 
implemented.


Helge Hafting

Re: Wishlist: let active branches add to the exported filename

[Enrico Forestieri]

On Wed, Jul 01, 2009 at 05:47:47PM +0200, Jean-Marc Lasgouttes wrote:
 Helge Hafting helge.haft...@hist.no writes:
 
  It is useful to give active branches opportunity to add to the
  filename of exported files. This way, exports with and without the
  branch won't collide.
 
  My common case:
  I make a test for my students, with answers in a answers branch.
  When I export this to pdf, I get test.pdf. After activating the
  answers branch, I export again and should get test-answers.pdf
 
 I have to say that I use that too. What we have to do is to find the
 correct, not over-engineered implementation.
 
 The simplest would be a add name when exporting checkbox. That could
 maybe be done by a change to Buffer::latexName.

I think that the simplest and best way to handle this is allowing to
change name (and location) of the exported file through a file dialog.
Not everybody knows that, when exporting, the file will be located next
to the lyx file and, UI wise, it is bad that nothing seems to have
happened.

-- 
Enrico

Re: Wishlist: let active branches add to the exported filename

[Jean-Marc Lasgouttes]

Enrico Forestieri for...@lyx.org writes:
 I think that the simplest and best way to handle this is allowing to
 change name (and location) of the exported file through a file dialog.
 Not everybody knows that, when exporting, the file will be located next
 to the lyx file and, UI wise, it is bad that nothing seems to have
 happened.

For the kind of uses I have in mind, automatic naming through branches
would be much more convenient.

The fact that Export As... would be useful is a separate problem.

JMarc

Re: Wishlist: let active branches add to the exported filename

[Enrico Forestieri]

On Wed, Jul 01, 2009 at 05:47:47PM +0200, Jean-Marc Lasgouttes wrote:
> Helge Hafting  writes:
> 
> > It is useful to give active branches opportunity to add to the
> > filename of exported files. This way, exports with and without the
> > branch won't collide.
> >
> > My common case:
> > I make a test for my students, with answers in a "answers" branch.
> > When I export this to pdf, I get "test.pdf". After activating the
> > answers branch, I export again and should get "test-answers.pdf"
> 
> I have to say that I use that too. What we have to do is to find the
> correct, not over-engineered implementation.
> 
> The simplest would be a "add name when exporting" checkbox. That could
> maybe be done by a change to Buffer::latexName.

I think that the simplest and best way to handle this is allowing to
change name (and location) of the exported file through a file dialog.
Not everybody knows that, when exporting, the file will be located next
to the lyx file and, UI wise, it is bad that nothing seems to have
happened.

-- 
Enrico

Re: Wishlist: let active branches add to the exported filename

[Jean-Marc Lasgouttes]

Enrico Forestieri  writes:
> I think that the simplest and best way to handle this is allowing to
> change name (and location) of the exported file through a file dialog.
> Not everybody knows that, when exporting, the file will be located next
> to the lyx file and, UI wise, it is bad that nothing seems to have
> happened.

For the kind of uses I have in mind, automatic naming through branches
would be much more convenient.

The fact that Export As... would be useful is a separate problem.

JMarc

Wishlist: let active branches add to the exported filename

[Helge Hafting]

It is useful to give active branches opportunity to add to the filename 
of exported files. This way, exports with and without the branch won't 
collide.


My common case:
I make a test for my students, with answers in a answers branch.
When I export this to pdf, I get test.pdf. After activating the 
answers branch, I export again and should get test-answers.pdf


One can also see how this is useful for documents with language 
versions. Figures can be shared, and the various languages kept in branches.


Obviously, not all branches need this, so it must be configurable per 
branch. The branches dialog in document settings already have a list 
of branches, this list could have an extra filename column. When 
filename is checked/yes for a branch, then the name of that branch 
will be appended to the exported filename.


It should be possible to have several such branches active at once, 
resulting in filenames like test-answers-comments.pdf when there is 
both a comments branch and a answers branch.


This could avoid a lot of file renaming outside lyx when exporting 
documents with and without particular branches.


Also registered as ticket #6048.

Helge Hafting

Re: Wishlist: let active branches add to the exported filename

[Jean-Marc Lasgouttes]

Helge Hafting helge.haft...@hist.no writes:

 It is useful to give active branches opportunity to add to the
 filename of exported files. This way, exports with and without the
 branch won't collide.

 My common case:
 I make a test for my students, with answers in a answers branch.
 When I export this to pdf, I get test.pdf. After activating the
 answers branch, I export again and should get test-answers.pdf

I have to say that I use that too. What we have to do is to find the
correct, not over-engineered implementation.

The simplest would be a add name when exporting checkbox. That could
maybe be done by a change to Buffer::latexName.

JMarc

Re: Wishlist: let active branches add to the exported filename

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

 I have to say that I use that too. What we have to do is to find the
 correct, not over-engineered implementation.

+1.

 The simplest would be a add name when exporting checkbox. That could
 maybe be done by a change to Buffer::latexName.

Which name (if several active branches are involved)?

Jürgen

Re: Wishlist: let active branches add to the exported filename

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller sp...@lyx.org writes:

 Jean-Marc Lasgouttes wrote:

 I have to say that I use that too. What we have to do is to find the
 correct, not over-engineered implementation.

 +1.

 The simplest would be a add name when exporting checkbox. That could
 maybe be done by a change to Buffer::latexName.

 Which name (if several active branches are involved)?

Append all the names of the active branches which have add name when
exporting selected.

JMarc

Re: Wishlist: let active branches add to the exported filename

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

 Append all the names of the active branches which have add name when
 exporting selected.

Yes, that would work in most cases.

Jürgen

Re: Wishlist: let active branches add to the exported filename

[Helge Hafting]

Jürgen Spitzmüller wrote:

Jean-Marc Lasgouttes wrote:


I have to say that I use that too. What we have to do is to find the
correct, not over-engineered implementation.


+1.


The simplest would be a add name when exporting checkbox. That could
maybe be done by a change to Buffer::latexName.


Which name (if several active branches are involved)?


The names of all active branches that has this box checked. I meant to 
have one checkbox per branch. If you simplify to only one checkbox - 
then use the names of all active branches in the order they are defined.


Example:
Document named test.lyx, containing test questions for students
One branch named answers, containing correct answers to the questions
Another branch named comments where the teacher later can add stuff 
like 90% failed this question, update the course material


With no branches active,  export-PDF yields test.pdf
With the answers branch active, you get test-answers.pdf
With both branches active, you get test-answers-comments.pdf

Other use cases:
* Multilingual document with language branches
* Docment with comments from several people, one branch per person

Helge Hafting

Re: Wishlist: let active branches add to the exported filename

[Jürgen Spitzmüller]

Helge Hafting wrote:

 Which name (if several active branches are involved)?
 
 The names of all active branches that has this box checked. I meant to
 have one checkbox per branch.

Yes, this strikes me sensible. I first thought Jean-Marc was thinking of one 
general check-box only.

Jürgen

Re: Wishlist: let active branches add to the exported filename

[John McCabe-Dansted]

I'll just mention that what I do is create a new master document that
has the correct branches enabled. In addition to giving the new
version of the document a new name, this is particularly useful when
there are many branches. For example the paper version may have e.g.
branches for Topic A and C while the tech report may have the branches
Topics A-E all enabled. Even for a single branch I find this more
convenient that digging around in the document settings.

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia

Wishlist: let active branches add to the exported filename

[Helge Hafting]

It is useful to give active branches opportunity to add to the filename 
of exported files. This way, exports with and without the branch won't 
collide.


My common case:
I make a test for my students, with answers in a "answers" branch.
When I export this to pdf, I get "test.pdf". After activating the 
answers branch, I export again and should get "test-answers.pdf"


One can also see how this is useful for documents with language 
versions. Figures can be shared, and the various languages kept in branches.


Obviously, not all branches need this, so it must be configurable per 
branch. The branches dialog in "document settings" already have a list 
of branches, this list could have an extra "filename" column. When 
"filename" is checked/yes for a branch, then the name of that branch 
will be appended to the exported filename.


It should be possible to have several such branches active at once, 
resulting in filenames like "test-answers-comments.pdf" when there is 
both a "comments" branch and a "answers" branch.


This could avoid a lot of file renaming outside lyx when exporting 
documents with and without particular branches.


Also registered as ticket #6048.

Helge Hafting

Re: Wishlist: let active branches add to the exported filename

[Jean-Marc Lasgouttes]

Helge Hafting  writes:

> It is useful to give active branches opportunity to add to the
> filename of exported files. This way, exports with and without the
> branch won't collide.
>
> My common case:
> I make a test for my students, with answers in a "answers" branch.
> When I export this to pdf, I get "test.pdf". After activating the
> answers branch, I export again and should get "test-answers.pdf"

I have to say that I use that too. What we have to do is to find the
correct, not over-engineered implementation.

The simplest would be a "add name when exporting" checkbox. That could
maybe be done by a change to Buffer::latexName.

JMarc

Re: Wishlist: let active branches add to the exported filename

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

> I have to say that I use that too. What we have to do is to find the
> correct, not over-engineered implementation.

+1.

> The simplest would be a "add name when exporting" checkbox. That could
> maybe be done by a change to Buffer::latexName.

Which name (if several active branches are involved)?

Jürgen

Re: Wishlist: let active branches add to the exported filename

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller  writes:

> Jean-Marc Lasgouttes wrote:
>
>> I have to say that I use that too. What we have to do is to find the
>> correct, not over-engineered implementation.
>
> +1.
>
>> The simplest would be a "add name when exporting" checkbox. That could
>> maybe be done by a change to Buffer::latexName.
>
> Which name (if several active branches are involved)?

Append all the names of the active branches which have "add name when
exporting" selected.

JMarc

Re: Wishlist: let active branches add to the exported filename

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

> Append all the names of the active branches which have "add name when
> exporting" selected.

Yes, that would work in most cases.

Jürgen

Re: Wishlist: let active branches add to the exported filename

[Helge Hafting]

Jürgen Spitzmüller wrote:

Jean-Marc Lasgouttes wrote:


I have to say that I use that too. What we have to do is to find the
correct, not over-engineered implementation.


+1.


The simplest would be a "add name when exporting" checkbox. That could
maybe be done by a change to Buffer::latexName.


Which name (if several active branches are involved)?


The names of all active branches that has this box checked. I meant to 
have one checkbox per branch. If you simplify to only one checkbox - 
then use the names of all active branches in the order they are defined.


Example:
Document named test.lyx, containing test questions for students
One branch named "answers", containing correct answers to the questions
Another branch named "comments" where the teacher later can add stuff 
like "90% failed this question, update the course material"


With no branches active,  export->PDF yields "test.pdf"
With the "answers" branch active, you get "test-answers.pdf"
With both branches active, you get "test-answers-comments.pdf"

Other use cases:
* Multilingual document with language branches
* Docment with comments from several people, one branch per person

Helge Hafting

Re: Wishlist: let active branches add to the exported filename

[Jürgen Spitzmüller]

Helge Hafting wrote:

>> Which name (if several active branches are involved)?
> 
> The names of all active branches that has this box checked. I meant to
> have one checkbox per branch.

Yes, this strikes me sensible. I first thought Jean-Marc was thinking of one 
general check-box only.

Jürgen

Re: Wishlist: let active branches add to the exported filename

[John McCabe-Dansted]

I'll just mention that what I do is create a new master document that
has the correct branches enabled. In addition to giving the new
version of the document a new name, this is particularly useful when
there are many branches. For example the paper version may have e.g.
branches for Topic A and C while the tech report may have the branches
Topics A-E all enabled. Even for a single branch I find this more
convenient that digging around in the document settings.

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia

Re: A wishlist for LyX

[Helge Hafting]

Tommaso Cucinotta wrote:

Richard Heck ha scritto:
do something like hold down control+shift and click on a label 
to insert a reference to that label at the current cursor position.
I'd like to suggest an alternative usage paradigm for this, 
conditioned to

the implementation of context-sensitive menus. The idea is:

1. right-click on a label, numbered equation or section/paragraph
2. select a menu entry copy reference
3. then simply paste wherever you want in the document, and you get
   a reference to the label.

So many times I have the label just a few lines above (because I just 
inserted
a table, picture, or formula), and I need to refer to it, but the 
process for doing
it is really boring (I wish I could even drag the label into a text 
position).

Well - I have the hope that we can get rid making the labels instead.
After all, LyX already knows about sections, subsections,
footnotes, formulas and the other referencable things.

So we should be able to insert a reference without having
to make a label first - LyX should then create a label automatically for us.

This approach helps a lot when referencing something that isn't
visible already. I do a lot of that.  Optimizations for the
case where you want to reference something that is visible
above or below should be possible for this case too.

Perhaps something like:
1. Press some hotkey for inserting a cross reference by pointing.
   The reference will be inserted where the text cursor is
   at that moment.
2. The mouse pointer changes to an arrow with ref written
   under it, to indicate this new mode of operation.
   You can still use the scrollbar or arrows/pgup/pgdown to
   scroll the document.
3. Click on whatever you want to refer to.  Could be a section heading,
   could be somewhere in the text, could be a footnote, a figure,
   a formula, . . .
  
4. Wherever you clicked, LyX checks for an existing label

  and uses that. If there is none, LyX auto-inserts a new label.
   A reference to that
   label happens in the original cursor location. The
   mouse pointer goes back to normal. The cursor remains
   at the reference, so you can keep writing.
   Perhaps the view scrolls
   back to the cursor - perhaps not - I am not sure what is best.
   One might want to check visually that the label happened
   in the correct place, and any typing should bring us back
   to the cursor anyway.

5. There is probably no need to pop up a dialog - the user can
   click the inserted reference if he need to set a ref style.
   Usually, documents have lots of references of the same
   kind, so just use whatever style the user used the last time.


This way we can insert the label and the reference at the
same time, and usually no dialogs involved. Of course
we still need a dialog for referencing stuff that is
too far away to look up directly, but this is a nice optimization
for the common case of referencing the nearest floats.

Helge Hafting

Re: A wishlist for LyX

[Alexander Streit]

This is would be handy in my opinion.

But, I would like to point out that the current automatic label is not quite
unique enough. For example, just today I inserted a label for a section
called Summary. The default label was sec:Summary. Problem is, I have a
Summary section in several chapters and so I had to manually edit it to be
sec:Ch3Summary. Luckily I spotted this, as LyX doesn't seem to notice
whether you have duplicate labels. If you do have more than one label of the
same name then LaTeX appears to use the last one that was defined. At least
this was for MikTex and I don't know if this is standard behavior or not.

It occurs to me that the outline panel has lists of sections, figures, and
tables. Perhaps that could be used somehow?

On 10/31/07, Helge Hafting [EMAIL PROTECTED] wrote:

 Well - I have the hope that we can get rid making the labels instead.
 After all, LyX already knows about sections, subsections,
 footnotes, formulas and the other referencable things.

 So we should be able to insert a reference without having
 to make a label first - LyX should then create a label automatically for
 us.

 This approach helps a lot when referencing something that isn't
 visible already. I do a lot of that.  Optimizations for the
 case where you want to reference something that is visible
 above or below should be possible for this case too.

 Perhaps something like:
 1. Press some hotkey for inserting a cross reference by pointing.
 The reference will be inserted where the text cursor is
 at that moment.
 2. The mouse pointer changes to an arrow with ref written
 under it, to indicate this new mode of operation.
 You can still use the scrollbar or arrows/pgup/pgdown to
 scroll the document.
 3. Click on whatever you want to refer to.  Could be a section heading,
 could be somewhere in the text, could be a footnote, a figure,
 a formula, . . .

 4. Wherever you clicked, LyX checks for an existing label
and uses that. If there is none, LyX auto-inserts a new label.
 A reference to that
 label happens in the original cursor location. The
 mouse pointer goes back to normal. The cursor remains
 at the reference, so you can keep writing.
 Perhaps the view scrolls
 back to the cursor - perhaps not - I am not sure what is best.
 One might want to check visually that the label happened
 in the correct place, and any typing should bring us back
 to the cursor anyway.

 5. There is probably no need to pop up a dialog - the user can
 click the inserted reference if he need to set a ref style.
 Usually, documents have lots of references of the same
 kind, so just use whatever style the user used the last time.


 This way we can insert the label and the reference at the
 same time, and usually no dialogs involved. Of course
 we still need a dialog for referencing stuff that is
 too far away to look up directly, but this is a nice optimization
 for the common case of referencing the nearest floats.

 Helge Hafting

Re: A wishlist for LyX

[Helge Hafting]

Alexander Streit wrote:

This is would be handy in my opinion.

But, I would like to point out that the current automatic label is not 
quite unique enough. 

Correct. But LyX knows all its own labels, so this can
be avoided with some programming. You might want
to file a bug at bugzilla.lyx.org - lyx shouldn't
suggest a label that cannot possibly work.
[...]

Helge Hafting

Re: A wishlist for LyX

[Helge Hafting]

Tommaso Cucinotta wrote:

Richard Heck ha scritto:
do something like hold down control+shift and click on a label 
to insert a reference to that label at the current cursor position.
I'd like to suggest an alternative usage paradigm for this, 
conditioned to

the implementation of context-sensitive menus. The idea is:

1. right-click on a label, numbered equation or section/paragraph
2. select a menu entry "copy reference"
3. then simply paste wherever you want in the document, and you get
   a reference to the label.

So many times I have the label just a few lines above (because I just 
inserted
a table, picture, or formula), and I need to refer to it, but the 
process for doing
it is really boring (I wish I could even "drag" the label into a text 
position).

Well - I have the hope that we can get rid making the labels instead.
After all, LyX already knows about sections, subsections,
footnotes, formulas and the other referencable things.

So we should be able to insert a reference without having
to make a label first - LyX should then create a label automatically for us.

This approach helps a lot when referencing something that isn't
visible already. I do a lot of that.  Optimizations for the
case where you want to reference something that is visible
above or below should be possible for this case too.

Perhaps something like:
1. Press some hotkey for inserting a cross reference by pointing.
   The reference will be inserted where the text cursor is
   at that moment.
2. The mouse pointer changes to an arrow with "ref" written
   under it, to indicate this new mode of operation.
   You can still use the scrollbar or arrows/pgup/pgdown to
   scroll the document.
3. Click on whatever you want to refer to.  Could be a section heading,
   could be somewhere in the text, could be a footnote, a figure,
   a formula, . . .
  
4. Wherever you clicked, LyX checks for an existing label

  and uses that. If there is none, LyX auto-inserts a new label.
   A reference to that
   label happens in the original cursor location. The
   mouse pointer goes back to normal. The cursor remains
   at the reference, so you can keep writing.
   Perhaps the view scrolls
   back to the cursor - perhaps not - I am not sure what is best.
   One might want to check visually that the label happened
   in the correct place, and any typing should bring us back
   to the cursor anyway.

5. There is probably no need to pop up a dialog - the user can
   click the inserted reference if he need to set a ref style.
   Usually, documents have lots of references of the same
   kind, so just use whatever style the user used the last time.


This way we can insert the label and the reference at the
same time, and usually no dialogs involved. Of course
we still need a dialog for referencing stuff that is
"too far away" to look up directly, but this is a nice optimization
for the common case of referencing the nearest floats.

Helge Hafting

Re: A wishlist for LyX

[Alexander Streit]

This is would be handy in my opinion.

But, I would like to point out that the current automatic label is not quite
unique enough. For example, just today I inserted a label for a section
called "Summary". The default label was "sec:Summary". Problem is, I have a
"Summary" section in several chapters and so I had to manually edit it to be
"sec:Ch3Summary". Luckily I spotted this, as LyX doesn't seem to notice
whether you have duplicate labels. If you do have more than one label of the
same name then LaTeX appears to use the last one that was defined. At least
this was for MikTex and I don't know if this is standard behavior or not.

It occurs to me that the "outline" panel has lists of sections, figures, and
tables. Perhaps that could be used somehow?

On 10/31/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
>
> Well - I have the hope that we can get rid making the labels instead.
> After all, LyX already knows about sections, subsections,
> footnotes, formulas and the other referencable things.
>
> So we should be able to insert a reference without having
> to make a label first - LyX should then create a label automatically for
> us.
>
> This approach helps a lot when referencing something that isn't
> visible already. I do a lot of that.  Optimizations for the
> case where you want to reference something that is visible
> above or below should be possible for this case too.
>
> Perhaps something like:
> 1. Press some hotkey for inserting a cross reference by pointing.
> The reference will be inserted where the text cursor is
> at that moment.
> 2. The mouse pointer changes to an arrow with "ref" written
> under it, to indicate this new mode of operation.
> You can still use the scrollbar or arrows/pgup/pgdown to
> scroll the document.
> 3. Click on whatever you want to refer to.  Could be a section heading,
> could be somewhere in the text, could be a footnote, a figure,
> a formula, . . .
>
> 4. Wherever you clicked, LyX checks for an existing label
>and uses that. If there is none, LyX auto-inserts a new label.
> A reference to that
> label happens in the original cursor location. The
> mouse pointer goes back to normal. The cursor remains
> at the reference, so you can keep writing.
> Perhaps the view scrolls
> back to the cursor - perhaps not - I am not sure what is best.
> One might want to check visually that the label happened
> in the correct place, and any typing should bring us back
> to the cursor anyway.
>
> 5. There is probably no need to pop up a dialog - the user can
> click the inserted reference if he need to set a ref style.
> Usually, documents have lots of references of the same
> kind, so just use whatever style the user used the last time.
>
>
> This way we can insert the label and the reference at the
> same time, and usually no dialogs involved. Of course
> we still need a dialog for referencing stuff that is
> "too far away" to look up directly, but this is a nice optimization
> for the common case of referencing the nearest floats.
>
> Helge Hafting
>
>
>
>
>
>
>
>
>
>
>
>

Re: A wishlist for LyX

[Helge Hafting]

Alexander Streit wrote:

This is would be handy in my opinion.

But, I would like to point out that the current automatic label is not 
quite unique enough. 

Correct. But LyX knows all its own labels, so this can
be avoided with some programming. You might want
to file a bug at bugzilla.lyx.org - lyx shouldn't
suggest a label that cannot possibly work.
[...]

Helge Hafting

Re: A wishlist for LyX

[Tommaso Cucinotta]

Richard Heck ha scritto:
do something like hold down control+shift and click on a label 
to insert a reference to that label at the current cursor position.

I'd like to suggest an alternative usage paradigm for this, conditioned to
the implementation of context-sensitive menus. The idea is:

1. right-click on a label, numbered equation or section/paragraph
2. select a menu entry copy reference
3. then simply paste wherever you want in the document, and you get
   a reference to the label.

So many times I have the label just a few lines above (because I just 
inserted
a table, picture, or formula), and I need to refer to it, but the 
process for doing
it is really boring (I wish I could even drag the label into a text 
position).


   T.

Re: A wishlist for LyX

[Tommaso Cucinotta]

Richard Heck ha scritto:
do something like hold down control+shift and click on a label 
to insert a reference to that label at the current cursor position.

I'd like to suggest an alternative usage paradigm for this, conditioned to
the implementation of context-sensitive menus. The idea is:

1. right-click on a label, numbered equation or section/paragraph
2. select a menu entry "copy reference"
3. then simply paste wherever you want in the document, and you get
   a reference to the label.

So many times I have the label just a few lines above (because I just 
inserted
a table, picture, or formula), and I need to refer to it, but the 
process for doing
it is really boring (I wish I could even "drag" the label into a text 
position).


   T.

Re: A wishlist for LyX

[Richard Heck]

Alexander Streit wrote:

Something like this is already possible: Type Alt-I, C, start typing,
hit Ctrl-Enter when you get the one you want.



Yes, this works very well! Thanks, I didn't know about this and have been
using the mouse for over 200 pages now, so you've saved me a lot of time!
For cross references there doesn't seem to be a keyboard shortcut. Also it
is harder to type the label you want - having the sec:, fig:, etc. prefix is
useful, but might get frustrating. Maybe I missed something?
  


Agreed. This is not so easy. Perhaps some improvement here would be 
worth making. For one thing, I'd like to see the sec: business made 
possible to turn off. This is only useful if you use \prettyref.

5. magi-click references


do something like hold down control+shift and click on a label to insert a 
reference to that label at the current cursor position.

  

This would be pretty easy to do but it's not clear how useful it would
be. The chance that the label is nearly isn't large.




True, but I find that I so often scroll through the document to find the
label, remember what it is, then click on insert cross reference, then sort
the list, then search for the label i had remembered. Since the label is
right there (and I've used the scroll bars to find it), clicking it would
cut out a lot of work. When using the scroll bar you don't change the cursor
position, so it is always waiting in the right place for me.
  


OK. Well, add this one, too. It's surely do-able.

Richard

Re: A wishlist for LyX

[Richard Heck]

Alexander Streit wrote:

Something like this is already possible: Type Alt-I, C, start typing,
hit Ctrl-Enter when you get the one you want.



Yes, this works very well! Thanks, I didn't know about this and have been
using the mouse for over 200 pages now, so you've saved me a lot of time!
For cross references there doesn't seem to be a keyboard shortcut. Also it
is harder to type the label you want - having the sec:, fig:, etc. prefix is
useful, but might get frustrating. Maybe I missed something?
  


Agreed. This is not so easy. Perhaps some improvement here would be 
worth making. For one thing, I'd like to see the "sec:" business made 
possible to turn off. This is only useful if you use \prettyref.

5. magi-click references


do something like hold down control+shift and click on a label to insert a 
reference to that label at the current cursor position.

  

This would be pretty easy to do but it's not clear how useful it would
be. The chance that the label is nearly isn't large.




True, but I find that I so often scroll through the document to find the
label, remember what it is, then click on insert cross reference, then sort
the list, then search for the label i had remembered. Since the label is
right there (and I've used the scroll bars to find it), clicking it would
cut out a lot of work. When using the scroll bar you don't change the cursor
position, so it is always waiting in the right place for me.
  


OK. Well, add this one, too. It's surely do-able.

Richard

A wishlist for LyX

[Alexander Streit]

Hi developers,

been writing on my thesis (love LyX for that) and collecting random ideas in
a text file about improvements. Some of these may already be planned, some
not. But if anyone is looking for something to add to LyX, then these are
what I would have enjoyed.
They are in rough order of preference. Maybe 5 and 8 should be higher up the
list.

1. todo tag
puts a tag in (much like a comment), but also adds this to a list of
some sort so that you can switch between items todo
perhaps this todo tag could be placed in the headings to flag a section
as needing to be done

2. spell-check highlight
this simply highlights every word that isn't recognized. it doesn't
interrupt your work in the intrusive way that the current spell checker
does. look at google docs for an example

3. auto-complete cite/crossref
press a magic key and start typing. lyx will try to auto-complete the
author name  year. press enter to accept, esc to cancel. insert citations
without having to use the mouse! The same goes for cross references (figures
etc).
NOTE: the figure that I want to reference is almost always the next
label in the document! therefore it would be great if that was the default
cross reference if you don't type anything.

4. in-cite
press the magic key to insert a magic reference at the current spot. it
is programmed to recognize common patterns. So basically, if someone has
already typed up a document this is a really easy way to add in references.
So, for example, if the following text is written and the * represents
where the cursor would be when the magic key is pressed:
Smith * -  Smith [Smith:2007]
Smith et. al. * -  Smith et. al. [Smith:2007]
Smith and Cox * -  Smith and Cox [Smith:2007]
Smith in 2007 * -  Smith in 2007 [Smith:2007]

5. magi-click references
do something like hold down control+shift and click on a label to insert
a reference to that label at the current cursor position.

6. cursor position shown in Lyx: CrossReference window
draw a thick black line between two entries in the list to indicate
where the cursor is so that it is much easier to find the cross reference in
a long long list. (I have a lot of trouble inserting cross-references from
such a long list!)

7. UNICODE support
for everything. including the bibtex library. would be great. (translate
it prior to running latex if needed, but have lyx support it)

8. Better tables
I know this is a latex issue, but the tables are so ugly and hard to
use. There possibly isn't an elegant solution to this. However, I'd like to
have a LyX table or something, maybe using custom latex. I'd want to have
more control over each cell, the borders, and be able to shade the cell. In
other words, this is one area that the word processors do well. I always
dread having to insert a table.

9. Paste from rich text/html
I'd like especially to be able to copy and paste Word with some
formatting preserved. It's not critical, but would be a nice to have,
especially for people who are considering switching.

9. An easier key combination for changing the style
Its just an idea. chances are you can already change this. I haven't
tried.


I love LyX as it is, these are just the things that I would have liked...

cheers,

Alex.

Re: A wishlist for LyX

[Richard Heck]

Many of these are reasonable ideas. You're welcome to add them to bugzilla.

1. todo tag
puts a tag in (much like a comment), but also adds this to a list of
some sort so that you can switch between items todo
perhaps this todo tag could be placed in the headings to flag a section
as needing to be done
  

Add to bugzilla

2. spell-check highlight
this simply highlights every word that isn't recognized. it doesn't
interrupt your work in the intrusive way that the current spell checker
does. look at google docs for an example
  

There's been discussion about this recent. Add to bugzilla

3. auto-complete cite/crossref
press a magic key and start typing. lyx will try to auto-complete the
author name  year. press enter to accept, esc to cancel. insert citations
without having to use the mouse! The same goes for cross references (figures
etc).
  
Something like this is already possible: Type Alt-I, C, start typing, 
hit Ctrl-Enter when you get the one you want.

4. in-cite
press the magic key to insert a magic reference at the current spot. it
is programmed to recognize common patterns. So basically, if someone has
already typed up a document this is a really easy way to add in references.
So, for example, if the following text is written and the * represents
where the cursor would be when the magic key is pressed:
Smith * -  Smith [Smith:2007]
Smith et. al. * -  Smith et. al. [Smith:2007]
Smith and Cox * -  Smith and Cox [Smith:2007]
Smith in 2007 * -  Smith in 2007 [Smith:2007]
  
This seems close in spirit to (2) and, in so far as it isn't, probably 
not in the spirit of LyX. We try not to guess what the user wants, as 
it's extremely annoying when you guess wrong.

5. magi-click references
do something like hold down control+shift and click on a label to insert
a reference to that label at the current cursor position.
  
This would be pretty easy to do but it's not clear how useful it would 
be. The chance that the label is nearly isn't large.

6. cursor position shown in Lyx: CrossReference window
draw a thick black line between two entries in the list to indicate
where the cursor is so that it is much easier to find the cross reference in
a long long list. (I have a lot of trouble inserting cross-references from
such a long list!)
  

Add to bugzilla

7. UNICODE support
for everything. including the bibtex library. would be great. (translate
it prior to running latex if needed, but have lyx support it)
  
I don't understand this one. Full Unicode support is a goal, but we 
don't control what LaTeX does. BibTeX is entirely external to LyX, and 
there are plenty of encoding issues there. Perhaps BibLaTeX will make 
things better?

9. Paste from rich text/html
I'd like especially to be able to copy and paste Word with some
formatting preserved. It's not critical, but would be a nice to have,
especially for people who are considering switching.
  
This isn't impossible, so you could add to bugzilla, if you wish. But it 
would be messy: LyX would have to take the data from the clipboard, 
write it to a temporary file, run wvLatex on it, I guess---but does that 
work on partial files?---and then read the output, etc. My guess is 
that, if you really want this one, you'll get to write it. (Hey, that's 
how I got involved. I really wanted layout modules. Now I really want 
BibLaTeX and user-definable command insets.)

9. An easier key combination for changing the style
Its just an idea. chances are you can already change this. I haven't
tried.
  
Yes, and with Bo Peng's new shortcut editor (forthcoming in 1.6.x), 
it'll be even easier.


Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto

Re: A wishlist for LyX

[Alexander Streit]

Hi Richard, thanks for your comments. I've made my own inline below to
clarify some points.

On 10/29/07, Richard Heck [EMAIL PROTECTED] wrote:

  3. auto-complete cite/crossref
  press a magic key and start typing. lyx will try to auto-complete
 the
  author name  year. press enter to accept, esc to cancel. insert
 citations
  without having to use the mouse! The same goes for cross references
 (figures
  etc).
 
 Something like this is already possible: Type Alt-I, C, start typing,
 hit Ctrl-Enter when you get the one you want.


Yes, this works very well! Thanks, I didn't know about this and have been
using the mouse for over 200 pages now, so you've saved me a lot of time!
For cross references there doesn't seem to be a keyboard shortcut. Also it
is harder to type the label you want - having the sec:, fig:, etc. prefix is
useful, but might get frustrating. Maybe I missed something?

 4. in-cite
  press the magic key to insert a magic reference at the current spot.
 it
  is programmed to recognize common patterns. So basically, if someone has
  already typed up a document this is a really easy way to add in
 references.
  So, for example, if the following text is written and the * represents
  where the cursor would be when the magic key is pressed:
  Smith * -  Smith [Smith:2007]
  Smith et. al. * -  Smith et. al. [Smith:2007]
  Smith and Cox * -  Smith and Cox [Smith:2007]
  Smith in 2007 * -  Smith in 2007 [Smith:2007]
 
 This seems close in spirit to (2) and, in so far as it isn't, probably
 not in the spirit of LyX. We try not to guess what the user wants, as
 it's extremely annoying when you guess wrong.


Yes, it was a rather random idea that I had when I had to transfer a
document from Word into LyX.


 5. magi-click references
  do something like hold down control+shift and click on a label to
 insert
  a reference to that label at the current cursor position.
 
 This would be pretty easy to do but it's not clear how useful it would
 be. The chance that the label is nearly isn't large.


True, but I find that I so often scroll through the document to find the
label, remember what it is, then click on insert cross reference, then sort
the list, then search for the label i had remembered. Since the label is
right there (and I've used the scroll bars to find it), clicking it would
cut out a lot of work. When using the scroll bar you don't change the cursor
position, so it is always waiting in the right place for me.


 7. UNICODE support
  for everything. including the bibtex library. would be great.
 (translate
  it prior to running latex if needed, but have lyx support it)
 
 I don't understand this one. Full Unicode support is a goal, but we
 don't control what LaTeX does. BibTeX is entirely external to LyX, and
 there are plenty of encoding issues there. Perhaps BibLaTeX will make
 things better?


Perhaps. I added this point in because I had an umlaut in someone's name in
a BibTex entry that came from someone else. In retrospect the error is
probably bibtex's but I was getting an incomprehensible error when I tried
to typeset the document. This was kind of far down the list for me and I
didn't think it through.


 9. Paste from rich text/html
  I'd like especially to be able to copy and paste Word with some
  formatting preserved. It's not critical, but would be a nice to have,
  especially for people who are considering switching.
 
 This isn't impossible, so you could add to bugzilla, if you wish. But it
 would be messy: LyX would have to take the data from the clipboard,
 write it to a temporary file, run wvLatex on it, I guess---but does that
 work on partial files?---and then read the output, etc. My guess is
 that, if you really want this one, you'll get to write it. (Hey, that's
 how I got involved. I really wanted layout modules. Now I really want
 BibLaTeX and user-definable command insets.)


That sounds like a lot more trouble than I expected. When I wrote this point
down I was only really thinking of translating italics to emphasis, because
it was annoying to have to try and figure that out. Now that I actually give
it thought, this is a non-trivial problem.

A wishlist for LyX

[Alexander Streit]

Hi developers,

been writing on my thesis (love LyX for that) and collecting random ideas in
a text file about improvements. Some of these may already be planned, some
not. But if anyone is looking for something to add to LyX, then these are
what I would have enjoyed.
They are in rough order of preference. Maybe 5 and 8 should be higher up the
list.

1. todo tag
puts a tag in (much like a comment), but also adds this to a list of
some sort so that you can switch between items "todo"
perhaps this todo tag could be placed in the headings to flag a section
as needing to be done

2. spell-check highlight
this simply highlights every word that isn't recognized. it doesn't
interrupt your work in the intrusive way that the current spell checker
does. look at google docs for an example

3. auto-complete cite/crossref
press a magic key and start typing. lyx will try to auto-complete the
author name & year. press enter to accept, esc to cancel. insert citations
without having to use the mouse! The same goes for cross references (figures
etc).
NOTE: the figure that I want to reference is almost always the next
label in the document! therefore it would be great if that was the default
cross reference if you don't type anything.

4. in-cite
press the magic key to insert a magic reference at the current spot. it
is programmed to recognize common patterns. So basically, if someone has
already typed up a document this is a really easy way to add in references.
So, for example, if the following text is written and the "*" represents
where the cursor would be when the magic key is pressed:
Smith * ->  Smith [Smith:2007]
Smith et. al. * ->  Smith et. al. [Smith:2007]
Smith and Cox * ->  Smith and Cox [Smith:2007]
Smith in 2007 * ->  Smith in 2007 [Smith:2007]

5. magi-click references
do something like hold down control+shift and click on a label to insert
a reference to that label at the current cursor position.

6. cursor position shown in "Lyx: CrossReference" window
draw a thick black line between two entries in the list to indicate
where the cursor is so that it is much easier to find the cross reference in
a long long list. (I have a lot of trouble inserting cross-references from
such a long list!)

7. UNICODE support
for everything. including the bibtex library. would be great. (translate
it prior to running latex if needed, but have lyx support it)

8. Better tables
I know this is a latex issue, but the tables are so ugly and hard to
use. There possibly isn't an elegant solution to this. However, I'd like to
have a "LyX table" or something, maybe using custom latex. I'd want to have
more control over each cell, the borders, and be able to shade the cell. In
other words, this is one area that the word processors do well. I always
dread having to insert a table.

9. Paste from rich text/html
I'd like especially to be able to copy and paste Word with some
formatting preserved. It's not critical, but would be a nice to have,
especially for people who are considering switching.

9. An easier key combination for changing the style
Its just an idea. chances are you can already change this. I haven't
tried.


I love LyX as it is, these are just the things that I would have liked...

cheers,

Alex.

Re: A wishlist for LyX

[Richard Heck]

Many of these are reasonable ideas. You're welcome to add them to bugzilla.

1. todo tag
puts a tag in (much like a comment), but also adds this to a list of
some sort so that you can switch between items "todo"
perhaps this todo tag could be placed in the headings to flag a section
as needing to be done
  

Add to bugzilla

2. spell-check highlight
this simply highlights every word that isn't recognized. it doesn't
interrupt your work in the intrusive way that the current spell checker
does. look at google docs for an example
  

There's been discussion about this recent. Add to bugzilla

3. auto-complete cite/crossref
press a magic key and start typing. lyx will try to auto-complete the
author name & year. press enter to accept, esc to cancel. insert citations
without having to use the mouse! The same goes for cross references (figures
etc).
  
Something like this is already possible: Type Alt-I, C, start typing, 
hit Ctrl-Enter when you get the one you want.

4. in-cite
press the magic key to insert a magic reference at the current spot. it
is programmed to recognize common patterns. So basically, if someone has
already typed up a document this is a really easy way to add in references.
So, for example, if the following text is written and the "*" represents
where the cursor would be when the magic key is pressed:
Smith * ->  Smith [Smith:2007]
Smith et. al. * ->  Smith et. al. [Smith:2007]
Smith and Cox * ->  Smith and Cox [Smith:2007]
Smith in 2007 * ->  Smith in 2007 [Smith:2007]
  
This seems close in spirit to (2) and, in so far as it isn't, probably 
not in the spirit of LyX. We try not to guess what the user wants, as 
it's extremely annoying when you guess wrong.

5. magi-click references
do something like hold down control+shift and click on a label to insert
a reference to that label at the current cursor position.
  
This would be pretty easy to do but it's not clear how useful it would 
be. The chance that the label is nearly isn't large.

6. cursor position shown in "Lyx: CrossReference" window
draw a thick black line between two entries in the list to indicate
where the cursor is so that it is much easier to find the cross reference in
a long long list. (I have a lot of trouble inserting cross-references from
such a long list!)
  

Add to bugzilla

7. UNICODE support
for everything. including the bibtex library. would be great. (translate
it prior to running latex if needed, but have lyx support it)
  
I don't understand this one. Full Unicode support is a goal, but we 
don't control what LaTeX does. BibTeX is entirely external to LyX, and 
there are plenty of encoding issues there. Perhaps BibLaTeX will make 
things better?

9. Paste from rich text/html
I'd like especially to be able to copy and paste Word with some
formatting preserved. It's not critical, but would be a nice to have,
especially for people who are considering switching.
  
This isn't impossible, so you could add to bugzilla, if you wish. But it 
would be messy: LyX would have to take the data from the clipboard, 
write it to a temporary file, run wvLatex on it, I guess---but does that 
work on partial files?---and then read the output, etc. My guess is 
that, if you really want this one, you'll get to write it. (Hey, that's 
how I got involved. I really wanted layout modules. Now I really want 
BibLaTeX and user-definable command insets.)

9. An easier key combination for changing the style
Its just an idea. chances are you can already change this. I haven't
tried.
  
Yes, and with Bo Peng's new shortcut editor (forthcoming in 1.6.x), 
it'll be even easier.


Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto

Re: A wishlist for LyX

[Alexander Streit]

Hi Richard, thanks for your comments. I've made my own inline below to
clarify some points.

On 10/29/07, Richard Heck <[EMAIL PROTECTED]> wrote:
>
> > 3. auto-complete cite/crossref
> > press a magic key and start typing. lyx will try to auto-complete
> the
> > author name & year. press enter to accept, esc to cancel. insert
> citations
> > without having to use the mouse! The same goes for cross references
> (figures
> > etc).
> >
> Something like this is already possible: Type Alt-I, C, start typing,
> hit Ctrl-Enter when you get the one you want.


Yes, this works very well! Thanks, I didn't know about this and have been
using the mouse for over 200 pages now, so you've saved me a lot of time!
For cross references there doesn't seem to be a keyboard shortcut. Also it
is harder to type the label you want - having the sec:, fig:, etc. prefix is
useful, but might get frustrating. Maybe I missed something?

> 4. in-cite
> > press the magic key to insert a magic reference at the current spot.
> it
> > is programmed to recognize common patterns. So basically, if someone has
> > already typed up a document this is a really easy way to add in
> references.
> > So, for example, if the following text is written and the "*" represents
> > where the cursor would be when the magic key is pressed:
> > Smith * ->  Smith [Smith:2007]
> > Smith et. al. * ->  Smith et. al. [Smith:2007]
> > Smith and Cox * ->  Smith and Cox [Smith:2007]
> > Smith in 2007 * ->  Smith in 2007 [Smith:2007]
> >
> This seems close in spirit to (2) and, in so far as it isn't, probably
> not in the spirit of LyX. We try not to guess what the user wants, as
> it's extremely annoying when you guess wrong.


Yes, it was a rather random idea that I had when I had to transfer a
document from Word into LyX.


> 5. magi-click references
> > do something like hold down control+shift and click on a label to
> insert
> > a reference to that label at the current cursor position.
> >
> This would be pretty easy to do but it's not clear how useful it would
> be. The chance that the label is nearly isn't large.


True, but I find that I so often scroll through the document to find the
label, remember what it is, then click on insert cross reference, then sort
the list, then search for the label i had remembered. Since the label is
right there (and I've used the scroll bars to find it), clicking it would
cut out a lot of work. When using the scroll bar you don't change the cursor
position, so it is always waiting in the right place for me.


> 7. UNICODE support
> > for everything. including the bibtex library. would be great.
> (translate
> > it prior to running latex if needed, but have lyx support it)
> >
> I don't understand this one. Full Unicode support is a goal, but we
> don't control what LaTeX does. BibTeX is entirely external to LyX, and
> there are plenty of encoding issues there. Perhaps BibLaTeX will make
> things better?


Perhaps. I added this point in because I had an umlaut in someone's name in
a BibTex entry that came from someone else. In retrospect the error is
probably bibtex's but I was getting an incomprehensible error when I tried
to typeset the document. This was kind of far down the list for me and I
didn't think it through.


> 9. Paste from rich text/html
> > I'd like especially to be able to copy and paste Word with some
> > formatting preserved. It's not critical, but would be a nice to have,
> > especially for people who are considering switching.
> >
> This isn't impossible, so you could add to bugzilla, if you wish. But it
> would be messy: LyX would have to take the data from the clipboard,
> write it to a temporary file, run wvLatex on it, I guess---but does that
> work on partial files?---and then read the output, etc. My guess is
> that, if you really want this one, you'll get to write it. (Hey, that's
> how I got involved. I really wanted layout modules. Now I really want
> BibLaTeX and user-definable command insets.)


That sounds like a lot more trouble than I expected. When I wrote this point
down I was only really thinking of translating italics to emphasis, because
it was annoying to have to try and figure that out. Now that I actually give
it thought, this is a non-trivial problem.

Re: Support for environments options ? wishlist idea for a general solution

[Helge Hafting]

Martin Vermeer wrote:

On Sat, Oct 06, 2007 at 11:52:37PM +0200, Tommaso Cucinotta wrote:
  

 Paul A. Rubin ha scritto:

The way I enter an optional argument (when one is allowed) is to open the 
minibuffer (M-x or View - Toolbars - Command buffer) and type the command 
'optional-insert'.
  

 Great ! Exactly what I was needing. Probably my fault for not having
 read throughly the user manual. Anyhow, a Insert-Optional argument,
 or Insert-Layout option menu voice would help users in finding this
 wonderful feature, wouldn't it ?

 What about considering the attached addition to the menu file ?

T.



Actually the is an entry like this: Short title. It has
been criticised for being descriptive only of one use case
(short versions of titles going to the toc), so perhaps
you could come up with a more descriptive name (that 
nevertheless doesn't lead the naive user astray)
  

Can't give you a new name, but an idea that is much more work
to implement. :-( Still, it'd be a nifty thing to have:

* Any layout (paragraph style or text/char style) implemented
 with a latex command or environment should be able to
 specify several arguments (optional and mandatory ones)
 as well as their types. (generic text, generic number, a length,
 or a set of predefined values.) Perhaps a few more. Numbers
 may have constraints, lengths might be glue lengths.

*  When using such a style, defaults are used for all the options. Just
  like what happens when you insert a minipage. If the user right-clicks
  the entity (paragraph or charstyle) then he gets a dialog where the
  parameters can be set withing the constraints of the type.

This concept would support lots of latex constructs, one could even
consider making the minipage a charstyle. :-)  It'd make the
flexible insets/modules much more powerful.

The hard part is those dialogs, that must be auto-generated
from the information in the layout/module. That is why
I suggest a limited amount of option types, to make it
possible at all. One could start with the generic text only,
because it can stand in for all the others.  (But in doing so,
it allows all sorts of latex errors.)
The autogenerated dialog could have one line per
parameter, each line having a label and a edit field,
or a combobox in the case of a predefined set of valid values.

Re: Support for environments options ? wishlist idea for a general solution

[Helge Hafting]

Martin Vermeer wrote:

On Sat, Oct 06, 2007 at 11:52:37PM +0200, Tommaso Cucinotta wrote:
  

 Paul A. Rubin ha scritto:

The way I enter an optional argument (when one is allowed) is to open the 
minibuffer (M-x or View -> Toolbars -> Command buffer) and type the command 
'optional-insert'.
  

 Great ! Exactly what I was needing. Probably my fault for not having
 read throughly the user manual. Anyhow, a Insert->Optional argument,
 or Insert->Layout option menu voice would help users in finding this
 wonderful feature, wouldn't it ?

 What about considering the attached addition to the menu file ?

T.



Actually the is an entry like this: "Short title". It has
been criticised for being descriptive only of one use case
(short versions of titles going to the toc), so perhaps
you could come up with a more descriptive name (that 
nevertheless doesn't lead the naive user astray)
  

Can't give you a new name, but an idea that is much more work
to implement. :-( Still, it'd be a nifty thing to have:

* Any layout (paragraph style or text/char style) implemented
 with a latex command or environment should be able to
 specify several arguments (optional and mandatory ones)
 as well as their types. (generic text, generic number, a length,
 or a set of predefined values.) Perhaps a few more. Numbers
 may have constraints, lengths might be glue lengths.

*  When using such a style, defaults are used for all the options. Just
  like what happens when you insert a minipage. If the user right-clicks
  the entity (paragraph or charstyle) then he gets a dialog where the
  parameters can be set withing the constraints of the type.

This concept would support lots of latex constructs, one could even
consider making the minipage a charstyle. :-)  It'd make the
flexible insets/modules much more powerful.

The hard part is those dialogs, that must be auto-generated
from the information in the layout/module. That is why
I suggest a limited amount of "option types", to make it
possible at all. One could start with the "generic text" only,
because it can stand in for all the others.  (But in doing so,
it allows all sorts of latex errors.)
The autogenerated dialog could have one "line" per
parameter, each line having a label and a edit field,
or a combobox in the case of a predefined set of valid values.

Re: [wishlist] server-client-architecture for LyX

[John Weiss]

On Sat, Jan 15, 2005 at 11:45:27AM +0100, Andre Poenitz wrote:
 On Thu, Jan 13, 2005 at 03:28:31PM -0500, Kuba Ober wrote:
  I didn't know LyX was that clean internally. For most other apps
  that would be close to a rewrite of the core parts.
 
 Guess what we did in the 1.4 cycle.

Ain't it great to see the payoff?  :)

-- 
John Weiss

Re: [wishlist] server-client-architecture for LyX

[John Weiss]

On Sat, Jan 15, 2005 at 11:45:27AM +0100, Andre Poenitz wrote:
> On Thu, Jan 13, 2005 at 03:28:31PM -0500, Kuba Ober wrote:
> > I didn't know LyX was that clean internally. For most other apps
> > that would be close to a rewrite of the core parts.
> 
> Guess what we did in the 1.4 cycle.

Ain't it great to see the payoff?  :)

-- 
John Weiss

Re: [wishlist] server-client-architecture for LyX

[Kuba Ober]

 I rather think it is the user interface parts that need work in
 such a case.  The core shouldn't really see the difference between
 two users updating one document, or one user moving
 rapidly back and forth doing modifications in two places. :-)

Makes sense.

Kuba

Re: [wishlist] server-client-architecture for LyX

[Andreas Vox]

Kuba Ober [EMAIL PROTECTED] writes:

 
  I rather think it is the user interface parts that need work in
  such a case.  The core shouldn't really see the difference between
  two users updating one document, or one user moving
  rapidly back and forth doing modifications in two places. 
 
 Makes sense.

I still don't see how that will work if users hit the undo button.
Will they undo their last own action or the last action any of them
did?

/Andreas

Re: [wishlist] server-client-architecture for LyX

[Kuba Ober]

On wtorek 18 stycze 2005 08:49 am, Andreas Vox wrote:
 Kuba Ober [EMAIL PROTECTED] writes:
   I rather think it is the user interface parts that need work in
   such a case.  The core shouldn't really see the difference between
   two users updating one document, or one user moving
   rapidly back and forth doing modifications in two places.
 
  Makes sense.

 I still don't see how that will work if users hit the undo button.
 Will they undo their last own action or the last action any of them
 did?

Without special provisions in the core, they would undo the globally most 
recent action.

Methinks the core has to associate a couple of stately* things with each 
client. Undo history being one of them.

Cheers, Kuba

*) pun intended

Re: [wishlist] server-client-architecture for LyX

[Andreas Vox]

Kuba Ober [EMAIL PROTECTED] writes:

 
 Without special provisions in the core, they would undo the globally most 
 recent action.

Not nice but simple and save.

 
 Methinks the core has to associate a couple of stately* things with each 
 client. Undo history being one of them.

And the undo histories of the clients would be related, so that if two users
edit the same paragraph, like A changes P, B changes P, A undoes, there is 
a clear strategy how this conflict is resolved? 
I think that's quite challenging. It would be easier if LyX already had 
unordered undo/redo.

Ciao
/Andreas

Re: [wishlist] server-client-architecture for LyX

[Kuba Ober]

> I rather think it is the user interface parts that need work in
> such a case.  The core shouldn't really see the difference between
> two users updating one document, or one user moving
> rapidly back and forth doing modifications in two places. :-)

Makes sense.

Kuba

Re: [wishlist] server-client-architecture for LyX

[Andreas Vox]

Kuba Ober <[EMAIL PROTECTED]> writes:

> 
> > I rather think it is the user interface parts that need work in
> > such a case.  The core shouldn't really see the difference between
> > two users updating one document, or one user moving
> > rapidly back and forth doing modifications in two places. 
> 
> Makes sense.

I still don't see how that will work if users hit the undo button.
Will they undo their last own action or the last action any of them
did?

/Andreas

Re: [wishlist] server-client-architecture for LyX

[Kuba Ober]

On wtorek 18 styczeÅ 2005 08:49 am, Andreas Vox wrote:
> Kuba Ober <[EMAIL PROTECTED]> writes:
> > > I rather think it is the user interface parts that need work in
> > > such a case.  The core shouldn't really see the difference between
> > > two users updating one document, or one user moving
> > > rapidly back and forth doing modifications in two places.
> >
> > Makes sense.
>
> I still don't see how that will work if users hit the undo button.
> Will they undo their last own action or the last action any of them
> did?

Without special provisions in the core, they would undo the globally most 
recent action.

Methinks the core has to associate a couple of stately* things with each 
client. Undo history being one of them.

Cheers, Kuba

*) pun intended

Re: [wishlist] server-client-architecture for LyX

[Andreas Vox]

Kuba Ober <[EMAIL PROTECTED]> writes:

> 
> Without special provisions in the core, they would undo the globally most 
> recent action.

Not nice but simple and save.

> 
> Methinks the core has to associate a couple of stately* things with each 
> client. Undo history being one of them.

And the undo histories of the clients would be related, so that if two users
edit the same paragraph, like "A changes P, B changes P, A undoes", there is 
a clear strategy how this conflict is resolved? 
I think that's quite challenging. It would be easier if LyX already had 
unordered undo/redo.

Ciao
/Andreas

Re: [wishlist] server-client-architecture for LyX

[John Weiss]

On Fri, Jan 14, 2005 at 10:53:52AM +0100, Lars Gullik Bjønnes wrote:
 I'll describe it as a change in viewpoint: instead of having the core
 call the frontend (sounds a bit backwards, right?), we change it so
 that it is the frontend that calls the core.
 
 My vision is that the core is almost just a library that the
 frontend calls into.

A Fine Idea.  I approve wholeheartedly.


(Not that you needed my approval. ;) ) 

-- 
John Weiss

Re: [wishlist] server-client-architecture for LyX

[Andre Poenitz]

On Thu, Jan 13, 2005 at 03:28:31PM -0500, Kuba Ober wrote:
 I didn't know LyX was that clean internally. For most other apps that would 
 be 
 close to a rewrite of the core parts.

Guess what we did in the 1.4 cycle.

Andre'

Re: [wishlist] server-client-architecture for LyX

[John Weiss]

On Fri, Jan 14, 2005 at 10:53:52AM +0100, Lars Gullik Bjønnes wrote:
> I'll describe it as a change in viewpoint: instead of having the core
> call the frontend (sounds a bit backwards, right?), we change it so
> that it is the frontend that calls the core.
> 
> My "vision" is that the core is almost just a library that the
> frontend calls into.

A Fine Idea.  I approve wholeheartedly.


(Not that you needed my approval. ;) ) 

-- 
John Weiss

Re: [wishlist] server-client-architecture for LyX

[Andre Poenitz]

On Thu, Jan 13, 2005 at 03:28:31PM -0500, Kuba Ober wrote:
> I didn't know LyX was that clean internally. For most other apps that would 
> be 
> close to a rewrite of the core parts.

Guess what we did in the 1.4 cycle.

Andre'

Re: [wishlist] server-client-architecture for LyX

[Lars Gullik Bjønnes]

Kuba Ober [EMAIL PROTECTED] writes:

 | I think we could have saved some time, if we were able to work both on a
 | single document at the same time. So I  propose a
 | server-client-architecture for LyX that works in the same way as the
 | team modus of starcraft. One opens a server with the document to edit
 | and other people connect. This could also be usefull for visualisation if
 | you want to discuss with a remote person.

 Actaully this wouldn't be _that_ hard, it is all about having a nice
 protocol between the gui and the core. I guess I could do it in a
 week. This also fits quite well with some other cleanup that I'd
 really like to do, but there are problems as well... security is one.

| Man, if you can do it in a week and it works then I'm donating a case of good 
| beer (or a monetary equivalent) to the cause (seriously).

| I didn't know LyX was that clean internally. For most other apps that would 
be 
| close to a rewrite of the core parts.

Perhaps I am a bit too optimistic :-)

The main work (before splitting in a server and client) would be to
change the interface between core and the frontends, turn it around
so to speak. This is something I have been wanting to do anyway...

We are not that squeaky clean internally, but the core/gui separation
is pretty good.

-- 
Lgb

Re: [wishlist] server-client-architecture for LyX

[Angus Leeming]

Lars Gullik Bjønnes wrote:
 | I didn't know LyX was that clean internally. For most other apps that
 | would be close to a rewrite of the core parts.
 
 Perhaps I am a bit too optimistic :-)
 
 The main work (before splitting in a server and client) would be to
 change the interface between core and the frontends, turn it around
 so to speak. This is something I have been wanting to do anyway...

Can you expand? It's always good to hear grand visions for the future.

-- 
Angus

Re: [wishlist] server-client-architecture for LyX

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| Lars Gullik Bjønnes wrote:
 | I didn't know LyX was that clean internally. For most other apps that
 | would be close to a rewrite of the core parts.
 
 Perhaps I am a bit too optimistic :-)
 
 The main work (before splitting in a server and client) would be to
 change the interface between core and the frontends, turn it around
 so to speak. This is something I have been wanting to do anyway...

| Can you expand? It's always good to hear grand visions for the future.

I'll describe it as a change in viewpoint: instead of having the core
call the frontend (sounds a bit backwards, right?), we change it so
that it is the frontend that calls the core.

My vision is that the core is almost just a library that the
frontend calls into.

-- 
Lgb

Re: [wishlist] server-client-architecture for LyX

[Helge Hafting]

Kuba Ober wrote:
Man, if you can do it in a week and it works then I'm donating a case 
of good

beer (or a monetary equivalent) to the cause (seriously).
I didn't know LyX was that clean internally. For most other apps that would be 
close to a rewrite of the core parts.

 

I rather think it is the user interface parts that need work in
such a case.  The core shouldn't really see the difference between
two users updating one document, or one user moving
rapidly back and forth doing modifications in two places. :-)
Helge Hafting

Re: [wishlist] server-client-architecture for LyX

[Lars Gullik Bjønnes]

Helge Hafting [EMAIL PROTECTED] writes:

| Kuba Ober wrote:

 Man, if you can do it in a week and it works then I'm donating a
 case of good

beer (or a monetary equivalent) to the cause (seriously).

 I didn't know LyX was that clean internally. For most other apps
 that would be close to a rewrite of the core parts.


| I rather think it is the user interface parts that need work in
| such a case.  The core shouldn't really see the difference between
| two users updating one document, or one user moving
| rapidly back and forth doing modifications in two places. :-)

But we don't want it implemented like that. (I think)

-- 
Lgb

Re: [wishlist] server-client-architecture for LyX

[Lars Gullik Bjønnes]

Kuba Ober <[EMAIL PROTECTED]> writes:

>> | I think we could have saved some time, if we were able to work both on a
>> | single document at the same time. So I  propose a
>> | server-client-architecture for LyX that works in the same way as the
>> | "team modus" of starcraft. One opens a server with the document to edit
>> | and other people connect. This could also be usefull for visualisation if
>> | you want to discuss with a remote person.
>>
>> Actaully this wouldn't be _that_ hard, it is all about having a nice
>> protocol between the gui and the core. I guess I could do it in a
>> week. This also fits quite well with some other cleanup that I'd
>> really like to do, but there are problems as well... security is one.
>
| Man, if you can do it in a week and it works then I'm donating a case of good 
| beer (or a monetary equivalent) to the cause (seriously).
>
| I didn't know LyX was that clean internally. For most other apps that would 
be 
| close to a rewrite of the core parts.

Perhaps I am a bit too optimistic :-)

The main work (before splitting in a server and client) would be to
change the interface between "core" and the frontends, turn it around
so to speak. This is something I have been wanting to do anyway...

We are not that squeaky clean internally, but the core/gui separation
is pretty good.

-- 
Lgb

Re: [wishlist] server-client-architecture for LyX

[Angus Leeming]

Lars Gullik Bjønnes wrote:
> | I didn't know LyX was that clean internally. For most other apps that
> | would be close to a rewrite of the core parts.
> 
> Perhaps I am a bit too optimistic :-)
> 
> The main work (before splitting in a server and client) would be to
> change the interface between "core" and the frontends, turn it around
> so to speak. This is something I have been wanting to do anyway...

Can you expand? It's always good to hear grand visions for the future.

-- 
Angus

Re: [wishlist] server-client-architecture for LyX

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
>> | I didn't know LyX was that clean internally. For most other apps that
>> | would be close to a rewrite of the core parts.
>> 
>> Perhaps I am a bit too optimistic :-)
>> 
>> The main work (before splitting in a server and client) would be to
>> change the interface between "core" and the frontends, turn it around
>> so to speak. This is something I have been wanting to do anyway...
>
| Can you expand? It's always good to hear grand visions for the future.

I'll describe it as a change in viewpoint: instead of having the core
call the frontend (sounds a bit backwards, right?), we change it so
that it is the frontend that calls the core.

My "vision" is that the core is almost just a library that the
frontend calls into.

-- 
Lgb

Re: [wishlist] server-client-architecture for LyX

[Helge Hafting]

Kuba Ober wrote:
Man, if you can do it in a week and it works then I'm donating a case 
of good

beer (or a monetary equivalent) to the cause (seriously).
I didn't know LyX was that clean internally. For most other apps that would be 
close to a rewrite of the core parts.

 

I rather think it is the user interface parts that need work in
such a case.  The core shouldn't really see the difference between
two users updating one document, or one user moving
rapidly back and forth doing modifications in two places. :-)
Helge Hafting

Re: [wishlist] server-client-architecture for LyX

[Lars Gullik Bjønnes]

Helge Hafting <[EMAIL PROTECTED]> writes:

| Kuba Ober wrote:
>
>> Man, if you can do it in a week and it works then I'm donating a
>> case of good
>>
>>beer (or a monetary equivalent) to the cause (seriously).
>>
>> I didn't know LyX was that clean internally. For most other apps
>> that would be close to a rewrite of the core parts.
>>
>>
| I rather think it is the user interface parts that need work in
| such a case.  The core shouldn't really see the difference between
| two users updating one document, or one user moving
| rapidly back and forth doing modifications in two places. :-)

But we don't want it implemented like that. (I think)

-- 
Lgb

[wishlist] server-client-architecture for LyX

[Tobias Spranger]

Hello,

last year a colleague and me had to write a script for my professor. So we 
took our laptops, and wrote the script during the lesson. Of course, we used 
LyX for text and formulas and xfig for graphs! My colleague was an faster 
typer, so he typed text and me made formulaes and graphs. Our prof was amazed 
with our speed and quality. And we could earn some money and play starcraft 
at the same time ;-). But we could have played even longer. Our main problem 
was that it took a lot of time to set my formulaes and graphs in his text. 

I think we could have saved some time, if we were able to work both on a 
single document at the same time. So I  propose a server-client-architecture 
for LyX that works in the same way as the team modus of starcraft. One 
opens a server with the document to edit and other people connect. This could 
also be usefull for visualisation if you want to discuss with a remote 
person.

I have looked in LyX Wanted Features list and found better LyXServer 
support but it doesn't seem that this server is already an implementation of 
my thought. Unforunately I couldn't find any doku about the LyXServer.

There are other things I would find very comfortable:
- FindReplace for Formulas
- CopyPaste between diffent instances of LyX or at least multiple windows for 
one instance
- a LyX Plug-In for Konqueror would be great
- especialy to wirte for a LyX-Wiki
- an (optional) Vim-Mode would be even better  

Desprite of that, LyX is already a great peace of software! Thank you very 
much!

Tobi

Re: [wishlist] server-client-architecture for LyX

[Lars Gullik Bjønnes]

Tobias Spranger [EMAIL PROTECTED] writes:

| Hello,

| I think we could have saved some time, if we were able to work both on a 
| single document at the same time. So I  propose a server-client-architecture 
| for LyX that works in the same way as the team modus of starcraft. One 
| opens a server with the document to edit and other people connect.
| This could also be usefull for visualisation if you want to discuss
| with a remote person.

Actaully this wouldn't be _that_ hard, it is all about having a nice
protocol between the gui and the core. I guess I could do it in a
week. This also fits quite well with some other cleanup that I'd
really like to do, but there are problems as well... security is one.

-- 
Lgb

Re: [wishlist] server-client-architecture for LyX

[Angus Leeming]

Lars Gullik Bjønnes wrote:
 Actaully this wouldn't be _that_ hard, it is all about having a nice
 protocol between the gui and the core. I guess I could do it in a
 week. This also fits quite well with some other cleanup that I'd
 really like to do, but there are problems as well... security is one.

I'm sure that this is only one part of the whole, but have you had a look
at http://giallo.sourceforge.net/ for a library to handle the sockets or
named pipes in a platform independent way? My understanding is that this
is slated to become Boost.Sockets eventually.

-- 
Angus

Re: [wishlist] server-client-architecture for LyX

[Andreas Vox]

Lars Gullik Bjnnes [EMAIL PROTECTED] writes:

 
 Tobias Spranger [EMAIL PROTECTED] writes:
 
 | Hello,
 
 | I think we could have saved some time, if we were able to work both on a 
 | single document at the same time. So I  propose a 
server-client-architecture 
 | for LyX that works in the same way as the team modus of starcraft. One 
 | opens a server with the document to edit and other people connect.
 | This could also be usefull for visualisation if you want to discuss
 | with a remote person.
 
 Actaully this wouldn't be _that_ hard, it is all about having a nice
 protocol between the gui and the core. I guess I could do it in a
 week. 

The week between LyX 1.4.0 final and LyX 2.0 RC1 ?  ;-)

 This also fits quite well with some other cleanup that I'd
 really like to do, but there are problems as well... security is one.


Hmm, maybe we can convince Tobias to try out sharing a LyX instance with
VNC and report to us how that works before you start redesigning LyX.

VNC might be even better than an integrated support because it would also 
share the external programs (eg. XFig) LyX uses.

OTOH it would probably not be possible for two persons to edit at the same time.


Another idea is to extend the version control support of LyX to remote CVS; 
maybe
include a nifty change merger mode like in Eclipse.


Cheers
/Andreas

Re: [wishlist] server-client-architecture for LyX

[Andreas Vox]

Angus Leeming [EMAIL PROTECTED] writes:

 
 Lars Gullik Bjnnes wrote:
  Actaully this wouldn't be _that_ hard, it is all about having a nice
  protocol between the gui and the core. I guess I could do it in a
  week. This also fits quite well with some other cleanup that I'd
  really like to do, but there are problems as well... security is one.
 
 I'm sure that this is only one part of the whole, but have you had a look
 at http://giallo.sourceforge.net/ for a library to handle the sockets or
 named pipes in a platform independent way? My understanding is that this
 is slated to become Boost.Sockets eventually.

Just to keep you going: what do you two plan for the undo function?
A central undo queue on the server which is shared by all users 
or individual queues for each client which are synchronized into a
consistent server state? 

What about the buffer? I think the lyx-paragraphs should be on the 
server but the cursor position at the client (I dont know the current
code too well, maybe they are already separated)

There should be a consensus that all included files must be on the server;
for temporary files it might be necessary to copy them to a client local
/tmp directory which should be a straightforward extension of 
the new Mover.

Well, I think we could have a *lot* of fun with this feature, it would be unfair
if Lars uses it all up in one week ;-)


/Andreas

Re: [wishlist] server-client-architecture for LyX

[Angus Leeming]

Andreas Vox wrote:
 What about the buffer? I think the lyx-paragraphs should be on the
 server but the cursor position at the client (I dont know the current
 code too well, maybe they are already separated)

They are. This is equivalent to having multiple views into the document.
That's something that Alfredo suggested is really close now. Early 1.5.x.

-- 
Angus

Re: [wishlist] server-client-architecture for LyX

[Kuba Ober]

 | I think we could have saved some time, if we were able to work both on a
 | single document at the same time. So I  propose a
 | server-client-architecture for LyX that works in the same way as the
 | team modus of starcraft. One opens a server with the document to edit
 | and other people connect. This could also be usefull for visualisation if
 | you want to discuss with a remote person.

 Actaully this wouldn't be _that_ hard, it is all about having a nice
 protocol between the gui and the core. I guess I could do it in a
 week. This also fits quite well with some other cleanup that I'd
 really like to do, but there are problems as well... security is one.

Man, if you can do it in a week and it works then I'm donating a case of good 
beer (or a monetary equivalent) to the cause (seriously).

I didn't know LyX was that clean internally. For most other apps that would be 
close to a rewrite of the core parts.

Cheers, Kuba

[wishlist] server-client-architecture for LyX

[Tobias Spranger]

Hello,

last year a colleague and me had to write a script for my professor. So we 
took our laptops, and wrote the script during the lesson. Of course, we used 
LyX for text and formulas and xfig for graphs! My colleague was an faster 
typer, so he typed text and me made formulaes and graphs. Our prof was amazed 
with our speed and quality. And we could earn some money and play starcraft 
at the same time ;-). But we could have played even longer. Our main problem 
was that it took a lot of time to set my formulaes and graphs in his text. 

I think we could have saved some time, if we were able to work both on a 
single document at the same time. So I  propose a server-client-architecture 
for LyX that works in the same way as the "team modus" of starcraft. One 
opens a server with the document to edit and other people connect. This could 
also be usefull for visualisation if you want to discuss with a remote 
person.

I have looked in "LyX Wanted Features list" and found "better LyXServer 
support" but it doesn't seem that this server is already an implementation of 
my thought. Unforunately I couldn't find any doku about the LyXServer.

There are other things I would find very comfortable:
- Find for Formulas
- Copy between diffent instances of LyX or at least multiple windows for 
one instance
- a LyX Plug-In for Konqueror would be great
- especialy to wirte for a LyX-Wiki
- an (optional) Vim-Mode would be even better  

Desprite of that, LyX is already a great peace of software! Thank you very 
much!

Tobi

Re: [wishlist] server-client-architecture for LyX

[Lars Gullik Bjønnes]

Tobias Spranger <[EMAIL PROTECTED]> writes:

| Hello,
>
| I think we could have saved some time, if we were able to work both on a 
| single document at the same time. So I  propose a server-client-architecture 
| for LyX that works in the same way as the "team modus" of starcraft. One 
| opens a server with the document to edit and other people connect.
| This could also be usefull for visualisation if you want to discuss
| with a remote person.

Actaully this wouldn't be _that_ hard, it is all about having a nice
protocol between the gui and the core. I guess I could do it in a
week. This also fits quite well with some other cleanup that I'd
really like to do, but there are problems as well... security is one.

-- 
Lgb

Re: [wishlist] server-client-architecture for LyX

[Angus Leeming]

Lars Gullik Bjønnes wrote:
> Actaully this wouldn't be _that_ hard, it is all about having a nice
> protocol between the gui and the core. I guess I could do it in a
> week. This also fits quite well with some other cleanup that I'd
> really like to do, but there are problems as well... security is one.

I'm sure that this is only one part of the whole, but have you had a look
at http://giallo.sourceforge.net/ for a library to handle the sockets or
named pipes in a platform independent way? My understanding is that this
is slated to become Boost.Sockets eventually.

-- 
Angus

Re: [wishlist] server-client-architecture for LyX

[Andreas Vox]

Lars Gullik BjÃnnes <[EMAIL PROTECTED]> writes:

< 
< Tobias Spranger <[EMAIL PROTECTED]> writes:
< 
< | Hello,
< >
< | I think we could have saved some time, if we were able to work both on a 
< | single document at the same time. So I  propose a 
server-client-architecture 
< | for LyX that works in the same way as the "team modus" of starcraft. One 
< | opens a server with the document to edit and other people connect.
< | This could also be usefull for visualisation if you want to discuss
< | with a remote person.
< 
< Actaully this wouldn't be _that_ hard, it is all about having a nice
< protocol between the gui and the core. I guess I could do it in a
< week. 

The week between LyX 1.4.0 final and LyX 2.0 RC1 ?  ;-)

< This also fits quite well with some other cleanup that I'd
< really like to do, but there are problems as well... security is one.
<

Hmm, maybe we can convince Tobias to try out sharing a LyX instance with
VNC and report to us how that works before you start redesigning LyX.

VNC might be even better than an integrated support because it would also 
share the external programs (eg. XFig) LyX uses.

OTOH it would probably not be possible for two persons to edit at the same time.


Another idea is to extend the version control support of LyX to remote CVS; 
maybe
include a nifty change merger mode like in Eclipse.


Cheers
/Andreas

Re: [wishlist] server-client-architecture for LyX

[Andreas Vox]

Angus Leeming <[EMAIL PROTECTED]> writes:

> 
> Lars Gullik BjÃnnes wrote:
> > Actaully this wouldn't be _that_ hard, it is all about having a nice
> > protocol between the gui and the core. I guess I could do it in a
> > week. This also fits quite well with some other cleanup that I'd
> > really like to do, but there are problems as well... security is one.
> 
> I'm sure that this is only one part of the whole, but have you had a look
> at http://giallo.sourceforge.net/ for a library to handle the sockets or
> named pipes in a platform independent way? My understanding is that this
> is slated to become Boost.Sockets eventually.

Just to keep you going: what do you two plan for the undo function?
A central undo queue on the server which is shared by all users 
or individual queues for each client which are synchronized into a
consistent server state? 

What about the buffer? I think the lyx-paragraphs should be on the 
server but the cursor position at the client (I dont know the current
code too well, maybe they are already separated)

There should be a consensus that all included files must be on the server;
for temporary files it might be necessary to copy them to a client local
/tmp directory which should be a straightforward extension of 
the new Mover.

Well, I think we could have a *lot* of fun with this feature, it would be unfair
if Lars uses it all up in one week ;-)


/Andreas

Re: [wishlist] server-client-architecture for LyX

[Angus Leeming]

Andreas Vox wrote:
> What about the buffer? I think the lyx-paragraphs should be on the
> server but the cursor position at the client (I dont know the current
> code too well, maybe they are already separated)

They are. This is equivalent to having multiple views into the document.
That's something that Alfredo suggested is really close now. Early 1.5.x.

-- 
Angus

Re: [wishlist] server-client-architecture for LyX

[Kuba Ober]

> | I think we could have saved some time, if we were able to work both on a
> | single document at the same time. So I  propose a
> | server-client-architecture for LyX that works in the same way as the
> | "team modus" of starcraft. One opens a server with the document to edit
> | and other people connect. This could also be usefull for visualisation if
> | you want to discuss with a remote person.
>
> Actaully this wouldn't be _that_ hard, it is all about having a nice
> protocol between the gui and the core. I guess I could do it in a
> week. This also fits quite well with some other cleanup that I'd
> really like to do, but there are problems as well... security is one.

Man, if you can do it in a week and it works then I'm donating a case of good 
beer (or a monetary equivalent) to the cause (seriously).

I didn't know LyX was that clean internally. For most other apps that would be 
close to a rewrite of the core parts.

Cheers, Kuba

mathed wishlist --- almost supported already?

[Angus Leeming]

Two more wishlist items that appear to be almost officically supported 
already:

1. If I right as normal text \mathcal{B}, highlight it and convert it to math 
with M-c m, I get a nicely typeset B. It'd be nice to do this directly in 
mathed too. I _can_ type \mathcal B  within mathed and the resulting dvi is 
correct, but I don't get the visual feedback.

On the same lines, if I type \mathtt{Angus} and then paste it into mathed: 
beautiful. Do the same within mathed and only the A is typeset. Perhaps 
these font commands should use the macro display mechanism?

2.  This convert normal text to math is great. I can go the other way 
using the X clipboard (ie highlight it and then paste with the middle mouse 
button WITHOUT saving it to LyX's buffer). But this is a fudge of course.

This effectively becomes a TeX mode for mathed, so that I can 
see exactly what I type. It'd be nice if we could toggle officially.

Angus

Re: mathed wishlist --- almost supported already?

[Andre Poenitz]

On Tue, Sep 04, 2001 at 02:44:27PM +0100, Angus Leeming wrote:
 On the same lines, if I type \mathtt{Angus} and then paste it into mathed: 
 beautiful. Do the same within mathed and only the A is typeset. Perhaps 
 these font commands should use the macro display mechanism?

That would be the easy implementation, however it is a pain if you want
glueing, i.e. thing like \mathtt{A}n\mathtt{g} and remove the 'n'...

 2.  This convert normal text to math is great.

Shshsh... nobody knows I sneaked that in...

 I can go the other way using the X clipboard (ie highlight it and then
 paste with the middle mouse button WITHOUT saving it to LyX's buffer).
 But this is a fudge of course.

Sure.
 
 This effectively becomes a TeX mode for mathed, so that I can see
 exactly what I type. It'd be nice if we could toggle officially.

I would have to mess around with stuff outside mathed for that...

Andre'

-- 
André Pönitz . [EMAIL PROTECTED]

mathed wishlist --- almost supported already?

[Angus Leeming]

Two more wishlist items that appear to be "almost" officically supported 
already:

1. If I right as normal text \mathcal{B}, highlight it and convert it to math 
with M-c m, I get a nicely typeset B. It'd be nice to do this directly in 
mathed too. I _can_ type "\mathcal B " within mathed and the resulting dvi is 
correct, but I don't get the visual feedback.

On the same lines, if I type \mathtt{Angus} and then paste it into mathed: 
beautiful. Do the same within mathed and only the "A" is typeset. Perhaps 
these font commands should use the macro display mechanism?

2.  This convert "normal" text to "math" is great. I can go the other way 
using the X clipboard (ie highlight it and then paste with the middle mouse 
button WITHOUT saving it to LyX's buffer). But this is a fudge of course.

This effectively becomes a "TeX" mode for mathed, so that I can 
see exactly what I type. It'd be nice if we could toggle "officially".

Angus