| vmx | how are multi day events sorted? | 00:48 |
|---|---|---|
| vmx | ok, there a sorted on the day the start | 00:50 |
| *** srichter has quit IRC | 00:57 | |
| *** srichter has joined #schooltool | 01:00 | |
| *** ignas has joined #schooltool | 01:28 | |
| vmx | anyone here? shouldn't all day events be independent of the timezone? | 01:30 |
| vmx | or doesn't schooltool handle the case that a user switches the timezone but has already entered some events? | 01:31 |
| th1a | What happens now? | 01:31 |
| vmx | i enter an all day event on let's say 2005-03-19 | 01:32 |
| vmx | in UTC | 01:32 |
| vmx | now i switch to CET | 01:32 |
| vmx | if i edit the event i still see 2005-03-19, but in the calendar (week view) i see it on 2005-03-20 | 01:33 |
| vmx | oh, wait, i see it on both days | 01:34 |
| vmx | even in day vew | 01:35 |
| vmx | view | 01:35 |
| vmx | but it's a good question how this should be handled by schooltool | 01:35 |
| vmx | ok, it's a bug. even if add a new event i see it on 2 days | 01:37 |
| vmx | timezones are really tricky | 01:37 |
| vmx | on my new code it doesn't happen, so it should be that hard to fix | 01:38 |
| vmx | anyone here for a discussion how this problem should be solved? i think i can fix it, i just need to know how it should look like in the end | 01:48 |
| vmx | i propose, that the all day event should occur at the date it was entered (the day the db says). and only as often as the duration lasts | 01:49 |
| Gwynn | th1a: I'd be happy to start on a translation of the schooltool.org site. Have registered. Need me to mail you first or is this way also a valid opion? | 02:04 |
| vmx | th1a: i would have a patch ready to fix the all-day-timezone-problem | 02:25 |
| vmx | it would be nice if it would be checked in: http://vmx.cx/schooltool/patches/alldayevents.diff | 02:31 |
| vmx | i can't remember the person who added the multi-day support. perhaps he could take a look at this patch | 02:32 |
| vmx | hm, the question is, should a multiday event be returned by getEvents twice (for both days) and displayed only on one day, or should it returned only once | 02:42 |
| *** deang has joined #schooltool | 03:04 | |
| deang | I have an edubuntu question @ schooltool. Should I proceed here or move to #edubuntu? | 03:05 |
| th1a | deang: Still here? | 03:18 |
| th1a | Gwynn: I can upgrade your account. | 03:19 |
| vmx | please forget my patch, it should not be fixed when displayed, but when created | 03:20 |
| th1a | vmx: We were a bit naive about the difficulty of timezones. | 03:21 |
| th1a | We probably should have avoided them altogether. | 03:21 |
| Gwynn | th1a: yes please. looked at the howto ^started a bit on the personal pages allready .. language is dutch btw | 03:21 |
| th1a | How do you say dutch in dutch? | 03:22 |
| Gwynn | th1a: the account is then also valid for LinguaPlone? | 03:22 |
| Gwynn | nederlands | 03:22 |
| vmx | th1a: yes, right. perhaps it would be the best to set it to UTC and leave it alone. there doesn't seem much usage for timezones | 03:22 |
| th1a | Yes. | 03:22 |
| deang | th1a: Sorry, back | 03:22 |
| th1a | vmx: There is usage for timezones, just not so much for SCHOOLS, unfortunately. | 03:23 |
| Gwynn | th1a, vmx _yet_ | 03:23 |
| vmx | th1a: ok, it might. but not even for me. i want to use the calendar for small business | 03:24 |
| deang | I installed flight 5. Frustrated that there isn't a short-cut to localhost schooltool. In either Firefox or Applications. | 03:24 |
| vmx | and comments like those: # XXX utc here is a bug, probably http://issues.schooltool.org/issue373 | 03:24 |
| vmx | start_dt = datetime.combine(start, time(tzinfo=utc)) | 03:24 |
| vmx | aren't that nice | 03:24 |
| th1a | deang: That is a good point, if edubuntu is going to start a SchoolTool server by default it should at least give you a link to it. | 03:25 |
| th1a | vmx: We also had some problems with some developers who are no longer with us who are responsible for some of these problems. | 03:26 |
| th1a | Gwynn: OK, you should be able to create translations now. | 03:27 |
| deang | th1a: Also very surprised that Gcompris is not in Education. I'm happy with it in games, but would also like it in Education. | 03:27 |
| th1a | Gwynn... hmmm, your language hasn't appeared though. | 03:28 |
| th1a | deang: I don't work on edubuntu directly. | 03:28 |
| deang | erg, wrong forum. my apologies. | 03:28 |
| Gwynn | th1a: I'll go and check it in a minuet | 03:29 |
| th1a | Gwynn: OK. | 03:29 |
| Gwynn | s/minuet/minute | 03:29 |
| th1a | Gwynn: OK, I Dutch is in there now. | 03:30 |
| th1a | Gwynn: Note that LinguaPlone doesn't work with some of our content types now, and I'm not very confident about it in general, so working in a text editor and keeping a copy of your translations is not a bad idea. | 03:31 |
| Gwynn | th1a: ok, duly noted. I'll go have a looksee now | 03:31 |
| *** deang has left #schooltool | 03:47 | |
| vmx | ok, here's the new patch http://vmx.cx/schooltool/patches/alldayevents_py.diff | 03:59 |
| vmx | it's a much better solution than the old one | 04:00 |
| vmx | now the bug gets fixed where it occurs | 04:01 |
| Gwynn | th1a: ok so I have translated the call for volunteers (sic) but unfortunately cant translate the graphical instructions. I'll find me another piece to chew on :) | 04:08 |
| vmx | i still haven't solved the bug completely | 04:14 |
| vmx | the problem is, when you add allday events in an earlier timezone (e.g. europe) and you change it to e.g. EST, day is one day before | 04:15 |
| vmx | the question is: do we want it this way? i think there is no plain right or wrong | 04:16 |
| th1a | vmx: I would say that an all day event should never shift due to a timezone change. | 04:39 |
| vmx | or they are still all day events, and the "borders" get "normal" events | 04:42 |
| th1a | What do you mean by "borders?" The beginning and end of the day in the original timezone? | 04:43 |
| vmx | but this will be most probably not that easy to code, or ugly code | 04:43 |
| vmx | yes | 04:43 |
| vmx | although that's also not that right | 04:43 |
| vmx | if you think of situations where all day events occur | 04:44 |
| vmx | e.g. vocations | 04:44 |
| th1a | Right. | 04:44 |
| vmx | they don't really start at stop at 0:00 | 04:44 |
| th1a | They simply should never change as a result of timezones changing. | 04:44 |
| vmx | on the other hand | 04:44 |
| vmx | if e.g. i add my vacations in germany | 04:45 |
| vmx | and you will look at it in the us | 04:45 |
| vmx | forget it | 04:46 |
| vmx | it to theoretical ;) | 04:46 |
| vmx | i mean, even if you would co-work across the world with a calendar | 04:46 |
| vmx | everybody with some brain will understand, that an all day event is in the co-workers timezone, and not in yours | 04:47 |
| vmx | is it right that schooltool tries to be like the icalendar standard? | 04:48 |
| vmx | then there's a nice solution. you can specify a date without a timezone, which means it is everywhere at the same time | 04:48 |
| vmx | i guess it isn't implemented in schooltool, is it? | 04:49 |
| th1a | Yes, we implement iCalendar. | 04:49 |
| vmx | ok, do you perhaps "no time zone" is implemented? | 04:50 |
| vmx | +know if | 04:50 |
| th1a | I don't know. | 04:50 |
| vmx | do you remember who implemented the multi-day events? | 04:51 |
| th1a | I'm afraid I don't. | 04:51 |
| vmx | np | 04:52 |
| Gwynn | th1a: I like to use this channel but if Im messing up the conv dont hesitate to tell me to shut up. Now : "What IS Included?" We hope .." why hope? why not "aim" or expect or plan or intend (or insist :P)... | 04:56 |
| th1a | I suppose it reflects some lack of confidence on my part. | 04:57 |
| Gwynn | want me to translate or be a lil bit more confident: ;) | 04:59 |
| th1a | You could express more confidence. | 05:00 |
| Gwynn | Iĺl just use the dutch word for expect | 05:00 |
| Gwynn | no, intend for the first hope and expect for the seond :) the first is after all basic funcions :) | 05:03 |
| * Gwynn abandons all hope | 05:13 | |
| vmx | *g* | 05:15 |
| *** jinty has quit IRC | 05:25 | |
| Gwynn | dutch vision is up, I'm affraid its hopeless :) | 05:37 |
| th1a | Gwynn: Thanks! | 05:37 |
| th1a | By the way, we've hired some developers in Rotterdam, if you didn't know that already. | 05:38 |
| Gwynn | no I didn't .. which firm if I can ask, maybe I know them | 05:39 |
| th1a | Infrae. | 05:39 |
| Gwynn | dont know them | 05:39 |
| th1a | They're a Zope shop. They created a content management system called SIlva. | 05:39 |
| Gwynn | I just stumbled over SchoolTool a few days back, and Im no developer, I'm an entire different breed of hacker :) | 05:40 |
| th1a | Where in Holland are you? | 05:41 |
| Gwynn | I'll try to remmber hat, allways on the lookout for and testing new cmsses | 05:41 |
| Gwynn | Tilburg | 05:41 |
| th1a | Is that near Rotterdam? | 05:41 |
| th1a | I've only been to Rotterdam, Heerlen and the Amsterdam airport. | 05:42 |
| Gwynn | everything is relatively close to each other in the netherlands :) but yes it is, I think half an hour, an hour by train | 05:42 |
| Gwynn | you ask m to heck the translation, if they like what they see I'm happy to do some more | 05:44 |
| Gwynn | check* even | 05:44 |
| Gwynn | I allowed for discussion in it | 05:44 |
| th1a | OK. Did you look at the Rosetta interface to translate the application itself? | 05:45 |
| Gwynn | yes I did and I translated a bit in there as well but I was gonna see if i could install it and show to some teacher friends, so I could get a better grip on some of the terms used, like the term term, which has tons of meanings :) | 05:46 |
| th1a | Indeed. | 05:47 |
| th1a | Actually, I need to fix our glossary as well. | 05:47 |
| th1a | It seems to be broken. | 05:47 |
| Gwynn | and there was a lot in there that was allreay translated quite good (onetheo or so) but it didnt sho in the fields and I didn't now what to do with thos | 05:48 |
| th1a | What do you mean it didn't show in the fields? | 05:50 |
| th1a | Didn't show up in the application when you ran it? | 05:51 |
| Gwynn | no. I mean there like x 'untranslated' fields but a lot of them have the right translation not in the input field, but mentioned under that, with 'previous occurance' or so somewhere else | 05:52 |
| Gwynn | like all the names of the months, they are there, but not in the input field | 05:52 |
| th1a | But it looks like you could override them if you wanted to? | 05:52 |
| th1a | Do they show up correctly in the application? | 05:53 |
| Gwynn | yeah, I think I could copy and paste them, but that would be rude toward the guy who gave the original translation | 05:53 |
| Gwynn | I dont know, I havent run the application yet | 05:53 |
| Gwynn | I'm dragging hardware all over town and wrestling with miles of cables | 05:54 |
| th1a | btw, isn't it like, 5:00AM there? | 05:54 |
| Gwynn | that why Im here on this BUFF which is actually my play machine, I usually dont use it for serious things | 05:54 |
| Gwynn | yes | 05:54 |
| th1a | Are you a vampire? | 05:54 |
| th1a | Actually, I often go to bed at 3:00, so I shouldn't talk. | 05:55 |
| Gwynn | :P last timei checked i had a hardbeat and could see stubs in the mirror | 05:55 |
| Gwynn | I used moved my operational timeframe, less hasle, no people calling, paying unexpected visits, dragging me to the bar | 05:56 |
| th1a | Yes, I know the technique well. | 05:57 |
| Gwynn | what time are you at now if I can ask? | 05:58 |
| vmx | ForbiddenAttribute: ('dtend', <schooltool.app.cal.CalendarEvent object at 0xb11f0cec>) :-/ | 06:01 |
| th1a | Gwynn: It is 23:00. | 06:01 |
| Gwynn | ahh you wuss | 06:01 |
| Gwynn | :) but itś time for me to wind down and call it a day :) | 06:02 |
| th1a | I'll be up at least three more hours. | 06:03 |
| th1a | Good night. Nice chatting with you. | 06:03 |
| vmx | ok, this error is to much for today, g'night | 06:03 |
| th1a | vmx: What brought that up? | 06:03 |
| vmx | i try to print out event.dtend | 06:04 |
| vmx | event.dtstart works | 06:04 |
| Gwynn | likewise, hope Infrae likes it, Ill get back here tomorrow | 06:04 |
| th1a | vmx: Yeah, I can't help you with that. Good night. | 06:04 |
| vmx | gwynn we are in the same timezone | 06:05 |
| Gwynn | vmx: you one of the ppl from rotterdam? | 06:05 |
| vmx | ok then good night to all of you | 06:05 |
| vmx | no, i live in germany | 06:05 |
| *** vmx is now known as vmx_afk | 06:06 | |
| *** Gwynn has quit IRC | 06:10 | |
| *** vmx_ has joined #schooltool | 09:13 | |
| *** vmx_afk has quit IRC | 09:13 | |
| *** ignas has quit IRC | 09:16 | |
| *** vmx_ has quit IRC | 11:25 | |
| *** vmx__ has joined #schooltool | 11:25 | |
| *** alga has joined #SchoolTool | 12:01 | |
| *** alga_ has joined #SchoolTool | 12:01 | |
| *** alga_ has quit IRC | 12:01 | |
| *** th1a has quit IRC | 12:01 | |
| *** jinty has joined #schooltool | 12:18 | |
| *** mgedmin has joined #schooltool | 12:33 | |
| *** Aiste has quit IRC | 12:45 | |
| *** Aiste has joined #schooltool | 13:10 | |
| *** vmx__ is now known as vmx | 13:11 | |
| vmx | re | 13:12 |
| *** ignas has joined #schooltool | 13:21 | |
| vmx | hi ignas | 13:30 |
| ignas | vmx, hi | 13:31 |
| vmx | lt, is that latvia? | 13:33 |
| vmx | ignas: were you the one who added the multi-day support? | 13:35 |
| ignas | vmx, yes | 13:35 |
| ignas | vmx, foud a bug already ? :) | 13:35 |
| ignas | lt is lithuania | 13:35 |
| vmx | yes | 13:35 |
| *** thisfred has joined #schooltool | 13:35 | |
| ignas | and the bug is ? | 13:36 |
| vmx | with timezones (you'll say oh my god timezones ;) | 13:36 |
| vmx | i have written already 3 different bugfixes, everyone got better, but still not perfekt | 13:36 |
| vmx | it spans 1 day to long | 13:36 |
| vmx | or it starts on the worng day | 13:37 |
| vmx | th1a and i thought about it. an all day event should be timezone independant | 13:37 |
| ignas | oh, well - i am going for these bugs slowly and in a way that will kill them all | 13:37 |
| ignas | vmx, there is such small thing like - monday on UTC might be Sunday in Australia ... | 13:38 |
| ignas | and when one is requesting a range "midnight - midnight tomorow", timezone has to be taken into accound when determining what is the "date" of the timestamp | 13:39 |
| vmx | or you declare it independant | 13:39 |
| ignas | well - can you tell should an Australian see "2005-01-01" event on 2005-01-01 00:00:00 UTC without knowin ghis timezone ? | 13:40 |
| vmx | what's the problem= | 13:41 |
| ignas | the idea was - adding a timezonde attribute to the expand() functions (the alternative would be taking the timezone of the first timestamp, but that would be not elegant/implicit) | 13:42 |
| ignas | so we would know what is the "date" of the timestamp | 13:42 |
| ignas | and could map allday event date to the user date | 13:42 |
| ignas | problems that appear without that are - events occuring each monday in Australia are shifting to Sunday on UTC and we can't handle it properly yet | 13:43 |
| ignas | and lot's of similar issues | 13:43 |
| vmx | but if you think of the cases when an allday event is used | 13:44 |
| ignas | yes | 13:44 |
| vmx | it is always clear that it is in the timezone the one who entered it lives | 13:44 |
| ignas | you must take into account that - events have no timezone, they are all UTC | 13:44 |
| ignas | in the backend | 13:44 |
| ignas | i am thinking of gradualy adding support for timezones on events, which involves adding timezone support to ICalendar export (i did the import already) | 13:45 |
| ignas | adding timezones to events | 13:45 |
| ignas | adding timezones to event edit/add UI | 13:45 |
| ignas | fixing hour grid to accomodate 23 hour and 25 hour days | 13:45 |
| ignas | DST | 13:46 |
| vmx | do you mean events in ical have no timezones, or the ones in schooltool | 13:46 |
| ignas | the ones in schooltool | 13:46 |
| ignas | and we are exporting them in UTC | 13:46 |
| ignas | thus losing user data | 13:46 |
| vmx | but what about handling all day events without any timezone? | 13:47 |
| ignas | yes | 13:47 |
| ignas | ? | 13:47 |
| vmx | ok, they will be internally UTC in schooltool, but not for the user/high level coder | 13:47 |
| vmx | all day events aren't even UTC, they are real local time | 13:48 |
| ignas | backend does not support that yet ... | 13:48 |
| ignas | you can only request all events in a range (dtstart, dtend) | 13:48 |
| ignas | you can work around it by making 2 requests, but it'd be ugly | 13:49 |
| vmx | hm, yes you make the request, so you'll get the needed all day events | 13:50 |
| vmx | then there's a function where the dates are transformed from UTC to the disired timezone | 13:51 |
| vmx | the only think you need to do is not converting the all day events | 13:51 |
| vmx | voila, you have have the all day events as expected | 13:51 |
| vmx | am i wrong? | 13:51 |
| ignas | converting all day events to what ? | 13:54 |
| vmx | you don't convert the all day events | 13:55 |
| vmx | if it is on 2005-03-04, it doesn't matter where you are | 13:56 |
| vmx | theoretically there would be a difference of course, but not practically | 13:56 |
| vmx | i'm not sure if it should be done in that function or in getEvents, but that's a patch i created yesterday (it might still be not perfect) | 13:57 |
| vmx | http://vmx.cx/schooltool/patches/alldayevents_notimezones.diff | 13:57 |
| ignas | the conversion should stay imho, the problem is getEvents will not return some all day events that would be in the date range | 13:59 |
| ignas | you should try testing it in a TDD style - add a unit that breaks | 14:00 |
| ignas | s/testing/writing | 14:01 |
| vmx | TDD? | 14:01 |
| ignas | Test driven development | 14:01 |
| vmx | ok | 14:01 |
| ignas | the style where you are not touching the code | 14:01 |
| ignas | until you got a unit test that fails | 14:01 |
| ignas | this helps you to be 100% sure about what behaviour you expect | 14:02 |
| ignas | before programming | 14:02 |
| vmx | i've done that (ok not really nice, but my way) | 14:02 |
| ignas | instead of changing the code and looking whether you like the result or not | 14:02 |
| vmx | as i said the patch isdn't finished yet | 14:02 |
| vmx | but i broke already | 14:03 |
| vmx | i had cases to break it | 14:03 |
| vmx | i think getEvents will return all needed events. atm soem wrong ones, but that can be fixed | 14:05 |
| ignas | err - what if you would really try it | 14:07 |
| ignas | by let's say adding some all day events | 14:08 |
| ignas | and looking a t getEvents | 14:08 |
| ignas | with Hawai timezone | 14:08 |
| ignas | and new zealand timezone | 14:08 |
| ignas | you know, just to be sure ;) | 14:08 |
| vmx | yesterday i tried it with UTC, EST and CET | 14:08 |
| vmx | i know, i need to write unit test, no question. but i'd like to know if i'm on the right why, or if you think i'm completely wrong | 14:09 |
| ignas | all timezones fall in +offset zone | 14:09 |
| ignas | last statement was false | 14:09 |
| vmx | i just take a look at the differences, e.g. setting up an event in EST and viewing in CET | 14:10 |
| ignas | you see - Australia is the other extreme | 14:11 |
| vmx | but as the getEvents looks like it should work | 14:11 |
| ignas | that should be tested too | 14:11 |
| vmx | yes i'll try that | 14:11 |
| ignas | you need a -10 timezone, UTC, +10 timezone | 14:11 |
| vmx | and writing a propper unit test | 14:11 |
| ignas | well - now that i think | 14:12 |
| vmx | but atm all day events a wrong. i mean an 1 day event occurs on 2 days on different timezones | 14:12 |
| ignas | your approach will work | 14:12 |
| ignas | but it will be wrong, as the getEvents and expand both are a part of schooltool, leaving bug in the backend and covering it up | 14:12 |
| ignas | is not the right approach : | 14:12 |
| ignas | :/ | 14:12 |
| vmx | does schooltool save dtend or duration? | 14:12 |
| ignas | duration | 14:12 |
| vmx | i which backend? | 14:13 |
| vmx | i=in | 14:13 |
| ignas | schooltool.calendar | 14:14 |
| ignas | the function that returns too many events is not a good thing tm | 14:14 |
| vmx | no it won't it uses getEvents | 14:14 |
| ignas | getEvents does what ? | 14:15 |
| ignas | :) | 14:15 |
| vmx | or am i wrong? | 14:15 |
| ignas | for event in calendar.expand(start_dt, end_dt): | 14:15 |
| ignas | the line in getEvents | 14:15 |
| vmx | yes, it returns to much all day events, as e.g. one is at 2005-02-15 and duration is 1d | 14:16 |
| vmx | so it's dtend is 2005-02-16 | 14:16 |
| vmx | if you have start_dt=2005-02-16 it gets returned | 14:16 |
| vmx | but that shouldn't be too hard to fix | 14:17 |
| vmx | of course the same will most probably happen to events that are e.g. at 23:00 and have duration 1h | 14:17 |
| vmx | ger really all needed events returned (i'm speaking of non-all day events) | 14:19 |
| vmx | ger=get | 14:19 |
| vmx | i'm not sure | 14:19 |
| ignas | these things are quite easily tested when writing tests for Calendar/CalendarEvent expand functions | 14:20 |
| ignas | and i think you should be fixing them not getEvents or _getDays | 14:20 |
| vmx | you're right. you have a better code knowledge :) | 14:21 |
| vmx | i had a short look, they don't look that nice ;) | 14:21 |
| vmx | timezones are really complex matter | 14:22 |
| ignas | duh! | 14:22 |
| ignas | :) | 14:22 |
| vmx | and they are mixex up in schooltool (at least i have the impression) | 14:23 |
| ignas | vmx, histerical reasons, the mistake of thinking that "storing everythin in UTC on the backend will simplyfy things" | 14:24 |
| ignas | the fact that they were added by programmers that did not grasp the true complexity of timezones ... | 14:25 |
| *** mgedmin has quit IRC | 14:25 | |
| vmx | yes, th1a told me yesterday that they were to naiv about the easyness of timezones | 14:25 |
| vmx | although i think storing everything in UTC isn't that wrong | 14:26 |
| ignas | vmx, it is! | 14:26 |
| ignas | Daylight saving time | 14:26 |
| ignas | and jumping events | 14:26 |
| vmx | but what if you have different timezones at once | 14:26 |
| vmx | that would make problems | 14:26 |
| vmx | e.g. the european daylight saving time starts this weekend, the us ones next week | 14:28 |
| vmx | the expanf i'm looking for is on calendar/mixins.py, right? | 14:29 |
| vmx | *expand | 14:29 |
| ignas | yes | 14:30 |
| ignas | both expands | 14:30 |
| ignas | the XXX parts by mgedmin | 14:31 |
| ignas | :) | 14:31 |
| ignas | my suggestion is - add timezone argument to the function, but if you will solve the problem more elegantly - i'll be glad ;) | 14:31 |
| vmx | first i have to check and understand what it really does | 14:32 |
| ignas | :) | 14:32 |
| ignas | srichter, ayt ? | 14:35 |
| srichter | yes, but I am still booting | 14:41 |
| *** mgedmin has joined #schooltool | 14:42 | |
| vmx | hm, expand shouldn't work at. i really wonder how it works ;) | 14:47 |
| srichter | ignas: ok, now I am here | 14:49 |
| ignas | is there some particular reason why gradebook views gradebook/browser/gradebook.py has so much code not covered by unit tests ? | 14:51 |
| * ignas is just wondering, there is a chance the code has a lot of functional tests | 14:51 | |
| srichter | ignas: I usually do not write unit tests for view code | 14:51 |
| srichter | I do write ftests to cover all angles though | 14:51 |
| ignas | i see, a lot of that code seems to be unit testable though ... like with many branching if statements etc. | 14:53 |
| vmx | ui, getEvents is really strange | 15:04 |
| vmx | if you print out start_dt and end_dt values. i really wonder why schooltool wants events from such ranges | 15:04 |
| ignas | :) | 15:08 |
| ignas | three month calendar viewlets | 15:08 |
| ignas | on the left side | 15:08 |
| ignas | tomorow event viewlet | 15:08 |
| ignas | + caching | 15:08 |
| ignas | and events you can see in the current calendar view | 15:09 |
| vmx | ah, the three month calendat viewlet: 2006-01-30 00:00:00+00:00 2006-05-01 00:00:00+00:00 | 15:09 |
| vmx | thanks | 15:09 |
| ignas | vmx, if you have non UTC timezone set then these dates are a bug ;) | 15:29 |
| ignas | unless you skipped tzinfo part | 15:29 |
| vmx | i've set it to CET (Europe/Berlin) | 15:31 |
| vmx | ignas: i think i need to change things in _getDays | 15:31 |
| vmx | the funny thing is that i had a patch for that yesterday, but then i thought i was wrong | 15:31 |
| vmx | it seems i was right | 15:32 |
| vmx | http://vmx.cx/schooltool/patches/alldayevents_notimezones.diff | 15:33 |
| vmx | in _getDays the events get splitted into the days (or better to day, the events are assigned to the days) | 15:33 |
| vmx | with this patch all day events get assigend to really a certain day, and not between days when you switch the timezone | 15:34 |
| ignas | true | 15:34 |
| ignas | allday events with a datetime as their dtstart is an oxymoron :/ | 15:35 |
| ignas | obscenity | 15:35 |
| ignas | even | 15:35 |
| vmx | yes | 15:35 |
| ignas | but spliting event into 2 different classes is a lot of work | 15:35 |
| vmx | no you mustn't | 15:36 |
| vmx | just ignore the time | 15:36 |
| ignas | you see - constructor handling arguments in 2 different ways depending on the value of the "allday" argument might be too convoluted | 15:38 |
| ignas | and all the code dispatching on "allday" should go into events | 15:39 |
| ignas | at least that's what OOP books are saying | 15:39 |
| ignas | else - someone might and WILL forget to check such thingds, and bugs will apear in other places ... | 15:40 |
| ignas | but yes - if it is possible to solve it in an elegant manner without 2 different classes - it would be easier | 15:40 |
| ignas | no evolution scripts, less modifications to the code | 15:41 |
| vmx | that's my proposition: | 15:41 |
| vmx | one moment please. i had an idea but it wasn't good | 15:43 |
| ignas | :D | 15:43 |
| vmx | ok, it's not that good but perhaps good enough | 15:45 |
| vmx | internally alldayevents are datetime events (like all others). when you want to change something with the timezone or whatever, you just have to check if it is an allday event or not | 15:46 |
| vmx | it would be cleaner to have an extra event for alldayevents which is date and not datetime | 15:46 |
| ignas | "you just have to check" part is really bad idea ... | 15:47 |
| vmx | yes i know, but | 15:47 |
| vmx | but that wouldn't be very pratically, think of the duplicated code when you e.g. want all events | 15:47 |
| ignas | programmers are people, people do forget such things, new programmers just don't know such stuff | 15:47 |
| vmx | you would need a function to get all "normal" events, and one for alldayevents | 15:48 |
| vmx | the would do exactly the same thing, the only difference is between the date and datetime object | 15:48 |
| ignas | you see - that would be better than the current state of affairs | 15:48 |
| ignas | because - one need to handle both kinds of events differently all the time | 15:48 |
| ignas | and only in some cases need to get ALL the vents | 15:48 |
| ignas | tough perfectly it is possible with one selector | 15:49 |
| ignas | and 2 different classes | 15:49 |
| ignas | if it was easy - we would have already implemented that though :/ | 15:49 |
| vmx | hm you're right. i don't know if you've seen my screenshot some days ago, i'd like to have alldayevents displayed in a differnt way | 15:49 |
| ignas | no i haven't seen it | 15:50 |
| vmx | http://vmx.cx/tmp/schooltool/screen001.png | 15:50 |
| vmx | not very nice yet, just a rough test | 15:50 |
| vmx | i have to admit it would be easier/nicer with 2 classes | 15:51 |
| ignas | some ordinary events can span multiple days too | 15:52 |
| ignas | :) | 15:52 |
| vmx | hm, that's true | 15:52 |
| vmx | that would be a reason for not splitting it into 2 classes | 15:52 |
| tiredbones | :q | 15:53 |
| vmx | and if you make a new alldayclass, but use the existing functions? | 15:53 |
| ignas | vmx, you see - 2 classes does not mean 2 interfaces | 15:53 |
| ignas | 2 classes would be used only to avoid if self.allday: foo else: bar code in methods | 15:54 |
| vmx | yes, but you would need to duplicate code | 15:54 |
| vmx | the problem is the differnce between date and datetime | 15:55 |
| vmx | or you create only 2 classen and convert between date and datetime all the time | 15:55 |
| vmx | that would at least give programmers an error message if they use alltheday events | 15:56 |
| ignas | the "right way"(tm) would be - adding if allday: else: | 15:56 |
| ignas | blocks to the currente event class | 15:56 |
| *** mgedmin has quit IRC | 15:56 | |
| ignas | making it use Date for ddtstart for allday events | 15:56 |
| ignas | fix everything that breaks | 15:56 |
| ignas | and then see whether it should be refactored into 2 classes | 15:56 |
| vmx | the question is: how should the breaks be fixed? | 15:57 |
| ignas | elegantly | 15:57 |
| vmx | converting between date and datetime (and the other way round) all the time? | 15:57 |
| vmx | would you prefer converting between them before you pass them to a function or make a "if self.__class__" at the beginning and at the end of a function? | 15:59 |
| ignas | no and no | 15:59 |
| vmx | k :) | 15:59 |
| ignas | it all depends on why and when do you want to add a time to the date | 16:00 |
| ignas | the only reason is - to compare it with a datetime | 16:00 |
| *** Gwynn has joined #schooltool | 16:00 | |
| vmx | yes, but it happens all the time, when you e.g. need the events of a specific time interval | 16:00 |
| ignas | and for these cases - you should be aware of users timezone (reasons i have stated earlier), and the relevant code should appear in some method of Simple calendar event maybe | 16:00 |
| ignas | it might even be sane (or maybe not) to add a __cmp__ function that compares an event with a datetime | 16:01 |
| vmx | hm, timezones wouldn't/shouldn't be a problem, as normally the function are timezone aware, and the alldayevents needn't | 16:03 |
| ignas | well - i'd say the code that compares datetime and date should get isolated in the expand, (not sure, can't check, i am quite busy at the moment) | 16:04 |
| ignas | or another idea - different expands - one for "timestamp, timestamp" and another for "date, date" | 16:05 |
| ignas | because well - you might say that expanding all day events between two timestamps is not making any sense | 16:05 |
| vmx | what do you mean with "expand"? the current expand function? | 16:06 |
| ignas | yes | 16:06 |
| vmx | that isn't the critical part | 16:06 |
| ignas | it's all interconnected ... | 16:07 |
| vmx | the critical part is where the events get splitted/assigned to the days | 16:07 |
| ignas | that part is easily fixable by adding a function like "getDateInterval" to an event or something like that | 16:08 |
| vmx | in expand they have no real assignment to the days. expand just get all events | 16:08 |
| ignas | event knows dates it belongs to better than anyone else ;) | 16:08 |
| vmx | yes to dates, but not to days | 16:09 |
| *** mgedmin has joined #schooltool | 16:11 | |
| vmx | what do you mean exactly with "getDateInterval"? is it hte interval the event acutually spans in the users timezone? | 16:12 |
| ignas | sorry i don't really have enough time to work on this at the moment :( | 16:13 |
| vmx | ok, np | 16:13 |
| vmx | it was a nice discussion, we'll see what other ideas i'll have :) | 16:14 |
| ignas | the problem with these bugs is - that they require some redesign of interfaces/classes in the schooltool.calendar and other places | 16:14 |
| ignas | and design, especially if it's any good is difficult to create | 16:14 |
| vmx | i actually don't need timezones, but i feel a bit bad creating new code on top of ugly/not fully working code | 16:15 |
| *** Tgylluad has joined #schooltool | 16:19 | |
| ignas | i do feel bad about it too, as i have skills and knowledge to fix that code, yet - new features are more important at the moment, as schooltool is not a Calendaring only application | 16:19 |
| *** Tgylluad has quit IRC | 16:20 | |
| ignas | and - some bugs are so obscure that well - they are not really important to users ;) | 16:20 |
| *** Gwynn has quit IRC | 16:22 | |
| *** Gwynn has joined #schooltool | 16:30 | |
| Gwynn | /msg NickServ IDENTIFY <owlsnest> | 16:30 |
| mgedmin | Gwynn: now we all know your nickserv password ;) | 16:31 |
| Gwynn | bloody hell I thought i clicked the other channel | 16:31 |
| Gwynn | hrmpf, thnx for the warning :) | 16:32 |
| vmx | ignas: can you give me a small hint where the events get into schooltool. i mean when you create a new one. i haven't found it in the source | 16:33 |
| mgedmin | http://bash.org/?44228 | 16:34 |
| vmx | hm, i think i found it | 16:35 |
| *** faassen has joined #schooltool | 16:49 | |
| mgedmin | Gwynn: /msg nickserv help set password | 16:56 |
| Gwynn | mgedmin: thnx a bundle, done :) | 16:58 |
| *** th1a has joined #schooltool | 17:18 | |
| *** alga has quit IRC | 17:43 | |
| vmx | can i delete all my events somehow? | 18:57 |
| vmx | forget, i have another one: where is the part in the source where the stored events become objects? | 19:01 |
| th1a | vmx: What do you mean, become objects? | 19:01 |
| vmx | i mean the initialization | 19:02 |
| vmx | i think i found it | 19:02 |
| *** jinty has quit IRC | 20:18 | |
| *** faassen has quit IRC | 20:21 | |
| *** Aiste has quit IRC | 20:32 | |
| *** jinty has joined #schooltool | 20:53 | |
| *** thisfred has quit IRC | 21:09 | |
| *** Aiste has joined #schooltool | 21:20 | |
| *** srichter has quit IRC | 22:29 | |
| *** vmx_ has joined #schooltool | 22:37 | |
| *** vmx has quit IRC | 22:38 | |
| *** ignas has quit IRC | 23:37 | |
| *** mgedmin has quit IRC | 23:41 | |
| *** welsh has joined #schooltool | 23:44 | |
| welsh | th1a: you there? | 23:44 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!
