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

[Tomeu Vizoso]

On Mon, Dec 14, 2009 at 17:40, Wade Brainerd <wadetb at gmail.com> wrote:
> +1 overall.
>
> The one thing that jumps out to me here is the idea that I could
> download frame components from ASLO, like a Clock or a Calendar.  That
> sounds fantastic.

Yes, but what about security? Right now the shell process only
executes code in /usr, executing activities in a separate process.

A possible approach would be to run extensions out-of-process and have
D-Bus APIs, but the memory usage would be pretty high...

> I also like  that activities such as Chat could install frame
> components, and have a proper notification system.

XOIrc emits a notification when a direct message is received, maybe
Chat needs the same? It has been already mentioned that the
notification alert doesn't call the attention enough.

http://www.galago-project.org/specs/notification/0.9/index.html

> A great addition to this feature would be to actually implement the
> freedesktop.org panel protocol, which would help Sugar run  native
> software like pidgin or claws-mail or skype (or nm-panel!).

Looks like GNOME 3 is going to drop those? There's the impression from
desktop developers that the application developers abused that
mechanism.

Regards,

Tomeu

> Regarding extensibility, we would have to clearly define the "roles"
> of the different sides of the screen.  IE the top is for task and view
> switching, the bottom is for information and devices, the left is for
> MIME objects, the right is for collaboration.  Rather than adding a
> panel to top/left/right/bottom, a panel should be added by role.
>
> I agree that all four sides should be independently "stickable".  Also
> would be nice if they could come out separately when the screen edge
> is hovered.
>
> -Wade
>
> On Mon, Dec 14, 2009 at 1:53 PM, Aleksey Lim <alsroot at member.fsf.org> wrote:
>> 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
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning