|
|
| Line 40: |
Line 40: |
| == Benefit to Sugar == | | == Benefit to Sugar == |
|
| |
|
| * 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. | | * let users more freedom to organize sugar shell how they want |
| * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar | | * 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) |
| * encourage developers create new view for different purposes(books, media etc.) | | * 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. |
| * 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)
| |
|
| |
|
| == Scope == | | == Scope == |