[sugar] Re: trial1 software page

[Marco Pesenti Gritti]

On Wed, 2007-03-07 at 10:24 +1100, Martin Sevior wrote:
> 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.
> 

Tomeu created a trial1 branch in the write activity repository, and made
it use the file metaphor. I'd suggest you focus on that one for now.

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

Sugar clipboard is more than a conventional desktop clipboard, and makes
use of drag and drop. What we will need on your side is support from
dropping images and text inside the abiword view.

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

I think uwog already hacked up that one :) About icons, the Pentagram
folks will work on a visual design, based on current implementation. We
should have something by the end of this week.

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

Same as images, we need drag and drop support. We could also make ctrl+c
in the browser, ctrl+v in abiword work. But that's really undiscoverable
since we don't have menus.

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

Since with the journal approach we would be saving automatically, having
undo/redo functionality in the abiword activity would be key. Obviously
it would be useful to have it for the file based one too.

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

Yeah, I'm not sure anyone tested that case well though, we need to
verify. Also we need to make the files opening automatically there, but
that's work on sugar itself.

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

Yeah, let's use trial1 branch for the file based write activity and head
for the journal based one.

Marco