[Sugar-devel] [FEATURE] [DESIGN] Frame Panels

[Eben Eliason]

On Sun, Dec 13, 2009 at 12:42 AM, Aleksey Lim <alsroot at member.fsf.org> wrote:
> Hi all,
>
> At the end Journal Plugins mutated to Frame Panles feature.
> All UI visible changes I wanted to implement in plugins could be done
> via Frame Panle components(the rest of code are shell agnostic).
>
> Frame Panles feature has the same major idea, social context - giving
> non core developers more freedom in case of releasing/supporting theirs
> code, e.g. adding GSM modem support could be implemented not in
> core(thus stuck to sugar version, when previous sugar version users
> can't grab last changes of GSM modem component) but as a standalone
> activity(and deployed as a regular activity).

Is this an extension of the "device" concept already present? The idea
there was to allow anyone to create devices (in the bottom edge of the
frame) that added extended features (such as text-to-speech,
additional hardware support, dictionaries, etc.). Having a way to
separate these from the core of Sugar, and even add or remove them at
will, would be nice.

> == Summary ==
>
> Treat frame as a containers(upper, left, right and bottom) for
> predefined or custom components i.e. having GNOME panels analog in
> sugar.

I'm a bit confused by this. The panels, clockwise from top, are for
activities, people, devices, and objects (clipboard). Only the bottom
edge is currently thought of as a place for extension. Are you
proposing that all of these would be extensible?

> == Detailed Description ==
>
> The major reason is to let activities like FileShare or Chat special UI
> representation in shell's interface. It could be also useful if user
> wants fast access to some activities like Journal replacements.

I would raise some caution here. The Frame was specifically designed
as a place for "active" elements to live, and is specifically not a
"launcher." As such, any running activities, current friends,
available devices, etc. appear there. Your description of "fast
access" makes it sound more like a launcher and less like a place of
status.

> Any of four panels could be stuck i.e. let user see its components all
> time.

This is an interesting idea. We played with similar concepts early on,
but decided at the time that the Frame as more comprehensible as a
single unit that could be shown and hidden at will. If we break that
paradigm, how do we handle the overlap that a persistent frame edge
would cause? Does the activity window move/shrink in these instances?

> === Predefined components ===
>
> * rings switch
> * activities list

These are views within the Home zoom level. What's your proposal for
making these Frame components?

> * clipboard
> * users list

Yup, these are the left and right edges, currently.

> * sources list
> * network component

Are these equivalent to the devices (bottom) edge of the frame? Are
you proposing we split them somehow?

> * notification area

I'd much rather see a general notification system built up (we have
the beginnings of one already). There are a number of design mockups
showing how notifications are "bound" to the 4 corners of the screen,
associated with the 4 edges for activities, people, devices, and
objects. notifications would include activity invitations, group
invitations, people joining/leaving activities, low battery, lost
network, etc.

I think these various notifications belong in the context of the
respective edges of the frame, instead of in a single area.


Overall, there are 7 components you've identified here, so it's
unclear to me how these map onto the 4 edges of the Frame.

> == Benefit to Sugar ==
>
> * let users more freedom to organize sugar shell how they want
> * provide to activity developers a way to integrate theirs activities
> * to shell UI(useful for activities that work in background and
> * requires some kind all-time-present indicator in UI)
> * having stable API for panel components, activity developers have more
> * freedom and aren't stuck to core releases e.g. Network
> * activity/component(analog of NM widget in GNOME) could support
> * several sugar releases and previous release sugar users will benefit
> * from last Network component.
> * previous sugar release users will benefit from last updates of
> * predefined components as well
>
> == UI Design ==
>
> * all of four frame panels could be stuck
> * manage components, way to add-new/remove/move components

This part definitely sounds like a good idea, to me.

> * components could have shell level key shortcuts

This also sounds good, but we'll have to be quite careful about it to
avoid breaking activities.

Eben


> == User Experience ==
>
> * sugar frame as a regular GNOME panels
>
> --
> Aleksey
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>