On 08/06/11 14:39, Corey O'Connor wrote:
On Tue, Jun 7, 2011 at 7:41 PM, Reiner Pope<[email protected]> wrote:
I'm not convinced that adding activity groups to the hierarchy is a good
idea. In my opinion, *all* window/view layout should be handled by a
'LayoutManager' object -- primarily for simplicity, but also because this
maintains a clean separation between layout and "semantics" of the
windows/views. (By "semantics" I mean everything non-layout-related; for
example, the behaviour of 'nextWinE'.)
I'm using the ActivityGroup construct as a stepping stone to a more
complete view/subview system. That was just too much to handle in one
go. The ActivityGroup construct was a useful intermediary.
What I am working towards is a view system where the child views of a
view are managed by the view's layout manager. With the view hierarchy
something like:
Editor
contains tab bar view (a view)
contains tab contents (where the subviews are activity views and
managed by a layout manager)
contains activity views (where each activity has it's own layout
manager)
contains command window (a view)
Thus the current ActivityGroup just becomes, more or less, a view with
a manual layout manager.
The more complete view/subview system is something I'm working towards
to also support more complex UIs within Yi.
Right, fair enough. However, suppose I want a different hierarchy. For
instance, I don't use multiple tabs, and I don't currently want nested
activity groups, so I might want:
Editor
contains (multiple?) OS-level windows
each (OS-level) window contains exactly one activity view
each activity view contains a (command/buffer) window
Will that also be supported?
I'm all for supporting more complex UIs in Yi -- the richer the
available widgets, the better. I just don't want a particular hierarchy
hard-coded into Yi. (I don't like how Yi currently forces a tab bar on
me, and also that Yi only has one OS-level window.)
In terms of code, I would prefer something like this:
data Editor = Editor {
...
uiSpec :: View,
...
}
data View
= CommandWindow WindowRef
| TabBar [View]
| ActivityGroup (Layout View)
over something like this:
data Editor = Editor {
...
tabs :: TabBar,
...
}
data TabBar = TabBar [Tab]
data Tab = Tab (Layout ActivityGroup)
data ActivityGroup = ActivityGroup (Layout WindowRef)
The advantage of the former over the latter is that you can nest the
elements however you want to.
If you're after manual control of your layout, then I think it would be
better to implement a 'ManualLayoutManager' object, and just send messages
to it telling it when to split. I've put an (incomplete, but compilable)
prototype up on my github repo:
https://github.com/reinerp/yi/tree/manual-layout-manager
As you can see, this adds a generic 'sendMessage' method to the
'LayoutManager' class, which I think is a good idea in any case.
I agree with that since that enables effective support for each of the
UI frontends.
Admittedly, this layout manager wouldn't actually provide everything your
"activities" support, because it gives you an all-or-nothing approach: you
either use an automatic layout manager, or you have to do your layout
entirely manually. If you want more advanced features, it should be possible
to build more advanced layout managers in the same vein.
I thought about a layout manager that provided support for both the
manual splits and automatic layout. However a single layout manager
that did both appeared unreasonably complex. I would prefer having a
layered approach where each view's subviews is managed by a layout
manager and Yi is programed to add the appropriate views with
appropriate layout managers to work as the user expects.
Indeed, that makes sense. Trying to get a layout manager to handle
everything seems a little bit complex.
By the way, how do you imagine using nested layout managers?
I find that I only want around 4-5 buffers open on one screen, or else I
run out of space. A single layout manager is quite sufficient for
managing those 4 buffers. I would imagine that if I subdivide my space
without one layout, and then subdivide again, then I would end up with
very small buffers.
Cheers,
Reiner
I think the other reason to stick with the 'LayoutManager' system is that it
minimises the changes to "core yi". That is, the 'ManualLayoutManager'
object could actually be implemented in someone's config file, without
needing to change any of yi itself.
True.
----
Regarding strictness: sorry if you're already aware of this, but we had a
small discussion on strictness and deepseq a few weeks ago:
https://groups.google.com/d/topic/yi-devel/3dBiglnS7ko/discussion
Because 'rnf' on lists requires traversing the entire list, it might be a
better idea (for efficiency reasons) to bite the bullet and migrate to
strict lists/pointedlists. Unfortunately, there is no element-strict version
of Data.Sequence, as far as I know.
----
Hm. I will read that discussion.
On 08/06/11 04:18, Corey O'Connor wrote:
screenshot:
http://imgur.com/JExhx
-Corey O'Connor
[email protected]
http://corebotllc.com/
On Tue, Jun 7, 2011 at 11:10 AM, Corey O'Connor<[email protected]>
wrote:
Howdy!
I just finished a large patch that adds horizontal and vertical
splits.* Only the VTY UI supports the changes for now. Layout
managers are still supported.
The branch is the activity-dev branch of mine on github:
https://github.com/coreyoconnor/yi/tree/activity-dev
With the patch being here:
https://github.com/coreyoconnor/yi/commit/0bec48fba7ac5538bc1d33f3540b541ffa24eebe
Read the patch notes for some more details. A short getting started:
1. checkout activity-dev from my yi git repo.
2. configure to only build and use the VTY UI.
3. Install.
4. Using the vim keymap try: control-w-s ; control-w-v ; ":new ...."
* Plus a concept called "activities" which I'll expand on later.
-Corey O'Connor
[email protected]
http://corebotllc.com/
--
Yi development mailing list
[email protected]
http://groups.google.com/group/yi-devel
