Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels
Tomeu wrote: Yes, but what about security? Right now the shell process only executes code in /usr, executing activities in a separate process. Executing activities in separate processes provides no security benefit unless the resulting processes are in some way isolated from the rest of the system. Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels
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?
Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels
On Sun, Dec 13, 2009 at 03:42, 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). I'm having trouble guessing which needs addresses this change. Does this idea come from any need expressed by our users? Thanks, Tomeu 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). == Summary == Treat frame as a containers(upper, left, right and bottom) for predefined or custom components i.e. having GNOME panels analog in sugar. == 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. Any of four panels could be stuck i.e. let user see its components all time. === Predefined components === * rings switch * activities list * clipboard * users list * sources list * network component * notification area == 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 * components could have shell level key shortcuts == User Experience == * sugar frame as a regular GNOME panels -- Aleksey ___ 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
Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels
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. == 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@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
Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels
On Mon, Dec 14, 2009 at 03:47:23PM -0200, Tomeu Vizoso wrote: On Sun, Dec 13, 2009 at 03:42, 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). I'm having trouble guessing which needs addresses this change. Does this idea come from any need expressed by our users? oh sorry, I denied my feature.. and user who asked for such feature was me the idea was instead of having modular Journal(former name for this feature was, Journal Plugins) I thought that having ala GNOME panels let 3rd party developers integrate theirs activities to shell UI e.g. replacing Journal by replacing Journal icon/in-this-proposal,-panel-component by launcher that starts their activity. But now, I think it(e.g. such Journal customizing) could be done by forking Journal itself i.e. w/o adding complexity like plugins or ala GNOME panels and sharing this fork via 0install. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels
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
Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels
+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. I also like that activities such as Chat could install frame components, and have a proper notification system. 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!). 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
[Sugar-devel] [FEATURE] [DESIGN] Frame Panels
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). == Summary == Treat frame as a containers(upper, left, right and bottom) for predefined or custom components i.e. having GNOME panels analog in sugar. == 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. Any of four panels could be stuck i.e. let user see its components all time. === Predefined components === * rings switch * activities list * clipboard * users list * sources list * network component * notification area == 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 * components could have shell level key shortcuts == User Experience == * sugar frame as a regular GNOME panels -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
