« Previous day | Index | Today | Next day » Channels | Search | Join
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
00:00 | lucian <lucian!~lucian![]() |
|
00:02 | lucian has quit IRC | |
00:19 | tch has quit IRC | |
00:38 | CanoeBerry <CanoeBerry!CanoeBerry![]() |
|
01:35 | CanoeBerry has quit IRC | |
01:59 | darlan <darlan!~darlan![]() |
|
02:00 | darlan has quit IRC | |
02:33 | dogi has quit IRC | |
02:34 | satellit-gn3 <satellit-gn3!~sugar![]() |
|
02:52 | satellit-gn3 has quit IRC | |
04:03 | dirakx has quit IRC | |
04:28 | satellit-gn3 <satellit-gn3!~sugar![]() |
|
04:41 | alsroot_away is now known as alsroot | |
04:56 | satellit-gn3 has quit IRC | |
06:32 | yama has quit IRC | |
06:38 | yama <yama!~yama![]() |
|
06:38 | yama has quit IRC | |
06:38 | yama <yama!~yama![]() |
|
06:46 | dirakx <dirakx!rafael![]() |
|
07:02 | icarito <icarito!~icaro![]() |
|
07:25 | meeting <meeting!~sugaroid![]() |
|
07:25 | asimov.freenode.net | [freenode-info] help freenode weed out clonebots -- please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup |
07:43 | dirakx has quit IRC | |
08:53 | icarito has quit IRC | |
08:57 | icarito <icarito!~icaro![]() |
|
09:11 | dfarning is now known as dfarning_afk | |
09:42 | lucian <lucian!~lucian![]() |
|
11:59 | lucian has quit IRC | |
12:15 | silbe <silbe!~silbe![]() |
|
13:39 | satellit-gn3 <satellit-gn3!~sugar![]() |
|
14:00 | CanoeBerry <CanoeBerry!CanoeBerry![]() |
|
14:11 | walterbender <walterbender!~webchat![]() |
|
14:16 | dfarning_afk is now known as dfarning | |
14:17 | dfarning has left #sugar-meeting | |
14:35 | garycmartin <garycmartin!~garycmart![]() |
|
14:44 | m_anish_afk is now known as m_anish | |
15:00 | garycmartin | Ping, any one here for the design meeting? |
15:01 | silbe | garycmartin: yup |
15:01 | garycmartin | Hi silbe! |
15:01 | silbe | walterbender might be, too, but I don't see Christian yet... |
15:01 | garycmartin: good afternoon! | |
15:02 | walterbender | hi |
15:02 | garycmartin | Hi walterbender |
15:03 | walterbender | We transitioned off of Daylight Savings Time in the US last night... |
15:03 | people are prob. a bit confused about the hour | |
15:03 | garycmartin | Aaaah... |
15:03 | christianmarcsch <christianmarcsch!~christian![]() |
|
15:04 | walterbender | google calander has the wrong time :) |
15:04 | christianmarcsch | hi |
15:04 | silbe | ok, christianmarcsch seems to have got the time right anyway :) |
15:04 | christianmarcsch | silbe: yes! |
15:04 | garycmartin | (Here in the UK we go UTC+1 in two weeks) |
15:04 | christianmarcsch: Hi. | |
15:04 | silbe | FGrose is from Germany AFAIK, so he shouldn't have DST issues (yet ;) ) |
15:05 | garycmartin | #startmeeting |
15:05 | meeting | Meeting started Sun Mar 13 15:05:59 2011 UTC. The chair is garycmartin. Information about MeetBot at http://wiki.debian.org/MeetBot. |
15:05 | Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting | |
15:06 | christianmarcsch | i just forwarded a pdf with the frame option for the activity detail view |
15:06 | garycmartin | #link http://wiki.sugarlabs.org/go/Design_Team/Meetings |
15:06 | christianmarcsch | if anyone didn't receive it let me know! |
15:07 | silbe | christianmarcsch: when did you send it? It didn't arrive yet. |
15:07 | garycmartin | The agenda still needs a tidy, I didn't get around to tackling it this week (apologies). |
15:07 | christianmarcsch | silbe: just now, a minute ago |
15:07 | silbe: i sent it to your sugarlabs email | |
15:08 | garycmartin | #topic frame option for the activity detail view |
15:08 | christianmarcsch: thanks, pdf just arrived. | |
15:08 | christianmarcsch | garycmartin: great |
15:08 | so, the frame option is relatively conservative--the idea is to simply insert activity naming, scope, and description into the activity menu | |
15:09 | works well, IMO | |
15:09 | silbe | ok, now it's there |
15:09 | christianmarcsch | of the three options, this actually feels the most tied to the existing UI |
15:09 | garycmartin | looking... |
15:10 | christianmarcsch | (btw, i'm not sure if the other items in the menu are totally up-to-date) |
15:10 | garycmartin | christianmarcsch: was the tag section just too much for option 3? |
15:11 | christianmarcsch | garycmartin: we could include, but it didn't seem essential in this usecase |
15:11 | i think of this as a paired-down version of the detail view in journal | |
15:11 | it would co-exist with the current detail view | |
15:12 | satellit_afk is now known as satellit_ | |
15:12 | christianmarcsch | this option actually makes sense to me, if we are going for minimal changes overall |
15:13 | there are two variations, by the way | |
15:13 | i am leaning towards the former, but curious about what you think | |
15:15 | garycmartin | christianmarcsch: visually, I like it (first version of option 3), but I think there are a few things that might make option 2 better. |
15:17 | christianmarcsch: 1) there is the technical issue that walterbender already hit trying to reference the correct Journal object from the frame (multiple kept objects have the same ID) | |
15:20 | 2) hmm actually I don't think there is a 2) ;-) | |
15:21 | christianmarcsch | garycmartin: hah, ok |
15:21 | silbe | 2) more space available |
15:21 | christianmarcsch | i'm relatively impartial towards these ideas |
15:21 | personally i also liked both option 1 and 2 for different reasons | |
15:22 | walterbender | christianmarcsch: me too... as long as we chose one of them |
15:22 | christianmarcsch | but 3 did feel right, also, and would be easier to implement |
15:22 | (i think) | |
15:23 | garycmartin | christianmarcsch: would the existing Activity secondary toolbar remain unchanged? |
15:23 | christianmarcsch | garycmartin: for option 3, yes. it is in addition to whatever there is already |
15:24 | silbe | #1 is probably the easiest to implement and could be changed to the "flip over" effect. #2 and #3 both require changes to activities, with #2 being a major effort in non-Python activities. |
15:24 | garycmartin | would the duplication of sharing and title cause any technical issues? |
15:25 | dirakx <dirakx!rafael![]() |
|
15:25 | silbe | garycmartin: in theory: no. In practice we seem to be having some trouble with the existing title toolbar widget already. |
15:27 | (metadata change in the data store gets triggered at the wrong time because we don't seem to get a focus-out event under all circumstances and have hacked around that) | |
15:27 | garycmartin | I think my preference is for #1, it's visually simple with the most focus on task. |
15:28 | silbe | garycmartin: ok. What do you think about turning it full-screen, non-modal (e.g. auto-close on window switch) if we have the flip-over effect (activity -> metadata -> activity)? |
15:29 | garycmartin | silbe: perhaps for folks with composition enabled, we can make the dialogue fullscreen and then paint the semi transparent border. |
15:29 | silbe | garycmartin: and along the same lines, what about auto-close of the dialog if the focus leaves the window (think learner clicking "beside" the window) |
15:30 | christianmarcsch | i'd prefer to keep the transparent border around the dialog |
15:30 | from a design-perspective that's the space that would be occupied by the frame, and therefor it is nice to keep it reserved. it also gives context | |
15:30 | garycmartin | +1 to keeping the transparent border around dialogue, it's pretty critical for context. |
15:30 | silbe | garycmartin: I don't expect alpha borders to work well enough on the XO. Some simple transition effects (like the flip-over) might work, though. |
15:31 | garycmartin | silbe: They seem to be working fine on my XO-1! |
15:31 | christianmarcsch | silbe: we could also try a |
15:31 | silbe: (sorry) | |
15:31 | silbe: we could also try a "fake" alpha border with a dot pattern | |
15:32 | silbe | garycmartin: interesting. You need to tell how exactly you're doing that after the meeting. |
15:32 | christianmarcsch: "fake" alpha? | |
15:32 | garycmartin | silbe: I even get drop shadows on all the pop-up palettes and the frame, and it still seems quite happy. My main worry is memory, needs checking to see how much we would be loosing. |
15:32 | christianmarcsch | silbe: meaning with a dot pattern overlay. i think garycmartin mentioned this in the last meeting |
15:35 | silbe | christianmarcsch: ah, so "just" 0% and 100% alpha (but with a pattern), instead of some value in between (but without a pattern)? Sounds like it could work better, but I can't tell for sure without trying it out. |
15:36 | garycmartin: looking forward to trying it out myself. My experiences with compositing on XOs so far haven't been exactly pleasant (still need to try the new "chrome" driver on the XO-1.5). | |
15:36 | christianmarcsch | silbe: yes--as a fallback :) |
15:37 | garycmartin | silbe: quick hack, just open terminal and type metacity --replace --composite Sugar gets a little funky (frame corner hotspots stopped along with some keyboard shortcuts) right after, but just reboot and the setting sticks. |
15:37 | silbe | ok, so I guess everybody would be fine with #1, only details needing some fleshing out? |
15:37 | christianmarcsch | i want walter to weigh in too, since i know he was in favor of a frame option! |
15:37 | silbe | walterbender: ^ |
15:38 | garycmartin | christianmarcsch: the other trick could be copy the edges of the main window, open a fullscreen dialogue, and paint in the edges again but tinted darker. |
15:39 | silbe | garycmartin: ah, ok. But that involves only some small areas, right? Nothing comparing to the size in the mock-ups? |
15:40 | garycmartin | silbe: sorry didn't follow that. |
15:43 | silbe | garycmartin: I guess the alpha / compositing stuff that metacity --composite does only affects small parts of the screen? A few pixels around each window? I'm worried that doing alpha composition on large parts of the screen would take too long to render on XO-1 (and maybe XO-1.5 for now). |
15:43 | garycmartin | silbe: idea is to make a dialogue that looks just like the dialogue in option 1. but cheating the alpha effect by faking the transparent effect with black tinted edge strips pasted in from the original (now hidden) canvas |
15:44 | silbe | garycmartin: I don't think the latter idea will fly - reading from video memory is rather slow on systems that don't share the main memory with the graphics chip. IIRC the XOs use a separate video memory. |
15:45 | garycmartin | silbe: running metacity --replace --composite worked fine on my XO-1 for casual use, and testing Moon activity running with 50% transparency, but yes I'm sure it is buffering all the windows and eating a bunch more memory, actual speed didn't seem slower. |
15:45 | silbe | but these should be implementation details anyway |
15:46 | christianmarcsch | i'm going to have to drop off in a few mins |
15:46 | it would be great if we could get a decision on this today though... | |
15:47 | any of the three directions would work i think | |
15:47 | garycmartin | Do we have agreement on Option 1? |
15:47 | christianmarcsch | i also like option 1 |
15:47 | garycmartin: +1 | |
15:47 | garycmartin | +1 (and do what ever we can to fix dialogues) |
15:47 | silbe | christianmarcsch: we could decide to give #1 a try. walterbender can still follow up via email, and if it doesn't work out during implementation we can still reconsider |
15:48 | christianmarcsch | silbe: that makes sense. |
15:48 | silbe: it would actually be good to test if before rolling out | |
15:49 | garycmartin | Fab. |
15:49 | christianmarcsch | great! |
15:50 | and if you have any other thoughts for additional options, let me know | |
15:50 | garycmartin | #agreed Option 1 (dialogue view of details) |
15:50 | silbe | christianmarcsch: we always test before shipping something. The only difference is how much work is going to be wasted when we decide to jump trains (does that make sense in english?) later. |
15:50 | christianmarcsch | silbe: yes, that's what i expected! |
15:51 | garycmartin | christianmarcsch: we need a standard toolbar button to pop-up the dialogue, ideally it would be used both in activities and in the journal. |
15:51 | christianmarcsch | one question about option 1 |
15:51 | would we be able to invoke it through the activity toolbar? | |
15:51 | or do we keep the current activity toolbar as is? | |
15:51 | garycmartin: we had the same thought! :) | |
15:51 | silbe | how else would the user invoke it? |
15:52 | christianmarcsch | silbe: through the hover palette in journal, and in other views |
15:52 | garycmartin | christianmarcsch: we could replace the Keep button with a details view button |
15:52 | christianmarcsch | silbe: but i agree there should be a way to do that through the activity toolbar |
15:52 | garycmartin: that's a great idea | |
15:52 | garycmartin: we could even repurpose the icon, unless there is a better solution | |
15:52 | silbe | oh, that reminds me: Browse has special UI to show the details view for downloaded items. How should the new feature interact with that? |
15:53 | garycmartin | As you need to dash, lets have a think over this week about it and tackle it next week. |
15:53 | christianmarcsch: ^ | |
15:53 | christianmarcsch | silbe: is there a screenshot of that feature on the wiki? |
15:53 | silbe | christianmarcsch: oh, so the dialog is meant to replace the details view in the Journal as well? |
15:53 | christianmarcsch | silbe: yes... |
15:53 | silbe: for option 1, i think it's best if it is fully consistent | |
15:54 | garycmartin | silbe: Browse? Does it? Hmmm, that's new to me :) |
15:55 | silbe: (or do you mean the alert that pop-up after a download has completed 'show in journal' thing?) | |
15:55 | silbe | garycmartin: that's the one. Haven't found any screenshot on the wiki showing it, though... |
15:56 | christianmarcsch | hmm |
15:56 | garycmartin | silbe: it has no icon, it's just an alert strip under the toolbar that pops up with text and OK/show in journal buttons |
15:56 | christianmarcsch | garycmartin: oh, i see |
15:57 | folks, i'm going to have to jump off | |
15:57 | but it's good we could reach consensus on option 1! | |
15:57 | garycmartin | christianmarcsch: many thanks for getting the mockups done! |
15:57 | christianmarcsch | garycmartin: sure! |
15:57 | same time next week? | |
15:57 | garycmartin | Yey, consensus! :-) |
15:57 | christianmarcsch: same time next week +1 for me | |
15:58 | silbe | garycmartin: from a technical PoV, the existing feature Browse uses and the proposed feature are very similar. The question is whether we to pop up the metadata dialog for a downloaded item on top of Browse (=> could just tweak the existing code), but ... |
15:58 | christianmarcsch | see you later |
15:58 | silbe | s/but .../ or switch to the Journal and pop it up there. |
15:58 | christianmarcsch has quit IRC | |
15:59 | walterbender | +1 and thanks to all |
16:00 | garycmartin | silbe: No I think the case is different, clicking the proposed "show detail view" widget in Browse would be for tweaking it's metadata, not the metadata of something you just downloaded. |
16:01 | silbe: ...or did you mean that the existing Browse 'show in journal' alert could be updated to use the new proposed detail view dialogue instead? | |
16:01 | silbe | garycmartin: the latter one |
16:02 | garycmartin | :) |
16:02 | silbe | garycmartin: the API is "show the details view for uid=xyz" |
16:03 | garycmartin | silbe: OK, well yes possibly, will need to think on the use case. One for next week? |
16:03 | silbe | garycmartin: +1 |
16:03 | garycmartin | #endmeeting |
16:03 | meeting | Meeting ended Sun Mar 13 16:03:40 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4) |
16:03 | Minutes: http://meeting.sugarlabs.org/s[…]-13T15:05:59.html | |
16:03 | Log: http://meeting.sugarlabs.org/s[…]11-03-13T15:05:59 | |
16:03 | silbe | garycmartin: thanks for leading the meetings, BTW. |
16:04 | garycmartin | Thanks silbe, walterbender, same time next week. |
16:04 | silbe | looking forward to it. |
16:04 | walterbender | OK. sorry I had to step out for a moment... |
16:05 | you guys are making good progress | |
16:05 | garycmartin | silbe: Weekly is OK as long as we don't go too much over time (we used to do it every two weeks to avoid burn out I think). |
16:05 | silbe | garycmartin: maybe we could also talk next week about how to fix dialogs (as you mentioned above)? |
16:06 | garycmartin | silbe: isn't that more a technical/implementation issue? |
16:07 | silbe | garycmartin: yep, keeping the time down is definitely a good idea. One, max. two hours would seem a good fit. |
16:07 | garycmartin: the dialog fixing? Depends on what exactly you meant. | |
16:08 | garycmartin: i.e. how _should_ the dialogs behave, and in what way do we currently deviate from that? The first part is design, the second implementation. | |
16:09 | garycmartin | silbe: ah, OK see what you mean, I was hoping you'd tell us the bits you thought were currently broken ;) |
16:09 | silbe | garycmartin: heh. |
16:09 | garycmartin: "We use dialogs." :-P | |
16:12 | garycmartin: you mentioned using alpha composition in / with Moon. Can you give details? Or was that just on an in-activity level, using Cairo? | |
16:14 | garycmartin | silbe: FWIW With my design hat on I don't like modal dialogues, however I'll make exceptions to that general rule when they are only modal to a single Activity (i.e don't block the whole system), and are used in a fullscreen design (e.g the user can't miss that they are now in a modal dialogue state). |
16:17 | silbe: Moon, just looking again, I was mucking around with full window transparency in gtk | |
16:18 | silbe | garycmartin: I agree on having no global dialogues. In applications (activities) that can be OK for some stuff, but I don't really like them. But not being a designer, I often don't have a better idea, so I try to restrain myself from complaining too much (not always successfully ;) ). |
16:18 | garycmartin: interesting. Can you send me the patch, please? (silbe![]() |
|
16:21 | garycmartin | silbe: it's a tidily little one liner, self.set_opacity(0.5) down at about line #193 of moon.py (at the end of the __init__ method) |
16:28 | silbe | garycmartin: thanks, will try that. FWIW, end of __init__.py is line 179/180 for me (mainline/master). |
16:35 | m_anish is now known as m_anish_afk | |
16:36 | m_anish_afk is now known as m_anish | |
16:39 | satellit_ | silbe: bugzilla 684588 surf-115.xo on sugar 0.90.0 on f15 gnome3 test day .iso installed to HD |
16:39 | browse 120 also will not start | |
16:40 | running gnome3 | |
16:41 | FYI looking foreward...... | |
16:50 | silbe | satellit_: can't say I'm surprised that Browse won't work (xulrunner has always been problematic), but I am (surprised) that Sugar starts at all on a system running Gnome 3. That's good news. |
16:52 | satellit-gn3 | here it is. Xchat I used dd to write iso to USB booted it and installed to USB external HD. works on ACER ASPIRE ONE but not on EeePC1000HE (that uses fallback to gnome 2.... |
16:53 | yum groupinstall sugar* --skip-broken (evince deps) | |
16:55 | sugar-emultor works also..but as teminal command "sugar-emulator -f" Netbook screen too small for menu start | |
16:55 | garycmartin has quit IRC | |
17:24 | satellit-gn3 has quit IRC | |
17:58 | m_anish is now known as m_anish_afk | |
18:59 | icarito has quit IRC | |
20:27 | alsroot is now known as alsroot_away | |
21:01 | yama` <yama`!~yama![]() |
|
21:01 | yama` has quit IRC | |
21:01 | yama` <yama`!~yama![]() |
|
21:02 | alsroot_away has quit IRC | |
21:03 | yama has quit IRC | |
21:04 | alsroot_away <alsroot_away!~alsroot![]() |
|
21:04 | alsroot_away has quit IRC | |
21:04 | alsroot_away <alsroot_away!~alsroot![]() |
|
21:44 | walterbender has quit IRC | |
22:38 | dogi <dogi!~nemo![]() |
|
22:52 | dogi has quit IRC | |
22:53 | dogi <dogi!~nemo![]() |
|
23:13 | silbe has quit IRC |
« Previous day | Index | Today | Next day » Channels | Search | Join