Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Tue, Dec 8, 2009 at 07:05, Simon Schampijer si...@schampijer.de wrote: On 12/07/2009 01:09 PM, Aleksey Lim wrote: On Mon, Dec 07, 2009 at 10:57:01AM +0100, Simon Schampijer wrote: On 12/07/2009 05:58 AM, Aleksey Lim wrote: On Sun, Dec 06, 2009 at 11:56:09PM +, Gary C Martin wrote: On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote: 2009/11/27 Aleksey Limalsr...@member.fsf.org: On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) Can anyway relate these benefits from actual requests from deployments? I think this is something that would be good to do in Sugar at some point, but I'm not convinced we are yet in the best moment for that. I can't see us finding the right solution for the whole action/object view concept/requirements in the next few months. The Journal_Plugins idea seem rather scary to me at the moment, and has a very broad effect that would need much design work (security, UI confusion, documentation issues). Now I admit I was hoping we had another shot at including the thumbnail view for 0.88 (thumbnails would seem to be a genuine improvement for finding/browsing many Journal entry types, and likely the default view for kids)... Perhaps just adding the thumbnail image (if available) to the Journal hover palette could be a low risk improvement we could agree on? The design intent seems to go way back in Sugar history, so lightly has plenty of supporters. The core idea of plugins is exactly to avoid situation when we have to release fat UI change set, plugins let us decentralize existed scheme when entirely sugar design(not only UI) depends on what core team thinks. We just provide usable toolset developers cold use to implement what they think. [1] proposes UI changes in [2] but plugins API could be implemented w/o any UI changes at all - user will see the same Journal(but it will be Journal plugin). The idea is let developers make plugin out of sucrose release cycle, yeah developers could do it in pure activities(but see [3]) and even out of sugar at all, but imho it will be useful(in all cases, not only technical) to initiate/support/organize such process from core. [3] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Detailed_Description Generally the idea of plugins is interesting - it always adds extensibility and make parts exchangeable. In the Journal case it is the support for different pluggable views. Looking just at the idea: great! Let's take a concrete example of a scenario with different views that is floating around: the action/object view. While there have been some pros for the change to have these two views, the implementation could be done using plugins or not. From a technical point of view: while having to change code it might be a good moment to add a plugin structure. Well, I guess there are two obvious ways, coding pure activities or having several views(somehow) in core. I tried 1st way while developing Library activity in 0.84 release cycle and, at the end, I realized that I copy/pasted much code from the shell, so tried to reimplement shell. So, we can just extend shell public API but there could be another issue - security reasons. I heard about plans to restrict activities in case of searching/changing/removing objects that were not created by this activity. Having special API(and plugins) could soften situation then. I prefer to have a plugins over activities - here I agree. Do you have a layout of the plugins structure already? How much code/how invasive is it? I agree with Tomeu in the question: has this Feature of pluggable views been asked by the community?. well, this feature is not final users targeted, it's just about making development process more flexible. Ok, then we should make this more clear in the proposal
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On 12/07/2009 01:09 PM, Aleksey Lim wrote: On Mon, Dec 07, 2009 at 10:57:01AM +0100, Simon Schampijer wrote: On 12/07/2009 05:58 AM, Aleksey Lim wrote: On Sun, Dec 06, 2009 at 11:56:09PM +, Gary C Martin wrote: On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote: 2009/11/27 Aleksey Limalsr...@member.fsf.org: On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) Can anyway relate these benefits from actual requests from deployments? I think this is something that would be good to do in Sugar at some point, but I'm not convinced we are yet in the best moment for that. I can't see us finding the right solution for the whole action/object view concept/requirements in the next few months. The Journal_Plugins idea seem rather scary to me at the moment, and has a very broad effect that would need much design work (security, UI confusion, documentation issues). Now I admit I was hoping we had another shot at including the thumbnail view for 0.88 (thumbnails would seem to be a genuine improvement for finding/browsing many Journal entry types, and likely the default view for kids)... Perhaps just adding the thumbnail image (if available) to the Journal hover palette could be a low risk improvement we could agree on? The design intent seems to go way back in Sugar history, so lightly has plenty of supporters. The core idea of plugins is exactly to avoid situation when we have to release fat UI change set, plugins let us decentralize existed scheme when entirely sugar design(not only UI) depends on what core team thinks. We just provide usable toolset developers cold use to implement what they think. [1] proposes UI changes in [2] but plugins API could be implemented w/o any UI changes at all - user will see the same Journal(but it will be Journal plugin). The idea is let developers make plugin out of sucrose release cycle, yeah developers could do it in pure activities(but see [3]) and even out of sugar at all, but imho it will be useful(in all cases, not only technical) to initiate/support/organize such process from core. [3] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Detailed_Description Generally the idea of plugins is interesting - it always adds extensibility and make parts exchangeable. In the Journal case it is the support for different pluggable views. Looking just at the idea: great! Let's take a concrete example of a scenario with different views that is floating around: the action/object view. While there have been some pros for the change to have these two views, the implementation could be done using plugins or not. From a technical point of view: while having to change code it might be a good moment to add a plugin structure. Well, I guess there are two obvious ways, coding pure activities or having several views(somehow) in core. I tried 1st way while developing Library activity in 0.84 release cycle and, at the end, I realized that I copy/pasted much code from the shell, so tried to reimplement shell. So, we can just extend shell public API but there could be another issue - security reasons. I heard about plans to restrict activities in case of searching/changing/removing objects that were not created by this activity. Having special API(and plugins) could soften situation then. I prefer to have a plugins over activities - here I agree. Do you have a layout of the plugins structure already? How much code/how invasive is it? I agree with Tomeu in the question: has this Feature of pluggable views been asked by the community?. well, this feature is not final users targeted, it's just about making development process more flexible. Ok, then we should make this more clear in the proposal then. In the arguments we list: encourage developers to create new views.
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Tue, Dec 08, 2009 at 10:05:30AM +0100, Simon Schampijer wrote: On 12/07/2009 01:09 PM, Aleksey Lim wrote: On Mon, Dec 07, 2009 at 10:57:01AM +0100, Simon Schampijer wrote: On 12/07/2009 05:58 AM, Aleksey Lim wrote: The core idea of plugins is exactly to avoid situation when we have to release fat UI change set, plugins let us decentralize existed scheme when entirely sugar design(not only UI) depends on what core team thinks. We just provide usable toolset developers cold use to implement what they think. [1] proposes UI changes in [2] but plugins API could be implemented w/o any UI changes at all - user will see the same Journal(but it will be Journal plugin). The idea is let developers make plugin out of sucrose release cycle, yeah developers could do it in pure activities(but see [3]) and even out of sugar at all, but imho it will be useful(in all cases, not only technical) to initiate/support/organize such process from core. [3] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Detailed_Description Generally the idea of plugins is interesting - it always adds extensibility and make parts exchangeable. In the Journal case it is the support for different pluggable views. Looking just at the idea: great! Let's take a concrete example of a scenario with different views that is floating around: the action/object view. While there have been some pros for the change to have these two views, the implementation could be done using plugins or not. From a technical point of view: while having to change code it might be a good moment to add a plugin structure. Well, I guess there are two obvious ways, coding pure activities or having several views(somehow) in core. I tried 1st way while developing Library activity in 0.84 release cycle and, at the end, I realized that I copy/pasted much code from the shell, so tried to reimplement shell. So, we can just extend shell public API but there could be another issue - security reasons. I heard about plans to restrict activities in case of searching/changing/removing objects that were not created by this activity. Having special API(and plugins) could soften situation then. I prefer to have a plugins over activities - here I agree. Do you have a layout of the plugins structure already? How much code/how invasive is it? iiuc, new feature should be included to new release cycle before starting development process, so I don't have detailed plan for plugins structure, but I guess it should mean at least refactoring of existed Journal code and I also think to include remote objects to model abstraction. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On 12/07/2009 05:58 AM, Aleksey Lim wrote: On Sun, Dec 06, 2009 at 11:56:09PM +, Gary C Martin wrote: On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote: 2009/11/27 Aleksey Limalsr...@member.fsf.org: On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) Can anyway relate these benefits from actual requests from deployments? I think this is something that would be good to do in Sugar at some point, but I'm not convinced we are yet in the best moment for that. I can't see us finding the right solution for the whole action/object view concept/requirements in the next few months. The Journal_Plugins idea seem rather scary to me at the moment, and has a very broad effect that would need much design work (security, UI confusion, documentation issues). Now I admit I was hoping we had another shot at including the thumbnail view for 0.88 (thumbnails would seem to be a genuine improvement for finding/browsing many Journal entry types, and likely the default view for kids)... Perhaps just adding the thumbnail image (if available) to the Journal hover palette could be a low risk improvement we could agree on? The design intent seems to go way back in Sugar history, so lightly has plenty of supporters. The core idea of plugins is exactly to avoid situation when we have to release fat UI change set, plugins let us decentralize existed scheme when entirely sugar design(not only UI) depends on what core team thinks. We just provide usable toolset developers cold use to implement what they think. [1] proposes UI changes in [2] but plugins API could be implemented w/o any UI changes at all - user will see the same Journal(but it will be Journal plugin). The idea is let developers make plugin out of sucrose release cycle, yeah developers could do it in pure activities(but see [3]) and even out of sugar at all, but imho it will be useful(in all cases, not only technical) to initiate/support/organize such process from core. [3] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Detailed_Description Generally the idea of plugins is interesting - it always adds extensibility and make parts exchangeable. In the Journal case it is the support for different pluggable views. Looking just at the idea: great! Let's take a concrete example of a scenario with different views that is floating around: the action/object view. While there have been some pros for the change to have these two views, the implementation could be done using plugins or not. From a technical point of view: while having to change code it might be a good moment to add a plugin structure. I agree with Tomeu in the question: has this Feature of pluggable views been asked by the community?. In the arguments we list: encourage developers to create new views. How many deployments will write their own view because they miss a Feature? As a deployer I would ask myself: When writing my own view I am off the mainline track. No support from the community etc. It might be interesting for testing purposes. I can modify/add a new view and it can be easily distributed for testing. Furthermore we say: having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment. Are deployments really blocked by the Sucrose release cycle to see changes in the Journal views happen? Putting my deployment head on, updating is a non-trivial task. I have only 30 machines running Sugar - but I do not change/tweak them constantly as it is just quite some work to do. And from my technical background I would be able to. I still run 0.84 just because it takes effort and time to update. I am a bit torn. Maybe the arguments are just not the right ones and from a technical point of view for
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Mon, Dec 07, 2009 at 10:57:01AM +0100, Simon Schampijer wrote: On 12/07/2009 05:58 AM, Aleksey Lim wrote: On Sun, Dec 06, 2009 at 11:56:09PM +, Gary C Martin wrote: On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote: 2009/11/27 Aleksey Limalsr...@member.fsf.org: On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) Can anyway relate these benefits from actual requests from deployments? I think this is something that would be good to do in Sugar at some point, but I'm not convinced we are yet in the best moment for that. I can't see us finding the right solution for the whole action/object view concept/requirements in the next few months. The Journal_Plugins idea seem rather scary to me at the moment, and has a very broad effect that would need much design work (security, UI confusion, documentation issues). Now I admit I was hoping we had another shot at including the thumbnail view for 0.88 (thumbnails would seem to be a genuine improvement for finding/browsing many Journal entry types, and likely the default view for kids)... Perhaps just adding the thumbnail image (if available) to the Journal hover palette could be a low risk improvement we could agree on? The design intent seems to go way back in Sugar history, so lightly has plenty of supporters. The core idea of plugins is exactly to avoid situation when we have to release fat UI change set, plugins let us decentralize existed scheme when entirely sugar design(not only UI) depends on what core team thinks. We just provide usable toolset developers cold use to implement what they think. [1] proposes UI changes in [2] but plugins API could be implemented w/o any UI changes at all - user will see the same Journal(but it will be Journal plugin). The idea is let developers make plugin out of sucrose release cycle, yeah developers could do it in pure activities(but see [3]) and even out of sugar at all, but imho it will be useful(in all cases, not only technical) to initiate/support/organize such process from core. [3] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Detailed_Description Generally the idea of plugins is interesting - it always adds extensibility and make parts exchangeable. In the Journal case it is the support for different pluggable views. Looking just at the idea: great! Let's take a concrete example of a scenario with different views that is floating around: the action/object view. While there have been some pros for the change to have these two views, the implementation could be done using plugins or not. From a technical point of view: while having to change code it might be a good moment to add a plugin structure. Well, I guess there are two obvious ways, coding pure activities or having several views(somehow) in core. I tried 1st way while developing Library activity in 0.84 release cycle and, at the end, I realized that I copy/pasted much code from the shell, so tried to reimplement shell. So, we can just extend shell public API but there could be another issue - security reasons. I heard about plans to restrict activities in case of searching/changing/removing objects that were not created by this activity. Having special API(and plugins) could soften situation then. I agree with Tomeu in the question: has this Feature of pluggable views been asked by the community?. well, this feature is not final users targeted, it's just about making development process more flexible. In the arguments we list: encourage developers to create new views. How many deployments will write their own view because they miss a Feature? As a deployer I would ask myself: When writing my own view I am off the mainline track. No support from the
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Mon, Dec 07, 2009 at 12:09:59PM +, Aleksey Lim wrote: Sorry I didn't enter into the other discussions about your features yet; I'm having quite a hard time understanding most of what you write. Would be nice if you could try to be more elaborate and explain your use cases and goals in more detail as that is likely to increase my understanding. Well, I guess there are two obvious ways, coding pure activities or having several views(somehow) in core. I tried 1st way while developing Library activity in 0.84 release cycle and, at the end, I realized that I copy/pasted much code from the shell, so tried to reimplement shell. What did you copy most of the time? UI code or backend? If the latter, why? I.e. in which way was the data store API insufficient for your activity? So, we can just extend shell public API but there could be another issue - security reasons. I heard about plans to restrict activities in case of searching/changing/removing objects that were not created by this activity. Having special API(and plugins) could soften situation then. No, it will just raise exactly the same concerns again that were the reason for including such restrictions in Bitfrost/Rainbow, leading to exactly the same solutions (only certain combinations of rights granted by default; elevated privileges by using signed builds or explicit user configuration). According to [1], those restrictions where never actually implemented. So when they are, we can take the use case Data store explorer into account and see whether there's anything we could do differently to address it. No need to design a new API to work around it, especially given it's a deliberate design decision. There will always be a way for the _user_ to gain full control (*) and thus grant any privilege to any activity, BTW: [2]: No lockdown Though in their default settings, the laptop's security systems may impose various prohibitions on the user's actions, there must exist a way for these security systems to be disabled. When that is the case, the machine will grant the user complete control. [1] http://wiki.laptop.org/go/Bitfrost#Current_Status [2] http://wiki.laptop.org/go/Bitfrost#Principles (*) At least from the upstream side. Any computer can be locked down to prevent the user from tampering with it (which again can be broken with enough sophistication from the user), there's nothing we can do about it. Whoever disables root access etc. is likely to disable Journal plugins and similar elevated rights as well. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Mon, Dec 07, 2009 at 02:01:16PM +0100, Sascha Silbe wrote: On Mon, Dec 07, 2009 at 12:09:59PM +, Aleksey Lim wrote: Sorry I didn't enter into the other discussions about your features yet; I'm having quite a hard time understanding most of what you write. Would be nice if you could try to be more elaborate and explain your use cases and goals in more detail as that is likely to increase my understanding. Well, I guess there are two obvious ways, coding pure activities or having several views(somehow) in core. I tried 1st way while developing Library activity in 0.84 release cycle and, at the end, I realized that I copy/pasted much code from the shell, so tried to reimplement shell. What did you copy most of the time? UI code or backend? If the latter, why? I.e. in which way was the data store API insufficient for your activity? UI, since I had the same widgets(activity, stared icons, list widget etc), lazy model and shell code to launch objects, edit them etc So, we can just extend shell public API but there could be another issue - security reasons. I heard about plans to restrict activities in case of searching/changing/removing objects that were not created by this activity. Having special API(and plugins) could soften situation then. No, it will just raise exactly the same concerns again that were the reason for including such restrictions in Bitfrost/Rainbow, leading to exactly the same solutions (only certain combinations of rights granted by default; elevated privileges by using signed builds or explicit user configuration). According to [1], those restrictions where never actually implemented. So when they are, we can take the use case Data store explorer into account and see whether there's anything we could do differently to address it. No need to design a new API to work around it, especially given it's a deliberate design decision. as I said, we can improve shell API, it will let activities launch Journal objects, having default list widget, default propery dialog, model for lazy displaying, model could provide source abstraction as well(e.g. could be useful to browse remote Journal objects, not only local or having subset of local/remote objects) There will always be a way for the _user_ to gain full control (*) and thus grant any privilege to any activity, BTW: [2]: No lockdown Though in their default settings, the laptop's security systems may impose various prohibitions on the user's actions, there must exist a way for these security systems to be disabled. When that is the case, the machine will grant the user complete control. [1] http://wiki.laptop.org/go/Bitfrost#Current_Status [2] http://wiki.laptop.org/go/Bitfrost#Principles (*) At least from the upstream side. Any computer can be locked down to prevent the user from tampering with it (which again can be broken with enough sophistication from the user), there's nothing we can do about it. Whoever disables root access etc. is likely to disable Journal plugins and similar elevated rights as well. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Mon, Dec 07, 2009 at 01:24:14PM +, Aleksey Lim wrote: On Mon, Dec 07, 2009 at 02:01:16PM +0100, Sascha Silbe wrote: On Mon, Dec 07, 2009 at 12:09:59PM +, Aleksey Lim wrote: Sorry I didn't enter into the other discussions about your features yet; I'm having quite a hard time understanding most of what you write. Would be nice if you could try to be more elaborate and explain your use cases and goals in more detail as that is likely to increase my understanding. Well, I guess there are two obvious ways, coding pure activities or having several views(somehow) in core. I tried 1st way while developing Library activity in 0.84 release cycle and, at the end, I realized that I copy/pasted much code from the shell, so tried to reimplement shell. What did you copy most of the time? UI code or backend? If the latter, why? I.e. in which way was the data store API insufficient for your activity? UI, since I had the same widgets(activity, stared icons, list widget etc), lazy model and shell code to launch objects, edit them etc So, we can just extend shell public API but there could be another issue - security reasons. I heard about plans to restrict activities in case of searching/changing/removing objects that were not created by this activity. Having special API(and plugins) could soften situation then. No, it will just raise exactly the same concerns again that were the reason for including such restrictions in Bitfrost/Rainbow, leading to exactly the same solutions (only certain combinations of rights granted by default; elevated privileges by using signed builds or explicit user configuration). According to [1], those restrictions where never actually implemented. So when they are, we can take the use case Data store explorer into account and see whether there's anything we could do differently to address it. No need to design a new API to work around it, especially given it's a deliberate design decision. as I said, we can improve shell API, it will let activities launch Journal objects, having default list widget, default propery dialog, model for lazy displaying, model could provide source abstraction as well(e.g. could be useful to browse remote Journal objects, not only local or having subset of local/remote objects) another featrure whic could be useful is UI integration with shell, ObjectChooser integration, having fast method to access to such plugins/activities(not only from activity tray, could keys or so) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
2009/11/27 Aleksey Lim alsr...@member.fsf.org: On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) Can anyway relate these benefits from actual requests from deployments? I think this is something that would be good to do in Sugar at some point, but I'm not convinced we are yet in the best moment for that. Regards, Tomeu -- «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] for Journal Plugins feature
On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote: 2009/11/27 Aleksey Lim alsr...@member.fsf.org: On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) Can anyway relate these benefits from actual requests from deployments? I think this is something that would be good to do in Sugar at some point, but I'm not convinced we are yet in the best moment for that. I can't see us finding the right solution for the whole action/object view concept/requirements in the next few months. The Journal_Plugins idea seem rather scary to me at the moment, and has a very broad effect that would need much design work (security, UI confusion, documentation issues). Now I admit I was hoping we had another shot at including the thumbnail view for 0.88 (thumbnails would seem to be a genuine improvement for finding/browsing many Journal entry types, and likely the default view for kids)... Perhaps just adding the thumbnail image (if available) to the Journal hover palette could be a low risk improvement we could agree on? The design intent seems to go way back in Sugar history, so lightly has plenty of supporters. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Sun, Dec 06, 2009 at 11:56:09PM +, Gary C Martin wrote: On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote: 2009/11/27 Aleksey Lim alsr...@member.fsf.org: On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) Can anyway relate these benefits from actual requests from deployments? I think this is something that would be good to do in Sugar at some point, but I'm not convinced we are yet in the best moment for that. I can't see us finding the right solution for the whole action/object view concept/requirements in the next few months. The Journal_Plugins idea seem rather scary to me at the moment, and has a very broad effect that would need much design work (security, UI confusion, documentation issues). Now I admit I was hoping we had another shot at including the thumbnail view for 0.88 (thumbnails would seem to be a genuine improvement for finding/browsing many Journal entry types, and likely the default view for kids)... Perhaps just adding the thumbnail image (if available) to the Journal hover palette could be a low risk improvement we could agree on? The design intent seems to go way back in Sugar history, so lightly has plenty of supporters. The core idea of plugins is exactly to avoid situation when we have to release fat UI change set, plugins let us decentralize existed scheme when entirely sugar design(not only UI) depends on what core team thinks. We just provide usable toolset developers cold use to implement what they think. [1] proposes UI changes in [2] but plugins API could be implemented w/o any UI changes at all - user will see the same Journal(but it will be Journal plugin). The idea is let developers make plugin out of sucrose release cycle, yeah developers could do it in pure activities(but see [3]) and even out of sugar at all, but imho it will be useful(in all cases, not only technical) to initiate/support/organize such process from core. [3] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Detailed_Description -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
