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

[Aleksey Lim]

On Mon, Dec 14, 2009 at 01:34:38PM -0500, Eben Eliason wrote:
> 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.

it was more common proposal, ala GNOME panels

> 
> > == 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?

yup, e.g. could move any predefined components to panel he wants..
i.e. like GNOME panle components

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

my intention was to have panel components ala GNOME panel launchers(or even
menus)

> > Any of four panels could be stuck i.e. let user see its components all
> > time.
> 
> This is an interesting idea.

yup, I'm also strongly for such feature, despite of accepting panels
feature

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

yup, activity windows should be shrunk e.g. like application in GNOME
have less free space for maximization after adding new panel.

> > === 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?

idea was just to make all existed frame components freely added/removed

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

the major idea was provide common tool - panels and panel components and
let 3rd party developers implement what they want e.g. notification
area(for example in GNOME, notification area is just another panel
component) and make this out of sucrose releases cycle like regular
activities.

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

In fact, I meant users driven shortcuts not hardcoded to activities

-- 
Aleksey