On Thursday, July 18, 2024 at 8:24:52 AM UTC-4 [email protected] wrote:
To be brief and frank -- @buttons are an objectively bad solution to this for a casual user. An @button to set their favorite layout is: 1) inflexible -- a button will set a *specific* layout, and nothing else 2) bespoke -- require *development time* of the user, or to go begging on the mailing list for someone else to do the work, which is objectively a bad UX 3) clutter -- would add both cognitive *and* visual clutter to an outline @buttons are certainly not a general solution. They can be useful but are limited. The same is true for new menu items. I feel that 'layout plugins' would assist with this, but they'd still be supremely inflexible. For the non-programming user, we went from 'you can have any layout you want' to 'here are your choices, get over it'. To point #1, with the old easter-egg approach, I frequently manipulated layouts dynamically within the same workbook, to achieve what I needed *at the time, on the fly*. Some layouts I only ended up using for a few minutes, *as suited my workflow*. There was also the layout saving+loading mechanism that helped switch when desired to a series of 'stable' layouts, across all outlines. I found it very hard to understand what results I was going to get with that old interface. Yes, I would save and restore named layouts once I got something I liked, and sometimes they got lost. I only ever had a few named layouts because managing and even remembering what they were for they were wasn't easy. So for me they were a mixed blessing. To #2, requiring a user to a) know the API, and b) be willing to put in the effort to write a custom bespoke script just to *move a panel around*. This is a bit much. I agree with this. It's not the same as the question of whether to only offer pre-canned layouts or to find ways to let a user roll their own. #3 is nothing new in Leo world, but is just one more point of friction for new users. If the splitters had context menus to add new splits, and panes had click&drag handles to let you move them around, my whole issue would be resolved. No new commands, no new plugins, no absurd development time requests of basic users. I don't know why, but drag-n-drop often seems to be a problem with Leo. Dragging a node in the tree to a new spot works but it's touchy and sometimes doesn't get the node where you want. Sometimes multiple nodes get highlighted and I don't know why, but only one of them will get moved by the mouse. It's possible to highlight more than one node but a delete will only deleted one of them, and it's not always the one I expect. Dropping files (other than outlines) doesn't work reliably yet. And so on. I think that dragging operations in general (in Qt but in other frameworks too) can be hard to get working right. I personally don't have much experience in this area so don't have anything useful to offer. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/485eb1b5-7e41-4120-8fa2-1daea6b75e2bn%40googlegroups.com.
