On Mon, Dec 14, 2009 at 17:40, Wade Brainerd <wad...@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 <alsr...@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 <alsr...@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@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel