Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#sugar-meeting meeting, 2011-06-12 16:09:29

Minutes | Index | Today     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
16:09 meeting Meeting started Sun Jun 12 16:09:29 2011 UTC. The chair is garycmartin. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:09 Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting
16:09 walterbender #link http://wiki.sugarlabs.org/go/D[…]urce_Enhancements
16:10 garycmartin #topic View Source
16:10 walterbender I have patches I sent to sugar-devel that implements all the features on this page
16:10 the questions I have are (1) is it even generally a good idea?
16:11 (2) are the icons and submenus OK?
16:11 manuq walterbender: I'm surprised to see you didn't get much reaction for this
16:11 walterbender (3) the icon for the modified activity could perhaps use some improvement (manuq has helped me some already)
16:12 manuq: the only one who has commented is Bernie... he loves it :)
16:12 garycmartin walterbender: I'm +1 on the idea.
16:12 manuq walterbender: +1 on the idea too!
16:12 it goes with the sugar philosophie
16:12 silbe walterbender: I like both ideas in general, but I'm not so sure about the concrete designs.
16:13 walterbender FWIW, I made a patch to Edit that will let you open your activity code from Sugar, perhaps more controversial
16:13 manuq wasn't sugar intended to be like this originally?
16:13 walterbender silbe: please speak up as this is why we have these meetings
16:13 manuq: yes
16:13 garycmartin walterbender: I don't have a better idea for where the feature should be exposed in the UI (i.e. I'm not convinced this is the correct place for it but I don't have a better suggestion and do not want to block landing the feature).
16:14 walterbender garycmartin: which feature?
16:14 silbe walterbender: Let's start with the "View Sugar Source" part. Do I understand correctly that you're going to show this option in the View Source dialog for all activities?
16:14 garycmartin walterbender: View Sugar Source
16:14 walterbender silbe: yes...
16:15 silbe: at first, I put it in under the Journal entry on the Frame, but then I decided that it should be available no matter what you view, since every activity uses Suagr
16:15 silbe walterbender: I don't think that's a good fit. How about enhancing the Frame icons of the zoom levels instead?
16:15 walterbender silbe: but it still may make sense to add it to the Sugar-specific entries too
16:16 silbe: the patch I had made for the Journal opened the Journal code by default...
16:16 silbe: we could open the appropriate Sugar code for each element
16:16 garycmartin silbe: the Frame zoom icons don't seem to map onto all the Sugar sources one might want to view.
16:16 walterbender silbe: and for Activities, perhaps open the toolkit
16:16 silbe walterbender: hmm, we could show the sugar-toolkit source in activities, but I'm a bit worried it encourages modifying the sugar-toolkit source to change the behaviour of a single activity...
16:17 manuq walterbender: if I understand correctly, the "original" activity is backed up, and the modified one starts being used, and this is represented in the sugar activity icon with an overlay
16:17 walterbender silbe: right now viewing and modifying are separate
16:17 manuq: correct...
16:17 silbe walterbender: I'd imagine the View Source option of each zoom level to show the full hierarchy, but pointing at the source file implementing that zoom level.
16:17 walterbender manuq: but right now, I only copy the activity code, not Sugar
16:18 silbe: yeah... I could do something like that...
16:18 silbe: and we could drop it into the menus whereever we can
16:18 garycmartin walterbender: straw man, what if 'all' source could be viewed via a CP module, like the about my computer, about me type thing
16:18 silbe walterbender: later on, we could enhance all other Frame icons (devices etc.) to do the same
16:18 walterbender silbe: right now, I expose all of the Sugar source (toolkit and jarabe)
16:19 garycmartin: I am OK with that idea as well.
16:19 silbe walterbender: I like that (exposing all of Sugar).
16:19 manuq +1
16:19 walterbender silbe: (I left out the stuff in usr/share/sugar for the moment... it is one line to add it
16:20 silbe walterbender: that would be the device icons (and Control Panel sections) part that comes later
16:20 walterbender silbe: yes
16:21 silbe: having lived with it for a while, I like having the Sugar source available when I look at activity source
16:21 garycmartin walterbender: I'm faintly concerned about rolling this out into 'every' primary palette, it'll add a lot of noise to the UI that 99% of folks will never touch.
16:22 silbe walterbender: interesting point. Maybe we could include it in View Source, but not in the Copy part?
16:22 walterbender silbe: that is the way it is currently implemented... I don't copy Sugar source
16:22 silbe: In part because it opens a whole can of worms
16:23 silbe walterbender: ok, in that case I'm less worried about including sugar-toolkit in the activity View Source.
16:23 lucian has quit IRC
16:23 walterbender silbe: if and when we can run Sugar in a VM inside of Sugar...
16:23 silbe walterbender: yes, View Source Sugar + Copy is definitely a can of worms...
16:23 walterbender silbe: I stopped at copy for Activities
16:24 silbe walterbender: VMs wouldn't be a solution (data store isn't shared), but that's more of a technical issue than a design one
16:24 walterbender silbe: it is pretty powerful to be able to directly modify activities on the fly within Sugar
16:24 silbe walterbender: ok, good.
16:25 walterbender silbe: should I only include the toolkit and not jarabe?
16:25 that is a matter of deleteing one line
16:25 garycmartin walterbender: Do you rename the activity? "My Abacus1"  (I'me sure we can improve on the svg overlay to be more clear)
16:25 walterbender and maybe we put the complere Sugar source somewhere else?
16:26 garycmartin: yes...
16:26 silbe walterbender: yes, please do. Activities are not supposed to interact with jarabe.* directly. All the API code is in sugar-toolkit. If that isn't sufficient (while browsing an activity), we should add more docstrings.
16:26 walterbender silbe: OK. I'll make that change
16:26 silbe:  and when we decide where to put the rest of the view source, I'll add it there.
16:27 manuq walterbender: there is also the issue about how the user gets to edit the code, that is, a code editor
16:27 garycmartin walterbender: It's a pity we couldn't manage a UI that made an auto activity copy on write, and then some UI to allow restoring the original if needed.
16:27 but that's a tougher to crack
16:27 silbe walterbender: thx! BTW, I guess you treat sugar-base the same as sugar-toolkit (since they share the same namespace)? What about sugar-artwork and sugar-datastore?
16:27 walterbender garycmartin: well, that is not so far off from what we have
16:27 silbe (personally I'd say leave those for the next iteration)
16:28 walterbender silbe: I agree.
16:28 silbe: I'll just include what is in site-map/sugar
16:28 silbe garycmartin: iff all activities are in the Journal, all you need to do is to use a data store with version support.
16:29 walterbender garycmartin: let me explain the copy workflow
16:29 garycmartin silbe: That is how I work here on my XOs and VMs.
16:29 walterbender (1) you click on copy on the View Source submenu
16:29 (2) you get a copy of the activity in $HOME/Activities, renamed My+... and with a new bundle_id and icon
16:30 garycmartin silbe: I keep the bundles of different version in Journal and then resume the bundle to get at a specific version for testing and checking.
16:30 walterbender (3) The new activity immediately appears in the Home View along with the old version
16:30 (4) you can remove the new activity from the List View
16:30 (5) If you copy a copy, you get yet another version
16:31 (6) If you recopy the original, you overwrite your copy (I need to add the Alert for that)
16:32 (7) You can edit your copy from Terminal using vi or from my modified Edit activity.
16:32 we should discuss Edit separately
16:32 silbe garycmartin: with version support we could combine those different entries in a single one, but otherwise it'd work very similar. The most important missing part is an IDE activity that can open bundles (i.e. zip files).
16:33 walterbender: is there a reason you copied to ~/Activities instead of putting a bundle in the Journal?
16:33 walterbender silbe: yes... because we run activites from ~/Activites, and I don't know how to run them from the Journal
16:33 silbe (both approaches have different downsides, FWIW)
16:34 manuq silbe: with version support it can be easier to send patches with the modifications also
16:34 walterbender silbe: I wanted the copy to be on an equal footing with the original
16:34 silbe walterbender: you simply put the bundle into the Journal. They get installed automatically when the user starts them.
16:35 walterbender silbe: when the user runs it, it gets unzipped into ~/Activities... same difference (except)
16:35 silbe: one more step for the user
16:35 garycmartin walterbender: though they can now share the source with Journal Send to --> friend.
16:35 silbe manuq: that's part of the different downsides. If you copy the activity to ~/Activities and initialise a git repository there, you can use git (almost) as usual. The same is not true of the Journal, unfortunately.
16:36 walterbender garycmartin: there is not point in sharing the copy until they modify it, which means it needs to be unzipped.
16:36 garycmartin: they get setup.py, so they can create a new budle
16:36 silbe walterbender: but now they have the a copy in the Journal, with everything that entails (backups, copying to storage medium, send to friend, ...).
16:36 garycmartin walterbender: good point.
16:37 walterbender silbe: we should either add a copy to journal action to setup.py or write an activity for managing activities
16:37 garycmartin walterbender: Is it possible to expose adding an activity as a bundle to the Journal?
16:38 walterbender garycmartin: I could do that easy enough, but I worry that the copy will not be what you expect, because it won't reflect your changes
16:38 garycmartin walterbender: this would allow editing the source and taking a snapshot into the Journal as a bundle for later recovery or sharing a new release.
16:39 silbe walterbender: why wouldn't the bundle include the changes?
16:39 walterbender garycmartin: but we never change the original activity, so it is redundant
16:39 silbe: the bundle I would generate and store in the Journal at copy is by definition *before* I make any changes to it
16:40 silbe: I am fine with bundles in the journal, but they should be made by the user when he makes changes, not when he copies
16:40 so it should be in setup.py, not in the copy mechanism
16:40 IMHO
16:41 silbe walterbender: I don't quite get it, sorry.
16:41 garycmartin silbe: What if the Journal exposed installed activities as bundles?
16:41 walterbender garycmartin: that would be cool
16:41 garycmartin: that would save a step and keep things autosynchronized
16:42 silbe: let me try to explain by reviewing the work flow:
16:42 silbe garycmartin: that's something I suggested at Sugar Camp in Paris. Some people liked it, others didn't. But if the Design Team says it's the way to go, I doubt anyone would oppose.
16:43 walterbender silbe: I copy an exisiting activity (let's ignore the how or even whether I copy a bundle into the Journal)
16:43 manuq garycmartin: and we have journal entries for the downloaded .xo activities currently
16:43 walterbender silbe: I now have an unzipped activity in ~/Activities
16:43 silbe: I modify that code
16:44 silbe: only at this point does it make sense to create a bundle with my modified code, because until now, I didn't modify it :P
16:44 make sense?
16:45 which brings up another point... should I reset the version no. to 1 when I make a copy?
16:46 silbe walterbender: the bundle-based work flow would be: 1. Copy the bundle to Journal, possibly doing some changes to activity/*. 2. Edit the bundle using some activity. 3. Run the activity from the edited bundle.
16:46 walterbender: if you change name and bundle_id, you should reset the version.
16:46 walterbender silbe: I don't know how you do your Step 1 without having unzipped first
16:47 silbe: how do you change the contents of the bundle without opening it?
16:47 #action: walter will reset the version no. on copy and changing bundle id
16:47 silbe walterbender: If you're inside an activity, you already have an unpacked copy. That's the purpose of ~/Activities: a cached of unpacked activity bundles.
16:47 walterbender #action walter will remove jarabe content from Sugar view source
16:47 silbe s/cached/cache/
16:48 walterbender silbe: exactly.
16:48 silbe: I suppose the difference is that I am not creating a bundle initially... I can.
16:48 silbe walterbender: Sugar will happily overwrite your changes in ~/Activities if you resume a bundle using the same name from the Journal, BTW.
16:49 walterbender silbe: but I think it adds an extra step fot the user
16:49 and as you point out, I think that users will accidently lose their changes by clicking on the bunlde
16:49 garycmartin walterbender: we could add a warning dialogue
16:49 walterbender silbe: I'd prefer to have the user explicitly create the bundle
16:50 silbe walterbender: I don't think it does. Instead of opening the Terminal to use a console text editor to edit ~/Activities/foo.Activity/*, they run an activity that can edit the contents of the bundle.
16:50 walterbender garycmartin: that is something we should do in general
16:50 silbe: maybe in an ideal world, but AFAIK, such an activity doesn't exisit
16:50 silbe I don't think adding that warning is straightforward...
16:50 walterbender ^exist
16:51 manuq walterbender: pippy?
16:51 walterbender manuq: pippy doesn't open activity bundles AFAIK
16:51 silbe walterbender: sure, but the code for your View Source enhancements didn't exist until very recently either.
16:52 walterbender silbe: true... but my view source enhancements do exist now... as do two other ways to edit activity code: Terminal and Edit
16:53 manuq walterbender, silbe I think ideally, the view source can be a edit source too
16:53 silbe I'm not sure what the _better_ workflow would be, BTW (especially if you consider the git issue). But what I'm sure about is that the bundle-based approach fits better into the Sugar design.
16:54 garycmartin manuq: Yea, I'd like to see that too. Apparently folks have in the past enabled some edit mode on the current view source widget to poke at this idea.
16:54 walterbender silbe: let me try to follow your proposed workflow.
16:54 garycmartin, manuq: I am not sanquin with that idea unless it is copy-on-write
16:55 garycmartin, manuq: and I think it adds a lot of complexity to view source
16:55 garycmartin, manuq it is the Sugar way to break such functionality up into different activities
16:56 back to silbe: just to make sure I understand what you are asking for
16:56 (1) copy into a bundle
16:56 (2) user opens bundle from Journal with some special bundle editor that
16:56 (2a) unpacks the bundle and
16:57 (2b) lets the user make changes and
16:57 (2c) create a new bundle
16:57 garycmartin walterbender: (2d) pauses to crank the XO powere handle for 10min.
16:58 walterbender silbe: I could kind of sort of live with that but we lose the magic of instantly getting a running copy in $HOME when you hit the copy button
16:58 silbe: and I would prefer to separate out the packing/unpacking of bundles from editing their content
16:59 silbe: so I would prefer to have 2a be the current mechanism
16:59 and have 2c be a sugarized version of setup.py dist_xo
16:59 and let a 1000 flowers bloom around 2b
17:01 notes that in order to do #1, I am going to have to make a copy, bundle it, and then delete it, only to unbundle it again at Step 2a...
17:01 garycmartin steps behind the heavy red curtain and in his best booming voice says, "Expose installed activities (and libraries) as bundles in the Journal!"
17:02 walterbender garycmartin: that is fine... but that is not really the issue here... I already said I was happy to add the bundle to the Journal
17:03 garycmartin: I think the issue is that it is being proposed that I delegate everything to a mythical bundle management/editing activity and I think it is unnessary and needlessly complex
17:03 ^unnecessary
17:04 or maybe I am missing some key insight here...
17:05 garycmartin: I don't see the point of making 2 abc be in an all-in-one uberactivity
17:06 shuts up and listens
17:06 garycmartin thinking still
17:10 walterbender: Slight tangent... Should the Activity Bundle Source palette option be "Duplicate", rather than "Copy"?
17:10 walterbender thinking
17:11 manuq garycmartin: +1
17:11 walterbender garycmartin: do we use duplicate for copying in the Journal and copy for the clipboard?
17:11 silbe_ <silbe_!~silbe@2001:6f8:120a:0:21f:d0ff:fe53:f5a2> has joined #sugar-meeting
17:11 walterbender garycmartin: if so, then yes
17:11 silbe_ walterbender: well, using ~/Activities could be considered needlessly complex as well. You're working against the internal architecture of Sugar (~/Activities is a cache), so you need to modify Sugar to cope with that (add some kind of warning dialog etc.).
17:12 walterbender silbe_: tell me how/where else someone runs/modifies activities?
17:12 silbe has quit IRC
17:12 aa` has quit IRC
17:12 cjb` has quit IRC
17:12 m_anish has quit IRC
17:12 bernie has quit IRC
17:12 satellit_ has quit IRC
17:12 silbe_ is now known as silbe
17:12 garycmartin thinks it could even be a new concept, just not Copy. Perhaps Clone, or Create My <activity name>
17:13 walterbender garycmartin: I am completely open to ideas...
17:13 silbe walterbender: Sugar does when you resume a bundle from the Journal
17:14 manuq silbe: using that cache is the way I hack activities
17:14 walterbender silbe: when you resume a bundle from the Journal, Sugar unzips to ~/Activities... what am I not getting?
17:14 manuq: I don't know how else to hack activities
17:14 silbe walterbender: that's exactly the problem. If you modify something in ~/Activities and later resume a bundle of that activity from the Journal, Sugar might overwrite it.
17:15 overwrite the changes in ~/Activities I mean
17:15 walterbender silbe: which was why I didn't want to make the bundle until the user wanted it... but we are going around in circles... I don't know where else to put it.
17:16 silbe: I am mostly an activity developer... I do a lot of that
17:16 garycmartin walterbender: another tangent, when the user clicks the Sugar Source, it might me good if the text "View source: '<activity name>', would change to indicate you were now viewing Sugar source.
17:16 silbe walterbender: yes, we should come to a decision. Both ways have their own set of drawbacks.
17:17 walterbender silbe: and the way I work is to make changes in ~/Activities...
17:17 silbe: when I like my changes, I make a new bundle
17:17 silbe walterbender: because nobody wrote an activity to do activity development in Sugar yet.
17:17 walterbender silbe: not quite true
17:18 silbe: you can write activities in Pippy and in Terminal
17:18 silbe:  and using my modified Edit
17:19 garycmartin walterbender: and there is Develop, which is a little scary but did work at one point
17:19 walterbender silbe: I need to review the Pippy code, but I think it creates something in ~/Activities, not just in the Journal
17:19 silbe walterbender: but they all modify the cache behind Sugars back, instead of using the Journal like other activities.
17:19 walterbender silbe: yes...
17:20 silbe: I think the idea that ~/Activities is just a cache is idealistic
17:20 but not the way people really work
17:20 silbe walterbender: maybe, but making it something else is a can of worms as well...
17:20 walterbender silbe: so unless we provide really good tools to make it easier to get your work done in the Journal rather than in the cache, we are going to ave issues
17:21 silbe: it already is something else
17:21 silbe: so that can is open
17:21 silbe: in practice, it you write activties, you do it in the "cache"
17:22 silbe: that is 99.9% the facts on the ground
17:22 silbe walterbender: not for Sugar. If we include your patch now, we'll have to make the internal code work well with it, too.
17:22 walterbender silbe: huh?
17:22 silbe: (1) Sugar doesn't use .xo bundles, just activities do
17:23 silbe: (2) my patch is not about modifying Sugar, just activities
17:23 silbe: unless you mean Sugar activities, in which case I think you are mistaken.
17:23 silbe walterbender: right now, we can say "be careful, you're doing something behind Sugars back". We can't say that if we include it as a feature.
17:24 walterbender: Sugar does the automatic unpacking of .xo bundles from the Journal. So it does use them.
17:24 walterbender silbe: we are talking across each other...
17:24 silbe walterbender: possibly
17:25 walterbender silbe: when I refer to the 99.9%, I am talking about writing/modifying activities
17:25 garycmartin silbe: Perhaps we can add a warning message when unpacking a bundle from Journal over an existing one?
17:25 silbe garycmartin: that's exactly what we'd need to do, but would be hard to get right.
17:25 walterbender silbe: almost every activity (except those preinstalled) is distributed as a bundle through the journal
17:25 garycmartin silbe: (manual rather than the automatic case as in a download via Browse or Software Update)
17:26 silbe garycmartin: huh?
17:26 walterbender maybe the situation is not so dire...
17:27 garycmartin silbe: user instigated unpacking via clicking on a Journal bundle should trigger the warning. Using Browse to download a .xo should be automatic.
17:27 walterbender unless I am mistaken, we don't unpack an activity if the version number hasn't increased
17:28 garycmartin walterbender: I thought that was removed.
17:28 silbe walterbender: what exactly would you expect Sugar to do if the user resumes a bundle from the Journal that has a different version than the unpacked (and potentially user-modified) copy in ~/Activities?
17:28 garycmartin silbe: It should raise a warning.
17:28 walterbender silbe: since it is My activity, I would be the one who changed the version number
17:29 silbe garycmartin: Downloading a bundle using Browse only puts it into the Journal. And there's no guarantee that the user hasn't modified exactly this activity.
17:29 walterbender silbe: I guess I am mistaken, but if the bundle didn't install unless the version number increased, I think we would have no issues at all
17:30 silbe garycmartin: then you raise a warning every time you try to run an updated activity. People will get used to clicking "Yes(, already, get out of my way!)".
17:30 walterbender silbe: my changes wouldn't be at risk unless I downgraded by version number in the cache copy
17:30 ^by^my
17:30 garycmartin silbe: No, only if they manually click on the .xo bundle in Journal.
17:31 silbe walterbender: or you get a newer version from somewhere else, yes.
17:31 walterbender silbe: how would I get a version of my activity from somewhere else?
17:31 silbe garycmartin: that's the only case we're talking about. Resuming an activity session always using the last-unpacked copy.
17:31 walterbender silbe: I suppose if I gave it to a friend to edit..
17:31 silbe walterbender: exactly
17:32 walterbender silbe: but that does raise a point: maybe ^My^nick
17:32 silbe: but if I get a copy from a friend, I am expecting that things will change...
17:33 silbe walterbender: but let's get this over with, one way or another. We'll deal with the fallout in the next version.
17:33 garycmartin Sorry folks, I need to bail. If I end meeting can one of you start it again and I'll catch up with the logs later?
17:33 walterbender silbe: the case I worry about is that the bundle you want me to create at the time of copy would potentially overwrite the changes I might havemade after copying
17:33 silbe garycmartin: you can change the chair instead.
17:33 garycmartin I can?
17:33 walterbender garycmartin: thanks for the input...
17:33 silbe meeting: help chair
17:33 meeting silbe: Error: There is no command "chair".
17:34 silbe meeting: help addchair
17:34 meeting silbe: (addchair <channel> <network> <nick>) -- Add a nick as a chair to the meeting.
17:35 silbe walterbender: I didn't get your last argument...
17:35 garycmartin Thanks, but I'll pass on grocking that..
17:36 silbe <g>
17:36 garycmartin #endmeeting
17:36 meeting Meeting ended Sun Jun 12 17:36:03 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4)
17:36 Minutes: http://meeting.sugarlabs.org/s[…]-12T16:09:29.html
17:36 Log:     http://meeting.sugarlabs.org/s[…]11-06-12T16:09:29

Minutes | Index | Today     Channels | Search | Join

Powered by ilbot/Modified.