[sugar] Re: trial1 software page

Martin Sevior msevior at physics.unimelb.edu.au
Tue Mar 6 18:24:10 EST 2007


On Tue, 2007-03-06 at 16:09 +0100, Marco Pesenti Gritti wrote:
> Hello,
> 
> I went over the trial1 plan with both Eben and Tomeu and I put together
> a TODO list for Sugar on the base of their feedback.
> 
> http://wiki.laptop.org/go/Trial1_TODO
> 
> There are two big high level decisions that we need to make:
> 
> 1 Use the journal prototype we have developed or a file based model.
> 2 Try to integrate the new presence service Dan and Collabora are
> working on, and base a simple chat on it.
> 
> I think we should aim at a feature freeze on 20 March.
> 
> Given the time frame I think 2 is out of question. We didn't even start
> integrating the new backend with the UI yet.
> 
> I've been putting a lot of thinking in 1, and, for how much I hate the
> fact, I think it's too late for it. You can get a sense of the work that
> would be necessary in the TODO. The clipboard stuff in particular would
> need a lot of work to be usable. And even more importantly the journal
> prototype code is very recent and untested. Finally the images are not
> quite stable yet (network connection issues, login screen issues...) and
> stabilizing should be our very first priority.
> 
> What I propose is:
> 
> * Branch sugar and the activities which will need Trial1 specific
> changes, so that Journal and presence service development can continue.
> * Get the features required for Trials1 in asap.
> * Go in bug fix only mode as soon as the features are implemented and
> definitely not after 20 March.
> 
> With this plan I think we will have to drop a few features that are part
> of the Trial1 page (but not as absolutely required):
> 
> * Deleting files
> * Renaming files
> * Browser bookmarks
> * Copy of text snippets from web browser to write activity
> 
> Anyway, this is my thinking. Let me know what you think about it!
> 
> And feel free to comment on the TODO page, I think it reflects the
> Trial1 page but there are a few minor design/implementation questions
> that needs to be addressed.
> 

Hi Marco,
         I see a lot of issues that the write activity needs to
address. 

It's a little frustrating to not know which way to put our efforts. 

One possibility would be fork write into two activities. One employing
the journal and one using the file metaphor. We abi types can quickly
fix the file metaphor to provide a baseline if the Journal falls
through.

In principle pasting images from the clipboard into abiword should "just
work" already (at least on the abiword side).

We can improve the UI for this by making the image a positioned image
and flow the text around it by default. I'll do this.

We can put in code for a toolbar icon to pop up a file browser to insert
an image in a few minutes, (of course we need a nice icon). Uwog has the
code this already.

We also have a graphical "insert table" widget set to go. 

What is the issue with pasting text snippets? A simple solution would be
to place the text snippets on the clipbaord then just do a regular paste
into abiword. This should already just work (including preserving the
formatting.)

On the journal side, what are the issues with "undo"/"redo"? Do you mean
save to journal on every undo/redo?

I haven't followed the progress of opening doc/odt files in the browser
but I was under the impression is was working some months ago.

So should we do the split? The amount of python code is trivial for the
baseline and then tomeu could focus on getting the Journal integrated.

Martin


> Marco
> 
> _______________________________________________
> Sugar mailing list
> Sugar at laptop.org
> http://mailman.laptop.org/mailman/listinfo/sugar



More information about the Sugar mailing list