Re: [Gzz] Summing up...

[Tuomas Lukka]

On Sat, Oct 05, 2002 at 12:00:32PM +0200, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> 
> >The demo went very well even though I could only show xupdf, not the client
> >due to the xu link saving problem.
> >
> 
> (sigh)-- well, the nasty bugs always come up in the last moment and when 
> you really didn't expect them-- can't do too much about it. Now that 
> page span saving works, I really wouldn't have expected this...
> 
> We need a unit test for the problem now.

Will try.

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

After a couple of releases, we will be in a state when the gfx backend
would change slower than the frontend so binary distributions of that
would be possible without having to remake them every release.

But someone would need to step up and do the ports and releases, of course.

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

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

        Tuomas