« Previous day | Index | Today | Next day » Channels | Search | Join
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
02:19 | valhalla has quit IRC | |
02:20 | valhalla <valhalla!~valhalla![]() |
|
03:47 | satellit_ <satellit_!~satellit![]() |
|
03:54 | cjl has quit IRC | |
07:31 | aa has quit IRC | |
07:31 | cjb has quit IRC | |
07:31 | dirakx has quit IRC | |
07:31 | marcopg has quit IRC | |
07:31 | satellit_ has quit IRC | |
07:31 | m_anish has quit IRC | |
07:31 | bernie has quit IRC | |
07:31 | alsroot has quit IRC | |
07:31 | pbrobinson has quit IRC | |
07:31 | yama has quit IRC | |
07:31 | mtd has quit IRC | |
07:31 | valhalla has quit IRC | |
07:31 | mk8 has quit IRC | |
07:31 | scorche has quit IRC | |
07:31 | rgs_ has quit IRC | |
07:31 | ChanServ has quit IRC | |
07:31 | CanoeBerry has quit IRC | |
07:31 | ClaudiaU_ has quit IRC | |
07:31 | [scs] has quit IRC | |
07:42 | aa <aa!~aa![]() |
|
07:42 | cjb <cjb!~cjb![]() |
|
07:43 | meeting | * ClaudiaU_-es has joined |
07:43 | CanoeBerry <CanoeBerry!~CanoeBerr![]() |
|
07:43 | ClaudiaU_ <ClaudiaU_!~ClaudiaU![]() |
|
07:43 | yama` <yama`!~yama![]() |
|
07:43 | valhalla <valhalla!~valhalla![]() |
|
07:43 | scorche <scorche!~scorche![]() |
|
07:43 | rgs_ <rgs_!~rgs![]() |
|
07:43 | mk8 <mk8!~torello![]() |
|
07:43 | mtd <mtd!~martin![]() |
|
07:43 | ChanServ <ChanServ!ChanServ![]() |
|
07:43 | hitchcock.freenode.net sets mode: +o ChanServ | |
07:44 | meeting_ <meeting_!~sugaroid![]() |
|
07:44 | [scs]_ has quit IRC | |
07:44 | dirakx has quit IRC | |
07:44 | marcopg has quit IRC | |
07:44 | alsroot has quit IRC | |
07:44 | pbrobinson has quit IRC | |
07:44 | CanoeBerry has quit IRC | |
07:44 | ClaudiaU_ has quit IRC | |
07:44 | mtd has quit IRC | |
07:44 | valhalla has quit IRC | |
07:44 | mk8 has quit IRC | |
07:44 | yama` has quit IRC | |
07:44 | scorche has quit IRC | |
07:44 | rgs_ has quit IRC | |
07:44 | ChanServ has quit IRC | |
07:44 | aa has quit IRC | |
07:44 | cjb has quit IRC | |
07:50 | bernie <bernie!~bernie![]() |
|
07:50 | m_anish <m_anish!~anish![]() |
|
07:50 | satellit_ <satellit_!~satellit![]() |
|
07:50 | marcopg <marcopg!~marcopg![]() |
|
07:50 | dirakx <dirakx!~rafael![]() |
|
07:50 | [scs]_ <[scs]_!~scs![]() |
|
07:50 | pbrobinson <pbrobinson!~pbrobinso![]() |
|
07:50 | alsroot <alsroot!~alsroot![]() |
|
07:50 | ChanServ <ChanServ!ChanServ![]() |
|
07:50 | mtd <mtd!~martin![]() |
|
07:50 | mk8 <mk8!~torello![]() |
|
07:50 | rgs_ <rgs_!~rgs![]() |
|
07:50 | scorche <scorche!~scorche![]() |
|
07:50 | valhalla <valhalla!~valhalla![]() |
|
07:50 | yama` <yama`!~yama![]() |
|
07:50 | ClaudiaU_ <ClaudiaU_!~ClaudiaU![]() |
|
07:50 | CanoeBerry <CanoeBerry!~CanoeBerr![]() |
|
07:50 | aa <aa!~aa![]() |
|
07:50 | cjb <cjb!~cjb![]() |
|
07:50 | sendak.freenode.net sets mode: +o ChanServ | |
07:54 | tch <tch!~tch![]() |
|
07:54 | tch has quit IRC | |
09:22 | m_anish has quit IRC | |
09:22 | bernie has quit IRC | |
09:23 | [scs]_ has quit IRC | |
09:23 | aa has quit IRC | |
09:26 | aa <aa!~aa![]() |
|
09:28 | bernie <bernie!~bernie![]() |
|
09:29 | [scs] <[scs]!~scs![]() |
|
09:31 | m_anish <m_anish!~anish![]() |
|
12:29 | meeting_ is now known as meeting | |
13:05 | cjb` <cjb`!~cjb![]() |
|
13:08 | aa` <aa`!~aa![]() |
|
13:10 | aa has quit IRC | |
13:10 | cjb has quit IRC | |
13:20 | lucian <lucian!~lucian![]() |
|
13:29 | lucian has quit IRC | |
13:30 | lucian <lucian!~lucian![]() |
|
13:56 | silbe <silbe!~silbe![]() |
|
14:05 | manuq <manuq!~manuq![]() |
|
14:35 | dfarning <dfarning!~dfarning![]() |
|
15:23 | dfarning has quit IRC | |
15:30 | garycmartin_ <garycmartin_!~garycmart![]() |
|
15:35 | garycmartin_ has quit IRC | |
15:43 | garycmartin <garycmartin!~garycmart![]() |
|
15:57 | walterbender <walterbender!~webchat![]() |
|
15:58 | silbe | walterbender: hey! Did you make the meeting after all? |
15:58 | walterbender | silbe: my ride was rained out :P |
15:59 | silbe | walterbender: let's hope it doesn't start raining here... Still have my laundry outdoors :) |
16:00 | walterbender | I think garycmartin and manuq are here for the meeting too |
16:00 | manuq | walterbender: hello! |
16:01 | walterbender | hi manuq |
16:01 | manuq | walterbender, I'll get your idea and go to ride my bike this afternoon |
16:02 | walterbender | I was going to be in a charity race this morning (50 miles) but it was rained out. |
16:02 | garycmartin | arrives late with a cup of tea |
16:03 | manuq | I use it all days for going here and there, but is a long time since I don't ride my bike just for distraction |
16:03 | hi garycmartin | |
16:03 | garycmartin | Hi all |
16:04 | silbe | hi garycmartin & manuq! |
16:04 | manuq | hi silbe! |
16:04 | garycmartin: just replied your email | |
16:05 | garycmartin | walterbender: you mentioned you wanted to discuss View Source and Journal. Shall I start meeting and we can dive in? |
16:05 | checks email | |
16:05 | manuq | is ready |
16:08 | walterbender | garycmartin: OK |
16:09 | maybe View Source first | |
16:09 | looks for the URL | |
16:09 | garycmartin | manuq: re:email you and Walter seemed to dis-like the clipboard icon (negative), where as you and Simon (erikos) both indicated you liked the scissors icon. I try not to count my own votes for things I suggest :) |
16:09 | #startmeeting | |
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![]() |
|
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 | |
17:36 | silbe | #startmeeting |
17:36 | meeting | Meeting started Sun Jun 12 17:36:10 2011 UTC. The chair is silbe. Information about MeetBot at http://wiki.debian.org/MeetBot. |
17:36 | Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting | |
17:36 | walterbender | bye garycmartin |
17:36 | silbe | #addchair #sugar-meeting freenode garycmartin |
17:36 | hmm, not quite apparently. | |
17:36 | garycmartin | silbe: lol |
17:37 | silbe | garycmartin: thx for joining in & have a nice evening! |
17:37 | walterbender | silbe: my last argument doesn't matter if bundles cannot overwrite the same version number |
17:37 | while I remember: | |
17:37 | #action change My to the user's nick | |
17:38 | silbe | manuq: are you still with us? |
17:38 | manuq | silbe: yes |
17:38 | garycmartin | walterbender: I'm still + on your changes, keeping in mind 'good' rather than stalling for 'perfect', just need to cross the t and dot the i, and polish where we can. |
17:39 | silbe | manuq: what's your take on this? |
17:39 | garycmartin | waves |
17:39 | manuq | thinking |
17:39 | garycmartin has quit IRC | |
17:39 | silbe | (I'm not trying to make you choose a "side", BTW - I'm unsure what the best approach is) |
17:41 | brb | |
17:42 | manuq | silbe: sorry I needed to read the last part of the discussion |
17:43 | aa` <aa`!~aa![]() |
|
17:43 | meeting | * aa`-es has joined |
17:43 | cjb` <cjb`!~cjb![]() |
|
17:43 | m_anish <m_anish!~anish![]() |
|
17:43 | bernie <bernie!~bernie![]() |
|
17:43 | satellit_ <satellit_!~satellit![]() |
|
17:43 | manuq | silbe, walterbender, IMHO I think it's good as a first take to try to mimic the current way of editing activities |
17:44 | that is, unzip to ~/Activities and hack there | |
17:45 | and avoid changing Sugar | |
17:47 | my two cents :) | |
17:47 | silbe | ok, let's do it walters way for now then. Maybe we can teach Sugar to use git for managing the cache. That way we don't need the warning. |
17:48 | if somebody develops a great IDE with bundle support, nobody prevents the users from using that workflow. | |
17:48 | walterbender | silbe: can you please confirm one way or another the current behaviour when you click on a bundle with the same version number as in the cache? |
17:49 | silbe: also same question but in regard to downgrades? | |
17:49 | silbe: this will inform me re how to best create the bundle on copy | |
17:50 | silbe: I am thinking it best to create a bundle with v 1 and *maybe* a cache with v1.1 ?? | |
17:51 | silbe | walterbender: jarabe.model.bundleregistry.BundleRegistry.upgrade(): |
17:51 | elif act.get_activity_version() == bundle.get_activity_version(): | |
17:51 | logging.debug('No upgrade needed, same version already installed.') | |
17:51 | walterbender | silbe: perfect... so there is no danger in making the bundle and unpacking it into the cache on copy |
17:52 | silbe | walterbender: as long as the version number is the same, nothing happens, yes. |
17:52 | walterbender | #action walter will make a bundle on copy and mv it to the Journal |
17:53 | silbe: so I think we are cool... as long as I create the bundle, I open the door to the future and as long as I unpack into the cache, I stay compatible with the status quo | |
17:53 | silbe | walterbender: sounds fine to me. |
17:53 | walterbender: thanks for hacking on this! | |
17:53 | manuq | walterbender: fine to me too |
17:54 | walterbender: yes, thankyou! | |
17:54 | walterbender | OK. I have 4-5 actions to take for the next pass... |
17:54 | manuq: if you could work more on the icon overlay, that would be appreciated | |
17:54 | silbe | ok, should we do a quick shot at PDF support in Browse and finish the meeting afterwards? |
17:54 | manuq | walterbender: yes! |
17:55 | walterbender | silbe, if you have the stamina, I'd like to add $HOME/Documents to the agenda as well |
17:55 | silbe | walterbender: fine with me. manuq? |
17:55 | manuq | silbe: yeah, I have time |
17:56 | silbe | walterbender: not sure we should discuss it without Gary, though. He had some issues with showing the Journal Volumes toolbar all the time. |
17:57 | walterbender | silbe: OK. it can wait... (although as I explained to Gary, it only appears if you have a $HOME/Documents, which the default builds don't include, I don't believe) |
17:58 | silbe: you should try the patch and live with it for a week... I'd be curious if you find it useful. | |
17:58 | silbe | #topic Browse: Export to PDF |
17:59 | #link Patch and description: https://patchwork.sugarlabs.org/patch/797/ | |
17:59 | #link Rationale: http://lists.sugarlabs.org/arc[…]1-May/031543.html | |
17:59 | walterbender: I'm not opposed to it - but let's discuss it in a few minutes. I'd like to get a PDF-enabled Browse out of the door soon. | |
18:00 | walterbender | silbe: sure... I am happy with the PDF approach... |
18:00 | manuq | reading |
18:00 | silbe | From the description: "Similar to the way it works for Turtle Art, we expose the functionality as a button in the Activity toolbar, with 'document-save' as icon. There is no way for the user to influence the result (i.e. to set print options)." |
18:00 | walterbender | silbe: that way we can focus all of our printing headaches into one place: PDF files |
18:01 | silbe | I'd like to get some feedback on the toolbar design - the place of the icon (currently: activity (sub)toolbar) and which icon to use (currently the generic 'document-save'). |
18:01 | walterbender | the only other approach that I think could work would be to do it in the Journal: copy Journal object to PDF |
18:02 | I thought at one point (in Write perhaps?) we had a specific icon for PDF save | |
18:02 | looks | |
18:03 | silbe | walterbender: that one would still require the activities themselves (resp. sugar-toolkit as a fallback) to implement the PDF support, but would require additional API so the Journal can tell the activity to save a PDF... |
18:04 | walterbender: ah, a PDF-specific icon would be great. | |
18:04 | walterbender | cannot find it... might have been in a long-ago deprecated version |
18:04 | manuq | walterbender: the pdf format has a popular icon |
18:05 | walterbender: I can sugarize it | |
18:05 | walterbender | I think it would be worth making the icon PDF specific |
18:06 | silbe | manuq: isn't that a trademark owned by Adobe? |
18:06 | manuq | pdf is a mark of adobe |
18:06 | yes | |
18:06 | silbe | #link http://www.adobe.com/misc/linking.html |
18:06 | "You may not use Adobe product icons except under a written license from Adobe." | |
18:07 | I don't think we should promote Adobe software by doing an icon based on their trademarks and asking for permission to use it. | |
18:07 | manuq | silbe: so we may need to generalize the icon, and the action, to export to printable format? |
18:08 | silbe | manuq: that would be one option. Or maybe put the letters "PDF" on it. I'll leave it up to you guys; I'm not a designer. |
18:08 | manuq | silbe: yes I don't like the idea of a trademark logo, there is no one in sugar and that's good |
18:10 | there is no "export document" icon in sugar already, right? | |
18:11 | silbe | manuq: I haven't found a specific one, nop. Write uses 'document-save', too. |
18:11 | manuq | silbe: yes |
18:11 | walterbender | manuq: we need a whole series of icons for importing and exporting different document types |
18:11 | silbe | and I guess that's fine - after all the only different is the format it gets saved in. |
18:12 | manuq | walterbender: good |
18:12 | walterbender, silbe, is it important that the icon reflects the format? | |
18:12 | walterbender | if you build them, I will use them :) |
18:13 | manuq | for example in a paint activity, export to png, to jpeg, etc |
18:13 | walterbender: ok :) | |
18:13 | walterbender | manuq: I think in Silbe's use case, the idea that the document is being exported for printing is important. |
18:13 | for paint, maybe you need that level of granularity | |
18:14 | manuq | walterbender: maybe, a pdf can be used to read on screen too |
18:14 | walterbender | in TA, I want to have a export as image; export as HTML, export as LOGO, etc. |
18:14 | silbe | manuq: I think it's important to use an icon that makes it clear that people can use it to export a PDF for printing / archiving. The generic document-save icon doesn't. |
18:14 | walterbender | manuq: good point |
18:14 | manuq | walterbender: and adding a printer to the icon may get the impression that the button would execute a print action |
18:15 | walterbender, silbe, so we need general export/import icons with the format explicit | |
18:15 | silbe | maybe something that gives the impression of taking a snapshot? |
18:16 | (for PDF) | |
18:17 | manuq | silbe, yes, or something to get the impression of a modification of the object that can be handled elswhere (export) of here (import) |
18:18 | silbe | if we define "export" to mean "saving in a format that isn't the preferred form of editing" (ala GPL), the snapshot icon (whatever it is) could be used for all exports, with the specific format given as text in the palette (like we do now with the document-save icon). |
18:18 | manuq | and something different than the copy/paste icons |
18:19 | silbe | ok, we're taking way longer than I anticipated. |
18:19 | do you agree with the placement of the export-pdf button or can we improve on that, too? | |
18:19 | manuq | silbe: ok, I can come with a proposal in the mailing list |
18:20 | silbe | manuq: awesome, thanks! |
18:20 | #action manuq to prepare a proposal for export icons and present it on sugar-devel | |
18:21 | manuq | walterbender: you still with us? |
18:21 | walterbender | +1 |
18:21 | manuq | good |
18:21 | silbe | ok. I guess the icon position is fine then. |
18:22 | manuq | silbe: I think yes, we may ask Gary too |
18:22 | silbe | ok |
18:22 | #topic Show ~/Documents in Journal | |
18:22 | walterbender: you have the stage | |
18:23 | walterbender | well, I think we wait until next week so that Gary can chime in, but I encourage you to try it... |
18:23 | I find that it makes me much more productive. | |
18:24 | and it is a feature that can be turned on/off by the availabily of $HOME/Documents, so it won't be noticed by the typical user. | |
18:24 | manuq | silbe: sorry one more thing about pdf export |
18:25 | maybe the good place for the button is inside the view subtoolbar | |
18:25 | walterbender | FWIW, I have gotten very positive feedback from all the teachers I have spoken with. |
18:25 | manuq | sorry edit subtoolbar |
18:25 | walterbender | manuq: if there is room there, it may make some logical sense... |
18:26 | manuq | walterbender: yes, it belongs there |
18:26 | silbe | manuq: interesting point. |
18:26 | manuq | walterbender: and more important, the url text imput is not shortened |
18:27 | silbe | manuq: at least on my system, the length of the activity title seems to have a fixed limit anyway |
18:28 | manuq | silbe: sorry I'm guessing the placement from reading your patch |
18:28 | silbe | manuq: an argument pro putting it into the activity toolbar is that Keep currently lives there, too. |
18:28 | manuq | I didn't have time to apply it |
18:29 | silbe | manuq: take a look at Write, it uses the same position. |
18:29 | manuq | silbe: yes I see now |
18:31 | silbe | walterbender: FWIW, I think your patch is a good interim measure for Sugar <-> Journal integration. |
18:31 | walterbender: in the long run I think datastore-fuse is the way to go. | |
18:31 | walterbender | silbe: thanks... mostly to tch |
18:31 | silbe: yes... any ETA? | |
18:33 | silbe: FWIW, in the long run, there are very different approaches to view source we may want to take as well... | |
18:33 | silbe | walterbender: ETA is infinite right now because no one is using it. With no users I can't justify the time to work on it (except when I need it myself). |
18:33 | walterbender | silbe: if/when we port to GNOME 3.0/Python 3.0, we have many more options |
18:34 | silbe | walterbender: +1 I consider the current View Source an interim measure as well. But I don't have a much better idea, so I'm mostly keeping my mouth shut. ;) |
18:34 | should we wrap up the meeting here? We can continue to chat afterwards. | |
18:34 | walterbender | I am running out of energy |
18:34 | plus I want to finish up my new activity... almost ready to launch | |
18:34 | manuq | needs to see sunday's sky |
18:34 | silbe | walterbender: no solar panel for your XO? ;) |
18:35 | ok, let's finish for today. | |
18:35 | #endmeeting | |
18:35 | meeting | Meeting ended Sun Jun 12 18:35:20 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4) |
18:35 | Minutes: http://meeting.sugarlabs.org/s[…]-12T17:36:10.html | |
18:35 | Log: http://meeting.sugarlabs.org/s[…]11-06-12T17:36:10 | |
18:35 | walterbender | silbe: no sun in Boston... 48 hours of heavy rain |
18:35 | silbe | Thanks everyone for joining in & have a nice day (or whatever is left of it)! |
18:36 | manuq | have a nice day! |
18:36 | silbe | walterbender: ok, would have to be a rather large panel then... |
18:36 | manuq | bye |
18:36 | silbe | manuq: cu next sunday I hope |
18:36 | walterbender | thanks manuq |
18:36 | CU | |
18:36 | manuq has left #sugar-meeting | |
18:39 | silbe has quit IRC | |
19:19 | dfarning <dfarning!~dfarning![]() |
|
22:01 | yama <yama!~yama![]() |
|
22:01 | yama has quit IRC | |
22:01 | yama <yama!~yama![]() |
|
22:04 | yama` has quit IRC |
« Previous day | Index | Today | Next day » Channels | Search | Join