Area model

[Andreas Pakulat]

On 12.05.08 08:18:50, Vladimir Prus wrote:
> On Monday 12 May 2008 00:08:44 Andreas Pakulat wrote:
> > On 11.05.08 17:34:16, Vladimir Prus wrote:
> > > On Sunday 11 May 2008 16:30:10 Andreas Pakulat wrote:
> > > > On 05.05.08 23:20:54, Vladimir Prus wrote:
> > > > > On Monday 05 May 2008 22:50:41 Alexander Dymo wrote:
> > > > > > Vladimir, thanks for the explanation (in this and your other mail). At least 
> > > > > > now I understand much better what areas are and how we want to use them. I 
> > > > > > didn't know that before I started implementing areas.
> > > > > > 
> > > > > > The current implementation still bothers me a bit. We have two separate 
> > > > > > concepts - area types and areas which are implemented using the same Area 
> > > > > > class and distinguished by uicontroller as "default" area shown nowhere 
> > > > > > or "clone of the default" shown in the mainwindow. I'd like to try separating 
> > > > > > these two in the code as well into Area and AreaType classes. AreaType would 
> > > > > > be the default area added in the code or by plugins and Area class would be 
> > > > > > the same as it was before - just collection of views shown in the mainwindow.
> > > > > 
> > > > > How those two would be related? The joy of the current model is that visible
> > > > > areas are indeed just clones of the default areas, and resetting areas to
> > > > > default is a simple clone. In smart words, this is called "Prototype" pattern.
> > > > > I'm not sure using two separate classes would keep this simplicity.
> > > > > 
> > > > > What personally bothers me right now is that we have this default/clone model,
> > > > > but outside of it, you can set any random area to a window, thereby probably
> > > > > breaking lots of things. I'd suggest making that impossible :-)
> > > > 
> > > > BTW: Please update the points in our wiki when you've figured out how
> > > > Areas and Sublime should work.
> > > 
> > > Wiki? I'd think this should be a comment in the code, most likely for the
> > > Sublime::Controller class.
> > 
> > I have to admit that I didn't read your initial text, but we do have
> > extensive docs on sublime and how it works/is designed in the wiki and
> > those who work on it should be responsible for keeping that wiki docs
> > up to date so they reflect reality. I know writing docs sucks, but you
> > already wrote an email, so the content is already there, just need some
> > formatting for the wiki ;)
> 
> I did not say writing docs sucks. The question is would not the docs be
> better in code, where doxygen can see them?

Maybe if you write separate .dox files in sublime for that. But I don't
think an extensive high-level overview about Sublime (or any of the
other libraries like DUChain) should be scattered around the various .h
files of the library. Thats why putting it in the wiki does make sense
IMHO. Also currently we keep (almost) all KDevelop4/KDevPlatform related
information in the wiki, so its a single place where to start looking
when you want to work with it.

However, if there's proper high-level-design-doc in either form (as wiki
page(s) or .dox file) we (read I or someone else who wants it) can
easily port it to the other format.

Andreas

-- 
Cold hands, no gloves.