Re: Beamer usage again

[Jürgen Spitzmüller]

Am Mittwoch, den 03.01.2018, 16:49 -0500 schrieb Scott Kostyshak:
> On Wed, Jan 03, 2018 at 12:25:52PM +, Jürgen Spitzmüller wrote:
> > Am Montag, den 01.01.2018, 17:57 +0100 schrieb Jürgen Spitzmüller:
> > > > I think we could add one more separator below the inset
> > > > arguments.
> > > > And
> > > > in general, some thought about potential improvements of the
> > > > order
> > > > cannot harm.
> > > 
> > > Here's a first small attempt to improve the grouping a bit.
> > 
> > I propose to commit this to master and 2.3.x. Objections?
> 
> No objection from me.

Since there were none, I committed.

Jürgen

> 
> Scott

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Scott Kostyshak]

On Wed, Jan 03, 2018 at 12:25:52PM +, Jürgen Spitzmüller wrote:
> Am Montag, den 01.01.2018, 17:57 +0100 schrieb Jürgen Spitzmüller:
> > > I think we could add one more separator below the inset arguments.
> > > And
> > > in general, some thought about potential improvements of the order
> > > cannot harm.
> > 
> > Here's a first small attempt to improve the grouping a bit.
> 
> I propose to commit this to master and 2.3.x. Objections?

No objection from me.

Scott


signature.asc
Description: PGP signature

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Montag, den 01.01.2018, 17:57 +0100 schrieb Jürgen Spitzmüller:
> > I think we could add one more separator below the inset arguments.
> > And
> > in general, some thought about potential improvements of the order
> > cannot harm.
> 
> Here's a first small attempt to improve the grouping a bit.

I propose to commit this to master and 2.3.x. Objections?

Jürgen

> 
> Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Scott Kostyshak]

On Tue, Jan 02, 2018 at 12:33:16PM +, Jürgen Spitzmüller wrote:

> > P.S. Sorry to feel like an overzealous hawk, but I've spent an
> > inordinate amount of time in LyX with Beamer over the past year or
> > so, so improvements are dear to me.  Since we're (you're) working in
> > the area, many of the thoughts I've had while using it are bubbling
> > forth.  Bottom line: I truly appreciate your selfless work on this!
> 
> I appreciate the input. It definitely helped to improve the UI a lot.

+1 thanks, Joel. Actually your great comments and testing are partly why
I thought we should go ahead with the changes for 2.3.0. Please keep
testing and giving comments!

Scott


signature.asc
Description: PGP signature

Re: Beamer usage again

[Scott Kostyshak]

On Mon, Jan 01, 2018 at 06:00:35PM +, Uwe Stöhr wrote:
> El 01.01.2018 a las 11:06, Scott Kostyshak escribió:
> 
> > I believe that Uwe is not going to be available to build the Windows
> > binary for the next month, so we will not be able to get rc2 out soon
> > anyway. In fact, I think the last day Uwe will be able to work on LyX
> > for a while is on Tuesday.
> 
> I had unforeseen troubles. So maybe I will be able to build an RC2 installer
> during January. But I cannot promise that.

OK good to know. Thanks for all of your packaging work, Uwe!

Scott


signature.asc
Description: PGP signature

Re: Beamer usage again

[Scott Kostyshak]

On Mon, Jan 01, 2018 at 11:47:10AM +, Jürgen Spitzmüller wrote:

> Thank you. And Happy New Year everybody.

Thanks for all your work, Jürgen, and best wishes to everyone for the
new year.

Scott


signature.asc
Description: PGP signature

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Dienstag, den 02.01.2018, 21:15 +0900 schrieb Joel Kulesza:
> Jürgen,
> 
> Thank you for working to clean-up the Insert menu and for moving
> around a couple of the items.  Am I correct that these ui.diff
> changes haven't yet been applied?  

Yes.

> I don't see them as of 8d8ee12e.  Is the logic behind the
> reorganization to isolate direct-TeX interacting elements to the
> bottom (and to better separate the Arguments, both of which I like
> the idea of)? 

Yes.

> Regardless, rather than split the menu elements that are present
> regardless of document type (presently Table through Preview), does
> it make sense to instead append the separated regions of Environments
> and Arguments to the bottom of the menu such that it will grow, as
> appropriate, rather than shift around contents?

Many other menu items will appear only in certain context, so you
always have items (dis)appear within a menu (and not only at the
bottom).

> A couple other questions/comments:
> Your commit 8f86feb prepends "Insert" to context menus.  I cannot see
> where these are shown.  Can you help me understand what changed
> here?  Sorry for my ignorance.

Context menu (right mouse click)

> In looking for the above, I notice that in the Preferences -> Editing
> -> Shortcuts, there is a "separator-insert" function.  Given past
> changes to Beamer in LyX, should this be removed?

No, this function is still needed. In fact, it is used by the
environment-split function.

> In looking for the above in Preferences -> Editing -> Shortcuts,
> should the environment insertion functions added to the Insert menu
> that we're discussing be added to receive shortcut key assignment?  A
> search for "insert" and "frame" did not reveal them to me.

environment-split, "environment-split outer", "environment-split
before", and "environment-split-previous"

You can assign shortcuts to them. Note that there are already bindings
for either environment-split or environment-split previous (Alt+Return)
, depending on which one is currently active, as well as "environment-
split outer" (Alt+Shift+Return). Only the latter is indicated in the
menu. This is due to the fact that the former is defined via command-
alternatives, and the code that builds the strings for display cannot
yet deal with that (the fix is beyond my knowledge).

> Thanks,
> Joel
> 
> P.S. Sorry to feel like an overzealous hawk, but I've spent an
> inordinate amount of time in LyX with Beamer over the past year or
> so, so improvements are dear to me.  Since we're (you're) working in
> the area, many of the thoughts I've had while using it are bubbling
> forth.  Bottom line: I truly appreciate your selfless work on this!

I appreciate the input. It definitely helped to improve the UI a lot.

Jürgen
> 

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Joel Kulesza]

On Tue, Jan 2, 2018 at 1:57 AM, Jürgen Spitzmüller  wrote:

> Am Montag, den 01.01.2018, 14:54 +0100 schrieb Jürgen Spitzmüller:
> > Am Montag, den 01.01.2018, 21:52 +0900 schrieb Joel Kulesza:
> > > I think the separators help reduce the need to "hunt" for the new
> > > items *a lot*.
> > >
> > > However, there are now five Insert menu "sections" (using Beamer)
> > > with only the first two discernibly grouping items.  A question
> > > regarding the Insert menu's organization: how are the non-expanding
> > > items ordered (i.e., the four bottom sections) both as whole
> > > sections
> > > and for each item within the section?
> >
> > I think we could add one more separator below the inset arguments.
> > And
> > in general, some thought about potential improvements of the order
> > cannot harm.
>
> Here's a first small attempt to improve the grouping a bit.


Jürgen,

Thank you for working to clean-up the Insert menu and for moving around a
couple of the items.  Am I correct that these ui.diff changes haven't yet
been applied?  I don't see them as of 8d8ee12e.  Is the logic behind the
reorganization to isolate direct-TeX interacting elements to the bottom
(and to better separate the Arguments, both of which I like the idea of)?

Regardless, rather than split the menu elements that are present regardless
of document type (presently Table through Preview), does it make sense to
instead append the separated regions of Environments and Arguments to the
bottom of the menu such that it will grow, as appropriate, rather than
shift around contents?

A couple other questions/comments:

   1. Your commit 8f86feb prepends "Insert" to context menus.  I cannot see
   where these are shown.  Can you help me understand what changed here?
   Sorry for my ignorance.
   2. In looking for the above, I notice that in the Preferences -> Editing
   -> Shortcuts, there is a "separator-insert" function.  Given past changes
   to Beamer in LyX, should this be removed?
   3. In looking for the above in Preferences -> Editing -> Shortcuts,
   should the environment insertion functions added to the Insert menu that
   we're discussing be added to receive shortcut key assignment?  A search for
   "insert" and "frame" did not reveal them to me.

Thanks,
Joel

P.S. Sorry to feel like an overzealous hawk, but I've spent an inordinate
amount of time in LyX with Beamer over the past year or so, so improvements
are dear to me.  Since we're (you're) working in the area, many of the
thoughts I've had while using it are bubbling forth.  Bottom line: I truly
appreciate your selfless work on this!

Re: Beamer usage again

[Uwe Stöhr]

El 01.01.2018 a las 11:06, Scott Kostyshak escribió:


I believe that Uwe is not going to be available to build the Windows
binary for the next month, so we will not be able to get rc2 out soon
anyway. In fact, I think the last day Uwe will be able to work on LyX
for a while is on Tuesday.


I had unforeseen troubles. So maybe I will be able to build an RC2 
installer during January. But I cannot promise that.


regards Uwe

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Montag, den 01.01.2018, 14:54 +0100 schrieb Jürgen Spitzmüller:
> Am Montag, den 01.01.2018, 21:52 +0900 schrieb Joel Kulesza:
> > I think the separators help reduce the need to "hunt" for the new
> > items *a lot*.  
> > 
> > However, there are now five Insert menu "sections" (using Beamer)
> > with only the first two discernibly grouping items.  A question
> > regarding the Insert menu's organization: how are the non-expanding
> > items ordered (i.e., the four bottom sections) both as whole
> > sections
> > and for each item within the section?
> 
> I think we could add one more separator below the inset arguments.
> And
> in general, some thought about potential improvements of the order
> cannot harm.

Here's a first small attempt to improve the grouping a bit.

Jürgendiff --git a/lib/ui/stdmenus.inc b/lib/ui/stdmenus.inc
index fc0db39d90..57077ed4b8 100644
--- a/lib/ui/stdmenus.inc
+++ b/lib/ui/stdmenus.inc
@@ -392,13 +392,14 @@ Menuset
 		Item "Hyperlink...|k" "href-insert"
 		Item "Footnote|F" "footnote-insert"
 		Item "Marginal Note|M" "marginalnote-insert"
+		Item "Program Listing[[Menu]]" "listing-insert"
+		Item "Date" "date-insert"
 		Separator
 		EnvironmentSeparators
 		Separator
 		Arguments
+		Separator
 		Item "TeX Code" "ert-insert"
-		Item "Program Listing[[Menu]]" "listing-insert"
-		Item "Date" "date-insert"
 		Item "Preview|w" "preview-insert"
 	End
 


signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Montag, den 01.01.2018, 21:52 +0900 schrieb Joel Kulesza:
> I think the separators help reduce the need to "hunt" for the new
> items *a lot*.  
> 
> However, there are now five Insert menu "sections" (using Beamer)
> with only the first two discernibly grouping items.  A question
> regarding the Insert menu's organization: how are the non-expanding
> items ordered (i.e., the four bottom sections) both as whole sections
> and for each item within the section?

I think we could add one more separator below the inset arguments. And
in general, some thought about potential improvements of the order
cannot harm.

> If there is no driving logic, should some be introduced at least for
> the items in each section (alphabetical, etc.)?  

Alphabetical order is impossible. It will only work for English and
fail with any localization (since the items have fixed positions within
the menu definition files).

Jürgen

> 
> Maybe a topic for a different email thread...?
> 
> Thanks,
> Joel
> 

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Joel Kulesza]

On Mon, Jan 1, 2018 at 9:41 PM, Jürgen Spitzmüller  wrote:

> Am Montag, den 01.01.2018, 11:52 +0100 schrieb Jürgen Spitzmüller:
> > Am Montag, den 01.01.2018, 05:01 -0500 schrieb Scott Kostyshak:
> > > However, in the context menu we just have "Separated itemize
> > > above".
> > > Should we prepend an "insert" in the context menu?
> >
> > I don't think we know which menu we populate when passing the
> > strings.
>
> But we can add two versions. I did that now. I also added a menu
> separator, which makes the Insert menu look a bit more organized, IMHO.
>

I think the separators help reduce the need to "hunt" for the new items *a
lot*.

However, there are now five Insert menu "sections" (using Beamer) with only
the first two discernibly grouping items.  A question regarding the Insert
menu's organization: how are the non-expanding items ordered (i.e., the
four bottom sections) both as whole sections and for each item within the
section?

If there is no driving logic, should some be introduced at least for the
items in each section (alphabetical, etc.)?

Maybe a topic for a different email thread...?

Thanks,
Joel

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Montag, den 01.01.2018, 11:52 +0100 schrieb Jürgen Spitzmüller:
> Am Montag, den 01.01.2018, 05:01 -0500 schrieb Scott Kostyshak:
> > However, in the context menu we just have "Separated itemize
> > above".
> > Should we prepend an "insert" in the context menu?
> 
> I don't think we know which menu we populate when passing the
> strings.

But we can add two versions. I did that now. I also added a menu
separator, which makes the Insert menu look a bit more organized, IMHO.

Jürgen

> 
> Jürgen
> 
> > 
> > Scott

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Montag, den 01.01.2018, 05:06 -0500 schrieb Scott Kostyshak:
> Let's go ahead with the beamer changes for 2.3.0. There seems to be
> strong opinions that the improvements are a clear step forward and
> that
> it is worth doing it this late in the release process because it
> improves on an apparently big confusion by LyX beamer users. 

Thank you. I know such latecomers are not the release manager's
pleasure.

> As José
> suggests, an alternative is to have a short 2.4.0 release cycle, but
> given our history I'm not sure how likely that is.

Right. It has always been a good wish.

> I would be fine with the more conservative approach of doing the
> format
> change now and phasing in the UI later (after testing in master) if
> others prefer. But I suggest going all in now so that there are not
> such
> big UI and documentation differences within the stable releases.
> 
> I believe that Uwe is not going to be available to build the Windows
> binary for the next month, so we will not be able to get rc2 out soon
> anyway. In fact, I think the last day Uwe will be able to work on LyX
> for a while is on Tuesday. Jürgen, you might want to commit as soon
> as
> possible to the 2.3.x branch so that if Uwe has time before he leaves
> he
> can check the documentation and distribute the changes.

Done now. Note that I have already distributed all changes.

> I'm guessing that follow-up commits will be desired to smooth things
> out. Jürgen, please only go ahead if you know you will have time and
> interest in the next month to fix any issues. You have done so much
> recently (thank you!) that if you sense you are getting burned out, I
> would not blame you. In this case, let's not commit anything to the
> 2.3.x branch and instead let's just wait for 2.4.0.

I know what I am responsible for. Even though the time frame will now
become smaller again.

> I will be traveling the next few days. Especially for the next day,
> I'm
> not sure if I will check my email. When I can, the next thing I will
> spend time on will be translations.
> 
> Thanks everyone for the advice, patches, testing, and good
> discussions.

Thank you. And Happy New Year everybody.

Jürgen

> 
> Scott

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Montag, den 01.01.2018, 05:01 -0500 schrieb Scott Kostyshak:
> However, in the context menu we just have "Separated itemize above".
> Should we prepend an "insert" in the context menu?

I don't think we know which menu we populate when passing the strings.

Jürgen

> 
> Scott

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Scott Kostyshak]

On Mon, Jan 01, 2018 at 06:06:13AM +, Pavel Sanda wrote:
> Richard Heck wrote:
> > That said, this strikes me too as enough of an improvement to warrant a
> > late change.
> > I've found these same aspects of the Beamer implementation unintuitive.
> 
> +1

Let's go ahead with the beamer changes for 2.3.0. There seems to be
strong opinions that the improvements are a clear step forward and that
it is worth doing it this late in the release process because it
improves on an apparently big confusion by LyX beamer users. As José
suggests, an alternative is to have a short 2.4.0 release cycle, but
given our history I'm not sure how likely that is.

I would be fine with the more conservative approach of doing the format
change now and phasing in the UI later (after testing in master) if
others prefer. But I suggest going all in now so that there are not such
big UI and documentation differences within the stable releases.

I believe that Uwe is not going to be available to build the Windows
binary for the next month, so we will not be able to get rc2 out soon
anyway. In fact, I think the last day Uwe will be able to work on LyX
for a while is on Tuesday. Jürgen, you might want to commit as soon as
possible to the 2.3.x branch so that if Uwe has time before he leaves he
can check the documentation and distribute the changes.

I'm guessing that follow-up commits will be desired to smooth things
out. Jürgen, please only go ahead if you know you will have time and
interest in the next month to fix any issues. You have done so much
recently (thank you!) that if you sense you are getting burned out, I
would not blame you. In this case, let's not commit anything to the
2.3.x branch and instead let's just wait for 2.4.0.

I will be traveling the next few days. Especially for the next day, I'm
not sure if I will check my email. When I can, the next thing I will
spend time on will be translations.

Thanks everyone for the advice, patches, testing, and good discussions.

Scott


signature.asc
Description: PGP signature

Re: Beamer usage again

[Scott Kostyshak]

On Mon, Jan 01, 2018 at 05:41:46AM +, Joel Kulesza wrote:

> I agree that "separated" is correct; however, I was wondering if separate
> (or I should have specified, another word) was better in an overall sense
> of clarity, lack of awkwardness, etc.  Regardless, of all the issues that
> have been addressed this is the one I'm least concerned with :-).  Thanks
> again for your work to bring Beamer much further ahead in terms of
> usability!

I at first also found "separated" strange. Now it sounds more normal to
me. I think what made it sound normal for me is that I began the
sentence in my head with "Insert...". When I just read "separated
itemize above", my brain wanted to view "separated" as the verb, not as
a modifier of "itemize".

However, in the context menu we just have "Separated itemize above".
Should we prepend an "insert" in the context menu?

Scott


signature.asc
Description: PGP signature

Re: Beamer usage again

[Scott Kostyshak]

On Sun, Dec 31, 2017 at 08:40:04AM +, Jürgen Spitzmüller wrote:

> Note that max. 3 entries are added. In many cases only 2 or 1. But I
> agree it's a long menu.

OK.

> A submenu is not an option IMO. That lowers accessibility.

Agreed.

Scott


signature.asc
Description: PGP signature

Re: Beamer usage again

[Scott Kostyshak]

On Mon, Jan 01, 2018 at 05:59:51AM +, Pavel Sanda wrote:

> I had the same thought. Still if there are these 3 options (edit menu/submenu
> in insert/insert menu) the last one wins. But your concern is right.

Fine with me.

Scott


signature.asc
Description: PGP signature

Re: Beamer usage again

[Pavel Sanda]

Richard Heck wrote:
> That said, this strikes me too as enough of an improvement to warrant a
> late change.
> I've found these same aspects of the Beamer implementation unintuitive.

+1
Pavel

Re: Beamer usage again

[Pavel Sanda]

Scott Kostyshak wrote:
> Not thinking about screen space, I do think that Insert is the most
> intuitive for new users. I think the Edit menu could be more intuitive
> if the names of the entries were "split environment" (like in the LFUN
> name): splitting to me is an edit operation, but "adding" and
> "prepending" sound more like "inserting" to me.
> 
> In summary, I'm conflicted.

I had the same thought. Still if there are these 3 options (edit menu/submenu
in insert/insert menu) the last one wins. But your concern is right.

Pavel

Re: Beamer usage again

[Joel Kulesza]

On Mon, Jan 1, 2018 at 12:54 AM, Jürgen Spitzmüller  wrote:

> Am Sonntag, den 31.12.2017, 23:20 +0900 schrieb Joel Kulesza:
> > On Sun, Dec 31, 2017 at 10:44 PM, Jürgen Spitzmüller 
> > wrote:
> > > Am Sonntag, den 31.12.2017, 21:35 +0900 schrieb Joel Kulesza:
> > > > Is "Separated" or "Separate" the better word to use in the Insert
> > > > menu?
> > >
> > > I'm not a native speaker of English, but my feeling was
> > > "Separated".
> >
> > I'm a native English speaker and I don't have a strong opinion, but
> > "Separated" reads strangely to me (though, I cannot identify why).
> >
> > I'll let others voice their opinion.
>
> I'll certainly trust the native speakers, but according to this
> https://english.stackexchange.com/questions/13144/separated-versus-sepa
> rate
>
> the past participle strikes me correct given that the environment is
> actually split ("Insert a frame above that has been separated from the
> one here" rather than "Insert a separate frame above").


I agree that "separated" is correct; however, I was wondering if separate
(or I should have specified, another word) was better in an overall sense
of clarity, lack of awkwardness, etc.  Regardless, of all the issues that
have been addressed this is the one I'm least concerned with :-).  Thanks
again for your work to bring Beamer much further ahead in terms of
usability!

- Joel

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Sonntag, den 31.12.2017, 23:20 +0900 schrieb Joel Kulesza:
> On Sun, Dec 31, 2017 at 10:44 PM, Jürgen Spitzmüller 
> wrote:
> > Am Sonntag, den 31.12.2017, 21:35 +0900 schrieb Joel Kulesza:
> > > Is "Separated" or "Separate" the better word to use in the Insert
> > > menu?
> > 
> > I'm not a native speaker of English, but my feeling was
> > "Separated".
> 
> I'm a native English speaker and I don't have a strong opinion, but
> "Separated" reads strangely to me (though, I cannot identify why).  
> 
> I'll let others voice their opinion.

I'll certainly trust the native speakers, but according to this
https://english.stackexchange.com/questions/13144/separated-versus-sepa
rate

the past participle strikes me correct given that the environment is
actually split ("Insert a frame above that has been separated from the
one here" rather than "Insert a separate frame above").

Jürgen



signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Joel Kulesza]

On Sun, Dec 31, 2017 at 10:44 PM, Jürgen Spitzmüller  wrote:

> Am Sonntag, den 31.12.2017, 21:35 +0900 schrieb Joel Kulesza:
> > Is "Separated" or "Separate" the better word to use in the Insert
> > menu?
>
> I'm not a native speaker of English, but my feeling was "Separated".
>

I'm a native English speaker and I don't have a strong opinion, but
"Separated" reads strangely to me (though, I cannot identify why).

I'll let others voice their opinion.


> > Please see this video (https://youtu.be/trVg_xStL0s) for when I
> > insert below and observe a breakage in nesting.  Is this expected?
> > As I would hope, I didn't see breakage in nesting otherwise.
>
> Fixed.
>

Confirmed; thank you!

- Joel

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Sonntag, den 31.12.2017, 21:35 +0900 schrieb Joel Kulesza:
> Is "Separated" or "Separate" the better word to use in the Insert
> menu?

I'm not a native speaker of English, but my feeling was "Separated".

> Either way, the above/below meaning seems somewhat lost when in the
> middle of a frame.  Is there logic that can/should be incorporated to
> note that the frame will be split where the cursor is positioned?

I have no idea. I mean the new environment is inserted above or below.
This seems reasonably clear to me.

> Is my experience expected: a frame can only be inserted above from
> the Frame line on the left of the Frame Title but above and below
> when to the right of Frame Title (see video below for demo)?

Yes.

> Please see this video (https://youtu.be/trVg_xStL0s) for when I
> insert below and observe a breakage in nesting.  Is this expected? 
> As I would hope, I didn't see breakage in nesting otherwise.

Fixed.

Jürgen

> Thanks,
> Joel

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Joel Kulesza]

On Sun, Dec 31, 2017 at 6:40 PM, Jürgen Spitzmüller  wrote:

> Am Sonntag, den 31.12.2017, 09:30 +0100 schrieb Jürgen Spitzmüller:
> > Am Samstag, den 30.12.2017, 22:52 -0500 schrieb Richard Heck:
> > > Can someone put the 9261 patch on trac so it's more accessible?
> >
> > Done.
>
> I've now also pushed it to master so everybody can try out more easily.
> I will revert if people think it's not a good idea.
>

Jürgen,

Thanks for your work on this.  I pulled and built through 761a5425.  The
crash I was experiencing before is fixed (I've been unable to cause
another).  A couple observations:

   - Is "Separated" or "Separate" the better word to use in the Insert menu?
   - Either way, the above/below meaning seems somewhat lost when in the
   middle of a frame.  Is there logic that can/should be incorporated to note
   that the frame will be split where the cursor is positioned?
   - Is my experience expected: a frame can only be inserted above from the
   Frame line on the left of the Frame Title but above and below when to the
   right of Frame Title (see video below for demo)?
   - Please see this video (https://youtu.be/trVg_xStL0s) for when I insert
   below and observe a breakage in nesting.  Is this expected?  As I would
   hope, I didn't see breakage in nesting otherwise.

Thanks,
Joel

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Sonntag, den 31.12.2017, 09:30 +0100 schrieb Jürgen Spitzmüller:
> Am Samstag, den 30.12.2017, 22:52 -0500 schrieb Richard Heck:
> > Can someone put the 9261 patch on trac so it's more accessible?
> 
> Done.

I've now also pushed it to master so everybody can try out more easily.
I will revert if people think it's not a good idea.

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Sonntag, den 31.12.2017, 09:40 +0100 schrieb Jürgen Spitzmüller:
> > Not thinking about screen space, I do think that Insert is the most
> > intuitive for new users. I think the Edit menu could be more
> > intuitive
> > if the names of the entries were "split environment" (like in the
> > LFUN
> > name): splitting to me is an edit operation, but "adding" and
> > "prepending" sound more like "inserting" to me.
> 
> I fear that "splitting" is not so clear to unexperienced users.

That's why we used "Start New Environment" until now, which is also
clearly an Edit (rather than an Insert) operation. The more serious
problem seems to be that users don't seek the operation in Edit,
notwithstanding how we label it, since what they really want is "insert
a new frame".

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Sonntag, den 31.12.2017, 09:25 +0100 schrieb Jürgen Spitzmüller:
> I'd think: If we touch the docs and strings (two new UI strings BTW,
> and [rather small] changes to Customization.lyx, UserGuide.lyx and
> beamer.lyx), we could do it now (or later) for all changes.

I have now done all necessary documentation work (including moving the
English changes to the translated docs) in master. So you can judge the
amount of change there. 3 new GUI strings plus:

http://www.lyx.org/trac/changeset/b0801b43f46/lyxgit (Customization)

http://www.lyx.org/trac/changeset/fe698caeeca/lyxgit (UG)

http://www.lyx.org/trac/changeset/cc8ce481f5/lyxgit (beamer.lyx)

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Sonntag, den 31.12.2017, 08:56 +0900 schrieb Joel Kulesza:
> I pulled 9f9c2e02 and applied the 9261 patch.  From there, attempting
> to use Insert > Frame gives me a crash. 

Stupid thinko of mine. Fixed.

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Samstag, den 30.12.2017, 17:52 -0500 schrieb Scott Kostyshak:
> I'm concerned that the insert menu is becoming too long. See the
> attached screenshot. I recognize that I do have a small laptop screen
> (13 in, with 1360 x 767 resolution), but I'm guessing I'm not the
> only
> one. If four entries are added to the Insert menu, such as:
> 
> - Prepend New Environment (Itemize)
> - Prepend New Environment (Frame)
> - Append New Environment (Itemize)
> - Append new Environment (Frame)
> 
> I think I will have to use a scroll arrow between the entries in the
> insert menu.

Note that max. 3 entries are added. In many cases only 2 or 1. But I
agree it's a long menu.

A submenu is not an option IMO. That lowers accessibility.

> Not thinking about screen space, I do think that Insert is the most
> intuitive for new users. I think the Edit menu could be more
> intuitive
> if the names of the entries were "split environment" (like in the
> LFUN
> name): splitting to me is an edit operation, but "adding" and
> "prepending" sound more like "inserting" to me.

I fear that "splitting" is not so clear to unexperienced users.

Jürgen

> 
> In summary, I'm conflicted.
> 
> Scott

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Samstag, den 30.12.2017, 22:52 -0500 schrieb Richard Heck:
> Can someone put the 9261 patch on trac so it's more accessible?

Done.

Jürgen

> 
> rh
> 

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Sonntag, den 31.12.2017, 01:28 -0500 schrieb Scott Kostyshak:
> On Sat, Dec 30, 2017 at 04:07:19PM +, Richard Heck wrote:
> 
> > That said, this strikes me too as enough of an improvement to
> > warrant a
> > late change.
> > I've found these same aspects of the Beamer implementation
> > unintuitive.
> 
> What exactly are we talking about potentially backporting? Is it the
> following changes?
> 
> 1. http://www.lyx.org/trac/ticket/10954
> 2. http://www.lyx.org/trac/ticket/10955
> 3. http://www.lyx.org/trac/ticket/10956
> 4. Move entries from Edit menu to Insert menu.

Yes. Plus (possibly) the painter change I proposed in this thread.

> And to be clear, the proposal is to consider these for 2.3.0, right?
> (not, e.g. a later 2.3.x release)

Depends on the layout format change policy. Or we could, as Kornel
suggested, just backport the auto-nest feature now (with the layout
format change), and do the others later.

I'd think: If we touch the docs and strings (two new UI strings BTW,
and [rather small] changes to Customization.lyx, UserGuide.lyx and
beamer.lyx), we could do it now (or later) for all changes.

Jürgen

> I'd like to make sure I understand correctly before I take a deeper
> look.
> 
> Scott

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Kornel Benko]

Am Samstag, 30. Dezember 2017 um 11:40:19, schrieb Jürgen Spitzmüller 

> Am Samstag, den 30.12.2017, 10:32 + schrieb José Abílio Matos:
> > The invariant in our stable series was always to keep the same file
> > format. In my humble opinion this is a very good practice and
> > something that we should continue.
> 
> Right. I am talking about the layout format here, though.
> 
> Jürgen

Why not proceed with format change for 2.3.0 and implement the UI later?

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Beamer usage again

[Scott Kostyshak]

On Sat, Dec 30, 2017 at 04:07:19PM +, Richard Heck wrote:

> That said, this strikes me too as enough of an improvement to warrant a
> late change.
> I've found these same aspects of the Beamer implementation unintuitive.

What exactly are we talking about potentially backporting? Is it the
following changes?

1. http://www.lyx.org/trac/ticket/10954
2. http://www.lyx.org/trac/ticket/10955
3. http://www.lyx.org/trac/ticket/10956
4. Move entries from Edit menu to Insert menu.

And to be clear, the proposal is to consider these for 2.3.0, right?
(not, e.g. a later 2.3.x release)

I'd like to make sure I understand correctly before I take a deeper
look.

Scott


signature.asc
Description: PGP signature

Re: Beamer usage again

[Joel Kulesza]

On Sun, Dec 31, 2017 at 12:52 PM, Richard Heck  wrote:

> On 12/30/2017 06:56 PM, Joel Kulesza wrote:
>
> On Sun, Dec 31, 2017 at 1:55 AM, Jürgen Spitzmüller  wrote:
>
>> Am Samstag, den 30.12.2017, 10:48 +0100 schrieb Pavel Sanda:
>> > I think we can safely go for it.
>> > Given that we already have two overlay item in the menu, we might
>> > want to group
>> > them at the end of insert menu?
>>
>> Done.
>>
>
> Jürgen,
>
> I pulled 9f9c2e02 and applied the 9261 patch.  From there, attempting to
> use Insert > Frame gives me a crash.
>
>
> Can someone put the 9261 patch on trac so it's more accessible?
>

I'll defer and Jürgen to in case he wants to make changes before doing so.

- Joel

Re: Beamer usage again

[Richard Heck]

On 12/30/2017 06:56 PM, Joel Kulesza wrote:
> On Sun, Dec 31, 2017 at 1:55 AM, Jürgen Spitzmüller  > wrote:
>
> Am Samstag, den 30.12.2017, 10:48 +0100 schrieb Pavel Sanda:
> > I think we can safely go for it.
> > Given that we already have two overlay item in the menu, we might
> > want to group
> > them at the end of insert menu?
>
> Done.
>
>
> Jürgen,
>
> I pulled 9f9c2e02 and applied the 9261 patch.  From there, attempting
> to use Insert > Frame gives me a crash. 

Can someone put the 9261 patch on trac so it's more accessible?

rh

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Samstag, den 30.12.2017, 10:48 +0100 schrieb Pavel Sanda:
> I think we can safely go for it.
> Given that we already have two overlay item in the menu, we might
> want to group
> them at the end of insert menu?

Done.

Jürgen

> 
> Pavel

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Richard Heck]

On 12/30/2017 05:52 AM, José Abílio Matos wrote:
>
> On Saturday, 30 December 2017 10.40.19 WET Jürgen Spitzmüller wrote:
>
> > Right. I am talking about the layout format here, though.
>
> >
>
> > Jürgen
>
>  
>
> Oops. :-)
>
> You are right.
>
>  
>
> IIRC we have been a little bit more permissive in this case. :-)
>

But I think the same rule should apply, if only because the layout
format becomes
part of the file format via local layout. But there's also an issue
about sharing layout
files across minor versions.

That said, this strikes me too as enough of an improvement to warrant a
late change.
I've found these same aspects of the Beamer implementation unintuitive.

Richard

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Samstag, den 30.12.2017, 21:25 +0900 schrieb Joel Kulesza:
> I've pulled (1ff34a97) and tested along with your 9261 patch.  It
> doesn't appear to work for me as I'd expect; please
> see: https://youtu.be/sEIFW9Vo0UY.

OK, I see now that it does not make sense to have this separate
function. I reverted it and disabled the function at this position.
Appending here is the same as prepending (with this particular cursor
position).

> > > Append from within the frame.  I can't recall if I demonstrated
> > this
> > > in my video, but it splits the current frame rather than
> > inserting a
> > > new frame after the current one.
> > 
> > This is intentional. The splitting always is relative to the cursor
> > position.
> 
> I understand this is intentional, but what is the rationale behind
> the decision to do this rather than to keep the frame a standalone
> component that exists before/after the current frame?  

If we would always move the cursor to the start/end of the environment
first, there would not be a way to split in between. As it is now, you
have full control over where the new environment is to start.

> As an aside: given the splitting, is append (and failing to mention
> the splitting) misleading in the menu entry? 

I'll rename it anyway when moving to insert.

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Richard Heck]

On 12/30/2017 06:00 AM, Jürgen Spitzmüller wrote:
> Am Samstag, den 30.12.2017, 11:30 +0900 schrieb Joel Kulesza:
>> I've tried to demonstrate with screen recording what I tried to
>> illustrate with my screenshot previously.  There are places I can
>> position the cursor where the Edit menus vary and produce varying
>> behavior.  I would expect that anywhere between "Frame" and the
>> horizontal separator to have the ability to pre/append a Frame and to
>> have it be created properly. Please use the MWE attached to further
>> explore the variation in the edit menu entries based on cursor
>> position and eventual action outcome: whether a self-contained frame
>> is inserted, or not.
> I have fixed the second problem (appending from the separator) in
> master. Please test.
>
> I am not sure how to fix the first issue. Actually, the procedure
> works. The problem ist, though, that an empty new frame is inserted,
> which is rightly deleted again by the delete empty paragraphs
> mechanism. This is really hard to fix in a general way.

KeepEmpty 1?

rh

Re: Beamer usage again

[Joel Kulesza]

On Sat, Dec 30, 2017 at 8:52 PM, Jürgen Spitzmüller  wrote:

> Am Samstag, den 30.12.2017, 20:19 +0900 schrieb Joel Kulesza:
> > > I am not sure how to fix the first issue. Actually, the procedure
> > > works. The problem ist, though, that an empty new frame is
> > > inserted,
> > > which is rightly deleted again by the delete empty paragraphs
> > > mechanism. This is really hard to fix in a general way.
>
> I found a solution.
>
> > As I see it, the remaining actions are not yet working:
> > Prepend from separator (missing menu entry).
>
> I won't add this now.
>
> > Append from frame (misbehavior as you described).
>
> Fixed.
>

I've pulled (1ff34a97) and tested along with your 9261 patch.  It doesn't
appear to work for me as I'd expect; please see:
https://youtu.be/sEIFW9Vo0UY.


> > Append from within the frame.  I can't recall if I demonstrated this
> > in my video, but it splits the current frame rather than inserting a
> > new frame after the current one.
>
> This is intentional. The splitting always is relative to the cursor
> position.


I understand this is intentional, but what is the rationale behind the
decision to do this rather than to keep the frame a standalone component
that exists before/after the current frame?  As an aside: given the
splitting, is append (and failing to mention the splitting) misleading in
the menu entry?

Thanks,
Joel

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Samstag, den 30.12.2017, 20:19 +0900 schrieb Joel Kulesza:
> > I am not sure how to fix the first issue. Actually, the procedure
> > works. The problem ist, though, that an empty new frame is
> > inserted,
> > which is rightly deleted again by the delete empty paragraphs
> > mechanism. This is really hard to fix in a general way.

I found a solution.

> As I see it, the remaining actions are not yet working:
> Prepend from separator (missing menu entry).

I won't add this now.

> Append from frame (misbehavior as you described).

Fixed.

> Append from within the frame.  I can't recall if I demonstrated this
> in my video, but it splits the current frame rather than inserting a
> new frame after the current one.

This is intentional. The splitting always is relative to the cursor
position.

> Prepend from within the frame (no menu entry).

Won't add this now.

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Samstag, den 30.12.2017, 20:25 +0900 schrieb Joel Kulesza:
> Thank you for the clarification; however, I would leave out the word
> environment (I'm not sure what value it's adding for the novice or
> average user).  I would suggest adding new expanding menus in the
> Insert Menu so
> 
> Insert > Math > ...
> ...
> Insert > Box > ...
> Insert > New Frame > Above
> Insert > New Frame > Below 
> Insert > New Itemize > Above
> Insert > New Itemize > Below
> etc.
> 
> Where frame/itemize/etc. conditionally appear or appear
> grayed/available depending on whether the cursor is at a valid
> position to perform the insertion.
> 
> I think this would allow a user, who would most likely go to the
> insert menu to insert a frame/slide, to most quickly identify what
> they want and then let them select the desired position.  Part of my
> suggestion of nesting comes from the Insert menu already becoming
> quite long (particularly when Beamer is being used).

No, sorry, this strikes me too complicated (and I've already invested
way too much time in this).

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Joel Kulesza]

On Sat, Dec 30, 2017 at 8:19 PM, Jürgen Spitzmüller  wrote:

> Am Samstag, den 30.12.2017, 20:09 +0900 schrieb Joel Kulesza:
> > One concern: the language used, while precise, isn't too self-
> > descriptive for a LaTeX / LyX novice.  My understanding is that part
> > of the need for precision stems from covering various environments
> > (e.g. an inner enumerate versus the outer frame).  Also, to a novice,
> > I'm not sure that "Environment" means much.  Instead of what's
> > proposed by Jürgen, I'd propose Insert > New  >
> > Above / Below where there is an additional level of nesting to the
> > two choices, Above and Below.  The environment name would be Frame,
> > Enumerate, etc.  I also wonder if we need to keep the designations of
> > inner/outer/parent/etc.  Thoughts?
>
> I have been imprecise. I meant to include the concrete layout name, as
> we already do. So "Insert > Separate Environment () Above"
>

Thank you for the clarification; however, I would leave out the word
environment (I'm not sure what value it's adding for the novice or average
user).  I would suggest adding new expanding menus in the Insert Menu so

Insert > Math > ...
...
Insert > Box > ...
Insert > New Frame > Above
Insert > New Frame > Below
Insert > New Itemize > Above
Insert > New Itemize > Below
etc.

Where frame/itemize/etc. conditionally appear or appear grayed/available
depending on whether the cursor is at a valid position to perform the
insertion.

I think this would allow a user, who would most likely go to the insert
menu to insert a frame/slide, to most quickly identify what they want and
then let them select the desired position.  Part of my suggestion of
nesting comes from the Insert menu already becoming quite long
(particularly when Beamer is being used).

Thanks,
Joel

Re: Beamer usage again

[Joel Kulesza]

On Sat, Dec 30, 2017 at 8:00 PM, Jürgen Spitzmüller  wrote:

> Am Samstag, den 30.12.2017, 11:30 +0900 schrieb Joel Kulesza:
> > Please excuse the typos in: https://youtu.be/yZyx_RaFynU
> >
> > Please let me know if there is a better way to provide such examples.
>
> This is excellent, thank you for the efforts.
>
> > I've tried to demonstrate with screen recording what I tried to
> > illustrate with my screenshot previously.  There are places I can
> > position the cursor where the Edit menus vary and produce varying
> > behavior.  I would expect that anywhere between "Frame" and the
> > horizontal separator to have the ability to pre/append a Frame and to
> > have it be created properly. Please use the MWE attached to further
> > explore the variation in the edit menu entries based on cursor
> > position and eventual action outcome: whether a self-contained frame
> > is inserted, or not.
>
> I have fixed the second problem (appending from the separator) in
> master. Please test.
>

I can confirm that appending from the separator is fixed (thank you!).
Prepend is still "missing" from the Edit menu.


> I am not sure how to fix the first issue. Actually, the procedure
> works. The problem ist, though, that an empty new frame is inserted,
> which is rightly deleted again by the delete empty paragraphs
> mechanism. This is really hard to fix in a general way.
>

Understood, and my thanks again for your work to get everything functional
and consistent.

As I see it, the remaining actions are not yet working:

   - Prepend from separator (missing menu entry).
   - Append from frame (misbehavior as you described).
   - Append from within the frame.  I can't recall if I demonstrated this
   in my video, but it splits the current frame rather than inserting a new
   frame after the current one.
   - Prepend from within the frame (no menu entry).

For the final two points, create a frame with three itemize items.  I would
expect that if my cursor is within the second item, I could prepend before
the current frame or append after it, without modifying the current frame.
Does this seem sensible?

Thanks,
Joel

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Samstag, den 30.12.2017, 20:09 +0900 schrieb Joel Kulesza:
> One concern: the language used, while precise, isn't too self-
> descriptive for a LaTeX / LyX novice.  My understanding is that part
> of the need for precision stems from covering various environments
> (e.g. an inner enumerate versus the outer frame).  Also, to a novice,
> I'm not sure that "Environment" means much.  Instead of what's
> proposed by Jürgen, I'd propose Insert > New  >
> Above / Below where there is an additional level of nesting to the
> two choices, Above and Below.  The environment name would be Frame,
> Enumerate, etc.  I also wonder if we need to keep the designations of
> inner/outer/parent/etc.  Thoughts?

I have been imprecise. I meant to include the concrete layout name, as
we already do. So "Insert > Separate Environment () Above"

Jürgen

> 
> - Joel
> 

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Joel Kulesza]

On Sat, Dec 30, 2017 at 7:14 PM, Jürgen Spitzmüller  wrote:

> Am Samstag, den 30.12.2017, 10:46 +0100 schrieb Pavel Sanda:
> > > From what I understand, there is no new string that would be added.
> > > The
> > > question is just about the translations of the help documents. Is
> > > that
> > > right?
> >
> > Unfortunately no, there is another new string for prepending the
> > slide.
>
> Correct. And I've changed "Start New Environment" to "Append New
> Environment" (in order to differentiate append/prepend). If I'd move
> the items to Insert, I would also propose to change the wording (from
> "Edit > Prepend New Environment" and "Edit > Append New Environment" to
> "Insert > Separate Environment Above" and "Insert > Separate
> Environment Below")
>

One concern: the language used, while precise, isn't too self-descriptive
for a LaTeX / LyX novice.  My understanding is that part of the need for
precision stems from covering various environments (e.g. an inner enumerate
versus the outer frame).  Also, to a novice, I'm not sure that
"Environment" means much.  Instead of what's proposed by Jürgen, I'd
propose Insert > New  > Above / Below where there is an
additional level of nesting to the two choices, Above and Below.  The
environment name would be Frame, Enumerate, etc.  I also wonder if we need
to keep the designations of inner/outer/parent/etc.  Thoughts?

- Joel

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Samstag, den 30.12.2017, 11:30 +0900 schrieb Joel Kulesza:
> Please excuse the typos in: https://youtu.be/yZyx_RaFynU
> 
> Please let me know if there is a better way to provide such examples.

This is excellent, thank you for the efforts.

> I've tried to demonstrate with screen recording what I tried to
> illustrate with my screenshot previously.  There are places I can
> position the cursor where the Edit menus vary and produce varying
> behavior.  I would expect that anywhere between "Frame" and the
> horizontal separator to have the ability to pre/append a Frame and to
> have it be created properly. Please use the MWE attached to further
> explore the variation in the edit menu entries based on cursor
> position and eventual action outcome: whether a self-contained frame
> is inserted, or not.

I have fixed the second problem (appending from the separator) in
master. Please test.

I am not sure how to fix the first issue. Actually, the procedure
works. The problem ist, though, that an empty new frame is inserted,
which is rightly deleted again by the delete empty paragraphs
mechanism. This is really hard to fix in a general way.

> > As I wrote, I think "Frame" is the expected default layout within a
> > Frame. It's synonymous to nested "Standard".
> 
> That's fine (and with the 9261 behavior, I'm much less opposed to how
> things behave); however, does this require a level of knowledge on
> the part of the user (regarding the subtleties of nested
> environments) that is reasonable?  Again, using the PowerPoint straw
> man, most people think of presentations as collections of
> slides/frames with content.  What does it mean to have frame-within-
> frame?

You're right that it should be usable (at least for basic
presentations) without having to read manuals. But it's a particular
tricky case.

Thanks again,
Jürgen

>  
> > Thanks for testing,
> > Jürgen
> 
> Thanks for the continued work and constructive dialog,
> Joel 
> 

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[José Abílio Matos]

On Saturday, 30 December 2017 10.40.19 WET Jürgen Spitzmüller wrote:
> Right. I am talking about the layout format here, though.
> 
> Jürgen

Oops. :-)
You are right.

IIRC we have been a little bit more permissive in this case. :-)

Happy new year. :-)
-- 
José Abílio

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Samstag, den 30.12.2017, 10:32 + schrieb José Abílio Matos:
> The invariant in our stable series was always to keep the same file
> format. In my humble opinion this is a very good practice and
> something that we should continue.

Right. I am talking about the layout format here, though.

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[José Abílio Matos]

On Saturday, 30 December 2017 10.14.53 WET Jürgen Spitzmüller wrote:
> Note, further, that this entails a layout format change. I am not sure
> what our current policy is wrt introducing this within a stable series.
> If we don't do that, no for 2.3.0 would mean no for 2.3.x.
> 
> Jürgen

The invariant in our stable series was always to keep the same file format. In 
my humble opinion 
this is a very good practice and something that we should continue.

With that said beamer support is something very useful. After spending much of 
the semester 
composing slides with lyx (in beamer) I appreciate an improved support for 
beamer. This is one 
of the areas where it is more difficult for newcomers to grasp (from personal 
experience).

There are then two choices: 1) incorporate the changes in 2.3 as they are more 
or less self-
contained or 2) have a short development cycle for 2.4.

Any of the two options has risks and advantages.
-- 
José Abílio

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Samstag, den 30.12.2017, 10:46 +0100 schrieb Pavel Sanda:
> > From what I understand, there is no new string that would be added.
> > The
> > question is just about the translations of the help documents. Is
> > that
> > right?
> 
> Unfortunately no, there is another new string for prepending the
> slide.

Correct. And I've changed "Start New Environment" to "Append New
Environment" (in order to differentiate append/prepend). If I'd move
the items to Insert, I would also propose to change the wording (from
"Edit > Prepend New Environment" and "Edit > Append New Environment" to
"Insert > Separate Environment Above" and "Insert > Separate
Environment Below")

> OTOH this set of patches quite improve the beamer situation.

Definitely, but I can understand that Scott needs to draw a line
somewhere.

Note, further, that this entails a layout format change. I am not sure
what our current policy is wrt introducing this within a stable series.
If we don't do that, no for 2.3.0 would mean no for 2.3.x.

Jürgen

> Pavel

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Samstag, den 30.12.2017, 10:44 +0100 schrieb Pavel Sanda:
> I do not see how this patch affects things out of beamer scope

It applies to all environments with a label. But I think they all
benefit from the improvement.

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> Am Donnerstag, den 28.12.2017, 22:58 +0100 schrieb Pavel Sanda:
> > We can definitely do it in the master.
> 
> Any objections to this?

I think we can safely go for it.
Given that we already have two overlay item in the menu, we might want to group
them at the end of insert menu?

Pavel

Re: Beamer usage again

[Pavel Sanda]

Scott Kostyshak wrote:
> On Thu, Dec 28, 2017 at 09:58:23PM +, Pavel Sanda wrote:
> > Jürgen Spitzmüller wrote:
> > > >a) one looks into insert menu, but starting new beamer environment
> > > > is hidden in edit menu once it appears, not intuitive
> > > 
> > > Moving this to Insert is the easiest thing. I don't have a strong
> > > preference on this, but take care to do it at a point where the
> > > documentation and translation can catch up.
> > 
> > We can definitely do it in the master.
> > The change looks valuable enough to have it in 2.3 as well,
> > but we already added new string I do not know whether we'd get
> > green light from Scott?
> 
> From what I understand, there is no new string that would be added. The
> question is just about the translations of the help documents. Is that
> right?

Unfortunately no, there is another new string for prepending the slide.
OTOH this set of patches quite improve the beamer situation.

Pavel

Re: Beamer usage again

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> Am Freitag, den 29.12.2017, 09:52 +0100 schrieb Jürgen Spitzmüller:
> > Exactly. Frame is the thing to use if you need just a standard
> > paragraph (nested standard is practically the same).
> > 
> > The on-screen display is sub-optimal, which leads to irritation. See
> > http://www.lyx.org/trac/ticket/9261
> > 
> > But again, this is not a beamer frame only problem, but applies to
> > all environments.
> 
> The attached patch addresses this. It paints the nested marker also for
> follow-up paragraphs in a paragraph group.
> 
> IMHO this gives a better (and consistent) indication of what belongs to
>  an environment.
> 
> What do you think?

I do not see how this patch affects things out of beamer scope, but for
slides it looks good. At this moment both frame/nested standard show indication
of nestedness and the situation of non-nested standard looks visually
unusual -- which gives clue to the user that somethong went wrong.
Which is exactly what we want - to give intuitive clues without user
need to read manual.

Pavel

Re: Beamer usage again

[Scott Kostyshak]

On Thu, Dec 28, 2017 at 09:58:23PM +, Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > >a) one looks into insert menu, but starting new beamer environment
> > > is hidden in edit menu once it appears, not intuitive
> > 
> > Moving this to Insert is the easiest thing. I don't have a strong
> > preference on this, but take care to do it at a point where the
> > documentation and translation can catch up.
> 
> We can definitely do it in the master.
> The change looks valuable enough to have it in 2.3 as well,
> but we already added new string I do not know whether we'd get
> green light from Scott?

From what I understand, there is no new string that would be added. The
question is just about the translations of the help documents. Is that
right?

Scott


signature.asc
Description: PGP signature

Re: Beamer usage again

[Joel Kulesza]

On Sat, Dec 30, 2017 at 12:45 AM, Jürgen Spitzmüller  wrote:

> Am Freitag, den 29.12.2017, 22:16 +0900 schrieb Joel Kulesza:
> > When within the Frame (e.g., I've typed my last itemize bullet),
> > Append new parent environment works as expected.  However, if after
> > having made additional modifications, there are a couple positions
> > that the cursor can exist where Appending a new frame doesn't give
> > expected behavior.
>
> Can you give concrete examples, please?
>

Please excuse the typos in: https://youtu.be/yZyx_RaFynU

Please let me know if there is a better way to provide such examples.

I've tried to demonstrate with screen recording what I tried to illustrate
with my screenshot previously.  There are places I can position the cursor
where the Edit menus vary and produce varying behavior.  I would expect
that anywhere between "Frame" and the horizontal separator to have the
ability to pre/append a Frame and to have it be created properly. Please
use the MWE attached to further explore the variation in the edit menu
entries based on cursor position and eventual action outcome: whether a
self-contained frame is inserted, or not.

Part of what I'm trying to communicate is how folks coming to Beamer from
something like PowerPoint may perceive things.  The subtleties of frame
environments, their contents (inner/outer), etc. shouldn't necessarily be
required knowledge.  Instead, it seems much more intuitive to me to have
the ability to anywhere prepend or append a frame relative to the cursor
position and have the frame appear properly.  Thus, I would expect that
anywhere I can have the cursor, my two Edit (or preferred: Insert) menu
entries are prepend and append frame and that the empty frame will be
created where and as requested.

> In some positions, prepending isn't available; however, it is
> > reasonable to want to insert a Frame before the one associated with
> > the cursor position.
>
> It's only available in the respective layout (i.e., the layout the
> cursor is in must be "Frame"). That's by design. I could add "Prepend
> outer", but that would be more difficult.
>
> > Having applied your 9261.diff:
> >
> > Now, when I  following the creation of a Frame, I'm
> > automatically nested (nice!) but the environment is still Frame
> > versus itemize, enumerate, standard, etc.  Again, I wonder if this
> > should be changed.  However, I think this more-directly speaks to my
> > earlier email regarding the appearance of "Frame" within the Frame.
>
> As I wrote, I think "Frame" is the expected default layout within a
> Frame. It's synonymous to nested "Standard".
>

That's fine (and with the 9261 behavior, I'm much less opposed to how
things behave); however, does this require a level of knowledge on the part
of the user (regarding the subtleties of nested environments) that is
reasonable?  Again, using the PowerPoint straw man, most people think of
presentations as collections of slides/frames with content.  What does it
mean to have frame-within-frame?


> Thanks for testing,
> Jürgen


Thanks for the continued work and constructive dialog,
Joel


beamer_cursor_regions.lyx
Description: Binary data

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Freitag, den 29.12.2017, 21:54 +0900 schrieb Joel Kulesza:
> Thank you for the quick and extensive work to address several of
> these beamer issues!  Given all that, I've downloaded/compiled master
> @3a4b233d.  The issue I'm commenting on is shown in the attached
> screenshot.  To reproduce:
> 
> 1. Launch LyX and change document type to Beamer
> 2. Change to a frame, enter a title, arrow over to the right, hit
> 
> 3.  in.  You have Frame.

Yes, that's expected.

> Rather than Frame, I'd imagine this would be set to something else.
> I'd prefer Itemize; maybe Enumerate is preferred by others.  Maybe
> Standard makes the most neutral choice?  Regardless, is there a way
> to get this changed from Frame to another default that is closer to
> what one might like (I cannot imagine when Frame would be what's
> wanted here)?  Or, have I done/misinterpreted something wrong?

I think this situation is much less likely to happen with all the
changes I've done (plus the painter changes proposed today).

In any case, we do not have the framework (yet) to change the layout on
tab or return action.

Jürgen

> 
> Thank you,
> Joel

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Freitag, den 29.12.2017, 22:16 +0900 schrieb Joel Kulesza:
> When within the Frame (e.g., I've typed my last itemize bullet),
> Append new parent environment works as expected.  However, if after
> having made additional modifications, there are a couple positions
> that the cursor can exist where Appending a new frame doesn't give
> expected behavior.  

Can you give concrete examples, please?

> In some positions, prepending isn't available; however, it is
> reasonable to want to insert a Frame before the one associated with
> the cursor position.

It's only available in the respective layout (i.e., the layout the
cursor is in must be "Frame"). That's by design. I could add "Prepend
outer", but that would be more difficult.

> Having applied your 9261.diff:
> 
> Now, when I  following the creation of a Frame, I'm
> automatically nested (nice!) but the environment is still Frame
> versus itemize, enumerate, standard, etc.  Again, I wonder if this
> should be changed.  However, I think this more-directly speaks to my
> earlier email regarding the appearance of "Frame" within the Frame.

As I wrote, I think "Frame" is the expected default layout within a
Frame. It's synonymous to nested "Standard".

Thanks for testing,
Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Freitag, den 29.12.2017, 09:52 +0100 schrieb Jürgen Spitzmüller:
> Exactly. Frame is the thing to use if you need just a standard
> paragraph (nested standard is practically the same).
> 
> The on-screen display is sub-optimal, which leads to irritation. See
> http://www.lyx.org/trac/ticket/9261
> 
> But again, this is not a beamer frame only problem, but applies to
> all environments.

The attached patch addresses this. It paints the nested marker also for
follow-up paragraphs in a paragraph group.

IMHO this gives a better (and consistent) indication of what belongs to
 an environment.

What do you think?

Jürgen
diff --git a/src/RowPainter.cpp b/src/RowPainter.cpp
index 6fbc783b35..69b480d185 100644
--- a/src/RowPainter.cpp
+++ b/src/RowPainter.cpp
@@ -272,7 +272,12 @@ void RowPainter::paintAppendix() const
 
 void RowPainter::paintDepthBar() const
 {
-	depth_type const depth = par_.getDepth();
+	depth_type depth = par_.getDepth();
+
+	// We also mark follow-up paragraphs in a paragraph group
+	if (par_.layout().isParagraphGroup()
+	&& !text_.isFirstInSequence(row_.pit()))
+		++depth;
 
 	if (depth <= 0)
 		return;
@@ -283,6 +288,10 @@ void RowPainter::paintDepthBar() const
 		if (row_.pos() == 0)
 			--pit2;
 		prev_depth = pars_[pit2].getDepth();
+		// We also mark follow-up paragraphs in a paragraph group
+		if (pars_[pit2].layout().isParagraphGroup()
+		&& !text_.isFirstInSequence(pit2))
+			++prev_depth;
 	}
 
 	depth_type next_depth = 0;
@@ -291,6 +300,10 @@ void RowPainter::paintDepthBar() const
 		if (row_.endpos() >= pars_[pit2].size())
 			++pit2;
 		next_depth = pars_[pit2].getDepth();
+		// We also mark follow-up paragraphs in a paragraph group
+		if (pars_[pit2].layout().isParagraphGroup()
+		&& !text_.isFirstInSequence(pit2))
+			++next_depth;
 	}
 
 	for (depth_type i = 1; i <= depth; ++i) {


signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> I don't know either. In any case, I will trac all these changes so we
> have them recorded for potential later backports.

Thanks Juergen for your prompt feedback :)
Pavel

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Donnerstag, den 28.12.2017, 17:14 -0500 schrieb Richard Heck:
> Yes, it works just like Theorem. Note that the Frame environment does
> NOT need to be nested, whereas Standard does have to be. This takes a
> little getting used to, but in the end I think it works.

Exactly. Frame is the thing to use if you need just a standard
paragraph (nested standard is practically the same).

The on-screen display is sub-optimal, which leads to irritation. See
http://www.lyx.org/trac/ticket/9261

But again, this is not a beamer frame only problem, but applies to all
environments.

Jürgen

> 
> Richard
> 

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Donnerstag, den 28.12.2017, 22:58 +0100 schrieb Pavel Sanda:
> We can definitely do it in the master.

Any objections to this?

> The change looks valuable enough to have it in 2.3 as well,
> but we already added new string I do not know whether we'd get
> green light from Scott?

I don't know either. In any case, I will trac all these changes so we
have them recorded for potential later backports.

Jürgen

> Pavel

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Donnerstag, den 28.12.2017, 23:07 +0100 schrieb Pavel Sanda:
> Now I see what you mean. Is the fact that enter in frame environment
> leads to
> new line with (again) frame environment instead of (say) standard
> environment
> intentional?

Yes.

Jürgen

> 
> Pavel

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Richard Heck]

On 12/28/2017 05:07 PM, Pavel Sanda wrote:
> Pavel Sanda wrote:
>> Jürgen Spitzmüller wrote:
>>> Am Donnerstag, den 28.12.2017, 10:24 +0100 schrieb Jürgen Spitzmüller:
>b) maybe there is some visual way to signalize that nesting is needed?
 I thought about something like auto-nesting. But this is certainly
 tricky to implement.
>>> Done in master. Please test.
>> I am lost. What should I see/check? Pavel
> Now I see what you mean. Is the fact that enter in frame environment leads to 
> new line with (again) frame environment instead of (say) standard environment 
> intentional?

Yes, it works just like Theorem. Note that the Frame environment does
NOT need to be nested, whereas Standard does have to be. This takes a
little getting used to, but in the end I think it works.

Richard

Re: Beamer usage again

[Pavel Sanda]

Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > Am Donnerstag, den 28.12.2017, 10:24 +0100 schrieb Jürgen Spitzmüller:
> > > >b) maybe there is some visual way to signalize that nesting is 
> > > > needed?
> > > 
> > > I thought about something like auto-nesting. But this is certainly
> > > tricky to implement.
> > 
> > Done in master. Please test.
> 
> I am lost. What should I see/check? Pavel

Now I see what you mean. Is the fact that enter in frame environment leads to
new line with (again) frame environment instead of (say) standard environment
intentional?

Pavel

Re: Beamer usage again

[Pavel Sanda]

Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > > > 1. Can't find way how to insert new slide.
> > > >b) if one breaks proper nesting in already existing slide the menu
> > > > option completely disappears so one has no clue whether such option
> > > > even exists in lyx
> > > >   maybe we can have disable menu option at least to signalize
> > > > that in some condition it is accessible?
> > > 
> > > Even better would be a way to keep it active. We could add one more
> > > option ("New previous environment (Frame)") that gets active in this
> > > case.
> > 
> > This one is addressed now in master. Please test.
> 
> Yep, not its visible. P

'not' -> 'now' 

Re: Beamer usage again

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> >a) one looks into insert menu, but starting new beamer environment
> > is hidden in edit menu once it appears, not intuitive
> 
> Moving this to Insert is the easiest thing. I don't have a strong
> preference on this, but take care to do it at a point where the
> documentation and translation can catch up.

We can definitely do it in the master.
The change looks valuable enough to have it in 2.3 as well,
but we already added new string I do not know whether we'd get
green light from Scott?

Pavel

Re: Beamer usage again

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> Am Donnerstag, den 28.12.2017, 10:24 +0100 schrieb Jürgen Spitzmüller:
> > >b) maybe there is some visual way to signalize that nesting is needed?
> > 
> > I thought about something like auto-nesting. But this is certainly
> > tricky to implement.
> 
> Done in master. Please test.

I am lost. What should I see/check? Pavel

Re: Beamer usage again

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> Am Donnerstag, den 28.12.2017, 10:24 +0100 schrieb Jürgen Spitzmüller:
> > >c) what is the fastest way how to add new beamer slide when one is
> > > in the _begining_ of slides?
> > >   'Start New Environment' just breaks the first slide instead of
> > > creating a new one.
> > >   I need to do many steps to make that happen which feels wrong
> > > but perhaps I missed something obvious?
> > 
> > This is indeed still unsatisfactory. I am not sure what to do with the
> > current means. We could try to add a "Prepend new environment"
> > function.
> 
> Addressed in master now as well. Please test.

Cool, this seems much better now. P

Re: Beamer usage again

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> > > 1. Can't find way how to insert new slide.
> > >b) if one breaks proper nesting in already existing slide the menu
> > > option completely disappears so one has no clue whether such option
> > > even exists in lyx
> > >   maybe we can have disable menu option at least to signalize
> > > that in some condition it is accessible?
> > 
> > Even better would be a way to keep it active. We could add one more
> > option ("New previous environment (Frame)") that gets active in this
> > case.
> 
> This one is addressed now in master. Please test.

Yep, not its visible. P

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Donnerstag, den 28.12.2017, 10:26 +0100 schrieb Jürgen Spitzmüller:
> Am Donnerstag, den 28.12.2017, 13:54 +0900 schrieb Joel Kulesza:
> > Another point of feedback that was brought to me from a new-ish but
> > enthusiastic and savvy LyX user: once a new slide/frame is inserted
> > and the frame title is entered, going to a new line and hitting
> > 
> > keeps the Frame environment when it would more(most?) logically be
> > the itemize environment.  Is there a reason that the interface
> > behaves this way, or is this an enhancement waiting to happen?
> 
> The latter. It is not possible to do this in LyX at the moment. It
> would need some "NestedChild " tag.

I think this is no longer needed with the auto-nesting feature I just
implemented in master (not 2.3.x). Now you just go to a new line and
change to itemize (or whatever), and it will be automatically nested in
the frame.

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Donnerstag, den 28.12.2017, 10:24 +0100 schrieb Jürgen Spitzmüller:
> >b) maybe there is some visual way to signalize that nesting is
> > needed?
> 
> I thought about something like auto-nesting. But this is certainly
> tricky to implement.

Done in master. Please test.

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Donnerstag, den 28.12.2017, 10:24 +0100 schrieb Jürgen Spitzmüller:
> >c) what is the fastest way how to add new beamer slide when one
> is
> > in the _begining_ of slides?
> >   'Start New Environment' just breaks the first slide instead
> of
> > creating a new one.
> >   I need to do many steps to make that happen which feels wrong
> > but perhaps I missed something obvious?
> 
> This is indeed still unsatisfactory. I am not sure what to do with
> the
> current means. We could try to add a "Prepend new environment"
> function.

Addressed in master now as well. Please test.

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Donnerstag, den 28.12.2017, 10:24 +0100 schrieb Jürgen Spitzmüller:
> Am Donnerstag, den 28.12.2017, 05:27 +0100 schrieb Pavel Sanda:
> > The major issues I experienced right now:
> > 1. Can't find way how to insert new slide.
> >b) if one breaks proper nesting in already existing slide the
> > menu
> > option completely disappears so one has no clue whether such option
> > even exists in lyx
> >   maybe we can have disable menu option at least to signalize
> > that in some condition it is accessible?
> 
> Even better would be a way to keep it active. We could add one more
> option ("New previous environment (Frame)") that gets active in this
> case.

This one is addressed now in master. Please test.

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Donnerstag, den 28.12.2017, 13:54 +0900 schrieb Joel Kulesza:
> Another point of feedback that was brought to me from a new-ish but
> enthusiastic and savvy LyX user: once a new slide/frame is inserted
> and the frame title is entered, going to a new line and hitting 
> keeps the Frame environment when it would more(most?) logically be
> the itemize environment.  Is there a reason that the interface
> behaves this way, or is this an enhancement waiting to happen?

The latter. It is not possible to do this in LyX at the moment. It
would need some "NestedChild " tag.

Jürgen

> 
> Thank you,
> Joel
> 

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Jürgen Spitzmüller]

Am Donnerstag, den 28.12.2017, 05:27 +0100 schrieb Pavel Sanda:
> The major issues I experienced right now:
> 1. Can't find way how to insert new slide.
>b) if one breaks proper nesting in already existing slide the menu
> option completely disappears so one has no clue whether such option
> even exists in lyx
>   maybe we can have disable menu option at least to signalize
> that in some condition it is accessible?

Even better would be a way to keep it active. We could add one more
option ("New previous environment (Frame)") that gets active in this
case.

>a) one looks into insert menu, but starting new beamer environment
> is hidden in edit menu once it appears, not intuitive

Moving this to Insert is the easiest thing. I don't have a strong
preference on this, but take care to do it at a point where the
documentation and translation can catch up.

>c) what is the fastest way how to add new beamer slide when one is
> in the _begining_ of slides?
>   'Start New Environment' just breaks the first slide instead of
> creating a new one.
>   I need to do many steps to make that happen which feels wrong
> but perhaps I missed something obvious?

This is indeed still unsatisfactory. I am not sure what to do with the
current means. We could try to add a "Prepend new environment"
function.

> 2. If one does not find atomic way how to insert slide due to points
> above and tries to do it manually, there are again major obstacles in
> the way:
>a) insert ending of slide. Changing environment to Standard and
> hit enter is not self discoverable. Is there another obvious way?

Not as far as I know. Note that this does not only apply to slides.
This is how the environment separator works nowadays. I agree it could
be better.

>   Could we make it part of insert menu or copy-paste-like from
> other parts of document?
>b) maybe there is some visual way to signalize that nesting is
> needed?

I thought about something like auto-nesting. But this is certainly
tricky to implement.

> I do not expect that all the points raised above have some solution,
> but if we
> can make at least some of them more obvious that would be improvement
> IMHO.

Sure. Thanks for the input.

Jürgen

> 
> Pavel

signature.asc
Description: This is a digitally signed message part

Re: Beamer usage again

[Joel Kulesza]

On Thu, Dec 28, 2017 at 1:27 PM, Pavel Sanda  wrote:

> Hi Juergen,
>
> ...
>
> I do not expect that all the points raised above have some solution, but
> if we
> can make at least some of them more obvious that would be improvement IMHO.


I've also been meaning to write some feedback along these lines.

Going to the Edit menu is *much* less intuitive than the Insert menu.
Perhaps a conditional Insert menu can exist for "New Slide" if the document
type is set to one of the subcategories of Presentation?  I have similarly
experienced that some manipulation is needed when I want to insert a new
slide; it is generally not as simple as ->New slide/frame.

Another point of feedback that was brought to me from a new-ish but
enthusiastic and savvy LyX user: once a new slide/frame is inserted and the
frame title is entered, going to a new line and hitting  keeps the
Frame environment when it would more(most?) logically be the itemize
environment.  Is there a reason that the interface behaves this way, or is
this an enhancement waiting to happen?

Thank you,
Joel

Beamer usage again

[Pavel Sanda]

Hi Juergen,

I am sorry if any of these points was already raised but even though I already
did some slides within the new framework months back working with it again was
so unintuitive that I needed to read beamer manual again just to start even
simplest slides.

Maybe we could do better?

The major issues I experienced right now:
1. Can't find way how to insert new slide.
   b) if one breaks proper nesting in already existing slide the menu option 
completely disappears so one has no clue whether such option even exists in lyx
  maybe we can have disable menu option at least to signalize that in some 
condition it is accessible?
   a) one looks into insert menu, but starting new beamer environment is hidden 
in edit menu once it appears, not intuitive
   c) what is the fastest way how to add new beamer slide when one is in the 
_begining_ of slides?
  'Start New Environment' just breaks the first slide instead of creating a 
new one.
  I need to do many steps to make that happen which feels wrong but perhaps 
I missed something obvious?

2. If one does not find atomic way how to insert slide due to points above and 
tries to do it manually, there are again major obstacles in the way:
   a) insert ending of slide. Changing environment to Standard and hit enter is 
not self discoverable. Is there another obvious way?
  Could we make it part of insert menu or copy-paste-like from other parts 
of document?
   b) maybe there is some visual way to signalize that nesting is needed?


I do not expect that all the points raised above have some solution, but if we
can make at least some of them more obvious that would be improvement IMHO.

Pavel