END-OF-FRAME, once again..

[UD K]

On 10/20/21 1:35 PM, Daniel wrote:
> On 19/10/2021 16:29, Scott Kostyshak wrote:
>> On Thu, Oct 14, 2021 at 03:14:48PM +0200, Daniel wrote:
>>> On 13/10/2021 16:50, Scott Kostyshak wrote:
>>>> On Wed, Oct 13, 2021 at 12:13:30PM +0200, Daniel wrote:
>>>>> Something that I thought while using beamer with LyX was that it 
>>>>> seems that
>>>>> it would be easier if Frames would not "hang together". I mean: 
>>>>> right now,
>>>>> if you press enter at the end or beginning of a frame, you get a 
>>>>> new line
>>>>> that is extending the same frame. Wouldn't it be easier if you get 
>>>>> a new
>>>>> frame this way and instead would just nest stuff in order to get 
>>>>> it onto a
>>>>> specific frame? So, no need for separators either. There may be 
>>>>> issues with
>>>>> this suggestion that I have not thought careful enough about but 
>>>>> on the face
>>>>> of it, it seems like a good idea to me and to solve the issues you
>>>>> mentioned. What do you think?
>>>>
>>>> I think the workflow you're suggesting makes the not-always-true 
>>>> assumption that the user does not use the "frame" layout for the 
>>>> *content* of the frame, and only uses nested layouts (e.g., itemize 
>>>> or standard). Did I understand right?
>>>
>>> Yes. It is not a conservative approach. It suggest to not use the frame
>>> layout for the content because, if I see it correctly, this can be 
>>> equally
>>> achieved by using a nested standard layout. So, why not have just 
>>> one way of
>>> doing things. And it seems to me more consistent in that, say, itemized
>>> lists have to be nested as well within a frame which makes them 
>>> appear at
>>> another level than the content of the frame when not nested but they 
>>> are
>>> not. Isn't that a bit strange or misleading?
>>>
>>> Instead, everything will have to be nested if it should go on a 
>>> frame. (Of
>>> course there must be a lyx2lyx mechanism to transfer old beamer 
>>> documents to
>>> the new "nesting-style".)
>>>
>>> The workflow would in the new style would be like this:
>>>
>>> 1. Select the Frame layout to create a new frame.
>>> 2. Press enter which creates a nested Standard paragraph to add 
>>> content.
>>> 3. Press enter twice to un-nest and get a Frame layout which starts 
>>> a new
>>> frame.
>>>
>>> Doesn't this appear more simple and intuitive?
>>
>> It does. I think it is a reasonable proposal. I'm just not sure 
>> everyone will agree. For example, our own beamer example uses the 
>> frame layout for content.
>>
>>>> What abut making it so that if the user changes the layout to 
>>>> "frame title", then a *new* frame is started (i.e., LyX realizes 
>>>> "oh this frame already has a frame title so the user must want a 
>>>> new frame)?
>>>
>>> I still tend to prefer the way I suggested because of its simplicity
>>> (especially for new users or people who use, say, beamer not 
>>> frequently)
>>> unless it has some flaw I missed.
>>
>> Perhaps we can start by writing some use cases that are currently 
>> annoying with the current interface. Then we can propose different 
>> interfaces to make those workflows easier. I think your proposal is a 
>> reasonable one, but I'm not sure it's the only one. Also, I'm 
>> hesitant to start this conversation since I would really want to see 
>> Jürgen's thoughts and I don't think he has much time these days.
>>
>> The main confusion I see is that I think users would like one key 
>> combination that always produces a new frame. Currently, the user has 
>> to think whether to do "Alt + P, return" or "Alt + P, shift + 
>> return", depending on what nesting level they are currently at. Do 
>> you agree this is the main problem that your proposal and my proposal 
>> were both trying to solve? Is there any other big issue with the 
>> current workflow?
>
> For me the key combinations is already where it starts. I don't use 
> any. I mean, I use the standard ones that work in every application 
> (copy, paste, cut, select all, etc.) But apart from that I never got 
> the hang of learning or using any key combinations specific to some 
> application. I am very much a toolbar and menu guy. In turn, I really 
> appreciate when I have to use these as seldom as possible. Hence my 
> urge to have as many features work with just pressing some obvious 
> keys such as the enter key (several times if need be). But I tend to 
> think I am not the only person who works that way and so far I found 
> professional applications to respect this preference quite well.
>
> Daniel
>
Since I am the one who started this END-OF-FRAME discussion because of 
my inability to do the simplest thing (adding a frame/slide where I 
wanted it), perhaps I should make my problem clearer than I managed to 
do initially.  Depending on where the cursor is in an existing 
presentation document, some commands are not shown in the menus, and 
some keyboard combinations are disabled or do nothing. Since I don''t 
use Lyx/Beamer often, I am hazy about what will work when the cursor is 
somewhere at the end of an existing frame, where I THINK it should be 
ready for a new frame or a frame terminator. If there was a way to force 
a frame terminator at the end of a frame, where it should not mess 
things up, it would make the occasional user less confused and frustrated.
    I can't help but think, still, that this issue suggests that 
something pretty basic is wrong, if one of the most elementary 
operations is problematic.  Lyx's code is opaque to me, so I cannot make 
any useful suggestions, but perhaps, if the designers of the Beamer 
interface tried to understand the casual user's difficulties, some 
simplification could result, and everyone would be a little happier.

EK