On 10/06/11 01:22, Corey O'Connor wrote:
On Tue, Jun 7, 2011 at 11:10 PM, Reiner Pope<[email protected]> wrote:
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?
Permitting this level of flexibility is a goal. Though, at this time I
do not have an exact idea of the implementation. ;-)
Nice to know. :-)
Speaking of OS-level windows: This is another reason the current
Window concept should be renamed to View. Which is probably the next
task I'm going to do. It's a small step but nice one.
Yeah, that's bothered me too.
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)
Agreed.
One point: We should work towards a design where the types of Views
are not fixed. That way new views could be defined outside of the yi
core library. I haven't seen any GUI library that really struck me as
having the best solution towards this requirement. (extensibility
problem anyone?) So I'm not going to get hung up on figuring this out
before getting something working ;-)
Fair enough. I think the problem is rather difficult in the case of yi,
since we have multiple UI providers (gtk, vty, cocoa). If we wanted to
add a view type, then we would also have to add it in (some of) the UI
providers, which would probably require modifying yi core (if that's
where the UI providers live, as they do now).
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.
I typically use about the same number of buffers. Still, having
multiple layout managers can provide a benefit.
The implementation currently works as follow:
* The layout of activities is automatic while the layout within an
activity is manual.
* The vim command "new<buffer name>" Creates a "new" activity.
* The "splitE" command splits the current activity into two views onto
the same activity.
The reasoning behind this behavior comes from:
1. I find that I group the buffers into individual "activities". For
example, for C++ development I have usage patterns like: "view the
counterparts stacked on top of each other. Top for the header. The
bottom for the implementation." ; "Open two views. One for one class.
One for another." I want these two activities treated differently. I
*always* want the two counterpart views stacked on top of each other
(manual layout). While the layout of views of multiple classes is
useful to cycle through what is has the largest screen real estate
focused. Which is something the auto layout managers provide.
2. XCode 4 has an interesting concept of an "assistant editor". This
editor pane appears to be just a split view but is actually an
automatically managed view. The assistant always tries to keep the two
editor panes displaying related content. For instance, one will show
interface definition for the the function being edited automatically.
If Yi was to support similar functionality (which I'd like) then I'd
expect the two views to always stay visually grouped together.
So even though the total number of views is low. There are still cases
where I want 2 or 3 views to stay is a specific configuration even
while the layout between the groups is automatically managed.
Though, what aspects of using the nested layout managers are you
asking about? I'm not sure.
Yes, that's what I meant. That C++ example makes sense. :-)
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
