[sugar] Preparing for the feature freeze

[Eben Eliason]

On Tue, Jun 3, 2008 at 5:20 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
> On Tue, Jun 3, 2008 at 11:03 AM, Marco Pesenti Gritti
> <mpgritti at gmail.com> wrote:
>> The feature (and strings) freeze is approaching very quickly. We have
>> 17 days left. Can we make a quick list of things that we need to get
>> in by the 20 June?
>>
>> Let me start it. Priorities goes from 0 to 5.
>>
>> * Control panel (almost ready) - priority 5
>> * New startup notification (has patch, has consensus?, needs to clean
>> it up) - priority 4
>> * Session. Can either create a sugar-session based on gnome-session or
>> come up with something minimal. I tend to prefer the first option at
>> the moment even if it will provide us some unneeded features. -
>> priority 4
>> * Browser bookmarks and autocompletion. - priority 3
>
> I agree with all that. Do we have clear what needs to be done in the
> last item? Eben, do you know?

Well, we can introduce this in a relatively straightforward manner
that has almost no additional UI up front.  Anytime a bookmark is
created in a session (by anyone in it, not just me), we would need to
log this into a database stored in the "shared" space for all Browse
instances.  We should also log all pages visited (the history) here as
well.  The only additional UI in the short term would be a special
palette of sorts attached to the URL entry which provides
autocompletion suggestions in all Browse instances.

On a more interesting note, it would be really fantastic to store some
additional metadata in addition to the URL for future use.  (See
wiki.laptop.org/go/Browse).  For instance, it would be nice to, map
the page titles, in some probabilistic fashion, to their URLs so that
kids can type in "One laptop" and get suggestions for "laptop.org/..."
(I'm not sure how feasible this is, but the thought is to keep the
autocompletion in sync with the idea of representing pages by their
titles, instead of their URLs, most of the time).  The design also
calls for some basic info like: timestamp of the bookmark/page visit;
type of visit (entered URL manually, followed a link, performed a
search, etc); preview thumbnail; bookmarker's identity; etc.  All of
these pieces of info will later be used for creating a rich
memory-based bookmark/history browser.  (And, as you can see, even
ties into the mockups of the URL completion palette.)

> * In-page search in Browse.

This should probably be implemented within an Edit toolbar (which
should be added...copy/paste are also good to have here).

I replied to a message on the lists, which included a patch from a
volunteer, regarding some additional changes to browse.  The changes
offered were fairly sane, and worth adding, and my enhancements to
them I feel would provide some really nice benefits at relatively low
cost as well.  Could one of you familiar with Browse locate and look
over those patches and my suggested modifications? (It was titled
"Patch to make browse annoy me less".)

- Eben