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. ;-)
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.
> 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 ;-)
> 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.
>>> 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
