Re: [Sugar-devel] Activity as regular objects proposal

2009-07-28 Thread Daniel Drake
2009/7/28 Aleksey Lim alsr...@member.fsf.org:
 The problems that 0.84 has in case of activity versions are:

 * it can't upgrade activities if they were pre-installed from
  native packages; it makes process of upgrading activities
  from .xo impossible

In reality Sugar's message is confusing here and I don't think any
distributor will mix-and-match the two ways of installing activities.
(either they'll use distro packages and disable .xo, or they will
exclusively use .xo e.g. OLPC).

This is a larger problem and I don't think yours is a solution, since
it will result in wasted disk space and we still end up with the
confusion of how activities can be installed and which one is being
used.

 * sugar can have only one activity version installed at the same
  time i.e. it could be useful to have several versions
  simultaneously e.g. to start proper version when join request
  arrived(activity version of arrived request could be different
  to installed version)

I think this calls for wider discussion. Having multiple versions of
the same activity installed sounds silly. Instead, activity designers
should be encouraged to strongly avoid making backwards-incompatible
protocol changes, just like the principles of any other software
designer. Once everything is compatible, this problem goes away. Sugar
should continue to make no promises about interoperability between
different major releases (e.g. no promises about 0.82 talking to 0.84)
and hence if it is necessary, activity developers are allowed to break
compatibility once every 6 months, which should be more than enough.

Finally, I personally don't like the idea of having activities (as in
applications) in the journal. The journal is for recording what the
user has done.

Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Activity as regular objects proposal

2009-07-28 Thread Aleksey Lim
On Tue, Jul 28, 2009 at 12:24:52PM +0545, Daniel Drake wrote:
 2009/7/28 Aleksey Lim alsr...@member.fsf.org:
  The problems that 0.84 has in case of activity versions are:
 
  * it can't upgrade activities if they were pre-installed from
   native packages; it makes process of upgrading activities
   from .xo impossible
 
 In reality Sugar's message is confusing here and I don't think any
 distributor will mix-and-match the two ways of installing activities.
 (either they'll use distro packages and disable .xo, or they will
 exclusively use .xo e.g. OLPC).

Well, thats question not only about distributor's comfort but about
users possibility to install new activity version.
Otherwise what your suggestion is?
* for pre-installed activities, using only non-xo methods to update
* using only non-xo activities
* using only xo activities

 This is a larger problem and I don't think yours is a solution, since
 it will result in wasted disk space

Proposal is not about storing all versions but about possibility of
storing not only one(last?) version and we can uninstall old versions
by removing entries from journal.

 and we still end up with the
 confusion of how activities can be installed and which one is being
 used.

There is no confusion, sugar is aware of what versions of particular
activity it has by using datastore.find() method, so user can run
`rpm update`, install any version by downloading .xo and sugar will run
last version(when user create new activity instance) or run particular
version(if activity object requires it). 

btw, activity can declare, in activity instance object, what activity
version(range) should be used with this particular instance object.

  * sugar can have only one activity version installed at the same
   time i.e. it could be useful to have several versions
   simultaneously e.g. to start proper version when join request
   arrived(activity version of arrived request could be different
   to installed version)
 
 I think this calls for wider discussion. Having multiple versions of
 the same activity installed sounds silly. Instead, activity designers
 should be encouraged to strongly avoid making backwards-incompatible
 protocol changes, just like the principles of any other software
 designer. Once everything is compatible, this problem goes away.

Well we can't say to activity developers that they must write
backwards-incompatible activities otherwise we won't host them on ASLO.
In that case using compatibility ranges of versions could fix problem
(w/o obliging developers write complicated code for
merge/support-backwards-incompatibility).

 Sugar
 should continue to make no promises about interoperability between
 different major releases (e.g. no promises about 0.82 talking to 0.84)
 and hence if it is necessary, activity developers are allowed to break
 compatibility once every 6 months, which should be more than enough.

I like this idea only if all sugar users have 100% access to internet.
And they can run upgrade my 0.82 to 0.84 from internet process by one
click. But imho thats impossible in case of educational infrastructure
around of the world.

 Finally, I personally don't like the idea of having activities (as in
 applications) in the journal. The journal is for recording what the
 user has done.

imho activities are the same kind of objects - user should have chance
to edit/hack/share them like other sugar objects.

-- 
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Activity as regular objects proposal

2009-07-28 Thread Aleksey Lim
On Tue, Jul 28, 2009 at 01:49:15PM +0545, Daniel Drake wrote:
 2009/7/28 Aleksey Lim alsr...@member.fsf.org:
  Proposal is not about storing all versions but about possibility of
  storing not only one(last?) version and we can uninstall old versions
  by removing entries from journal.
 
 The journal can't delete activities that are installed by a package at
 /usr/share/activities, and I also think it is unlikely that our users
 would realise to do this even if it were possible.
 
  There is no confusion, sugar is aware of what versions of particular
  activity it has by using datastore.find() method, so user can run
  `rpm update`, install any version by downloading .xo and sugar will run
  last version(when user create new activity instance) or run particular
  version(if activity object requires it).
 
 I was referring to confusion by deployments and those who are
 diagnosing bugs and soforth.
 
  btw, activity can declare, in activity instance object, what activity
  version(range) should be used with this particular instance object.
 
 Sounds like overcomplication.
 
 
 In response to your question on how I think it should be done, I feel
 that it's time to admit that packaging activities in this way is a
 mess. We should leave packaging and the related complications to the
 experts - packagers, and the package manager, and then we can stop
 wasting our time on it. For some kind of cross-distro package manager
 compatibility, someone recently raised the idea of PackageKit which
 seems well worth investigating and given its rapid development can
 probably be adapted to our needs.
 
 IOW I feel that the concept of sugar providing prepackaged binary
 activities should die.

+1, the way which was chosen by soas is a good example(all activities
come from .xo bundles)

 I think you would be a good person to work on
 this, and it is an interesting problem.
 
  Well we can't say to activity developers that they must write
  backwards-incompatible activities otherwise we won't host them on ASLO.
  In that case using compatibility ranges of versions could fix problem
  (w/o obliging developers write complicated code for
  merge/support-backwards-incompatibility).
 
 It's nice to have the freedom to post whatever I want on ASLO and I'm
 not saying that should change. I'm free to write a buggy activity or
 one that isn't sugarized and post it on ASLO. Even though my activity
 is low quality and doesn't fit into the desktop, I'm welcome to post
 it. The consequence is that my activity probably won't be included in
 deployments, and I'll get some mails from testers making suggestions
 how I could improve it, and maybe even some patches. I'd say that this
 case is no different.
 
  I like this idea only if all sugar users have 100% access to internet.
  And they can run upgrade my 0.82 to 0.84 from internet process by one
  click. But imho thats impossible in case of educational infrastructure
  around of the world.
 
 The responsibility of keeping all machines in sync can be handled by
 the deployments, with the aid of good tools from Sugar/distro/OLPC.
 This is how it already works in the field. It's not your problem, but
 you could certainly help improve those tools and their concepts which
 seem a bit neglected right now.

Well, for me 0.82 doesn't work with 0.84 is very strong requirement 
btw it relates to [2]

  imho activities are the same kind of objects - user should have chance
  to edit/hack/share them like other sugar objects.
 
 Good point, but this seems to be beyond what sugar is capable of at
 the moment and raises more questions. Perhaps once there is the
 ability to modify your activity within sugar, the development activity
 could offer functionality to package up the modified version and save
 it in the journal. Exactly how the user could modify activities, how
 the user-modified activity would be saved on-disk alongside the
 original one, how they would be differentiated in the UI and how the
 user could switch between the two seems to be out of scope of this
 discussion -- or at least I can't see how it would be covered by your
 proposal.

Yeah it raise many new questions.

In my mind we can do the first step on this road by creating
activity-less Composite Journal entries[2](objects w/o activity DS
field), so over activities(like Develop) can change activity's code
inplace. And delegate(for the first time at least) all maintenance
procedures (like what version I can change, what version is my backup
copy) to users, they can do this if all activities will be Journal
entries.

[1] http://wiki.sugarlabs.org/go/Features/Decoupling_of_Sucrose
[2] http://wiki.sugarlabs.org/go/Features/Object_Bundles#METADATA_file
 
 Daniel
 

-- 
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Activity as regular objects proposal

2009-07-28 Thread Sascha Silbe

On Tue, Jul 28, 2009 at 05:14:57AM +, Aleksey Lim wrote:


* it can't upgrade activities if they were pre-installed from
  native packages; it makes process of upgrading activities
  from .xo impossible

Yeah, this is really a PITA.


* sugar can have only one activity version installed at the same
  time
That's being worked on, see bug #1042 [1] (patch available, but not 
merged yet) and #1053 [2] (fixed).



i.e. it could be useful to have several versions
  simultaneously e.g. to start proper version when join request
  arrived(activity version of arrived request could be different
  to installed version)
That's not implemented yet, of course, and needs further design 
decisions (esp. regarding the UI).



[1] http://wiki.sugarlabs.org/go/Features/Activity_Objects
This sounds a lot like what I imagined as a solution for the first 
problem: represent system-installed activities as a virtual Journal 
object - inside Journal / shell only, not exposed to activities or the 
datastore.
What I don't get is how this depends on your Object Bundles proposal 
[3]. AIUI the latter is only an on-the-wire format, similar to the way 
regular Bundles work now.



[1] http://dev.sugarlabs.org/ticket/1042
[2] http://dev.sugarlabs.org/ticket/1053
[3] http://wiki.sugarlabs.org/go/Features/Object_Bundles

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] Activity as regular objects proposal

2009-07-28 Thread Tomeu Vizoso
On Tue, Jul 28, 2009 at 12:14, Sascha
Silbesascha-ml-ui-sugar-de...@silbe.org wrote:
 On Tue, Jul 28, 2009 at 05:14:57AM +, Aleksey Lim wrote:

 * it can't upgrade activities if they were pre-installed from
  native packages; it makes process of upgrading activities
  from .xo impossible

 Yeah, this is really a PITA.

As discussed in #sugar, deployers can choose between putting
activities in /usr/share or in ~/Activities depending on whether they
want to give users an easy way to uninstall and update activities.

To avoid space duplication in LTSP environments, ~/Activities can
contain symlinks to somewhere in /usr if the deployer wants users to
be able to uninstall and upgrade activities.

Regards,

Tomeu

 * sugar can have only one activity version installed at the same
  time

 That's being worked on, see bug #1042 [1] (patch available, but not merged
 yet) and #1053 [2] (fixed).

 i.e. it could be useful to have several versions
  simultaneously e.g. to start proper version when join request
  arrived(activity version of arrived request could be different
  to installed version)

 That's not implemented yet, of course, and needs further design decisions
 (esp. regarding the UI).

 [1] http://wiki.sugarlabs.org/go/Features/Activity_Objects

 This sounds a lot like what I imagined as a solution for the first problem:
 represent system-installed activities as a virtual Journal object - inside
 Journal / shell only, not exposed to activities or the datastore.
 What I don't get is how this depends on your Object Bundles proposal [3].
 AIUI the latter is only an on-the-wire format, similar to the way regular
 Bundles work now.


 [1] http://dev.sugarlabs.org/ticket/1042
 [2] http://dev.sugarlabs.org/ticket/1053
 [3] http://wiki.sugarlabs.org/go/Features/Object_Bundles

 CU Sascha

 --
 http://sascha.silbe.org/
 http://www.infra-silbe.de/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iQEcBAEBAgAGBQJKbs+bAAoJELpz82VMF3DafE4H/3tMOMuT0Rb/n2BNxtR/nT0T
 RqUXQjNDTK0eFgL5Y5ZgslBWszxf7SmronfKEayTXhthtzATsbwAtNxTt326Cv55
 nlDL8mOaFYohM8d8xT2j0ezOlukkK2FnK0Tmj3v3em388Ge54uJyKczAXC+LUY7K
 BN6y/GCFQQCD4n1L9AnkVwv3xMSobAbaUvduYQj5CrgxOIXYvMXOGxxpZNR9eFSW
 PdvDxACNeaejjNvGI+oAc/mCPlEx8bIDH4gJaQ5oMBg0RMo2T4sunmialsuw4NQ9
 XzDZOHHo41HnBWZX0vE2RMnTbTnc02ofR6k2za4xArhbbE4WYj8WwNRiBKCuW5I=
 =B498
 -END PGP SIGNATURE-

 ___
 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] Activity as regular objects proposal

2009-07-28 Thread Sascha Silbe

On Tue, Jul 28, 2009 at 12:18:58PM +0200, Tomeu Vizoso wrote:


To avoid space duplication in LTSP environments, ~/Activities can
contain symlinks to somewhere in /usr if the deployer wants users to
be able to uninstall and upgrade activities.
But this won't allow them to downgrade to the system-installed version 
without using Terminal and fiddling with symlinks.



PS: Please don't CC me, I'm subscribed to the list and set 
Mail-Followup-To accordingly (GMail ignores this unfortunately). By 
CCing my Reply-To address you cause my MUA to use that address as From 
when replying, so I have to manually change the address because 
otherwise the mailing list won't accept my post (i.e. queue it for 
moderation).


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] Activity as regular objects proposal

2009-07-28 Thread Aleksey Lim
On Tue, Jul 28, 2009 at 12:14:54PM +0200, Sascha Silbe wrote:
 On Tue, Jul 28, 2009 at 05:14:57AM +, Aleksey Lim wrote:
 
 * it can't upgrade activities if they were pre-installed from
   native packages; it makes process of upgrading activities
   from .xo impossible
 Yeah, this is really a PITA.
 
 * sugar can have only one activity version installed at the same
   time
 That's being worked on, see bug #1042 [1] (patch available, but not
 merged yet) and #1053 [2] (fixed).
 
 i.e. it could be useful to have several versions
   simultaneously e.g. to start proper version when join request
   arrived(activity version of arrived request could be different
   to installed version)
 That's not implemented yet, of course, and needs further design
 decisions (esp. regarding the UI).
 
 [1] http://wiki.sugarlabs.org/go/Features/Activity_Objects
 This sounds a lot like what I imagined as a solution for the first
 problem: represent system-installed activities as a virtual Journal
 object - inside Journal / shell only, not exposed to activities or
 the datastore.
 What I don't get is how this depends on your Object Bundles proposal
 [3]. AIUI the latter is only an on-the-wire format, similar to the
 way regular Bundles work now.

Since [3] is(in addition) an idea of having composite Journal
objects(when we have content of bundle stored somewhere in form of
ready to use directly, and this content is represented by one Journal
item) we can treat activities like a composite objects.

So, the idea is having Journal entries that should represent activities
(they are regular Journal entries and users can search/tag/etc. them)
and each of these Journal entries has entry field which points to
directory with activity. Shell can find() DS to be aware of what
versions/activities it has to start proper activity/activity-version to
activate particular object in Journal.

 [1] http://dev.sugarlabs.org/ticket/1042
 [2] http://dev.sugarlabs.org/ticket/1053
 [3] http://wiki.sugarlabs.org/go/Features/Object_Bundles
 
 CU Sascha
 
 -- 
 http://sascha.silbe.org/
 http://www.infra-silbe.de/



-- 
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Activity as regular objects proposal

2009-07-28 Thread Tomeu Vizoso
On Tue, Jul 28, 2009 at 12:30, Sascha
Silbesascha-ml-ui-sugar-de...@silbe.org wrote:
 On Tue, Jul 28, 2009 at 12:18:58PM +0200, Tomeu Vizoso wrote:

 To avoid space duplication in LTSP environments, ~/Activities can
 contain symlinks to somewhere in /usr if the deployer wants users to
 be able to uninstall and upgrade activities.

 But this won't allow them to downgrade to the system-installed version
 without using Terminal and fiddling with symlinks.

Anybody thinks this is worth changing so much code thus introducing new bugs?

Regards,

Tomeu

 PS: Please don't CC me, I'm subscribed to the list and set Mail-Followup-To
 accordingly (GMail ignores this unfortunately). By CCing my Reply-To address
 you cause my MUA to use that address as From when replying, so I have to
 manually change the address because otherwise the mailing list won't accept
 my post (i.e. queue it for moderation).

 CU Sascha

 --
 http://sascha.silbe.org/
 http://www.infra-silbe.de/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iQEcBAEBAgAGBQJKbtNVAAoJELpz82VMF3Da1xkH/joZkWzhgymva5YzNPnDF1gG
 SH0o82IDpc57XMV9ltRzDwa5sT9WlfjPJcz45LGg/sAhFBHO8ySreh83+iwSSpu4
 dM//r59twdlruVOwBEQ5OJsv95CXkFEOitjwzRGot6SHAmkQaDrR9rUICa5fF1Z2
 wJSRHgb2eSl/tlNnYp4jqkxChmtmpNQWnl6tttYqV4+Rf1A9kBrLuvTGHp5ViEtq
 hNUng6ucG3Zfv4umJBeLpJW7Gm9JJbPcnRBW0s/AsQLBDQYSqoIyOCj367ahgpXb
 Bt+gym2RYsRBDkLzoshEsfBuvTH2CFOHEZlcDzI7VY8HXJNxRSiPl6v77FB/vjE=
 =cSvj
 -END PGP SIGNATURE-


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Activity as regular objects proposal

2009-07-28 Thread Sascha Silbe

On Tue, Jul 28, 2009 at 12:38:32PM +0200, Tomeu Vizoso wrote:


To avoid space duplication in LTSP environments, ~/Activities can
contain symlinks to somewhere in /usr if the deployer wants users to
be able to uninstall and upgrade activities.
But this won't allow them to downgrade to the system-installed 
version

without using Terminal and fiddling with symlinks.
Anybody thinks this is worth changing so much code thus introducing 
new bugs?
The more important point is that it also works for people installing 
Sugar from packages on their own system, without manual symlink 
fiddling. My imagined use case is someone doing a full Sugar desktop 
installation (by using a corresponding meta package) and wanting to try 
out the latest Read release now featuring continuous scrolling (entirely 
fictional).


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] Activity as regular objects proposal

2009-07-28 Thread Tomeu Vizoso
On Tue, Jul 28, 2009 at 12:55, Sascha
Silbesascha-ml-ui-sugar-de...@silbe.org wrote:
 On Tue, Jul 28, 2009 at 12:38:32PM +0200, Tomeu Vizoso wrote:

 To avoid space duplication in LTSP environments, ~/Activities can
 contain symlinks to somewhere in /usr if the deployer wants users to
 be able to uninstall and upgrade activities.

 But this won't allow them to downgrade to the system-installed version
 without using Terminal and fiddling with symlinks.

 Anybody thinks this is worth changing so much code thus introducing new
 bugs?

 The more important point is that it also works for people installing Sugar
 from packages on their own system, without manual symlink fiddling. My
 imagined use case is someone doing a full Sugar desktop installation (by
 using a corresponding meta package) and wanting to try out the latest Read
 release now featuring continuous scrolling (entirely fictional).

Why this person doesn't have Read installed in ~/Activities?

Regards,

Tomeu

 CU Sascha

 --
 http://sascha.silbe.org/
 http://www.infra-silbe.de/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iQEcBAEBAgAGBQJKbtkHAAoJELpz82VMF3Da4yIH/Aw/GR+wWR1bg0e6mDt/K0xt
 fDDayc8V4/T7zA9EuJti9Hfykh41s2W+1UyzMNMMCAdZHY5HbMa2kAmI32tf7JCA
 /bKVf5y4Df2YNFg6PKc7Sq0hrzLHMsZQJqua803OKA2+MhnlyhLG5wSe1FrWU4NU
 BQ3/W6iI1cHFf5UkoJNmWiiDePMDxH3M7eh7h9wMhrvN7TJud0jZndyuNyjIZTm0
 +En0smg3NHAlWJg2shFfHM5xAvCOq3cZg1zCFmJWiZmIGrrQI8rFi0zjgiw9bPfb
 yBKkTQpTdBCvNsNomVCcwSNwDvsHAu+N/mamXNa9tDxdKusJcVe+YzfBGX6rfSc=
 =gtAA
 -END PGP SIGNATURE-


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Activity as regular objects proposal

2009-07-28 Thread Sascha Silbe

On Tue, Jul 28, 2009 at 10:37:18AM +, Aleksey Lim wrote:


Since [3] is(in addition) an idea of having composite Journal
objects(when we have content of bundle stored somewhere in form of
ready to use directly, and this content is represented by one Journal
item) we can treat activities like a composite objects.

So, the idea is having Journal entries that should represent 
activities

(they are regular Journal entries and users can search/tag/etc. them)
and each of these Journal entries has entry field which points to
directory with activity. Shell can find() DS to be aware of what
versions/activities it has to start proper activity/activity-version 
to

activate particular object in Journal.
So [3] is intended to be used inside Sugar itself? I don't think I like 
that. :-P

What's the reason for
a) storing several, different entities in the datastore object?
b) storing actual content outside of the datastore?



[3] http://wiki.sugarlabs.org/go/Features/Object_Bundles


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] Activity as regular objects proposal

2009-07-28 Thread Sascha Silbe

On Tue, Jul 28, 2009 at 12:59:43PM +0200, Tomeu Vizoso wrote:

The more important point is that it also works for people installing 
Sugar
from packages on their own system, without manual symlink fiddling. 
My
imagined use case is someone doing a full Sugar desktop 
installation (by
using a corresponding meta package) and wanting to try out the latest 
Read

release now featuring continuous scrolling (entirely fictional).

Why this person doesn't have Read installed in ~/Activities?
Because package managers usually don't touch home directories (for good 
reasons)?


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] Activity as regular objects proposal

2009-07-28 Thread Tomeu Vizoso
On Tue, Jul 28, 2009 at 13:36, Sascha
Silbesascha-ml-ui-sugar-de...@silbe.org wrote:
 On Tue, Jul 28, 2009 at 12:59:43PM +0200, Tomeu Vizoso wrote:

 The more important point is that it also works for people installing
 Sugar
 from packages on their own system, without manual symlink fiddling. My
 imagined use case is someone doing a full Sugar desktop installation
 (by
 using a corresponding meta package) and wanting to try out the latest
 Read
 release now featuring continuous scrolling (entirely fictional).

 Why this person doesn't have Read installed in ~/Activities?

 Because package managers usually don't touch home directories (for good
 reasons)?

But apps do on their first start.

Anyway, this is a packaging issue, representing out-of-DS dirs in the
journal doesn't seem to me like directly attacking the problem.

Other desktops use PackageKit for this, but we are not going to be
able to all interesting activities packaged for all distros anyway.

Regards,

Tomeu

 CU Sascha

 --
 http://sascha.silbe.org/
 http://www.infra-silbe.de/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iQEcBAEBAgAGBQJKbuKdAAoJELpz82VMF3DaB30H/19vNqdbF0BHfp1DUdHOduzl
 Z9plPyqODs5PtE3/Zw/LKH8Ay8wuNHTNOBnM/a01U/1H/19nmkH1IYMv09F+orO9
 vsPhu5o3OCQtMrpI65+7YB3yATGH+W0xgTN7Cx6sNBRt9rfStRrfR7QtXUe5cibq
 BpxHaQYI9vyH/OaZxUawykyPj3eEk7iarDNi2y+JnT22/rWZeunQNzj3c8WolpSB
 Lc0Qr6A5tYhFUQ6BDrdG/hptMS2Y4+Guu2a0emcjdp5hs59gaw4kfDOQFL/ptyiz
 +ZbPUwubCMOd3pFyvMUw3Pu85RxJDpPHdi8d3CcIUg4M2aOcItgsdzCDO22SYJ4=
 =1OLo
 -END PGP SIGNATURE-


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Activity as regular objects proposal

2009-07-28 Thread Albert Cahalan
Daniel Drake writes:

 Finally, I personally don't like the idea of having activities
 (as in applications) in the journal. The journal is for
 recording what the user has done.

I think that **uninstalled** activities belong in the journal.
An activity can be in the journal like any random data file,
or it can be in the launcher. It can be moved back and forth.

This should reduce confusion, clutter, accidental damage, etc.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Activity as regular objects proposal

2009-07-28 Thread Aleksey Lim
On Tue, Jul 28, 2009 at 01:01:32PM +0200, Sascha Silbe wrote:
 On Tue, Jul 28, 2009 at 10:37:18AM +, Aleksey Lim wrote:
 
 Since [3] is(in addition) an idea of having composite Journal
 objects(when we have content of bundle stored somewhere in form of
 ready to use directly, and this content is represented by one Journal
 item) we can treat activities like a composite objects.
 
 So, the idea is having Journal entries that should represent
 activities
 (they are regular Journal entries and users can search/tag/etc. them)
 and each of these Journal entries has entry field which points to
 directory with activity. Shell can find() DS to be aware of what
 versions/activities it has to start proper
 activity/activity-version to
 activate particular object in Journal.
 So [3] is intended to be used inside Sugar itself? I don't think I
 like that. :-P
 What's the reason for
 a) storing several, different entities in the datastore object?

The original purpose was fixing ugly(imho) situation with library
bundles, we had .xol in Journal, unzipped library in ~/Library, library
sidebar in Browse to open libraries. [3] simplifies process, so we have
only Journal entry which represent library (we can utilize regular(not
yet implemented) Journal features like [4] and [5] to browse and open
these libraries). 

 b) storing actual content outside of the datastore?

In fact it was temporary decision(but it works fine w/o dirty hacks)
later we can move it to DS(we can get feedback in 0.86 cycle and maybe
even change/remove OB at all).

[3] http://wiki.sugarlabs.org/go/Features/Object_Bundles
[4] 
http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#What.2FAnything_palette
[5] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tags_palette


-- 
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Activity as regular objects proposal

2009-07-28 Thread David Farning
On Tue, Jul 28, 2009 at 1:39 AM, Daniel Draked...@laptop.org wrote:
 2009/7/28 Aleksey Lim alsr...@member.fsf.org:
 The problems that 0.84 has in case of activity versions are:

 * it can't upgrade activities if they were pre-installed from
  native packages; it makes process of upgrading activities
  from .xo impossible

 In reality Sugar's message is confusing here and I don't think any
 distributor will mix-and-match the two ways of installing activities.
 (either they'll use distro packages and disable .xo, or they will
 exclusively use .xo e.g. OLPC).

This grows into a somewhat complicated issue for mozilla addons.  It
is rather common for distributions to mix and match the method for
installing addon.  Distros tend to repackage addons when they want to
add branding or add a bug fix.

david

 This is a larger problem and I don't think yours is a solution, since
 it will result in wasted disk space and we still end up with the
 confusion of how activities can be installed and which one is being
 used.

 * sugar can have only one activity version installed at the same
  time i.e. it could be useful to have several versions
  simultaneously e.g. to start proper version when join request
  arrived(activity version of arrived request could be different
  to installed version)

 I think this calls for wider discussion. Having multiple versions of
 the same activity installed sounds silly. Instead, activity designers
 should be encouraged to strongly avoid making backwards-incompatible
 protocol changes, just like the principles of any other software
 designer. Once everything is compatible, this problem goes away. Sugar
 should continue to make no promises about interoperability between
 different major releases (e.g. no promises about 0.82 talking to 0.84)
 and hence if it is necessary, activity developers are allowed to break
 compatibility once every 6 months, which should be more than enough.

 Finally, I personally don't like the idea of having activities (as in
 applications) in the journal. The journal is for recording what the
 user has done.

 Daniel
 ___
 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] Activity as regular objects proposal

2009-07-28 Thread Edward Cherlin
On Mon, Jul 27, 2009 at 11:39 PM, Daniel Draked...@laptop.org wrote:
 2009/7/28 Aleksey Lim alsr...@member.fsf.org:
 The problems that 0.84 has in case of activity versions are:

 * it can't upgrade activities if they were pre-installed from
  native packages; it makes process of upgrading activities
  from .xo impossible

 In reality Sugar's message is confusing here and I don't think any
 distributor will mix-and-match the two ways of installing activities.
 (either they'll use distro packages and disable .xo, or they will
 exclusively use .xo e.g. OLPC).

Sugar on a Stick currently presents this problem, where stock
Activities are installed from packages, but I can use .xos for
anything else. I found that I could go to the Activities directory,
delete a preinstalled Activity directory, and install a later version
by downloading. I wrote this up on [[The undiscoverable]].

 Daniel
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel




-- 
Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
And Children are my nation.
The Cosmos is my dwelling place, The Truth my destination.
http://earthtreasury.org/worknet (Edward Mokurai Cherlin)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Activity as regular objects proposal

2009-07-28 Thread Martin Dengler
On Tue, Jul 28, 2009 at 04:19:15PM -0700, Edward Cherlin wrote:
 Sugar on a Stick currently [has Fructose Activities installed] from
 packages

This has changed now in SoaS and F11-on-XO, which both now just use
.xos for Fructose and other non-Glucose activities.

Martin



pgphc53u8MLGc.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel