Re: [Sugar-devel] Home view activities layout
On Sat, Jul 31, 2010 at 12:31 AM, Frederick Grose fgr...@gmail.com wrote:
On Fri, Jul 30, 2010 at 11:32 PM, Walter Bender walter.ben...@gmail.com
wrote:
On Fri, Jul 30, 2010 at 8:25 PM, Chris Ball c...@laptop.org wrote:
{...}
Here is a tighter spiral of 74 icons for the home view (running in the
Sugar emulator at 800x600).
Running the emulator with usr/bin/sugar-emulator -i 832x624
give a close match to the XO screen proportions.
Done. See http://wiki.sugarlabs.org/go/User:Walter#Home_View
-walter
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Home view activities layout
I am heading off to vacation for a week, but I may get a chance to
play with moving/snapping the icons as well. In the meantime, the code
is quite simple:
--- favoriteslayout.py 2010-07-20 13:31:05.0 -0400
+++ favoriteslayout.py 2010-07-30 23:26:56.0 -0400
+
+class MyLayout(RingLayout):
+Spiral layout based on Archimedean spiral: r = a + b*theta.
+
+__gtype_name__ = 'MyLayout'
+
+icon_name = 'view-mylayout'
+Name of icon used in home view dropdown palette.
+
+profile_key = 'my-layout'
+String used in profile to represent this view.
+
+def __init__(self):
+RingLayout.__init__(self)
+self.my_radius = _MINIMUM_RADIUS
+self.my_orientation = math.pi
+
+def _calculate_radius_and_icon_size(self, children_count):
+Stub out this method; not used in `My Layout`.
+return _MINIMUM_RADIUS, style.STANDARD_ICON_SIZE
+
+def _calculate_position(self, radius, icon_size, index, children_count):
+ Increment the radius as you go; decrease the angle of rotation
+as the radius increases to keep the distance between icons constant.
+
+print index %d (r: %f, o: %f) % (index, self.my_radius,
self.my_orientation)
+if index == 0:
+self.my_radius = _MINIMUM_RADIUS
+self.my_orientation = math.pi
+
+x, y = self._calculate_xy()
+# add some buffering around the icon
+self._calculate_new_radius_orientation(icon_size + 10)
+
+
+# angle decreases as the radius increases
+angle = index * (2 * math.pi / (12.0 + index / 6.0)) - math.pi / 2
+# radius is proportional to index/children_count
+myminimum = _MINIMUM_RADIUS * .67
+newradius = ((_MAXIMUM_RADIUS - myminimum) * (index * 1.1) /
children_count) + myminimum
+x = newradius * math.cos(angle) + (width - icon_size) / 2
+y = newradius * math.sin(angle) + (height - icon_size -
style.GRID_CELL_SIZE) / 2
+
+width, height = self.box.get_allocation()
+return int(x) + (width - icon_size) / 2, \
+int(y) + (height - icon_size - (style.GRID_CELL_SIZE / 2) ) / 2
+
+def _calculate_xy(self):
+return -math.sin(self.my_orientation) * self.my_radius, \
+math.cos(self.my_orientation) * self.my_radius
+
+def _calculate_new_radius_orientation(self, icon_size):
+circumference = self.my_radius * 2 * math.pi
+n = circumference / icon_size
+self.my_orientation += 2 * math.pi / n
+self.my_radius += float(icon_size) / n
On Sat, Jul 31, 2010 at 7:36 AM, Walter Bender walter.ben...@gmail.com wrote:
On Sat, Jul 31, 2010 at 12:31 AM, Frederick Grose fgr...@gmail.com wrote:
On Fri, Jul 30, 2010 at 11:32 PM, Walter Bender walter.ben...@gmail.com
wrote:
On Fri, Jul 30, 2010 at 8:25 PM, Chris Ball c...@laptop.org wrote:
{...}
Here is a tighter spiral of 74 icons for the home view (running in the
Sugar emulator at 800x600).
Running the emulator with usr/bin/sugar-emulator -i 832x624
give a close match to the XO screen proportions.
Done. See http://wiki.sugarlabs.org/go/User:Walter#Home_View
-walter
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Home view activities layout
I have a version which will let you reposition the icons (haven't
added swap yet) but I am not sure how best to reset the layout. We
could have a separate icon on the Home View secondary palette that
will reset the spiral to an initial state. Any other ideas?
-walter
On Sat, Jul 31, 2010 at 7:40 AM, Walter Bender walter.ben...@gmail.com wrote:
I am heading off to vacation for a week, but I may get a chance to
play with moving/snapping the icons as well. In the meantime, the code
is quite simple:
--- favoriteslayout.py 2010-07-20 13:31:05.0 -0400
+++ favoriteslayout.py 2010-07-30 23:26:56.0 -0400
+
+class MyLayout(RingLayout):
+ Spiral layout based on Archimedean spiral: r = a + b*theta.
+
+ __gtype_name__ = 'MyLayout'
+
+ icon_name = 'view-mylayout'
+ Name of icon used in home view dropdown palette.
+
+ profile_key = 'my-layout'
+ String used in profile to represent this view.
+
+ def __init__(self):
+ RingLayout.__init__(self)
+ self.my_radius = _MINIMUM_RADIUS
+ self.my_orientation = math.pi
+
+ def _calculate_radius_and_icon_size(self, children_count):
+ Stub out this method; not used in `My Layout`.
+ return _MINIMUM_RADIUS, style.STANDARD_ICON_SIZE
+
+ def _calculate_position(self, radius, icon_size, index, children_count):
+ Increment the radius as you go; decrease the angle of rotation
+ as the radius increases to keep the distance between icons
constant.
+
+ print index %d (r: %f, o: %f) % (index, self.my_radius,
self.my_orientation)
+ if index == 0:
+ self.my_radius = _MINIMUM_RADIUS
+ self.my_orientation = math.pi
+
+ x, y = self._calculate_xy()
+ # add some buffering around the icon
+ self._calculate_new_radius_orientation(icon_size + 10)
+
+
+ # angle decreases as the radius increases
+ angle = index * (2 * math.pi / (12.0 + index / 6.0)) - math.pi / 2
+ # radius is proportional to index/children_count
+ myminimum = _MINIMUM_RADIUS * .67
+ newradius = ((_MAXIMUM_RADIUS - myminimum) * (index * 1.1) /
children_count) + myminimum
+ x = newradius * math.cos(angle) + (width - icon_size) / 2
+ y = newradius * math.sin(angle) + (height - icon_size -
style.GRID_CELL_SIZE) / 2
+
+ width, height = self.box.get_allocation()
+ return int(x) + (width - icon_size) / 2, \
+ int(y) + (height - icon_size - (style.GRID_CELL_SIZE / 2) ) / 2
+
+ def _calculate_xy(self):
+ return -math.sin(self.my_orientation) * self.my_radius, \
+ math.cos(self.my_orientation) * self.my_radius
+
+ def _calculate_new_radius_orientation(self, icon_size):
+ circumference = self.my_radius * 2 * math.pi
+ n = circumference / icon_size
+ self.my_orientation += 2 * math.pi / n
+ self.my_radius += float(icon_size) / n
On Sat, Jul 31, 2010 at 7:36 AM, Walter Bender walter.ben...@gmail.com
wrote:
On Sat, Jul 31, 2010 at 12:31 AM, Frederick Grose fgr...@gmail.com wrote:
On Fri, Jul 30, 2010 at 11:32 PM, Walter Bender walter.ben...@gmail.com
wrote:
On Fri, Jul 30, 2010 at 8:25 PM, Chris Ball c...@laptop.org wrote:
{...}
Here is a tighter spiral of 74 icons for the home view (running in the
Sugar emulator at 800x600).
Running the emulator with usr/bin/sugar-emulator -i 832x624
give a close match to the XO screen proportions.
Done. See http://wiki.sugarlabs.org/go/User:Walter#Home_View
-walter
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Problem with Pippy layout on =0.84
I agree that 'hiding' the action buttons away in a toolbar is rather unfortunate :-( , but wouldn't placing buttons as in the original layout eat up vertical space? No more than before (as has been the design for years). The old design with the buttons in the middle always struck me as non-standard in Sugar. I prefer the new design with all buttons in the toolbars. If it causes problems with Sugar 0.84, maybe we could simply mark the new bundle as 0.86-0.88 only? There is another way around this. alsroot, bemasc suggested using a local 'toolkit' version. This can be seen implemented in the fully-bundled branches of flipstiks, cartoonbuilder, speak. The idea is to use a local toolkit copy so that all activities are consistent across 0.82-0.88 and use the =0.86 toolbar. In the case of pippy, this means that the action buttons will always be visible on the main activity toolbar. Here [1] is an xo with the same implemented. This has been tested to work on 0.82-xo1, 0.84-xo1 (build 301), 0.88-jhbuild. Does anyone see roadblocks in using this scheme? [1] http://people.sugarlabs.org/~anish/Pippy-37-toolbar-fix-new.xo You are correct, and also wrong. Alexey (alsroot) created a system called toolkit that lets you backport the toolbars to older Sugar versions. bemasc but could m_anish use an old version of toolkit to get new toolbars across Sugar versions? alsroot bemasc: yup, in repos like flipstiks, cartoonbuilder and speak, there are fully-bundled brnach w/ toolkit directory which is new toolbars that work on 0.82 Using that has the advantages of only requiring the maintenance of one set of toolbars, and achieving consistency across Sugar versions. It has the disadvantage of breaking consistency with other Activities on 0.86. Anish -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Problem with Pippy layout on =0.84
On Sat, Jul 31, 2010 at 10:34 AM, Anish Mangal anishmangal2...@gmail.com wrote: I agree that 'hiding' the action buttons away in a toolbar is rather unfortunate :-( , but wouldn't placing buttons as in the original layout eat up vertical space? No more than before (as has been the design for years). The old design with the buttons in the middle always struck me as non-standard in Sugar. I prefer the new design with all buttons in the toolbars. If it causes problems with Sugar 0.84, maybe we could simply mark the new bundle as 0.86-0.88 only? There is another way around this. alsroot, bemasc suggested using a local 'toolkit' version. This can be seen implemented in the fully-bundled branches of flipstiks, cartoonbuilder, speak. The idea is to use a local toolkit copy so that all activities are consistent across 0.82-0.88 and use the =0.86 toolbar. In the case of pippy, this means that the action buttons will always be visible on the main activity toolbar. Here [1] is an xo with the same implemented. This has been tested to work on 0.82-xo1, 0.84-xo1 (build 301), 0.88-jhbuild. Does anyone see roadblocks in using this scheme? With this version, I n longer have an edit toolbar. This is a regression. It really is not so difficult to maintain toolbars across different versions. You can share most of the code even if the layout f the buttons changes. See Abacus as an example. -walter [1] http://people.sugarlabs.org/~anish/Pippy-37-toolbar-fix-new.xo You are correct, and also wrong. Alexey (alsroot) created a system called toolkit that lets you backport the toolbars to older Sugar versions. bemasc but could m_anish use an old version of toolkit to get new toolbars across Sugar versions? alsroot bemasc: yup, in repos like flipstiks, cartoonbuilder and speak, there are fully-bundled brnach w/ toolkit directory which is new toolbars that work on 0.82 Using that has the advantages of only requiring the maintenance of one set of toolbars, and achieving consistency across Sugar versions. It has the disadvantage of breaking consistency with other Activities on 0.86. Anish -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Problem with Pippy layout on =0.84
With this version, I n longer have an edit toolbar. This is a regression. No (and neither does the current Pippy-36 version), I've yet to merge that code into the mainline. This was just for testing out local toolkit. It really is not so difficult to maintain toolbars across different versions. You can share most of the code even if the layout f the buttons changes. See Abacus as an example. I see this as a unique case since we _really_ don't want to create a new 'Actions' toolbar to place the run, stop, clear buttons in . On the other hand, placing the buttons on the main toolbar (for =0.84 with the old design) results in corruption of the share combo, stop and keep buttons (probably due to lack of screen space). btw, [1] is another Pippy-xo with the change (similar to Abacus) that you're suggesting: [1] http://people.sugarlabs.org/~anish/Pippy-37-new.xo Anish On Sat, Jul 31, 2010 at 8:13 PM, Walter Bender walter.ben...@gmail.com wrote: On Sat, Jul 31, 2010 at 10:34 AM, Anish Mangal anishmangal2...@gmail.com wrote: I agree that 'hiding' the action buttons away in a toolbar is rather unfortunate :-( , but wouldn't placing buttons as in the original layout eat up vertical space? No more than before (as has been the design for years). The old design with the buttons in the middle always struck me as non-standard in Sugar. I prefer the new design with all buttons in the toolbars. If it causes problems with Sugar 0.84, maybe we could simply mark the new bundle as 0.86-0.88 only? There is another way around this. alsroot, bemasc suggested using a local 'toolkit' version. This can be seen implemented in the fully-bundled branches of flipstiks, cartoonbuilder, speak. The idea is to use a local toolkit copy so that all activities are consistent across 0.82-0.88 and use the =0.86 toolbar. In the case of pippy, this means that the action buttons will always be visible on the main activity toolbar. Here [1] is an xo with the same implemented. This has been tested to work on 0.82-xo1, 0.84-xo1 (build 301), 0.88-jhbuild. Does anyone see roadblocks in using this scheme? With this version, I n longer have an edit toolbar. This is a regression. It really is not so difficult to maintain toolbars across different versions. You can share most of the code even if the layout f the buttons changes. See Abacus as an example. -walter [1] http://people.sugarlabs.org/~anish/Pippy-37-toolbar-fix-new.xo You are correct, and also wrong. Alexey (alsroot) created a system called toolkit that lets you backport the toolbars to older Sugar versions. bemasc but could m_anish use an old version of toolkit to get new toolbars across Sugar versions? alsroot bemasc: yup, in repos like flipstiks, cartoonbuilder and speak, there are fully-bundled brnach w/ toolkit directory which is new toolbars that work on 0.82 Using that has the advantages of only requiring the maintenance of one set of toolbars, and achieving consistency across Sugar versions. It has the disadvantage of breaking consistency with other Activities on 0.86. Anish -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Problem with Pippy layout on =0.84
On Sat, Jul 31, 2010 at 08:04:35PM +0530, Anish Mangal wrote: I agree that 'hiding' the action buttons away in a toolbar is rather unfortunate :-( , but wouldn't placing buttons as in the original layout eat up vertical space? No more than before (as has been the design for years). The old design with the buttons in the middle always struck me as non-standard in Sugar. I prefer the new design with all buttons in the toolbars. If it causes problems with Sugar 0.84, maybe we could simply mark the new bundle as 0.86-0.88 only? There is another way around this. alsroot, bemasc suggested using a local 'toolkit' version. This can be seen implemented in the fully-bundled branches of flipstiks, cartoonbuilder, speak. The idea is to use a local toolkit copy so that all activities are consistent across 0.82-0.88 and use the =0.86 toolbar. In the case of pippy, this means that the action buttons will always be visible on the main activity toolbar. Here [1] is an xo with the same implemented. This has been tested to work on 0.82-xo1, 0.84-xo1 (build 301), 0.88-jhbuild. Does anyone see roadblocks in using this scheme? Just to inform.. This hack with bundled toolkit, is just a workaround. The regular way will be using polyol dependency (when sugar will understand dependecies) which will provide the same python API as current sugar-toolkit but will work (it already works in simple cases in GC) on all, popular in the field, sugars (also, it is vala based and the same code works not only in python but also, e.g., in GC). [1] http://people.sugarlabs.org/~anish/Pippy-37-toolbar-fix-new.xo You are correct, and also wrong. Alexey (alsroot) created a system called toolkit that lets you backport the toolbars to older Sugar versions. bemasc but could m_anish use an old version of toolkit to get new toolbars across Sugar versions? alsroot bemasc: yup, in repos like flipstiks, cartoonbuilder and speak, there are fully-bundled brnach w/ toolkit directory which is new toolbars that work on 0.82 Using that has the advantages of only requiring the maintenance of one set of toolbars, and achieving consistency across Sugar versions. It has the disadvantage of breaking consistency with other Activities on 0.86. Anish -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] getting TA into debain and universe
Matt, In order to reduce the maintain burden OLPC Debian and Ubuntu Sugarteam have a rather distinct workflow. Would you mind joining IRC #ubuntu-sugarteam between 9am and noon and 9pm and mid night? We have developers from around the world working so those are two prefer times we try to be available. If you can meet us there, we can help you push your package into Debian and sync it into Ubuntu. david On Sat, Jul 31, 2010 at 1:18 PM, Matthew Gallagher mattv...@gmail.com wrote: Sure, I'd probably have to clean up my package a bit, but that sounds like a good idea. On Sat, Jul 31, 2010 at 10:51 AM, David Farning dfarn...@gmail.com wrote: Hey Matt, I was wondering if you were interested in working with the Sugarteam to get TA into Debian and Ubuntu universe? david -- -Matthew Gallagher ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Home view activities layout
On 30.07.2010, at 20:25, Chris Ball wrote: Hi Christian, Hi Chris--to address scalability we have a list view from which you can select favorite activities to go in the ring. This is a similar technique to the OSX dock or Windows taskbar. I don't think this is working out. Yep. The frame menu is hardly discoverable. And even though it's there I tend to forget about it. And when I used it I press F3 and wonder why the home view doesn't show up (because the list view feels so unlike home). To solve at least this, F3 should toggle between home and list view. But +1 to spiral from here ... - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Name for Sugar Packages
Hi all, Just wondering, how to name Sugar Packages. The reasons to not reuse package name - it is not regular (GNU/Linux distributions) packages, because: * primal deploying model is decentralized (via 0install) not centralized which is the core point of regular distros * sugar packages still could be represented as regular packages to support centralized sugar distributions but in that case it will look like tunneling, e.g., ssh tunnels via http * in most cases, packages will contain results of doer experiments, e.g., not fully tested/QAed/etc stuff like packages in regular distributions (at least in stable distro releases) * in most cases, package maintainers will be their developers because there is no need in any packaging work except supporting an analog of activity.info file (for activities) The reasons to not reuse activity name: * packages might contain not only activities but libraries, other (not)well distro packaged dependencies, .xol content or sugar itself * it is about deploying content not about its quality The reasons to not reuse bundle name: * distribution will happen not only (or, usually, not at all) via bundles (e.g. .xo bundles) And the last but not least :) reason, it would be really cool to have special name for sugar packages, e.g, Ruby has gems, Python has eggs. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Name for Sugar Packages
On Sat, Jul 31, 2010 at 6:24 PM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Just wondering, how to name Sugar Packages. The reasons to not reuse package name - it is not regular (GNU/Linux distributions) packages, because: * primal deploying model is decentralized (via 0install) not centralized which is the core point of regular distros * sugar packages still could be represented as regular packages to support centralized sugar distributions but in that case it will look like tunneling, e.g., ssh tunnels via http * in most cases, packages will contain results of doer experiments, e.g., not fully tested/QAed/etc stuff like packages in regular distributions (at least in stable distro releases) * in most cases, package maintainers will be their developers because there is no need in any packaging work except supporting an analog of activity.info file (for activities) The reasons to not reuse activity name: * packages might contain not only activities but libraries, other (not)well distro packaged dependencies, .xol content or sugar itself * it is about deploying content not about its quality The reasons to not reuse bundle name: * distribution will happen not only (or, usually, not at all) via bundles (e.g. .xo bundles) And the last but not least :) reason, it would be really cool to have special name for sugar packages, e.g, Ruby has gems, Python has eggs. -- Aleksey Sugar cubes come to mind. The are prepared, bite-size or cup-size packages of compressed sugar grains. --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Name for Sugar Packages
On 31 Jul 2010, at 23:24, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Just wondering, how to name Sugar Packages. The reasons to not reuse package name - it is not regular (GNU/Linux distributions) packages, because: * primal deploying model is decentralized (via 0install) not centralized which is the core point of regular distros * sugar packages still could be represented as regular packages to support centralized sugar distributions but in that case it will look like tunneling, e.g., ssh tunnels via http * in most cases, packages will contain results of doer experiments, e.g., not fully tested/QAed/etc stuff like packages in regular distributions (at least in stable distro releases) * in most cases, package maintainers will be their developers because there is no need in any packaging work except supporting an analog of activity.info file (for activities) The reasons to not reuse activity name: * packages might contain not only activities but libraries, other (not)well distro packaged dependencies, .xol content or sugar itself * it is about deploying content not about its quality The reasons to not reuse bundle name: * distribution will happen not only (or, usually, not at all) via bundles (e.g. .xo bundles) Not sure I grasp the above. And the last but not least :) reason, it would be really cool to have special name for sugar packages, e.g, Ruby has gems, Python has eggs. But if it's a name game, I can't avoid suggesting Sugar cube ;) Regards, --Gary -- 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] Name for Sugar Packages
On Sun, Aug 01, 2010 at 01:00:04AM +0100, Gary Martin wrote: On 31 Jul 2010, at 23:24, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Just wondering, how to name Sugar Packages. The reasons to not reuse package name - it is not regular (GNU/Linux distributions) packages, because: * primal deploying model is decentralized (via 0install) not centralized which is the core point of regular distros * sugar packages still could be represented as regular packages to support centralized sugar distributions but in that case it will look like tunneling, e.g., ssh tunnels via http * in most cases, packages will contain results of doer experiments, e.g., not fully tested/QAed/etc stuff like packages in regular distributions (at least in stable distro releases) * in most cases, package maintainers will be their developers because there is no need in any packaging work except supporting an analog of activity.info file (for activities) The reasons to not reuse activity name: * packages might contain not only activities but libraries, other (not)well distro packaged dependencies, .xol content or sugar itself * it is about deploying content not about its quality The reasons to not reuse bundle name: * distribution will happen not only (or, usually, not at all) via bundles (e.g. .xo bundles) Not sure I grasp the above. And the last but not least :) reason, it would be really cool to have special name for sugar packages, e.g, Ruby has gems, Python has eggs. But if it's a name game, you got it :) I can't avoid suggesting Sugar cube ;) so, 3:0 for cubes.. I guess the place where these cubes are produced could be named refinery.sugarlabs.org -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] (fav)icons for SL sites
Hi all, What about having normal favions and icons for SL sites (current favions looks for me like $ symbols). I already have a couple of ideas: * library icon for activities.sl.o like http://activities.sugarlabs.org/en-US/sugar/addon/4089 I hope after switching to new AMO codebase, ASLO will support not only activities (after implementing 0sugar, links to activities i.e. w/o any activities tarbals) but also regular journal objects and we can rename activities.sl.o to library.sl.o. * smoky stand-pipe(s) for refinary.sl.o were activities are live/built i.e. activities sources and binaries (library.sl.o will be just users friendly catalog of activities). * (sugar) beet, i.e. source of sugar, for git.sl.o -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Name for Sugar Packages
On Sat, Jul 31, 2010 at 8:11 PM, Aleksey Lim alsr...@member.fsf.org wrote:
On Sun, Aug 01, 2010 at 01:00:04AM +0100, Gary Martin wrote:
On 31 Jul 2010, at 23:24, Aleksey Lim alsr...@member.fsf.org wrote:
{...}
so, 3:0 for cubes..
Sugar cubes nicely suggest a regular, ordered volume that would hold
packed content, which might sweeten your cup of brew.
I guess the place where these cubes are produced could be named
refinery.sugarlabs.org
refinery nicely suggests refinement or a place where one may find raw
materials, intermediate refinements, and the sweetest refinements or
finished products, and the tools or equipment needed for the process.
--Fred
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Name for Sugar Packages
On 1 August 2010 12:11, Aleksey Lim alsr...@member.fsf.org wrote: so, 3:0 for cubes.. I guess the place where these cubes are produced could be named refinery.sugarlabs.org +1 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
