ghost at cs.msu.su
Mon May 12 04:18:50 UTC 2008
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?
More information about the KDevelop-devel