Re: [Gzz] Summing up...

[Benja Fallenstein]

Tuomas Lukka wrote:

> On Sat, Oct 05, 2002 at 12:00:32PM +0200, Benja Fallenstein wrote:
>  
>
> > My Gzz project at school has resumed work, and now that 0.8 is in a 
> > runnable state again, we can concentrate on that (we did a Sokoban game 
> > for 0.6 last spring, because 0.8 wasn't ready yet). We've decided that 
> > we're going to write a mail client (deadline: 4th week of 2003 IIRC, the 
> > whole time for the project is 12 weeks plus 4 weeks of holidays, started 
> > last week). Now, I need to get everybody up and running with 0.8 first 
> > thing, and the AWT client is the most workable possibility for that 
> > (esp. for the two ppl who run MacOS X-- would've to port the os-specific 
> > C++ code, really not easy). 
> >    
>
> Well, it's written to be fairly portable, it shouldn't be impossible.
> But it would need someone with Mac C++ experience.

*Precisely* the point. ;-)

> > So, I promised getting AWT to work ASAP 
> > after the demo is over, and since our next meeting is on Monday, that's 
> > my deadline for that.
> >    
>
> Sounds very good. If there's anything I can do to help, do tell, I have
> some time tomorrow.

How about making the connections work again? The problem is not showing 
them in gl (I have a fix) but the coordinate systems: currently they're 
drawn between the ul corners of the cells, because of the (w=2, h=2) 
coord systems. Fix needs to be implemented in both VobVanishing and RowCol.

> > We'll also use the containment mechanism for representing emails, which 
> > is why that's on my alpha4 task list as '+': I'd really like to get ppl 
> > to use that in reality soon. This needs discussion about the celltexter 
> > interfaces for it.-- I'd like to propose to handle paragraphs of text 
> > through containment: each paragraph start needs to be its own cell (but 
> > doesn't need to be an empty one, as in Nile), and is determined to start 
> > a paragraph through a connection on another dimension (as in Nile), 
> > where the type of paragraph is determined by what the cell is connected 
> > to. Does that sound ok?
> >    
>
> Hmmmmmm.
>
> What I'm thinking is whether celltexter is the right interface; this goes
> again the same route as enfiladematching: is this robust and clear enough
> to be in the core.
>
> Because it might be better to handle this by the views, possibly through
> an intermediate interface.

Hm. That means that the insertText() etc. functions won't work with it. 
Isn't the point of celltexter to hide the implementation details of 
text, presenting "the text in a cell" in a coherent way and allowing 
editing of it through a set of methods that take care that the internals 
(xu identity etc.) aren't broken?

-b.