**** BEGIN LOGGING AT Mon Dec 27 15:53:07 2004 | ||
-->You are now talking on #schooltool | 15:53 | |
---Topic for #schooltool is http://schooltool.org | 15:53 | |
---Topic for #schooltool set by Aiste at Mon Oct 18 12:47:26 2004 | 15:53 | |
-->Aiste (~aiste@office.pov.lt) has joined #schooltool | 17:40 | |
mgedmin | bska|mobile: ayt? | 17:41 |
---|---|---|
bska|mobile | yes | 17:48 |
mgedmin | could I ask you a question or two about overlaying calendars in schoolbell? | 17:49 |
bska|mobile | I'm not the best person to ask, Tom did them right before leaving for the holiday | 17:50 |
bska|mobile | I'm looking at them today | 17:50 |
mgedmin | as far as I can understand from looking at the user interface | 17:51 |
mgedmin | there is a portlet on the lest | 17:51 |
mgedmin | left | 17:51 |
mgedmin | that shows a list of calendars | 17:51 |
mgedmin | and a button that says 'overlay' | 17:51 |
mgedmin | the list is empty in my case, and the button appears to do nothing | 17:51 |
mgedmin | (I think the button, and perhaps the whole portlet, should be hidden when there are no calendars that can be overlaid) | 17:51 |
*bska|mobile nods | 17:52 | |
mgedmin | what calendars should be shown there? | 17:52 |
mgedmin | calendars of groups that the logged in user is a member of? | 17:52 |
bska|mobile | yes | 17:52 |
bska|mobile | the calendars are toggled in the personal info page | 17:52 |
mgedmin | ok, if I select the 'system managers' group in the manager's info page, I can see that group in the overlay box | 17:53 |
mgedmin | why two levels of selection? | 17:53 |
bska|mobile | the goal is to store a list of calendars you may want to see | 17:53 |
bska|mobile | with the ability to toggle any of that list on/off easily | 17:54 |
bska|mobile | a new user starts with just their calendar a manager defined system defaults | 17:54 |
bska|mobile | the user can add "Joe's Calendar" and "The science dept. calendar" to their portlet | 17:55 |
mgedmin | I see | 17:55 |
bska|mobile | and toggle them on off as needed | 17:55 |
mgedmin | it could be expressed a bit better, I think | 17:55 |
mgedmin | in the person's info page it could say | 17:55 |
mgedmin | "Select calendars to be shown in the overlay box" | 17:55 |
mgedmin | or something like that | 17:55 |
mgedmin | also, perhaps selected calendars should be overlaid by default, no | 17:55 |
mgedmin | ? | 17:55 |
mgedmin | anyway, now that I understand the reason for two levels of selection | 17:56 |
bska|mobile | new selected calendars should I think | 17:56 |
mgedmin | I'd like to talk about implementation | 17:56 |
mgedmin | in SchoolTool trunk we have a relationship that defines which calendars are overlaid on top of a user's calendar | 17:56 |
bska|mobile | ok | 17:58 |
mgedmin | you changed the meaning of that relationship to "calendars that can be selected for overlaying", added a list attribute on a person (there's a bug there, by the way -- see my comments on the list), and added a bunch of tal:conditions to page templates to perform additional filtering | 17:58 |
bska|mobile | calendar subscriptions | 17:58 |
mgedmin | I think a simpler implementation would be to keep using that relationship for overlaying | 17:59 |
mgedmin | (perhaps it should be renamed, as we now refer to the same process as "merging", "composing", "overlaying" and "subscribing") | 17:59 |
mgedmin | and add a new relationship "calendars shown in the overlay box" | 18:00 |
mgedmin | then you need no extra attributes on persons | 18:00 |
mgedmin | and you need no extra tal:conditions in page templates, because all events will already be filtered in view code | 18:00 |
bska|mobile | ok, I'll work on that approach today | 18:00 |
bska|mobile | where do you think the public system calendar should be? | 18:00 |
mgedmin | also, it would make merging the branch and trunk easier, as the meaning of URICalendarSubscription would not be changed | 18:00 |
*mgedmin thinks | 18:01 | |
mgedmin | calendar for the root group, pehaps? | 18:01 |
bska|mobile | that makes sense | 18:01 |
bska|mobile | thanks | 18:01 |
mgedmin | we could rename "Root Group" to "Everyone" | 18:01 |
*bska|mobile nods | 18:01 | |
mgedmin | and have a calendar for Everyone | 18:01 |
mgedmin | newly added persons could automatically become a members of the Everyone group | 18:02 |
*mgedmin thinks he saw something about all new persons becoming members of the root group in the RELEASE file on schooltool-0.9.x branch | 18:02 | |
bska|mobile | tom h. wanted to remove some of the nesting in groups | 18:02 |
mgedmin | minor suggestion: could you show the day of the week in daily calendar view? | 18:03 |
*bska|mobile nods | 18:03 | |
bska|mobile | yeah, that should be displayed | 18:03 |
mgedmin | ok, thanks for answering my questions about calendar overlaying | 18:04 |
mgedmin | the new calendar views look nice, although firefox for some reason sometimes does not show some of the icons | 18:04 |
bska|mobile | no problem, thanks for the help | 18:04 |
mgedmin | probably a firefox bug | 18:04 |
bska|mobile | I'm not sure about that | 18:04 |
mgedmin | the icons get shown when I reload the page | 18:04 |
bska|mobile | I'm afraid its related to the safari/konqueror bug | 18:05 |
bska|mobile | some files getting loaded inconsistently | 18:05 |
bska|mobile | in safari/konq its the css file, in mozilla its the images | 18:05 |
*mgedmin can't reproduce the problem | 18:08 | |
bska|mobile | with konqueror? | 18:10 |
bska|mobile | or firefox? | 18:10 |
bska|mobile | IE running doesn't seem to have either problem | 18:11 |
bska|mobile | s/running /running in wine / | 18:11 |
mgedmin | firefox | 18:13 |
mgedmin | today, e.g, I saw about half of the "add event" icons in one view, while the other half was just white squares | 18:14 |
mgedmin | but I cannot reproduce this at will -- I tried clearing the browser cache and restarting firefox | 18:14 |
-->th1a (~hoffman@pool-70-105-178-27.alt.east.verizon.net) has joined #schooltool | 18:21 | |
gintas | mgedmin: should absoluteURL quote the suffix or not? | 18:59 |
mgedmin | gintas: huh? | 19:00 |
gintas | i.e., should absoluteURL(request, context, 'hi!') return '...!' or '...%21'? | 19:00 |
gintas | I'm implementing what you suggested in issue 96 | 19:00 |
gintas | and lots of tests broke because they did not expect the arguments to be quoted | 19:01 |
gintas | they do things like absoluteURL(r, c, '?foo=bar&baz=xyzzy') | 19:01 |
mgedmin | I did not realize that ! must be quoted in URLs | 19:02 |
gintas | should I use urllib.encode just on the result of getPath rather than the entire URL? | 19:02 |
gintas | I'm not sure it needs to be | 19:02 |
gintas | urllib.quote does quote it | 19:02 |
mgedmin | absoluteURL(request, context, u'something in unicode') should return URL-quoted UTF-8 representation of u'something in unicode' | 19:02 |
mgedmin | I think | 19:02 |
mgedmin | If we use absoluteURL in views, we could get by with simply encoding the URL in UTF-8 | 19:03 |
gintas | so I should change instances of absoluteURL(r, c, '?a=b') to absoluteURL(r, c) + '?a=b' then, or does the quoting do no harm here? | 19:03 |
mgedmin | however setHeader('Location', absoluteURL(...)) won't handle that | 19:03 |
mgedmin | perhaps we should just special-case 'Location' in our Request.setHeader and perform URL quoting there? | 19:04 |
*mgedmin does not know whether path?a=b is equivalent to path%3Fa%3Db or not | 19:04 | |
gintas | Do we have to quote ? and & in the Location field or not? | 19:05 |
mgedmin | no | 19:05 |
mgedmin | we have to quote non-ASCII characters | 19:05 |
gintas | well, urllib.quote is not as picky | 19:05 |
mgedmin | HTTP/1.1 says | 19:05 |
mgedmin | Location = "Location" ":" absoluteURI | 19:05 |
mgedmin | For definitive information on | 19:06 |
mgedmin | URL syntax and semantics, see "Uniform Resource Identifiers (URI): | 19:06 |
mgedmin | Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs | 19:06 |
mgedmin | 1738 [4] and RFC 1808 [11]). This specification adopts the | 19:06 |
mgedmin | definitions of "URI-reference", "absoluteURI", "relativeURI", "port", | 19:06 |
mgedmin | "host","abs_path", "rel_path", and "authority" from that | 19:06 |
mgedmin | specification. | 19:06 |
*mgedmin 's mozilla is going crazy | 19:07 | |
mgedmin | RFC 2396 is tricky | 19:10 |
mgedmin | I believe you should replace absoluteURL(..., '?a=b') with absoluteURL(...) + '?a=b' | 19:11 |
gintas | ok | 19:11 |
mgedmin | and then url-escape the suffix | 19:11 |
mgedmin | we want absoluteURL(..., someobject.__name__) to work, don't we | 19:11 |
mgedmin | ? | 19:11 |
gintas | fine, that's what I originally suggested | 19:11 |
mgedmin | even if __name__ contains '?' or something else that is outlandish | 19:12 |
gintas | btw, why do I get this: | 19:14 |
gintas | doctest_TraversableView (schooltool.rest.tests.test_rest) changed class view registry | 19:14 |
gintas | test_delete (schooltool.rest.tests.test_timetable.TestTimetableReadWriteView) changed class view registry | 19:15 |
gintas | but only when I run the whole suite | 19:15 |
mgedmin | strange | 19:15 |
gintas | (try make test) | 19:15 |
mgedmin | unbalanced use of RegistriesSetupMixin.cleanUp and tearDown? | 19:15 |
gintas | I think I checked and didn't find anything out of the ordinary | 19:16 |
mgedmin | by the way I am currently working on that | 19:16 |
gintas | on what? | 19:17 |
gintas | not on URLs I hope | 19:17 |
mgedmin | hunting tests that don't clean up after themselves | 19:17 |
gintas | ah | 19:17 |
gintas | cool | 19:17 |
mgedmin | are there any modules that do things on import? | 19:18 |
mgedmin | yes there are, and these are in Zope 3, grr | 19:21 |
gintas | if there are just a few, you could preemptively import them | 19:21 |
mgedmin | no, wait a second | 19:21 |
*mgedmin is deeply confused | 19:21 | |
gintas | zope.component adds a hook on zope.interface on import, I think | 19:22 |
mgedmin | waag | 19:26 |
*mgedmin slaps gintas a little bit | 19:26 | |
mgedmin | absolutePath calls setUpRegistries but doesn't call tearDownRegistries | 19:27 |
mgedmin | and I am staring at the doctest of absoluteURL which calls both | 19:27 |
*mgedmin stupid | 19:27 | |
mgedmin | however I am surprised why running just tests for schooltool.rest failed to discover the problem and I had to run the full test suite | 19:28 |
*mgedmin slaps himself | 19:32 | |
mgedmin | of course! the test runner applies the file name filter to checks.py as well | 19:32 |
mgedmin | that's why no safety checks are run if you limit the tests to a subpackage | 19:32 |
gintas | oops | 19:33 |
mgedmin | I should just give up and create a config file for the test runner | 19:34 |
gintas | did you commit a fix? | 19:34 |
gintas | maybe it's a good idea | 19:34 |
mgedmin | no, I haven't committed my fixes yet | 19:34 |
*mgedmin tries to commit but gets an out of date error | 19:39 | |
*mgedmin commits | 19:41 | |
*mgedmin wants an irc bot to sit in #schooltool and announce all commits, plus keep logs | 19:42 | |
th1a | That's a good idea. | 19:46 |
*mgedmin fights the urge to write one from scratch during his spare time | 19:51 | |
mgedmin | (fighting the urge isn't difficult as I have no spare time ;) | 19:51 |
th1a | I think there are plenty of existing alternatives. | 19:51 |
gintas | mgedmin: I'm inclined to mark all wxclient-related bug reports as resolved, so that they don't get in the way | 19:56 |
gintas | we are not going to revive wxclient anyway, right? | 19:56 |
gintas | mgedmin: can I do that? | 19:59 |
th1a | As far as I'm concerned you can. | 19:59 |
gintas | th1a: OK | 20:00 |
mgedmin | I think it is better to not do that while we have wxclient in the source repository | 20:00 |
mgedmin | change the importance to minor... uh, we don't have 'minor' there, do we? | 20:00 |
mgedmin | roundup's default set of priorities is... suboptimal | 20:01 |
th1a | We need to weed out the source tree before 1.0. | 20:01 |
<--gintas has quit ("Bye") | 20:49 | |
Aiste | bska|mobile: ayt? | 21:04 |
bska|mobile | yes | 21:04 |
Aiste | Marius showed me the schoolbell design | 21:07 |
Aiste | looks much prettier than the old stuff :) | 21:08 |
Aiste | the only problem that I see there is the overlaping events | 21:08 |
Aiste | I find it somewhat disturbing, that the actual event boxes overlap | 21:09 |
Aiste | does not look nice | 21:09 |
bska|mobile | its a bit of a pain when you have just 2 events a the same time, when we have 5 or 10 calendars displayed together though we could get multiple events at the same time | 21:10 |
bska|mobile | if we don't overlap them, they'd have to get smaller and smaller | 21:11 |
bska|mobile | how else could they display? | 21:11 |
Aiste | smaller :) | 21:12 |
bska|mobile | heh | 21:12 |
bska|mobile | maybe we should put it to a vote ;) | 21:12 |
bska|mobile | I don't like it when they get skinny | 21:12 |
bska|mobile | though, now that I think about it | 21:13 |
bska|mobile | maybe they could get smaller and just have javascript hover boxes | 21:13 |
mgedmin | I think that many overlapping events will be a rare case | 21:14 |
bska|mobile | I'm not sure about the accesibility of that | 21:14 |
Aiste | is it possible to make them overlap only when there is too many of the events? | 21:15 |
bska|mobile | its tricky to decide when that happens | 21:15 |
bska|mobile | not knowing the width of the screen | 21:15 |
bska|mobile | that's the ideal though | 21:16 |
bska|mobile | imo | 21:16 |
bska|mobile | I was advocating not overlapping until there are 4 or more | 21:16 |
Aiste | yup, something like that | 21:16 |
mgedmin | in javascript, can you get the width of the screen (or better yet, the calendar box)? | 21:16 |
bska|mobile | width of the screen I believe, not sure about the width of the element | 21:17 |
bska|mobile | everything is done in ems to be scalale | 21:17 |
bska|mobile | er., scalable even | 21:17 |
bska|mobile | lets go with three side by side then start overlapping | 21:21 |
bska|mobile | brb | 21:21 |
<--bska|mobile has quit (Read error: 110 (Connection timed out)) | 21:38 | |
-->bska|mobile (~bskahan@66.93.119.120) has joined #schooltool | 21:48 | |
<--SteveA has quit ("Leaving") | 23:29 | |
**** ENDING LOGGING AT Mon Dec 27 23:45:56 2004 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!