UI idea: body editors in a grid
Ville M. Vainio
No time to mock this up right now, just throwing it out there.
"tabula" plugin allowed you to edit many nodes simultaneously in an
MDI canvas - i.e. you could move the body editors around freely.
How about taking this idea further and locking the body editors in a
grid, or column?
One fun idea would by layout like this
| Child 1
Outline | Child 2
| Child3
That is, you would edit and view all the children of the currently
focused node all at once. We can already do two body editors at once,
so this would seem like natural extension.
Of course you could only see a small amount of text per body, but for
a "workbook" / sheet like use cases it would be fine.
Edward K. Ream
> "tabula" plugin allowed you to edit many nodes simultaneously in an
> MDI canvas - i.e. you could move the body editors around freely.
Tabula is part of the stickynotes plugin. It creates the following commands:
tabula
tabula-marked
tabula-show
tabula-subtree
The "windowlets" show the node's headline. So this is the "sea of nodes" view!
The tabula nodes are "live": changes made in the tabula window
instantly affect the corresponding nodes in the regular outline.
An easter egg: double-clicking the title of a windowlet fills the
tabula window with the windowlet. Another double-click undoes the
expansion.
> How about taking this idea further and locking the body editors in a
> grid, or column?
Good idea. The tabula window is a great playground for invention.
In the "multi-colored link" world (coming soon, I hope), we could
imagine commands that create "tabula-colored" links, so that the
tabula window would work like a chapter. (And each chapter would have
its own links).
The Light Table video suggested something else that I never considered
before. Suppose each node "carries" its own mini-context outline,
showing just the parents of the node. The tabula window might be
natural for that.
The idea is that each windowlet would have two parts: the top would
show the parents, the bottom would show the body pane. This allows
context to be visible without actually having to show the outline
pane.
Edward
Terry Brown
"Ville M. Vainio" <viva...@gmail.com> wrote:
> How about taking this idea further and locking the body editors in a
> grid, or column?
When the body editor is a well behaved widget it should be straight
forward to place them where ever you want in using the free-layout
mechanism. I think that's a better goal, it allows you more
flexibility in terms of maybe one small (both dimensions) and one large
editor, for example.
Cheers -Terry
Kent Tenney
> On Wed, 18 Apr 2012 12:37:22 +0300
> "Ville M. Vainio" <viva...@gmail.com> wrote:
>
>> How about taking this idea further and locking the body editors in a
>> grid, or column?
>
> When the body editor is a well behaved widget it should be straight
> forward to place them where ever you want in using the free-layout
> mechanism.
Plus, free-layout provides persistence: it's worth putting effort into
configuring pane configuration because it will be available next time.
(I guess I'm persistent about wanting persistence)
Thanks,
Kent
I think that's a better goal, it allows you more
> flexibility in terms of maybe one small (both dimensions) and one large
> editor, for example.
>
> Cheers -Terry
>
> --
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To post to this group, send email to leo-e...@googlegroups.com.
> To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
>
Edward K. Ream
> When the body editor is a well behaved widget it should be straight
> forward to place them where ever you want in using the free-layout
> mechanism.
Are you suggesting doing free-layout in tabula?
EKR
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> > When the body editor is a well behaved widget it should be straight
> > forward to place them where ever you want in using the free-layout
> > mechanism.
>
> Are you suggesting doing free-layout in tabula?
No, although that gives me another idea...
Another feature I've wanted to add to free_layout is popping out any
element into its own window (replacing sticky-notes). You could go one
better and pop-out free-layout frames which could contain multiple
widgets, like tabula currently does.
I'll try and get those features into free-layout. Note that a couple
of widgets already have their own pop-out capability, the body editor
and view-rendered.
Also some frame manipulation tools in free-layout would be good. To
maximize / restore one frame, and layout frames in a grid, if there was
an intent to replace tabula.
Not that tabular needs replacing, but I think it's benefits can be
generalized.
Cheers -Terry
Ville M. Vainio
I am bringing another angle into play here - systematic selection of what nodes are shown in the editors, in the proposed scheme we would have a single column of editors, each displaying every child of currently selected node.
Expanding the scope to a grid, we could have a grid-lock-column that would freeze the current column, allowing you to move the selected position in the tree to another node, and locking the nodes for column 2 etc etc
Terry Brown
"Ville M. Vainio" <viva...@gmail.com> wrote:
> I am bringing another angle into play here - systematic selection of what
> nodes are shown in the editors, in the proposed scheme we would have a
> single column of editors, each displaying every child of currently selected
> node.
>
> Expanding the scope to a grid, we could have a grid-lock-column that would
> freeze the current column, allowing you to move the selected position in
> the tree to another node, and locking the nodes for column 2 etc etc
Ok, but I still think it makes sense to implement this with the
free-layout system, so that your grid could be a separate window, or
not, as desired. free-layout is basically nested QSplitters, so it can
represent a grid, but with more flexibility (cell 1,0 doesn't have to
be the same height as cell 0,0, etc.)
Cheers -Terry
Ville Vainio
based on the amount of text in the nodes
Sent from my Windows Phone
From: Terry Brown
Sent: 4/18/2012 10:31 PM
To: leo-e...@googlegroups.com
Subject: Re: UI idea: body editors in a grid
Cheers -Terry
--
Edward K. Ream
> When the body editor is a well behaved widget it should be straight
> forward to place them where ever you want in using the free-layout
> mechanism.
As I was thinking about doing body editors with free_layout (and by
extension, the tabula editors) I had another new thought: it's time to
replace the present difficult selection code with a broadcaster/
listener framework.
In particular, the multiple body editor code is on the verge of
collapse because it tries to figure out too much in a spaghetti-like
mass of logic. This doesn't generalize, and Leo is becoming so
"exuberant" in its IDE that a simpler, more general mechanism is
becoming essential.
Edward
Edward K. Ream
> I am bringing another angle into play here - systematic selection of what
> nodes are shown in the editors, in the proposed scheme we would have a
> single column of editors, each displaying every child of currently selected
> node.
handle this. That is, in the new framework it should explicitly be
possible to select multiple nodes.
> Expanding the scope to a grid, we could have a grid-lock-column that would
> freeze the current column, allowing you to move the selected position in
> the tree to another node, and locking the nodes for column 2 etc etc
Interesting. For some purposes the column would be like a "super
node", that is, an explicit collection of nodes.
EKR
Kent Tenney
> On Apr 18, 10:53 am, Terry Brown <terry_n_br...@yahoo.com> wrote:
>
>> When the body editor is a well behaved widget it should be straight
>> forward to place them where ever you want in using the free-layout
>> mechanism.
>
> Yes. This might the key.
>
> As I was thinking about doing body editors with free_layout (and by
> extension, the tabula editors) I had another new thought: it's time to
> replace the present difficult selection code with a broadcaster/
> listener framework.
'publish / subscribe' has buzzword cred these days, there are several
protocols out there, reportedly fairly simple to implement, don't know
if any are a fit here.
>
> In particular, the multiple body editor code is on the verge of
> collapse because it tries to figure out too much in a spaghetti-like
> mass of logic. This doesn't generalize, and Leo is becoming so
> "exuberant" in its IDE that a simpler, more general mechanism is
> becoming essential.
>
> Edward
>
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> As I was thinking about doing body editors with free_layout (and by
> extension, the tabula editors) I had another new thought: it's time to
> replace the present difficult selection code with a broadcaster/
> listener framework.
Although such a framework might be quite useful, I can't help thinking
it would insert a big delay between now and getting flexible body
editors implemented.
> In particular, the multiple body editor code is on the verge of
> collapse because it tries to figure out too much in a spaghetti-like
> mass of logic. This doesn't generalize, and Leo is becoming so
> "exuberant" in its IDE that a simpler, more general mechanism is
> becoming essential.
I think that getting body editors working as described in my recently
bumped "Free range body editors" post would not be that hard, certainly
simpler and faster than a broadcaster / listener framework. And the
current multiple body editors code could just be dropped completely, so
while I suspect you're right about it being on the edge of implosion, I
don't think that's a problem :-)
Cheers -Terry
Terry Brown
Terry Brown <terry_...@yahoo.com> wrote:
> Another feature I've wanted to add to free_layout is popping out any
> element into its own window (replacing sticky-notes). You could go one
> better and pop-out free-layout frames which could contain multiple
> widgets, like tabula currently does.
>
> I'll try and get those features into free-layout.
Woohoo - done and pushed. Went for the second option, instead of
pop-out windows holding a single widget, they hold a whole new
free-layout hierarchy, which of course can be a single widget, or much
more, if you want. See the 'Open Window' command on the free-layout
splitter handle context menu.
Even made a screencast to demonstrate, but unfortunately the sound was
useless, despite being ok in trials before hand. Might try again later.
Cheers -Terry
Terry Brown
Ville Vainio <viva...@gmail.com> wrote:
> > Expanding the scope to a grid, we could have a grid-lock-column that would
> > freeze the current column, allowing you to move the selected position in
> > the tree to another node, and locking the nodes for column 2 etc etc
Attached screen-shot shows the potential for free-layout with the new
Open Window command to open a separate window as a 'grid' editor. Here
instead of body editors I just have 5 view-rendered panes open, and
they're all looking at the same node because there's no mechanism for
locking them to separate nodes presently(*). Free layout could handle
body editors in the same way, if they were more agnostic about their
containers.
Cheers -Terry
(*) I think there's a way to lock/unlock a special case singleton
view-rendered pane, but not a flock of them like this.
Ville M. Vainio
If you fill the cells with stickynotes (as in tabula), the editors would at least stick to the nodes.
Otoh, if more felxible body editors are just around the corner, it may not be worth the hassle.
Matt Wilkie
> focused node all at once.
I often use "Edit in notepad" (or more likely pyscripter) for this
purpose. It would be nice to stay inside Leo; I sometimes lose data by
forgetting which editor has the most current version.
--
-matt
Ville M. Vainio
Have you tried alt-x stickynote from stickynotes plugin?