Re: [E-devel] views, positions, iconbars, layout and fried fish

[Christian K. <kre...@in...>]

Till Adam wrote:
> 
> Ok, and there is what that thinking amounts to:
> (another bulleted list, I hope you bear with me on those, I like em ;)
> 
> - E_View_Model becomes E_Dir

Yup. Good. So far we're probably the only file manager on this planet
that doesn't have a directory abstraction, and thank you for introducing
a file abstraction :)

> - all information on bg, iconbar, layout moves into E_Layout
> - E_Dir stores a list of listeners, not views
> - listeners can be either E_Views, or E_Layouts
> - each view has an E_Dir and and an E_Layout
> - each E_Layout holds a list of views that its used for
> - each E_Layout also has an E_Dir it monitors (.e_layout somewhere)
> - something in the dir changes, the E_Dir informs its listener (views)
>   and the views are updated
> - something in the .e_layout changes, the E_Dir informs its listener
>   (the E_Layout), the E_Layout updates its views

Sounds good. If you want to take the oo route, the cleanest thing would
be having observer and observee interfaces that can be derived from.
Directories are then observee instances, and both views and layouts are
observers, and the whole broadcasting mechanism lives in the observee
code. I'm sure you're aware of that, just thought I'd mention it.

I've noticed a couple things on the horizon that would be a lot easier
with a real oo language. Just allow me to mention that it would be nice
to have clean, derivable interfaces for views, so that we could have
FileViews, ConfigViews, WindowViews, or Icon abstractions that could
polymorphically be BigIcons, ListIcons, or layout mechanisms that work
that way. Not being oo is fine for a window manager, I think its flow of
control is sufficiently linear for that. But a file manager allows much
more variation here, so if we want to stay flexible, we need to invest
more effort. <cKs-daily-unpopular-statement> If this were my little
project, it'd be in C++. </cKs-daily-unpopular-statement> :)

And yeah, I know that we can do all that in C. It's just a whole lot
more work. We're currently quite far from being oo -- our mechanism only
covers member variables (you can cast up and access the superclass
members), but not methods, i.e. we don't have a vtable equivalent.
Spending some time on a good vtable mechanism like gtk's would be a good
investment imo. Would you guys be interested in that? 
 
> or, trying to be an ascii artist like cK ;)

Let me take that as a compliment :)
 
>       E_View       E_View               E_View
>      |     |      |      |             |      |
>  E_Dir(/)   E_Layout     E_Dir(/home/till)    E_Layout
>               |                                   |
>             E_Dir                               E_Dir
>         (~/.e/.e_layout)                (~/.e/layouts/funky_layout/)


Roughly resembles a sine wave. Very cool :)

Cheers,
Christian.
-- 
________________________________________________________________________
                                                    http://www.whoop.org