Re: #7273: beamer/sweave issue: need [containsverbatim]

[Guenter Milde]

On 2012-05-30, Jürgen Spitzmüller wrote:
 Guenter Milde wrote:
 Using ERT for options is hackish, too.

 Sure it is. But at least it can be done (with insets, it simply can't, 
 AFAICS).

It is just as easy with insets. E.g. wit the seminar document class, I
could InsertCustom...LandscapeSlide (for a custom inset), drop your
options example into the box, select and convert it to ERT, and add some
content to get in the source view:

  \begin{slide}
  presentation[shrink=.9]{My frame title}
  
  frame content
  \end{slide}

I did not test, whether the whitespace between {slide} and
presentation may pose a problem. However, this whitespace is not
related to inset vs. style but to the LatexType. It is also present in
Styles with LatexType Environment while the standard Beamer frame has
LatexType Command.

As a workaround, we can use the \frame command instead of the frame
environment. (You create a frame using the command \frame or the
environment frame, which do the same. [beameruserguide])


 OTOH, maybe this can be solved with an alternative beamer layout that
 does not use the \lyxframe{} etc. hacks but (like the old seminar
 layout) keepempty Styles for frames with content explicitly nested
 and the EnvironmentSeparator to start a new frame.

 I thought about this solution, too. But can you produce

 \begin{frame}presentation[shrink=.9]{My frame title}
 ...
 \end{frame}

 with this approach without even more ERT?

I think so.

The sane solution would be using the \frametitle and
\framesubtitle macros instead of the very non-LaTeXish 
optional arguments in {}. These are then provided via styles.

The overlay specification is indeed a problem, as its position is *before*
the optional arguments. This means that if an overlay specification is
required, following optional arguments need to be given as ERT, too.

I see two possibilities for proper support in LyX:

a) convince the beamer author to provide an optional keyword argument,
   e.g. visibility. The above could then be written as

 \begin{frame}[visibility=presentation,shrink=.9]
   \frametitle{My frame title}
   ...
 \end{frame}

   which can be achieved with the default support for optional arguments.

b) introduce a new keyword OverlayArgs similar to the OptionalArgs
   or add the option to output an argument in   to the more
   sophisticated support for command/environment arguments envisaged for
   the future (http://www.lyx.org/trac/ticket/6753), like
   
 Argument
Typeoverlay
LabelString Overlay Specification
 EndArgument
   

 I think creating a less hackish beamer layout (or both, a simplified
 Style based and an inset based one) is a step forward. It offers the
 chance to try concepts and to spot requirements on the way to a user
 friendly frame UI. But also for real work on a beamer presentation, I
 know that I will start with writing a new beamer layout.

 I wonder if the time would not be better invested in writing a decent 
 InsetSlide from scratch. 

Only for someone familiar with LyX's C sources (i.e. not me).

 An inset with two cells (the upper for the frame title, the lower for
 the content) and a dialog to set the options and overlay 
 specifications, which integrates with the outliner etc. is what I could
 imagine as a good UI.

This is a very much beamer specific specification.  In my view, it is
important to consider all types of presentation/transparency
document classes as well as HTML presentations. I rather think of it as a
container inset. (The new inset should also care for Proofs, Theorems
and Lemmas -- otherwise it's time to re-open the ten year old bug 341.)

In my view, e.g., it fits better into the LyX UI and is far more
versatile when we use a FrameTitle (or SlideHeading ...) style
instead of a box with two cells.

An option dialogue is useful for many other commands and environments
(and in both, insets and styles) so this should be part of a more generic
approach (http://www.lyx.org/trac/ticket/6753), too. 

Thanks,

Günter

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Liviu Andronic]

On Wed, May 30, 2012 at 8:54 AM, Jürgen Spitzmüller sp...@lyx.org wrote:
 Jean-Marc Lasgouttes wrote:
 Concerning the module itself, I do not see why it is not in beamer.layout:

 * either the code is good enough and we support it in beamer.layout
 * or the code is too hackish and we should not IMO distribute it
 directly. It could nevertheless be put on the wiki.

 I'd tend towards the latter.

To get back to the original inquiry, I think we all agree that the
module shouldn't be merged with beamer.layout. So, does it go in
branch, or do I publish it on the wiki?

Liviu

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Guenter Milde]

On 2012-05-30, Jürgen Spitzmüller wrote:
> Guenter Milde wrote:
>> Using ERT for options is hackish, too.

> Sure it is. But at least it can be done (with insets, it simply can't, 
> AFAICS).

It is just as easy with insets. E.g. wit the "seminar" document class, I
could Insert>Custom...>LandscapeSlide (for a custom inset), drop your
options example into the box, select and convert it to ERT, and add some
content to get in the source view:

  \begin{slide}
  [shrink=.9]{My frame title}
  
  frame content
  \end{slide}

I did not test, whether the whitespace between "{slide}" and
"" may pose a problem. However, this whitespace is not
related to inset vs. style but to the LatexType. It is also present in
Styles with LatexType "Environment" while the standard Beamer frame has
LatexType "Command".

As a workaround, we can use the \frame command instead of the "frame"
environment. ("You create a frame using the command \frame or the
environment frame, which do the same." [beameruserguide])


>> OTOH, maybe this can be solved with an alternative beamer layout that
>> does not use the \lyxframe{} etc. hacks but (like the old seminar
>> layout) "keepempty" Styles for frames with content explicitly nested
>> and the EnvironmentSeparator to start a new frame.

> I thought about this solution, too. But can you produce

> \begin{frame}[shrink=.9]{My frame title}
> ...
> \end{frame}

> with this approach without even more ERT?

I think so.

The sane solution would be using the \frametitle and
\framesubtitle macros instead of the very non-LaTeXish 
optional arguments in {}. These are then provided via styles.

The overlay specification is indeed a problem, as its position is *before*
the optional arguments. This means that if an overlay specification is
required, following optional arguments need to be given as ERT, too.

I see two possibilities for proper support in LyX:

a) convince the beamer author to provide an optional keyword argument,
   e.g. "visibility". The above could then be written as

 \begin{frame}[visibility=presentation,shrink=.9]
   \frametitle{My frame title}
   ...
 \end{frame}

   which can be achieved with the default support for optional arguments.

b) introduce a new keyword "OverlayArgs" similar to the "OptionalArgs"
   or add the option to output an argument in "< >" to the more
   sophisticated support for command/environment arguments envisaged for
   the future (http://www.lyx.org/trac/ticket/6753), like
   
 Argument
Typeoverlay
LabelString "Overlay Specification"
 EndArgument
   

>> I think creating a less hackish beamer layout (or both, a simplified
>> Style based and an inset based one) is a step forward. It offers the
>> chance to try concepts and to spot requirements on the way to a user
>> friendly frame UI. But also for real work on a beamer presentation, I
>> know that I will start with writing a new beamer layout.

> I wonder if the time would not be better invested in writing a decent 
> InsetSlide from scratch. 

Only for someone familiar with LyX's C sources (i.e. not me).

> An inset with two cells (the upper for the frame title, the lower for
> the content) and a dialog to set the options and overlay 
> specifications, which integrates with the outliner etc. is what I could
> imagine as a good UI.

This is a very much "beamer specific" specification.  In my view, it is
important to consider all types of presentation/transparency
document classes as well as HTML presentations. I rather think of it as a
"container inset". (The new inset should also care for Proofs, Theorems
and Lemmas -- otherwise it's time to re-open the ten year old bug 341.)

In my view, e.g., it fits better into the LyX UI and is far more
versatile when we use a "FrameTitle" (or "SlideHeading" ...) style
instead of a box with two cells.

An option dialogue is useful for many other commands and environments
(and in both, insets and styles) so this should be part of a more generic
approach (http://www.lyx.org/trac/ticket/6753), too. 

Thanks,

Günter

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Liviu Andronic]

On Wed, May 30, 2012 at 8:54 AM, Jürgen Spitzmüller  wrote:
> Jean-Marc Lasgouttes wrote:
>> Concerning the module itself, I do not see why it is not in beamer.layout:
>>
>> * either the code is good enough and we support it in beamer.layout
>> * or the code is too hackish and we should not IMO distribute it
>> directly. It could nevertheless be put on the wiki.
>
> I'd tend towards the latter.
>
To get back to the original inquiry, I think we all agree that the
module shouldn't be merged with beamer.layout. So, does it go in
branch, or do I publish it on the wiki?

Liviu

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Liviu Andronic]

On Tue, May 29, 2012 at 11:18 PM, Jean-Marc Lasgouttes
lasgout...@lyx.org wrote:
 Le 29/05/2012 10:55, Liviu Andronic a écrit :

 I fail to see how #8041 and #7273 are related, if at all. Uwe?

 I also think there is no relation.

Good, I'm not the only one.


 Concerning the module itself, I do not see why it is not in beamer.layout:

 * either the code is good enough and we support it in beamer.layout
 * or the code is too hackish and we should not IMO distribute it directly.
 It could nevertheless be put on the wiki.

In my (evolved) view the module itself is a clean implementation. It
could be better in case #6753 were addressed, but as current
infrastructure goes it is fine.

One may argue that it is a hackish implementation wrt beamer.layout
since it takes a different approach: Beamer's regular frames are
handled via LyX environments, while the module's fragile frames are
provided via custom insets. But I would argue that beamer.layout
itself is a big hack. It uses intricate preamble definitions:
Preamble
\long\def\lyxframe#1{\@lyxframe#1\@lyxframestop}%
\def\@lyxframe{\@ifnextchar{\@@lyxframe}{\@@lyxframe*}}%
\def\@@lyxframe#1{\@ifnextchar[{\@@@lyxframe#1}{\@@@lyxframe#1[]}}

\def\@@@lyxframe#1[{\@ifnextchar{\@lyxframe#1[}{\lyxframe#1[*][}}

\def\@lyxframe#1[#2]{\@ifnextchar[{\lyxframe#1[#2]}{\lyxframe#1[#2][]}}
\long\def\lyxframe#1[#2][#3]#4\@lyxframestop#5\lyxframeend{%
  \frame#1[#2][#3]{\frametitle{#4}#5}}
  EndPreamble

and perfectly non-standard LaTeX commands:
\lyxframeend{}\lyxframe{}

In contrast, the module simply uses native LaTeX constructs:
\begin{frame}[fragile]
\frametitle{}
\end{frame}

In this sense the layout and the module take different approaches, and
the two shouldn't simply be merged.

Given the above I would suggest that we better, if possible given
current infrastructure, fix beamer.layout to use native LaTeX
constructs instead of the current hacks. (Of course, this is likely a
job for 2.1.) Basically I propose that we bring beamer.layout more in
line with #7624, a new-generation layout for seminar.cls. And in both
cases fixing #7877 would help.

In my own experience, using custom insets for the Beamer frames is
preferable to the current UI-layout. The insets provide a visual,
clearly defined boundary of a frame, and would provide a first step
towards a 'presentation mode' in LyX [1]. Moreover I tend to get less
lost in my own document when it contains a handful of fragile insets:
the Beamer frames are much easier to identify. The only drawback with
using insets is that they're slightly more difficult to insert, but
this could be easily solved by fixing #7877.

Opinions welcome. Regards
Liviu

[1] http://wiki.lyx.org/Devel/SummerOfCode2011Ideas#toc3

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Jürgen Spitzmüller]

Liviu Andronic wrote:
 The only drawback with
 using insets is that they're slightly more difficult to insert, but
 this could be easily solved by fixing #7877.

* They do not work with the outliner (i.e. you cannot easily move frames with 
the outliner, which is an important feature IMHO).

* You cannot add custom options such as \begin{frame}[shrink=.9] or 
\begin{frame}presentation[+-] with the custom inset approach, can you?

I agree that the current layout solution is a hack, but either we need a much 
more sophisticated inset for frames, or we need to go for a different 
approach.

Jürgen

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
 Concerning the module itself, I do not see why it is not in beamer.layout:
 
 * either the code is good enough and we support it in beamer.layout
 * or the code is too hackish and we should not IMO distribute it 
 directly. It could nevertheless be put on the wiki.

I'd tend towards the latter. An approach which needs its own custom inset for 
each and every option of the frame environment just does not look sane. And 
mixing insets/layouts for the same concept does not look sane either (I have 
elaborated in my other post why I think a switch to insets is not the way to 
go [at least with the current limitations of the insets]).

The beamer class simply goes beyond our current UI. Someone would need to sit 
down, take a deep breath and then design a unser interface which really fits 
beamer (and powerdot, for that matter).

Jürgen

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Guenter Milde]

On 2012-05-30, Jürgen Spitzmüller wrote:
 Liviu Andronic wrote:
 The only drawback with
 using insets is that they're slightly more difficult to insert, but
 this could be easily solved by fixing #7877.

 * They do not work with the outliner (i.e. you cannot easily move
   frames with the outliner, which is an important feature IMHO).



 * You cannot add custom options such as \begin{frame}[shrink=.9] or 
   \begin{frame}presentation[+-] with the custom inset approach, can
   you?

I know you can insert options like [shrink=.9] as InsertShort Title
(only LyX insiders will find it under this name). How do you insert
presentation with a frame Style?

 I agree that the current layout solution is a hack, but either we need
 a much more sophisticated inset for frames, or we need to go for a
 different approach.

I still favour the frames as insets approach. 

Ideal for Definitions Theorems and Proofs (amsmath), presentation frames
(seminar, powerdot, beamer), poster-boxes (a0poster) and similar
environments, would be a block inset, a mixture of the current
Style and Inset layout elements:

* Represents a LaTeX environment or HTML block-level element.

* Is not a paragraph style but a container at paragraph level
  (while current insets are inline elements).
  Content is nested (by default as a Standard style
  paragraph).

* Consecutive elements of same type are not merged into one environment
  (the main problem with current Styles, see
  http://www.lyx.org/trac/ticket/341),
  
* The LyX GUI draws a box around the content, moving in and out is done
  as in other Insets.

* Accepts the OptionalArgs and RequiredArgs keywords (actually, this
  should be possible for all custom insets),

* Can be moved around with the outliner.

I don't think that this is much more sophisticated -- all building
blocks are already there.

Günter

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Liviu Andronic]

On Wed, May 30, 2012 at 8:35 AM, Jürgen Spitzmüller sp...@lyx.org wrote:
 Liviu Andronic wrote:
 The only drawback with
 using insets is that they're slightly more difficult to insert, but
 this could be easily solved by fixing #7877.

 * They do not work with the outliner (i.e. you cannot easily move frames with
 the outliner, which is an important feature IMHO).

In my module you get frames in the outliner when you add a frame title
(because the latter is a Style). But indeed this doesn't cover moving
a frame using the outliner. Perhaps this would be easily possible if
custom insets had a 'outline' option, allowing them to be included in
the outliner : worth a feature request.


 * You cannot add custom options such as \begin{frame}[shrink=.9] or
 \begin{frame}presentation[+-] with the custom inset approach, can you?

In theory Styles support adding options via InsertShort Title, but
this doesn't work with the Beamer frame Styles. Beamer.layout uses
\lyxframe{} commands, which use \begin{frame} only internally. So
options like [fragile] cannot be passed with the current setup. If it
were possible, then my entire module would be perfectly unnecessary.
Please correct me if I'm wrong.


 I agree that the current layout solution is a hack, but either we need a much
 more sophisticated inset for frames, or we need to go for a different
 approach.

I agree that for a good implementation we need an upgraded version of
custom insets, but as Guenter suggested it doesn't require someting
radical: most of the functionality is already there.


On Wed, May 30, 2012 at 8:54 AM, Jürgen Spitzmüller sp...@lyx.org wrote:
 Jean-Marc Lasgouttes wrote:
 Concerning the module itself, I do not see why it is not in beamer.layout:

 * either the code is good enough and we support it in beamer.layout
 * or the code is too hackish and we should not IMO distribute it
 directly. It could nevertheless be put on the wiki.

 I'd tend towards the latter. An approach which needs its own custom inset for
 each and every option of the frame environment just does not look sane. And

This is the status-quo in beamer.layout: for each and every option of
the frame environment you need a new frame Style. The very reason for
my coming up with this module.


 mixing insets/layouts for the same concept does not look sane either (I have

Yes, this is a bit problematic. This is why I don't think that the
module definitions should be merged with the beamer.layout.

Regards
Liviu


 elaborated in my other post why I think a switch to insets is not the way to
 go [at least with the current limitations of the insets]).

 The beamer class simply goes beyond our current UI. Someone would need to sit
 down, take a deep breath and then design a unser interface which really fits
 beamer (and powerdot, for that matter).

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Jürgen Spitzmüller]

Guenter Milde wrote:
 I know you can insert options like [shrink=.9] as InsertShort Title
 (only LyX insiders will find it under this name). 

Can you? AFAIK InsetLayout does not yet support optional arguments.

 How do you insert
 presentation with a frame Style?

Via ERT immediately after the label.

  I agree that the current layout solution is a hack, but either we need
  a much more sophisticated inset for frames, or we need to go for a
  different approach.
 
 I still favour the frames as insets approach.
 
 Ideal for Definitions Theorems and Proofs (amsmath), presentation frames
 (seminar, powerdot, beamer), poster-boxes (a0poster) and similar
 environments, would be a block inset, a mixture of the current
 Style and Inset layout elements:
 
 * Represents a LaTeX environment or HTML block-level element.
 
 * Is not a paragraph style but a container at paragraph level
   (while current insets are inline elements).
   Content is nested (by default as a Standard style
   paragraph).
 
 * Consecutive elements of same type are not merged into one environment
   (the main problem with current Styles, see
   http://www.lyx.org/trac/ticket/341),
 
 * The LyX GUI draws a box around the content, moving in and out is done
   as in other Insets.
 
 * Accepts the OptionalArgs and RequiredArgs keywords (actually, this
   should be possible for all custom insets),
 
 * Can be moved around with the outliner.
 
 I don't think that this is much more sophisticated -- all building
 blocks are already there.

This is not far away from what I have in mind (I would add that frame title 
insertion should be somewhat intuitive). But we do not have it. If you think 
you can put it together easily, go ahead! But until all this is possible, 
custom insets for frames is a step backwards.

Jürgen

 Günter

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Jürgen Spitzmüller]

Liviu Andronic wrote:
 In my module you get frames in the outliner when you add a frame title
 (because the latter is a Style). But indeed this doesn't cover moving
 a frame using the outliner. Perhaps this would be easily possible if
 custom insets had a 'outline' option, allowing them to be included in
 the outliner : worth a feature request.

Yes, that's what I mean. I would rate this a must-have before insets of any 
kind can replace the current hack.

  * You cannot add custom options such as \begin{frame}[shrink=.9] or
  \begin{frame}presentation[+-] with the custom inset approach, can you?
 
 In theory Styles support adding options via InsertShort Title, but
 this doesn't work with the Beamer frame Styles. Beamer.layout uses
 \lyxframe{} commands, which use \begin{frame} only internally. So
 options like [fragile] cannot be passed with the current setup. If it
 were possible, then my entire module would be perfectly unnecessary.
 Please correct me if I'm wrong.

It's only correct for fragile options, because the lyxframe definition chokes 
on those. Any other option can be passed via ERT, both the overlay 
specifications (...) and the real options ([...]), in all combinations. 
See the beamerlyxexample1.lyx example file for some applications.

  I agree that the current layout solution is a hack, but either we need a
  much more sophisticated inset for frames, or we need to go for a
  different approach.
 
 I agree that for a good implementation we need an upgraded version of
 custom insets, but as Guenter suggested it doesn't require someting
 radical: most of the functionality is already there.

Fact is, it's not there. It needs to be implemented. It might be trivial in 
some cases, more tricky in others. But it needs to be done. With the current 
state of the art, insets are just not ready for this task yet.

I would think that a good UI would just need some more thought. And I think it 
would be worth investigating some time and establishing a real intuitive frame 
UI rather than putting together something that works somehow for some 
limited use cases.

Jürgen

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Guenter Milde]

On 2012-05-30, Jürgen Spitzmüller wrote:
 Liviu Andronic wrote:
 In my module you get frames in the outliner when you add a frame title
 (because the latter is a Style). But indeed this doesn't cover moving
 a frame using the outliner. Perhaps this would be easily possible if
 custom insets had a 'outline' option, allowing them to be included in
 the outliner : worth a feature request.

 Yes, that's what I mean. I would rate this a must-have before insets of any 
 kind can replace the current hack.

As I never used the outliner, I consider this less important than the issues
with the current beamer layout.


  * You cannot add custom options such as \begin{frame}[shrink=.9] or
  \begin{frame}presentation[+-] with the custom inset approach, can you?

 In theory Styles support adding options via InsertShort Title, but
 this doesn't work with the Beamer frame Styles. Beamer.layout uses
 \lyxframe{} commands, which use \begin{frame} only internally. So
 options like [fragile] cannot be passed with the current setup. If it
 were possible, then my entire module would be perfectly unnecessary.
 Please correct me if I'm wrong.

 It's only correct for fragile options, because the lyxframe definition
 chokes on those. Any other option can be passed via ERT, both the
 overlay specifications (...) and the real options ([...]), in all
 combinations.  See the beamerlyxexample1.lyx example file for some
 applications.

Using ERT for options is hackish, too. OTOH, maybe this can be solved
with an alternative beamer layout that does not use the \lyxframe{} etc.
hacks but (like the old seminar layout) keepempty Styles for frames
with content explicitely nested and the EnvironmentSeparator to start a
new frame.

For people using the Outliner, this might be preferable to an inset-based
layout.

...
 With the current state of the art, insets are just not ready for this
 task yet.

 I would think that a good UI would just need some more thought. And I
 think it would be worth investigating some time and establishing a real
 intuitive frame UI rather than putting together something that works
 somehow for some limited use cases.

I think creating a less hackish beamer layout (or both, a simplified
Style based and an inset based one) is a step forward. It offers the
chance to try concepts and to spot requirements on the way to a user
friendly frame UI. But also for real work on a beamer presentation, I
know that I will start with writing a new beamer layout.

However, as (hopefully) this will only be a temporary solution, I agree that
the better place for such an alternative beamer layout is the wiki.

Günter

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Jürgen Spitzmüller]

Guenter Milde wrote:
 Using ERT for options is hackish, too.

Sure it is. But at least it can be done (with insets, it simply can't, 
AFAICS).

 OTOH, maybe this can be solved
 with an alternative beamer layout that does not use the \lyxframe{} etc.
 hacks but (like the old seminar layout) keepempty Styles for frames
 with content explicitely nested and the EnvironmentSeparator to start a
 new frame.

I thought about this solution, too. But can you produce

\begin{frame}presentation[shrink=.9]{My frame title}
...
\end{frame}

with this approach without even more ERT?

 I think creating a less hackish beamer layout (or both, a simplified
 Style based and an inset based one) is a step forward. It offers the
 chance to try concepts and to spot requirements on the way to a user
 friendly frame UI. But also for real work on a beamer presentation, I
 know that I will start with writing a new beamer layout.

I wonder if the time would not be better invested in writing a decent 
InsetSlide from scratch. An inset with two cells (the upper for the frame 
title, the lower for the content) and a dialog to set the options and overlay 
specifications, which integrates with the outliner etc. is what I could 
imagine as a good UI.

I think the effort would not be very much higher.

 However, as (hopefully) this will only be a temporary solution, I agree that
 the better place for such an alternative beamer layout is the wiki.

The more so since this is of course a file format change, and you would need 
to setup lyx2lyx routines to convert and revert the old to the new scheme.

Jürgen

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Liviu Andronic]

On Wed, May 30, 2012 at 3:45 PM, Jürgen Spitzmüller sp...@lyx.org wrote:
 Liviu Andronic wrote:
 In my module you get frames in the outliner when you add a frame title
 (because the latter is a Style). But indeed this doesn't cover moving
 a frame using the outliner. Perhaps this would be easily possible if
 custom insets had a 'outline' option, allowing them to be included in
 the outliner : worth a feature request.

 Yes, that's what I mean. I would rate this a must-have before insets of any
 kind can replace the current hack.

Actually, this shouldn't be a show-stopper. Although not as clean as
moving 'style' frames using the outliner, 'inset' frames can easily be
moved using 'alt+up/down' in the editor.

Liviu

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Liviu Andronic]

On Tue, May 29, 2012 at 11:18 PM, Jean-Marc Lasgouttes
 wrote:
> Le 29/05/2012 10:55, Liviu Andronic a écrit :
>
>> I fail to see how #8041 and #7273 are related, if at all. Uwe?
>
> I also think there is no relation.
>
Good, I'm not the only one.


> Concerning the module itself, I do not see why it is not in beamer.layout:
>
> * either the code is good enough and we support it in beamer.layout
> * or the code is too hackish and we should not IMO distribute it directly.
> It could nevertheless be put on the wiki.
>
In my (evolved) view the module itself is a clean implementation. It
could be better in case #6753 were addressed, but as current
infrastructure goes it is fine.

One may argue that it is a "hackish" implementation wrt beamer.layout
since it takes a different approach: Beamer's regular frames are
handled via LyX environments, while the module's fragile frames are
provided via custom insets. But I would argue that beamer.layout
itself is a big hack. It uses intricate preamble definitions:
Preamble
\long\def\lyxframe#1{\@lyxframe#1\@lyxframestop}%
\def\@lyxframe{\@ifnextchar<{\@@lyxframe}{\@@lyxframe<*>}}%
\def\@@lyxframe<#1>{\@ifnextchar[{\@@@lyxframe<#1>}{\@@@lyxframe<#1>[]}}

\def\@@@lyxframe<#1>[{\@ifnextchar<{\@lyxframe<#1>[}{\lyxframe<#1>[<*>][}}

\def\@lyxframe<#1>[#2]{\@ifnextchar[{\lyxframe<#1>[#2]}{\lyxframe<#1>[#2][]}}
\long\def\lyxframe<#1>[#2][#3]#4\@lyxframestop#5\lyxframeend{%
  \frame<#1>[#2][#3]{\frametitle{#4}#5}}
  EndPreamble

and perfectly non-standard LaTeX commands:
\lyxframeend{}\lyxframe{}

In contrast, the module simply uses native LaTeX constructs:
\begin{frame}[fragile]
\frametitle{}
\end{frame}

In this sense the layout and the module take different approaches, and
the two shouldn't simply be merged.

Given the above I would suggest that we better, if possible given
current infrastructure, fix beamer.layout to use native LaTeX
constructs instead of the current hacks. (Of course, this is likely a
job for 2.1.) Basically I propose that we bring beamer.layout more in
line with #7624, a new-generation layout for seminar.cls. And in both
cases fixing #7877 would help.

In my own experience, using custom insets for the Beamer frames is
preferable to the current UI-layout. The insets provide a visual,
clearly defined boundary of a frame, and would provide a first step
towards a 'presentation mode' in LyX [1]. Moreover I tend to get less
lost in my own document when it contains a handful of fragile insets:
the Beamer frames are much easier to identify. The only drawback with
using insets is that they're slightly more difficult to insert, but
this could be easily solved by fixing #7877.

Opinions welcome. Regards
Liviu

[1] http://wiki.lyx.org/Devel/SummerOfCode2011Ideas#toc3

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Jürgen Spitzmüller]

Liviu Andronic wrote:
> The only drawback with
> using insets is that they're slightly more difficult to insert, but
> this could be easily solved by fixing #7877.

* They do not work with the outliner (i.e. you cannot easily move frames with 
the outliner, which is an important feature IMHO).

* You cannot add custom options such as \begin{frame}[shrink=.9] or 
\begin{frame}[<+->] with the custom inset approach, can you?

I agree that the current layout solution is a hack, but either we need a much 
more sophisticated inset for frames, or we need to go for a different 
approach.

Jürgen

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
> Concerning the module itself, I do not see why it is not in beamer.layout:
> 
> * either the code is good enough and we support it in beamer.layout
> * or the code is too hackish and we should not IMO distribute it 
> directly. It could nevertheless be put on the wiki.

I'd tend towards the latter. An approach which needs its own custom inset for 
each and every option of the frame environment just does not look sane. And 
mixing insets/layouts for the same concept does not look sane either (I have 
elaborated in my other post why I think a switch to insets is not the way to 
go [at least with the current limitations of the insets]).

The beamer class simply goes beyond our current UI. Someone would need to sit 
down, take a deep breath and then design a unser interface which really fits 
beamer (and powerdot, for that matter).

Jürgen

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Guenter Milde]

On 2012-05-30, Jürgen Spitzmüller wrote:
> Liviu Andronic wrote:
>> The only drawback with
>> using insets is that they're slightly more difficult to insert, but
>> this could be easily solved by fixing #7877.

> * They do not work with the outliner (i.e. you cannot easily move
>   frames with the outliner, which is an important feature IMHO).



> * You cannot add custom options such as \begin{frame}[shrink=.9] or 
>   \begin{frame}[<+->] with the custom inset approach, can
>   you?

I know you can insert options like [shrink=.9] as "Insert>Short Title"
(only LyX insiders will find it under this name). How do you insert
 with a frame Style?

> I agree that the current layout solution is a hack, but either we need
> a much more sophisticated inset for frames, or we need to go for a
> different approach.

I still favour the "frames as insets" approach. 

Ideal for Definitions Theorems and Proofs (amsmath), presentation frames
(seminar, powerdot, beamer), poster-boxes (a0poster) and similar
environments, would be a "block inset", a mixture of the current
"Style" and "Inset" layout elements:

* Represents a LaTeX environment or HTML block-level element.

* Is not a paragraph style but a container at "paragraph level"
  (while current insets are "inline" elements).
  Content is nested (by default as a Standard style
  paragraph).

* Consecutive elements of same type are not merged into one environment
  (the main problem with current Styles, see
  http://www.lyx.org/trac/ticket/341),
  
* The LyX GUI draws a box around the content, moving in and out is done
  as in other Insets.

* Accepts the OptionalArgs and RequiredArgs keywords (actually, this
  should be possible for all custom insets),

* Can be moved around with the outliner.

I don't think that this is "much more sophisticated" -- all building
blocks are already there.

Günter

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Liviu Andronic]

On Wed, May 30, 2012 at 8:35 AM, Jürgen Spitzmüller  wrote:
> Liviu Andronic wrote:
>> The only drawback with
>> using insets is that they're slightly more difficult to insert, but
>> this could be easily solved by fixing #7877.
>
> * They do not work with the outliner (i.e. you cannot easily move frames with
> the outliner, which is an important feature IMHO).
>
In my module you get frames in the outliner when you add a frame title
(because the latter is a Style). But indeed this doesn't cover moving
a frame using the outliner. Perhaps this would be easily possible if
custom insets had a 'outline' option, allowing them to be included in
the outliner : worth a feature request.


> * You cannot add custom options such as \begin{frame}[shrink=.9] or
> \begin{frame}[<+->] with the custom inset approach, can you?
>
In theory Styles support adding options via "Insert>Short Title", but
this doesn't work with the Beamer frame Styles. Beamer.layout uses
\lyxframe{} commands, which use \begin{frame} only internally. So
options like [fragile] cannot be passed with the current setup. If it
were possible, then my entire module would be perfectly unnecessary.
Please correct me if I'm wrong.


> I agree that the current layout solution is a hack, but either we need a much
> more sophisticated inset for frames, or we need to go for a different
> approach.
>
I agree that for a good implementation we need an upgraded version of
custom insets, but as Guenter suggested it doesn't require someting
radical: most of the functionality is already there.


On Wed, May 30, 2012 at 8:54 AM, Jürgen Spitzmüller  wrote:
> Jean-Marc Lasgouttes wrote:
>> Concerning the module itself, I do not see why it is not in beamer.layout:
>>
>> * either the code is good enough and we support it in beamer.layout
>> * or the code is too hackish and we should not IMO distribute it
>> directly. It could nevertheless be put on the wiki.
>
> I'd tend towards the latter. An approach which needs its own custom inset for
> each and every option of the frame environment just does not look sane. And
>
This is the status-quo in beamer.layout: for each and every option of
the frame environment you need a new frame Style. The very reason for
my coming up with this module.


> mixing insets/layouts for the same concept does not look sane either (I have
>
Yes, this is a bit problematic. This is why I don't think that the
module definitions should be merged with the beamer.layout.

Regards
Liviu


> elaborated in my other post why I think a switch to insets is not the way to
> go [at least with the current limitations of the insets]).
>
> The beamer class simply goes beyond our current UI. Someone would need to sit
> down, take a deep breath and then design a unser interface which really fits
> beamer (and powerdot, for that matter).
>

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Jürgen Spitzmüller]

Guenter Milde wrote:
> I know you can insert options like [shrink=.9] as "Insert>Short Title"
> (only LyX insiders will find it under this name). 

Can you? AFAIK InsetLayout does not yet support optional arguments.

> How do you insert
>  with a frame Style?

Via ERT immediately after the label.

> > I agree that the current layout solution is a hack, but either we need
> > a much more sophisticated inset for frames, or we need to go for a
> > different approach.
> 
> I still favour the "frames as insets" approach.
> 
> Ideal for Definitions Theorems and Proofs (amsmath), presentation frames
> (seminar, powerdot, beamer), poster-boxes (a0poster) and similar
> environments, would be a "block inset", a mixture of the current
> "Style" and "Inset" layout elements:
> 
> * Represents a LaTeX environment or HTML block-level element.
> 
> * Is not a paragraph style but a container at "paragraph level"
>   (while current insets are "inline" elements).
>   Content is nested (by default as a Standard style
>   paragraph).
> 
> * Consecutive elements of same type are not merged into one environment
>   (the main problem with current Styles, see
>   http://www.lyx.org/trac/ticket/341),
> 
> * The LyX GUI draws a box around the content, moving in and out is done
>   as in other Insets.
> 
> * Accepts the OptionalArgs and RequiredArgs keywords (actually, this
>   should be possible for all custom insets),
> 
> * Can be moved around with the outliner.
> 
> I don't think that this is "much more sophisticated" -- all building
> blocks are already there.

This is not far away from what I have in mind (I would add that frame title 
insertion should be somewhat intuitive). But we do not have it. If you think 
you can put it together easily, go ahead! But until all this is possible, 
custom insets for frames is a step backwards.

Jürgen

> Günter

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Jürgen Spitzmüller]

Liviu Andronic wrote:
> In my module you get frames in the outliner when you add a frame title
> (because the latter is a Style). But indeed this doesn't cover moving
> a frame using the outliner. Perhaps this would be easily possible if
> custom insets had a 'outline' option, allowing them to be included in
> the outliner : worth a feature request.

Yes, that's what I mean. I would rate this a must-have before insets of any 
kind can replace the current "hack".

> > * You cannot add custom options such as \begin{frame}[shrink=.9] or
> > \begin{frame}[<+->] with the custom inset approach, can you?
> 
> In theory Styles support adding options via "Insert>Short Title", but
> this doesn't work with the Beamer frame Styles. Beamer.layout uses
> \lyxframe{} commands, which use \begin{frame} only internally. So
> options like [fragile] cannot be passed with the current setup. If it
> were possible, then my entire module would be perfectly unnecessary.
> Please correct me if I'm wrong.

It's only correct for fragile options, because the lyxframe definition chokes 
on those. Any other option can be passed via ERT, both the overlay 
specifications ("<...>") and the real options ("[...]"), in all combinations. 
See the beamerlyxexample1.lyx example file for some applications.

> > I agree that the current layout solution is a hack, but either we need a
> > much more sophisticated inset for frames, or we need to go for a
> > different approach.
> 
> I agree that for a good implementation we need an upgraded version of
> custom insets, but as Guenter suggested it doesn't require someting
> radical: most of the functionality is already there.

Fact is, it's not there. It needs to be implemented. It might be trivial in 
some cases, more tricky in others. But it needs to be done. With the current 
state of the art, insets are just not ready for this task yet.

I would think that a good UI would just need some more thought. And I think it 
would be worth investigating some time and establishing a real intuitive frame 
UI rather than putting together something that works "somehow" for some 
limited use cases.

Jürgen

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Guenter Milde]

On 2012-05-30, Jürgen Spitzmüller wrote:
> Liviu Andronic wrote:
>> In my module you get frames in the outliner when you add a frame title
>> (because the latter is a Style). But indeed this doesn't cover moving
>> a frame using the outliner. Perhaps this would be easily possible if
>> custom insets had a 'outline' option, allowing them to be included in
>> the outliner : worth a feature request.

> Yes, that's what I mean. I would rate this a must-have before insets of any 
> kind can replace the current "hack".

As I never used the outliner, I consider this less important than the issues
with the current beamer layout.


>> > * You cannot add custom options such as \begin{frame}[shrink=.9] or
>> > \begin{frame}[<+->] with the custom inset approach, can you?

>> In theory Styles support adding options via "Insert>Short Title", but
>> this doesn't work with the Beamer frame Styles. Beamer.layout uses
>> \lyxframe{} commands, which use \begin{frame} only internally. So
>> options like [fragile] cannot be passed with the current setup. If it
>> were possible, then my entire module would be perfectly unnecessary.
>> Please correct me if I'm wrong.

> It's only correct for fragile options, because the lyxframe definition
> chokes on those. Any other option can be passed via ERT, both the
> overlay specifications ("<...>") and the real options ("[...]"), in all
> combinations.  See the beamerlyxexample1.lyx example file for some
> applications.

Using ERT for options is hackish, too. OTOH, maybe this can be solved
with an alternative beamer layout that does not use the \lyxframe{} etc.
hacks but (like the old seminar layout) "keepempty" Styles for frames
with content explicitely nested and the EnvironmentSeparator to start a
new frame.

For people using the Outliner, this might be preferable to an inset-based
layout.

...
> With the current state of the art, insets are just not ready for this
> task yet.

> I would think that a good UI would just need some more thought. And I
> think it would be worth investigating some time and establishing a real
> intuitive frame UI rather than putting together something that works
> "somehow" for some limited use cases.

I think creating a less hackish beamer layout (or both, a simplified
Style based and an inset based one) is a step forward. It offers the
chance to try concepts and to spot requirements on the way to a user
friendly frame UI. But also for real work on a beamer presentation, I
know that I will start with writing a new beamer layout.

However, as (hopefully) this will only be a temporary solution, I agree that
the better place for such an alternative beamer layout is the wiki.

Günter

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Jürgen Spitzmüller]

Guenter Milde wrote:
> Using ERT for options is hackish, too.

Sure it is. But at least it can be done (with insets, it simply can't, 
AFAICS).

> OTOH, maybe this can be solved
> with an alternative beamer layout that does not use the \lyxframe{} etc.
> hacks but (like the old seminar layout) "keepempty" Styles for frames
> with content explicitely nested and the EnvironmentSeparator to start a
> new frame.

I thought about this solution, too. But can you produce

\begin{frame}[shrink=.9]{My frame title}
...
\end{frame}

with this approach without even more ERT?

> I think creating a less hackish beamer layout (or both, a simplified
> Style based and an inset based one) is a step forward. It offers the
> chance to try concepts and to spot requirements on the way to a user
> friendly frame UI. But also for real work on a beamer presentation, I
> know that I will start with writing a new beamer layout.

I wonder if the time would not be better invested in writing a decent 
InsetSlide from scratch. An inset with two cells (the upper for the frame 
title, the lower for the content) and a dialog to set the options and overlay 
specifications, which integrates with the outliner etc. is what I could 
imagine as a good UI.

I think the effort would not be very much higher.

> However, as (hopefully) this will only be a temporary solution, I agree that
> the better place for such an alternative beamer layout is the wiki.

The more so since this is of course a file format change, and you would need 
to setup lyx2lyx routines to convert and revert the old to the new scheme.

Jürgen

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Liviu Andronic]

On Wed, May 30, 2012 at 3:45 PM, Jürgen Spitzmüller  wrote:
> Liviu Andronic wrote:
>> In my module you get frames in the outliner when you add a frame title
>> (because the latter is a Style). But indeed this doesn't cover moving
>> a frame using the outliner. Perhaps this would be easily possible if
>> custom insets had a 'outline' option, allowing them to be included in
>> the outliner : worth a feature request.
>
> Yes, that's what I mean. I would rate this a must-have before insets of any
> kind can replace the current "hack".
>
Actually, this shouldn't be a show-stopper. Although not as clean as
moving 'style' frames using the outliner, 'inset' frames can easily be
moved using 'alt+up/down' in the editor.

Liviu

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Pavel Sanda]

Liviu Andronic wrote:
 Uwe, you suggested that we should release the module at the same time
 as #8041, which is due for 2.1.

What is the relation to #8041? Do we want both module and 8041 in trunk
or this is kind of a hack before 8041 is fixed by 2.1?

 Are there serious reasons to delay the release of the module for so long?

Well, we have a rule that fileformat change won't enter stable series. The
reason behind is that users can safely to update to newer version and still
easily use and interchange files. Layout/modules changes are not strictly
fileformat change and some new things already went in 2.0.x, but you can
understand the hesitation... 

Pavel

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Liviu Andronic]

On Tue, May 29, 2012 at 10:14 AM, Pavel Sanda sa...@lyx.org wrote:
 Liviu Andronic wrote:
 Uwe, you suggested that we should release the module at the same time
 as #8041, which is due for 2.1.

 What is the relation to #8041? Do we want both module and 8041 in trunk
 or this is kind of a hack before 8041 is fixed by 2.1?

I'm not quite sure. #8041 adds native support for the 'verbatim'
environment (a fileformat change), while Sweave uses the 'Verbatim'
environment to print its output in LaTeX. However, Sweave doesn't use
'Verbatim' directly but via 'Schunk' environments, so #8041 doesn't
seem to modify anything on this front. At the same time, the fragile
module simply adds native support for the [fragile] and
[fragile,allowframebreaks] options of Beamer's 'frame' environment.
This allows to include verbatim environments in Beamer frames, and by
extension R output in Beamer.

I fail to see how #8041 and #7273 are related, if at all. Uwe?


 Are there serious reasons to delay the release of the module for so long?

 Well, we have a rule that fileformat change won't enter stable series. The
 reason behind is that users can safely to update to newer version and still
 easily use and interchange files. Layout/modules changes are not strictly
 fileformat change and some new things already went in 2.0.x, but you can
 understand the hesitation...

Oh, definitely. In this case I don't think that the module addition
would pose problems regarding fileformat changes. And since the two
bugs seem vaguely related..

Regards
Liviu

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Jean-Marc Lasgouttes]

Le 29/05/2012 10:55, Liviu Andronic a écrit :

I fail to see how #8041 and #7273 are related, if at all. Uwe?


I also think there is no relation.

Concerning the module itself, I do not see why it is not in beamer.layout:

* either the code is good enough and we support it in beamer.layout
* or the code is too hackish and we should not IMO distribute it 
directly. It could nevertheless be put on the wiki.


JMarc

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Pavel Sanda]

Liviu Andronic wrote:
> Uwe, you suggested that we should release the module at the same time
> as #8041, which is due for 2.1.

What is the relation to #8041? Do we want both module and 8041 in trunk
or this is kind of a hack before 8041 is fixed by 2.1?

> Are there serious reasons to delay the release of the module for so long?

Well, we have a rule that fileformat change won't enter stable series. The
reason behind is that users can safely to update to newer version and still
easily use and interchange files. Layout/modules changes are not strictly
fileformat change and some new things already went in 2.0.x, but you can
understand the hesitation... 

Pavel

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Liviu Andronic]

On Tue, May 29, 2012 at 10:14 AM, Pavel Sanda  wrote:
> Liviu Andronic wrote:
>> Uwe, you suggested that we should release the module at the same time
>> as #8041, which is due for 2.1.
>
> What is the relation to #8041? Do we want both module and 8041 in trunk
> or this is kind of a hack before 8041 is fixed by 2.1?
>
I'm not quite sure. #8041 adds native support for the 'verbatim'
environment (a fileformat change), while Sweave uses the 'Verbatim'
environment to print its output in LaTeX. However, Sweave doesn't use
'Verbatim' directly but via 'Schunk' environments, so #8041 doesn't
seem to modify anything on this front. At the same time, the fragile
module simply adds native support for the [fragile] and
[fragile,allowframebreaks] options of Beamer's 'frame' environment.
This allows to include verbatim environments in Beamer frames, and by
extension R output in Beamer.

I fail to see how #8041 and #7273 are related, if at all. Uwe?


>> Are there serious reasons to delay the release of the module for so long?
>
> Well, we have a rule that fileformat change won't enter stable series. The
> reason behind is that users can safely to update to newer version and still
> easily use and interchange files. Layout/modules changes are not strictly
> fileformat change and some new things already went in 2.0.x, but you can
> understand the hesitation...
>
Oh, definitely. In this case I don't think that the module addition
would pose problems regarding fileformat changes. And since the two
bugs seem vaguely related..

Regards
Liviu

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Jean-Marc Lasgouttes]

Le 29/05/2012 10:55, Liviu Andronic a écrit :

I fail to see how #8041 and #7273 are related, if at all. Uwe?


I also think there is no relation.

Concerning the module itself, I do not see why it is not in beamer.layout:

* either the code is good enough and we support it in beamer.layout
* or the code is too hackish and we should not IMO distribute it 
directly. It could nevertheless be put on the wiki.


JMarc

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Liviu Andronic]

Hello
In #7273 I proposed that we include the beamer fragile module (and
associated template) into 2.0.4.

Uwe, you suggested that we should release the module at the same time
as #8041, which is due for 2.1. Are there serious reasons to delay the
release of the module for so long?

Regards
Liviu


On Tue, May 29, 2012 at 12:28 AM, LyX Ticket Tracker t...@lyx.org wrote:
 #7273: beamer/sweave issue: need [containsverbatim]
 +-
  Reporter:  pauljohn32  |       Owner:  lasgouttes
     Type:  defect      |      Status:  new
  Priority:  normal      |   Milestone:  2.0.4
 Component:  general     |     Version:  2.0.0svn
  Severity:  normal      |  Resolution:
  Keywords:  patch       |
 +-

 Comment (by rgheck):

  Could you post a note to devel about this? I'm not an expert with Sweave
  or Beamer, so discussion might be useful. We haven't yet frozen strings,
  it could still be possible. But I want to do that soon.

Re: #7273: beamer/sweave issue: need [containsverbatim]

[Liviu Andronic]

Hello
In #7273 I proposed that we include the beamer fragile module (and
associated template) into 2.0.4.

Uwe, you suggested that we should release the module at the same time
as #8041, which is due for 2.1. Are there serious reasons to delay the
release of the module for so long?

Regards
Liviu


On Tue, May 29, 2012 at 12:28 AM, LyX Ticket Tracker <t...@lyx.org> wrote:
> #7273: beamer/sweave issue: need [containsverbatim]
> +-
>  Reporter:  pauljohn32  |       Owner:  lasgouttes
>     Type:  defect      |      Status:  new
>  Priority:  normal      |   Milestone:  2.0.4
> Component:  general     |     Version:  2.0.0svn
>  Severity:  normal      |  Resolution:
>  Keywords:  patch       |
> +-
>
> Comment (by rgheck):
>
>  Could you post a note to devel about this? I'm not an expert with Sweave
>  or Beamer, so discussion might be useful. We haven't yet frozen strings,
>  it could still be possible. But I want to do that soon.
>