| **** ŽURNALAS PRADĖTAS Thu Jan 6 15:01:51 2005 | ||
| -->Jūs dabar kalbate #schooltool | 15:01 | |
| ---#schooltool tema yra http://schooltool.org | 15:01 | |
| ---#schooltool temą nustatė mgedmin Wed Jan 5 20:29:01 2005 | 15:01 | |
| **** ŽURNALAS BAIGTAS Thu Jan 6 16:32:50 2005 | ||
| **** ŽURNALAS PRADĖTAS Thu Jan 6 16:32:50 2005 | ||
| ---Atsijungta (). | 16:42 | |
| **** ŽURNALAS BAIGTAS Thu Jan 6 16:42:20 2005 | ||
| **** ŽURNALAS PRADĖTAS Thu Jan 6 17:16:08 2005 | ||
| -->Jūs dabar kalbate #schooltool | 17:16 | |
| ---#schooltool tema yra http://schooltool.org | 17:16 | |
| ---#schooltool temą nustatė mgedmin Wed Jan 5 20:29:01 2005 | 17:16 | |
| ---#schooltool :[freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup | 17:16 | |
| *mgedmin sitting in a cellar in a cafe | 17:16 | |
| -->alga (~alga@213.226.190.88) atėjo į #SchoolTool | 17:16 | |
| *mgedmin has internet over wifi to alga's laptop which gets internet over gprs via a bluetooth phone | 17:17 | |
| alga | yeah | 17:17 |
|---|---|---|
| bska|mobile | heh | 17:17 |
| alga | hi guys | 17:18 |
| bska|mobile | hey | 17:18 |
| th1a | Give me a minute to blog that. | 17:19 |
| SteveA | "I'll blog that for a dollar!" | 17:20 |
| tvon | actually I think the zodb errors are due to some firefox tweaks I made recently | 17:21 |
| tvon | seems fine in epiphany | 17:21 |
| SteveA | how on earth could a browser influence getting a zodb error? | 17:21 |
| th1a | Yeah? | 17:21 |
| SteveA | unless something is wrong at a deeper level | 17:21 |
| tvon | lemme see if I can find it | 17:21 |
| SteveA | okay | 17:23 |
| SteveA | are you using frames? | 17:23 |
| SteveA | iframes? | 17:23 |
| tvon | http://tonytalkstech.com/2004/12/28/turbo-charge-your-firefox-browser/ | 17:23 |
| th1a | Ah. | 17:25 |
| tvon | though Brian says he doesnt get the error and he did the same thing I believe | 17:25 |
| th1a | There's a reason that's off by default. | 17:25 |
| *bska|mobile nods | 17:25 | |
| mgedmin | what error do you get? | 17:25 |
| SteveA | that is such a sucky thing to do | 17:25 |
| SteveA | netscape did the same trick to make navigator seem faster back in the day | 17:25 |
| mgedmin | HTTP pipelining is part of the HTTP/1.1 standard, isn't that? and schooltool claims to support HTTP/1.1 | 17:26 |
| ---Atsijungta (). | 17:41 | |
| **** ŽURNALAS BAIGTAS Thu Jan 6 17:41:20 2005 | ||
| **** ŽURNALAS PRADĖTAS Thu Jan 6 17:43:14 2005 | ||
| -->Jūs dabar kalbate #schooltool | 17:43 | |
| ---#schooltool tema yra http://schooltool.org | 17:43 | |
| ---#schooltool temą nustatė mgedmin Wed Jan 5 20:29:01 2005 | 17:43 | |
| ---#schooltool :[freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup | 17:43 | |
| SteveA | at canonical, we'll be moving launchpad to use 2.4 in the near future | 17:43 |
| tvon | is it an issue with packaging schooltool or with testing 2.4? | 17:43 |
| -->alga_ (~alga@213.226.190.57) atėjo į #SchoolTool | 17:43 | |
| SteveA | zope3 should support python 2.4 right now | 17:44 |
| tvon | not to suggest we would dep on 2.4 | 17:44 |
| bska|mobile | mgedmin_: you mentioned generating an empty .po file for testing i18n: coverage | 17:45 |
| bska|mobile | after make extract-translations and update-translations | 17:46 |
| jinty | So then we just follow the default pyhton | 17:46 |
| mgedmin_ | not exactly an empty one | 17:46 |
| mgedmin_ | use msgen to generate an English translation (each msgstr == msgid) | 17:46 |
| jinty | and change to 2.5 automatically when that comes around. | 17:46 |
| SteveA | jinty: i think we should promote using 2.4 on hoary for everything except zope 2 | 17:46 |
| mgedmin_ | then use msgfilter to change the translations | 17:46 |
| mgedmin_ | then you will see which strings were translated | 17:46 |
| bska|mobile | thanks | 17:47 |
| SteveA | i have no idea what python 2.5 will bring | 17:47 |
| mgedmin_ | jinty, could you change 'make schooltooltar' so that it builds schooltool.pot and include schooltool.pot in the tarball? | 17:48 |
| jinty | I don't want to specify numbers if we support 2.4 because then the packages for ubuntu and debian have to be different | 17:48 |
| SteveA | there is no 2.5 yet, so that's not a problem. there will not be a 2.5 in hoary | 17:49 |
| tvon | can't we dep on >= 2.3 ? | 17:49 |
| jinty | mgedmin: yes. | 17:49 |
| jinty | ok, so, for now follow the default - and re-asses the situation when 2.5 comes. | 17:50 |
| <--alga išėjo (Read error: 110 (Connection timed out)) | 17:50 | |
| SteveA | the schooltool project will need to write python at the 2.3 level | 17:51 |
| <--mgedmin išėjo (Read error: 110 (Connection timed out)) | 17:51 | |
| jinty | please, for backportablitity to sarge | 17:51 |
| jinty | Anyway, my time is up -- so caio | 17:52 |
| <--jinty išėjo ("Leaving") | 17:53 | |
| SteveA | well, it needs to be an explicit statement of the schooltool project | 17:53 |
| SteveA | that it will be written to python 2.3, and compatible with python 2.3 and python 2.4 | 17:53 |
| th1a | OK. | 17:54 |
| th1a | I'll add it to the docs. | 17:55 |
| *mgedmin_ has a theory about conflict errors | 17:58 | |
| SteveA | marius has a good idea what the conflict error is | 17:58 |
| SteveA | fortunately, it is fixed by moving to use more of zope 3 | 17:58 |
| SteveA | the current "session" machinery in schooltool, which deals with cookie auth, writes to the database a bit on each access | 17:59 |
| SteveA | this writing creates contention | 17:59 |
| SteveA | the zope3 session machinery writes only infrequently | 18:00 |
| SteveA | so avoiding this problem | 18:00 |
| tvon | okay | 18:00 |
| mgedmin_ | from now on this will be known ashttp://issues.schooltool.org/issue152 | 18:01 |
| **** ŽURNALAS BAIGTAS Thu Jan 6 18:03:22 2005 | ||
| **** ŽURNALAS PRADĖTAS Thu Jan 6 18:03:22 2005 | ||
| mgedmin_ | one other thing that needs to be done before a release | 18:04 |
| mgedmin_ | make update-translations | 18:04 |
| mgedmin_ | then check schoolbell.po for missing translations | 18:04 |
| mgedmin_ | although this is probably not necessary in the schoolbell-ui branch | 18:04 |
| mgedmin_ | if the code and page templates no longer refer to "teachers" and "pupils" | 18:04 |
| SteveA | th1a: let's talk about meetings | 18:07 |
| th1a | Yes? | 18:08 |
| SteveA | so, I'd like to see the two teams talking about what they did during the past week, | 18:08 |
| SteveA | what issues stood in the way of effectively working on the parts of schooltool they've been working on | 18:08 |
| SteveA | the plans for the coming week of work | 18:08 |
| th1a | That certainly sounds reasonable. | 18:09 |
| SteveA | work out what things depend on other things, especially across teams | 18:09 |
| SteveA | talk about interesting items of code or UI that were checked in | 18:10 |
| SteveA | maybe choose one item from each team and look at it in the meeting | 18:10 |
| SteveA | constructive criticism | 18:10 |
| SteveA | discussion of using the code | 18:10 |
| SteveA | of course, it doesn't have to be all of this at once | 18:10 |
| bska|mobile | that makes sense | 18:11 |
| ---bska|mobile dabar žinoma(s) kaip bskahan | 18:11 | |
| th1a | Right. I suppose I've been expecting the conversation to generate itself more spontaneously and feeling frustrated about it not happening. | 18:11 |
| SteveA | put together a standard agenda | 18:12 |
| th1a | Some structure. | 18:12 |
| *mgedmin_ thought this specific meeting was an exception | 18:13 | |
| tvon | yeah | 18:13 |
| mgedmin_ | no standard agenda, just focusing on the release | 18:13 |
| mgedmin_ | making sure that all things that need to be done will be done | 18:14 |
| SteveA | that's fine | 18:14 |
| th1a | The thing you guys need to remember is that I've _never_ done this before. | 18:14 |
| th1a | So I don't even know exactly what happens in a bug squashing meeting over IRC. | 18:15 |
| *mgedmin_ neither | 18:15 | |
| SteveA | look through the bugs. choose the top 5. | 18:16 |
| SteveA | work on them, different people / groups taking on each one. talking about progress / problems. | 18:16 |
| tvon | The biggest that I know of is the rendering issue in KHTMl and the quirks in mozilla | 18:16 |
| SteveA | maybe get other to review proposed fixes | 18:16 |
| th1a | OK. I'll keep testing with iCal. Something is out of whack. | 18:17 |
| SteveA | th1a: tcpwatch can be helpful to see what is going on | 18:18 |
| th1a | I've generally used ethereal. | 18:18 |
| mgedmin_ | there's also a mozilla extension (livehttpheaders) | 18:19 |
| th1a | I'll take a quick look at that. | 18:20 |
| th1a | When you edit an event in the popup, it doesn't refresh the main window. Is there a way to do that? | 18:20 |
| tvon | hrm...anyway to sort by priority in our Roundup that I'm missing? | 18:21 |
| th1a | I'm regretting saying we should use a popup for that. It seems like it introduces way more complication than I'd realized. | 18:21 |
| tvon | ah, nm | 18:21 |
| mgedmin_ | we're about to go back to the office | 18:22 |
| mgedmin_ | we'll be offline for about 20 minutes | 18:22 |
| -->gintas (~gintas@adsl-212-59-30-232.takas.lt) atėjo į #schooltool | 18:22 | |
| *mgedmin_ dislikes popups greatly and has disabled them in his firefox | 18:22 | |
| bskahan | th1a: yes | 18:23 |
| bskahan | the add event popup closes/refreshes | 18:23 |
| tvon | I don't care for popups too much myself, though they can give more of an application feel at times | 18:23 |
| bskahan | the edit event popup doesn't | 18:23 |
| bskahan | I noticed it yesterday | 18:23 |
| <--alga_ išėjo ("see you when we get back") | 18:23 | |
| ---Atsijungta (). | 18:23 | |
| **** ŽURNALAS BAIGTAS Thu Jan 6 18:23:57 2005 | ||
| **** ŽURNALAS PRADĖTAS Thu Jan 6 18:45:16 2005 | ||
| -->Jūs dabar kalbate #schooltool | 18:45 | |
| ---#schooltool tema yra http://schooltool.org | 18:45 | |
| ---#schooltool temą nustatė mgedmin Wed Jan 5 20:29:01 2005 | 18:45 | |
| th1a | So let's pick a reasonable number (like 20) and go on. | 18:47 |
| *bskahan nods | 18:47 | |
| *mgedmin was just looking at checkins on schooltool-ui branch | 18:48 | |
| th1a | In the month view I'd just like each day to be a fixed size. | 18:48 |
| mgedmin | bskahan, is the 'portlet_calendars' attribute used anywhere? I think it should be just removed | 18:48 |
| bskahan | I'm working on the form to modify it now | 18:51 |
| mgedmin | I thought we had agreed to replace it with a relationship | 18:51 |
| bskahan | its a list of additional calendars (other than groups your a member of) to add to the portlet | 18:52 |
| bskahan | the displayed calendars use the subscription relationship now | 18:52 |
| mgedmin | yes | 18:52 |
| tvon | th1a: I'm working on that one. The monthly view is still a table which is causing problems when trying to fix the size | 18:53 |
| th1a | OK. | 18:53 |
| bskahan | portlet_calendars lets you add calendars of resources/people/groups-you-arent-a-member of to your portket so that you can subscribe/unsusbscribe to them | 18:53 |
| mgedmin | yes | 18:53 |
| mgedmin | there are two pretty similair things: | 18:54 |
| mgedmin | - a list of objects whose calendars you want merged with your calendar | 18:54 |
| mgedmin | - a list of objects that you want shown in the portlet so that you can easily merge them with your calendar | 18:54 |
| bskahan | right | 18:54 |
| mgedmin | I think it would be better if they were implemented in the same way | 18:54 |
| bskahan | ok | 18:55 |
| mgedmin | it is possible that defining a new relationship is too hard now | 18:55 |
| mgedmin | if it is so, then it should be fixed | 18:55 |
| mgedmin | defining new relationships should be trivial | 18:55 |
| bskahan | its alot of boilerplate | 18:56 |
| mgedmin | I've noticed | 18:56 |
| bskahan | its not difficult though | 18:56 |
| <--SteveA išėjo ("Leaving") | 18:56 | |
| mgedmin | I agree that it there should be less | 18:56 |
| mgedmin | I think that just defining three URIs and using the 'relate' function will work | 18:57 |
| mgedmin | relationship schemas add some syntactic sugar and some type checking | 18:57 |
| -->SteveA (~steve@adsl-213-190-44-43.takas.lt) atėjo į #schooltool | 18:58 | |
| tvon | th1a: can we push the fixed width till after the release (when we can use tableless layouts for the montly views)? | 18:58 |
| th1a | How does PHP iCalendar do it? | 19:00 |
| th1a | I'm not sure what the hard part here is. | 19:00 |
| tvon | its not doing what I tell it to, in short | 19:01 |
| th1a | In what sense? | 19:01 |
| th1a | What's happening? | 19:01 |
| tvon | one sec | 19:03 |
| th1a | mgedmin: We need to do a little more ugly trickery to get iCal to be able to post calendars. | 19:04 |
| Aiste | th1a: did you read my note on the iCal bug you filed? | 19:04 |
| th1a | Let me check. | 19:04 |
| Aiste | it is possible to do that without any tricketry | 19:05 |
| Aiste | s/tricketry/trickery | 19:05 |
| mgedmin | th1a, let me get this straight: in iCal you can only do calendar synchronization in one direction | 19:05 |
| th1a | Yes. | 19:05 |
| -->alga (~alga@office.pov.lt) atėjo į #SchoolTool | 19:05 | |
| mgedmin | that is, either you subscribe to a web calendar and have it read-only | 19:05 |
| mgedmin | or you have a local calendar and publish it on the web | 19:05 |
| mgedmin | when you publish a calendar you have to manually enter the calendar name and URL, right? | 19:06 |
| Aiste | that is correct as far as I understand it | 19:07 |
| mgedmin | we should document that the calendar name must be 'calendar' and the URL must end with the user's username (http://servername:7080/persons/username) | 19:07 |
| th1a | That only works if you're managing one calendar. | 19:07 |
| mgedmin | what do you mean? | 19:08 |
| th1a | Since the calendar's name has to be 'calendar' | 19:08 |
| mgedmin | schoolbell currently supports only one calendar per person | 19:08 |
| th1a | If you're managing, say, the school calendar and you're personal calendar. | 19:09 |
| mgedmin | we might consider allowing several calendars per person, but I suggest doing that after schoolbell is a zope3 component | 19:09 |
| th1a | Yeah, not now. | 19:09 |
| mgedmin | if you're managing the school calendar and your personal calendar | 19:09 |
| mgedmin | I assume that you will have two separate local calendar | 19:09 |
| mgedmin | you will publish one to http://servername:7080/groups/root and another to http://servername:7080/persons/me | 19:10 |
| th1a | The problem is that literally the first two good test sites I have both have one person managing multiple calendars in iCal, so this isn't an edge case. | 19:10 |
| mgedmin | both will be published as "calendar" | 19:10 |
| mgedmin | however the publication name can be different from the local calendar name | 19:10 |
| th1a | Ah. Let me check that on mine. | 19:10 |
| tvon | th1a: I think I can get the width. | 19:10 |
| <--thisfred išėjo ("Farewell, cruel channel...") | 19:11 | |
| th1a | Ah. Brilliant. | 19:14 |
| th1a | OK. Yeah, you can make the publish name different than the "display" name. | 19:14 |
| th1a | So we're good. | 19:14 |
| th1a | I'll take care of adding that to the docs. | 19:14 |
| th1a | iCal does do link hooking properly. | 19:16 |
| th1a | Doesn't seem to work at all over https at all, but that's not our problem. | 19:23 |
| mgedmin | pity | 19:23 |
| th1a | Apparently... 'The "normal" workaround for this bug is first subscribe to http:// calendar (insecure), then manualy edit ~/Library -> Preferences -> com.apple.iCal.sources.plist and replace http:// with https://.' | 19:24 |
| th1a | Or so I'm told. | 19:24 |
| Aiste | oh :( that is not very nice | 19:25 |
| Aiste | and I was wondering the other day, why it wouldn't connect over https... | 19:25 |
| th1a | Apple is on the naughty list. | 19:25 |
| Aiste | :) | 19:25 |
| mgedmin | calendar.pov.lt is only available over https | 19:25 |
| th1a | That's how I discovered that issue. | 19:25 |
| tvon | the Firefox calendar extension seems to work...on the brighter side of life | 19:29 |
| tvon | oh, wait...I lied | 19:30 |
| th1a | Calendar extension? | 19:30 |
| bskahan | mozilla calendar for firefox | 19:31 |
| th1a | Not Sunbird? | 19:31 |
| bskahan | sunbird segfaults on me | 19:31 |
| bskahan | the last 3 releases | 19:31 |
| tvon | wait, no, it does work | 19:33 |
| th1a | One would hope. | 19:34 |
| *bskahan wishes evolution did iCal | 19:35 | |
| alga | it almost does | 19:35 |
| tvon | heh | 19:35 |
| bskahan | ;) | 19:35 |
| mgedmin | evolution can subscribe to a web calendar, but it can't publish | 19:36 |
| bskahan | yeah | 19:36 |
| mgedmin | as a nice side effect, if you subscribe to a web calendar with evolution, those calendar events will be visible in the calendar popup in your GNOME desktop | 19:36 |
| mgedmin | however evolution is a stinking piece^W^Wnot really ready for prime time yet | 19:37 |
| th1a | Let's see... other issues. | 19:43 |
| th1a | Are the merge calendar checkboxes going to be removed from the person info page? | 19:43 |
| bskahan | yes | 19:44 |
| th1a | OK. | 19:44 |
| tvon | I have a q relating to overlays | 19:45 |
| bskahan | assuming I get the relationships working for URICalendarListing there are 3 boxes to add at the bottom of the page for updating the portlet listing | 19:45 |
| tvon | We need to store colors for each overlay for use in the UI. Any suggestions on where to actually store this information? | 19:45 |
| bskahan | 3 boxes - groups, resources, people | 19:45 |
| tvon | I figure the colors need to be consistant on a per user basis..meaning that Foo group is always Mauve when Joe views his calendar....beyond that I'm not sure if any consistancy is required (Foo needn't always be Mauve for everyone, as that gets complicated). | 19:46 |
| th1a | Right. Consistent per user. | 19:47 |
| tvon | my kneejerk reaction is to store a dict on the user with {calendar.__parent__.__name__:color}...but that doesnt sound like a "right way" | 19:48 |
| mgedmin | tvon, a very good question | 19:48 |
| mgedmin | easy workaround: a_list_of_standard_colors[hash(getPath(calendar)) % len(a_list_of_standard_colors)] or something | 19:49 |
| mgedmin | the "right way" would be attaching annotations to relationships, however we cannot do that now | 19:50 |
| alga | or introduce several rels: | 19:52 |
| alga | URIOrangeCalendarOverlay | 19:52 |
| mgedmin | no!!! | 19:52 |
| alga | :) | 19:52 |
| bskahan | heh | 19:52 |
| mgedmin | URIRGBCalendar84caff | 19:52 |
| *mgedmin shudders | 19:52 | |
| mgedmin | you can have a PersistentKeysDict with calendars as keys | 19:53 |
| mgedmin | (from schooltool.db import PersistentKeysDict) | 19:53 |
| alga | hm, register a utility that chooses a colour for a calendar? | 19:53 |
| *mgedmin thinks | 19:53 | |
| mgedmin | perhaps relationships were not such a good idea after all... | 19:54 |
| *bskahan stops typing | 19:54 | |
| mgedmin | ok, the advantage of relationships: | 19:55 |
| alga | in principle, facets are annotations on steroids | 19:55 |
| mgedmin | - no need to change interfaces | 19:55 |
| SteveA | well | 19:55 |
| mgedmin | - when a group or a person is removed, the relevant relationships disappear automatically | 19:55 |
| mgedmin | disadvantage of relationships: | 19:55 |
| mgedmin | - no way to attach extra information to a relationship... | 19:55 |
| mgedmin | actually that's not true | 19:55 |
| alga | IAttributeAnnotatable! | 19:56 |
| mgedmin | we have an (insanely complicated) way to attach extra information to a relationship | 19:56 |
| mgedmin | it involves facets | 19:56 |
| tvon | relate it to a note | 19:56 |
| alga | come on, we can use Zope annotations! | 19:56 |
| mgedmin | not in schoolbell-ui | 19:56 |
| alga | not yet, you mean | 19:56 |
| mgedmin | we can use zope annotations in the trunk | 19:57 |
| mgedmin | but the relevant zope packages are not present in the schoolbell-ui branch | 19:57 |
| tvon | heh, unless we merge before the release :) | 19:58 |
| tvon | for the future, it would be good to have a way to generate a years worth of an 'intersting calendar' for importing | 20:07 |
| tvon | for testing | 20:07 |
| <--bskahan išėjo ("Leaving") | 20:08 | |
| -->bska|mobile (~bskahan@dsl093-119-225.blt1.dsl.speakeasy.net) atėjo į #schooltool | 20:08 | |
| ---bska|mobile dabar žinoma(s) kaip bskahan | 20:09 | |
| tvon | Hello? | 20:15 |
| <--tvon (tvon@dsl093-119-225.blt1.dsl.speakeasy.net) paliko #schooltool ("Leaving") | 20:16 | |
| -->tvon (tvon@dsl093-119-225.blt1.dsl.speakeasy.net) atėjo į #schooltool | 20:16 | |
| th1a | Where do we end up in the discussion of storing colors? | 20:16 |
| th1a | That was a good discussion for a while. | 20:17 |
| th1a | Meanwhile, here's a little question: if I was to add a link to a calendar's acl page to the left toolbar, where would I do that? | 20:19 |
| th1a | Left column. | 20:19 |
| tvon | you could fill the "column-left-extra" slot in the template | 20:19 |
| th1a | Which template? | 20:20 |
| tvon | acl.pt I believe | 20:20 |
| tvon | stick it between the h1 slot and the content slot | 20:20 |
| tvon | <metal:slot fill-slot="column-left-extra">something</metal:slot> | 20:20 |
| tvon | eg | 20:20 |
| th1a | Which template do I edit? | 20:20 |
| tvon | www/acl.pt | 20:21 |
| tvon | oh oh | 20:21 |
| tvon | a link "to" the acl page, not "on" the acl page, sorry | 20:21 |
| th1a | Yeah. | 20:21 |
| bskahan | macros.pt | 20:22 |
| tvon | hrm...from all the calendar views? probably in macros.pt...in the calendarpage macro | 20:22 |
| bskahan | the last macro in macros.pt | 20:23 |
| bskahan | nm | 20:23 |
| th1a | common-calendar-portlets? | 20:23 |
| th1a | Then make a little macro for it? | 20:24 |
| bskahan | yeah | 20:24 |
| bskahan | that will put it on all calendar views | 20:24 |
| th1a | And I don't need to do a test for that kind of thing, right? | 20:25 |
| bskahan | there are places where the rendered output is tested, so its possible to break existing tests that way | 20:25 |
| th1a | OK. | 20:26 |
| bskahan | normally it won't | 20:26 |
| th1a | I'm going to take a shower. | 20:27 |
| th1a | Hopefully alga and mgedmin aren't lying unconscious in a cellar somewhere in Vilnius. | 20:27 |
| *bskahan agrees | 20:28 | |
| mgedmin | do we need user-selectable colours for calendars in this release? | 20:30 |
| bskahan | no | 20:31 |
| bskahan | I don't think we need user selectable colors | 20:32 |
| bskahan | . | 20:32 |
| bskahan | tvon disagrees with me | 20:32 |
| bskahan | at least not for schooltool | 20:32 |
| bskahan | for schoolbell its a different story | 20:32 |
| mgedmin | I think we need user selectable colors for schoolbell 1.0 | 20:32 |
| bskahan | but either way, not for this release | 20:32 |
| SteveA | th1a: did you agree with jeff waugh what status schoolbell will have in hoary? | 20:32 |
| mgedmin | I as asking about 0.9 | 20:32 |
| tvon | they werent in the plan | 20:33 |
| tvon | for 9 | 20:33 |
| tvon | plan was to provide 20 or so pre-selected colors | 20:33 |
| tvon | (though I think thats a lot) | 20:33 |
| <--tvon (tvon@dsl093-119-225.blt1.dsl.speakeasy.net) paliko #schooltool ("Leaving") | 20:37 | |
| -->tvon (tvon@dsl093-119-225.blt1.dsl.speakeasy.net) atėjo į #schooltool | 20:37 | |
| th1a | SteveA: I didn't hear back from Jeff. Did you? What's his email? | 20:40 |
| th1a | Yeah, 20 is a lot of colors, having thought about it a bit. | 20:41 |
| bskahan | how many calendars do you expect people to display at one time? | 20:43 |
| bskahan | in a school setting my thought model is: | 20:43 |
| tvon | I really think 4-6 colors would be enough...10 at an absolute maximum | 20:44 |
| tvon | its mostly a matter of finding colors that are easily distinguishable and don't need a changed font color | 20:44 |
| bskahan | a teacher with 1 personal, 5 classes, 1 dept., 1 ext carricular, and 1 school | 20:44 |
| SteveA | jeff.waugh at canonical.com should reach him | 20:44 |
| tvon | and ideally that still fit the theme | 20:44 |
| th1a | A student could have six or seven classes, with one calendar for each class. | 20:44 |
| th1a | Sports schedules... | 20:44 |
| tvon | th1a: true, but thats not needed for schoolbell is it? | 20:44 |
| th1a | Right. | 20:45 |
| bskahan | I lean towards 10 | 20:45 |
| th1a | Anyway, we just need a palette of colors. 10-ish is enough for now. | 20:45 |
| th1a | My discussion of colors with my sister got theoretical pretty quickly. | 20:46 |
| alga | why? | 20:46 |
| tvon | heh | 20:46 |
| tvon | in the long run we can try mixing patterns in too | 20:46 |
| th1a | Various ways to generate a large variety of distinct yet harmonious colors. | 20:46 |
| th1a | She was also thrown off by the transparency issues. | 20:47 |
| th1a | She's kind of a perfectionist. | 20:47 |
| th1a | So anyway, just pick 10 colors for now. | 20:48 |
| th1a | We can tweak that later. | 20:48 |
| tvon | the idea needs some testing though | 20:48 |
| *tvon snuggles the unloved little overlapping translucent events | 20:48 | |
| tvon | okay, 10 colors is no problem | 20:49 |
| th1a | The translucency is nice. | 20:53 |
| th1a | SteveA: I sent an email to Jeff. | 20:53 |
| bskahan | th1a: I've pondered the automatic color generation problem a bit (being colorblind and all) it gets ugly pretty quickly | 20:54 |
| th1a | You can pick a harmonious set of colors and then vary them in different ways to create more variations. | 20:55 |
| *bskahan nods | 20:55 | |
| bskahan | adobe has published some whitepapers on it | 20:55 |
| th1a | Ah. Makes sense. | 20:56 |
| mgedmin | that's interesting, any urls? | 20:57 |
| bskahan | I'll look for them | 20:58 |
| th1a | mgedmin: http://vanrees.org/weblog/1105032675 | 21:15 |
| mgedmin | wow, I'm famous | 21:17 |
| mgedmin | 1. create a weblog | 21:18 |
| mgedmin | 2. ??? | 21:18 |
| mgedmin | 3. profit! | 21:18 |
| th1a | So did we reach a conclusion about how to store the colors? | 21:20 |
| mgedmin | I think the conclusion was to assign them on the fly | 21:20 |
| th1a | That'll do for now, I guess. | 21:20 |
| tvon | I'm not sure that will work...that gives each calendar an assigned color basically, right? | 21:21 |
| mgedmin | if you use hashing on the groups name or path, the colours will be stable | 21:21 |
| *mgedmin thinks a bit more | 21:21 | |
| mgedmin | a | 21:22 |
| mgedmin | (keyboard accident | 21:22 |
| mgedmin | ) | 21:22 |
| mgedmin | hashing may result in collisions, though | 21:22 |
| tvon | if each calendar has an assigned color and there are only 10 colors then there is a very good chance that some user will have overlaid calendars of the same color | 21:22 |
| bskahan | that could lead to one person having all calendars the same color (depending on their selection) and another person having all unique colers | 21:22 |
| mgedmin | if you have N calendars overlaid and select an extra one | 21:23 |
| mgedmin | I suppose you want those N calendars to keep the same colour | 21:23 |
| tvon | yeah | 21:23 |
| tvon | though we could overlook that for this release... | 21:23 |
| tvon | I'm open to suggestions | 21:24 |
| bskahan | my initial thought was to assign a color to each color added to your portlet in succession | 21:25 |
| bskahan | but that doesn't handle removing one in the middle later on | 21:25 |
| mgedmin | it would be best to store colours | 21:27 |
| bskahan | color facet on the calendar, updated by URICalendarListing relate events? | 21:28 |
| mgedmin | different users may have different colours for the same calendar | 21:29 |
| bskahan | true | 21:29 |
| bskahan | I meant on the users calendar | 21:30 |
| mgedmin | option 1 (ugly dirty hack): set an attribute on the relationship link | 21:30 |
| mgedmin | option 2 (large architectural investment): devise a framework for attaching arbitrary annotations on relationships | 21:30 |
| mgedmin | or perhaps a specific schema of attributes for a given relationship type | 21:30 |
| bskahan | what would you set the attribute on? | 21:31 |
| mgedmin | option 3: forget about relationships, use a named facet on a person for storing a list of tuples (calendar, overlay, colour) | 21:31 |
| mgedmin | option 4: add an attribute to ICalendarOwner with this attribute instead of using a facet | 21:31 |
| bskahan | I like option 3 at this point | 21:32 |
| mgedmin | btw ICalendarOwner has a method makeCompositeCalendar | 21:34 |
| mgedmin | having an attribute that explains how the composite calendar is made is somewhat fitting | 21:34 |
| mgedmin | I think 3 or 4 makes more sense | 21:36 |
| mgedmin | 4 might be easier to implement | 21:36 |
| *bskahan agrees | 21:36 | |
| mgedmin | uhh | 21:36 |
| mgedmin | there are some downsides | 21:36 |
| mgedmin | if you delete a group, now you must go through *all* objects in the system and remove that group from their subscribed_to_calendars_or_something attribute | 21:37 |
| bskahan | true, with relationships you don't have to | 21:38 |
| mgedmin | otherwise the group object will be kept in the ZODB and never garbage collected | 21:38 |
| mgedmin | also, attributes that are lists of items are somewhat tricky to use correctly with ZODB | 21:38 |
| bskahan | how so | 21:38 |
| mgedmin | it either must be a PersistentList or you must never modify its items directly | 21:39 |
| mgedmin | (or if you do modify its items directly, you have to change some attribute on the object to make sure ZODB notices the change) | 21:39 |
| bskahan | I didn't know that (/me wonders about bugs out in the wild) thanks | 21:43 |
| mgedmin | bskahan, http://zope.org/Wikis/ZODB/FrontPage/guide/node3.html#SECTION000360000000000000000 | 21:46 |
| th1a | So is the problem with http://issues.schooltool.org/issue136 that line 148 in macros.pt shouldn't be using tal:condition="view/isManager"? | 21:47 |
| tvon | th1a: yeah, that seems to be it | 21:49 |
| th1a | Ta da! | 21:50 |
| tvon | should check to see if authenticated user has permissions to modify the acl | 21:50 |
| bskahan | mgedmin: thanks | 21:50 |
| bskahan | th1a: the link for manager is in calendarpages content, iirc | 21:52 |
| bskahan | to edit calendar acl | 21:53 |
| th1a | Actually, is that a bug in the first place. | 21:54 |
| th1a | It might be a bug for SchoolBell but a feature for SchoolTool. | 21:54 |
| th1a | Because student's shouldn't be able to make their calendar public. | 21:55 |
| th1a | But in most organizations it would be ok to decide... | 21:55 |
| th1a | Although employees (for example) shouldn't be able to arbitrarily decide to make their calendar private, if their employer purposely set up a public calendar for him. | 21:57 |
| th1a | I think this isn't a bug. | 21:58 |
| tvon | need ModifyCalendarACLPermission of sorts | 21:58 |
| tvon | because in a "normal" calendaring environment a person should be able to share/hide their calendar | 21:59 |
| th1a | It is fine for now. | 21:59 |
| bskahan | I think its a bug, whether or not that link appears is a (possibly complex) ACL issue | 21:59 |
| th1a | What does "Nosy List" mean, by the way? | 22:00 |
| bskahan | I expected it to mean I would get mails when changes happen to the bug | 22:00 |
| tvon | ala zilla's CC list I think | 22:01 |
| bskahan | that would be the bugzilla CC: equivalent | 22:01 |
| bskahan | but it doesn't seem to | 22:01 |
| bskahan | mgedmin: on balance I think option 4 wins | 22:03 |
| bskahan | using relationships is probably the easiest, but I don't know how we'd do the colors in that case | 22:04 |
| mgedmin | Nosy List in roundup contains comma separated usernames, not emails | 22:05 |
| mgedmin | I think we need to rethink our relationship APIs a little bit | 22:06 |
| tvon | mgedmin: I assumed the usernames were supposed to represent account holders, which have emails | 22:06 |
| mgedmin | yes | 22:07 |
| mgedmin | I meant that the nosy list field contains usernames, not email addresses | 22:07 |
| bskahan | after saying that, I got an email on a bug I was nosy on | 22:08 |
| bskahan | mgedmin: can you add us to the default nosy list | 22:08 |
| *mgedmin tries to remember where that one is defined... probably in the python source file somewhere | 22:10 | |
| bskahan | not a huge deal, but if you think of it some time | 22:10 |
| th1a | alga: I see you found SchoolBell on Rosetta. I'm afraid I couldn't make heads or tails of what I was supposed to do with it. | 22:17 |
| th1a | Makes a little more sense now. | 22:19 |
| th1a | So should we direct people who are interested in doing translations to Rosetta? | 22:19 |
| th1a | It's here, btw: https://launchpad.ubuntu.com/rosetta/products/schoolbell/schoolbell-ui/ | 22:20 |
| SteveA | the rosetta team will be very receptive to feedback from translators | 22:27 |
| th1a | Do they have an email address. | 22:29 |
| SteveA | there's a mailing list for rosetta users | 22:30 |
| SteveA | but also, mail carlos at canonical.com or daf at canonical.com | 22:30 |
| th1a | OK. | 22:30 |
| th1a | So, Rosetta isn't exclusive of other translation tools, right. If someone wants to use KBabel, or something like that, we'll be able to import their work into it? | 22:31 |
| tvon | mgedmin: for this release I'm leaning towards option #1 for colors (hack an attribute onto the relationship). After we merge with trunk we can make the relationships annotatable and do it that way. | 22:35 |
| tvon | #2 requires significant effort/time and restructuring. #3 and #4 both have issues when something is deleted | 22:36 |
| tvon | thats my thinking anyways | 22:37 |
| th1a | I'm going to shovel the walk. | 22:56 |
| bskahan | its 50 F here | 23:01 |
| bskahan | supposed to be 60s next week | 23:01 |
| SteveA | th1a: i don't know kbabel, but i'd expect so, so long as everything uses po files | 23:02 |
| th1a | OK. I'll announce it to the list. | 23:02 |
| *mgedmin was trying to think of a more or less clean way to implement option #1, but couldn't | 23:03 | |
| mgedmin | it's getting late | 23:03 |
| mgedmin | see you tomorrow | 23:03 |
| ---Atsijungta (). | 23:03 | |
| **** ŽURNALAS BAIGTAS Thu Jan 6 23:03:33 2005 | ||
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!