| *** jinty has quit IRC | 00:13 | |
| *** tiredbones has quit IRC | 00:13 | |
| *** jinty has joined #schooltool | 00:14 | |
| *** jinty has quit IRC | 00:32 | |
| *** jinty has joined #schooltool | 00:33 | |
| *** tiredbones has joined #schooltool | 00:46 | |
| *** tiredbones has quit IRC | 01:05 | |
| *** tiredbones has joined #schooltool | 01:05 | |
| *** jinty has quit IRC | 02:15 | |
| *** jinty has joined #schooltool | 02:16 | |
| *** jinty has quit IRC | 02:55 | |
| *** jinty has joined #schooltool | 02:57 | |
| *** jinty has quit IRC | 04:28 | |
| *** jinty has joined #schooltool | 04:29 | |
| *** jinty has quit IRC | 04:57 | |
| *** jinty has joined #schooltool | 04:58 | |
| *** vmx__ has joined #schooltool | 05:57 | |
| *** vmx_ has quit IRC | 05:57 | |
| *** vmx_ has joined #schooltool | 07:18 | |
| *** vmx__ has quit IRC | 07:20 | |
| *** vmx_ is now known as vmx | 09:33 | |
| vmx | re | 09:34 |
|---|---|---|
| *** jinty has quit IRC | 10:43 | |
| *** jinty has joined #schooltool | 10:44 | |
| *** jinty has quit IRC | 11:14 | |
| *** jinty has joined #schooltool | 11:15 | |
| *** jinty has quit IRC | 11:38 | |
| *** jinty has joined #schooltool | 11:42 | |
| *** jinty has quit IRC | 12:02 | |
| *** jinty has joined #schooltool | 12:18 | |
| *** alga has joined #SchoolTool | 12:20 | |
| *** Aiste has quit IRC | 12:23 | |
| vmx | can a run a specific unittest instead of all tests? (atm i use "make test") | 12:31 |
| *** mgedmin has joined #schooltool | 12:39 | |
| *** mgedmin changes topic to "SchoolTool development | IRC logs at http://source.schooltool.org/irclogs/ | Dev meetings Tue, 14:30 UTC (17:30 EEST)| CanDo dev meetings Tue, 4pm EST" | 12:42 | |
| *** ignas has joined #schooltool | 12:45 | |
| *** Aiste has joined #schooltool | 12:55 | |
| *** thisfred has joined #schooltool | 13:05 | |
| *** faassen has joined #schooltool | 13:06 | |
| *** jinty has quit IRC | 13:52 | |
| *** jinty has joined #schooltool | 13:55 | |
| *** jinty has quit IRC | 14:16 | |
| *** ignas has quit IRC | 14:23 | |
| *** ignas has joined #schooltool | 14:27 | |
| *** povbot` has joined #schooltool | 15:20 | |
| *** faassen has quit IRC | 15:24 | |
| *** Aiste has quit IRC | 15:26 | |
| *** mgedmin has quit IRC | 15:26 | |
| *** jinty has joined #schooltool | 15:33 | |
| *** povbot has quit IRC | 15:34 | |
| *** vmx_ has joined #schooltool | 15:37 | |
| *** vmx has quit IRC | 15:39 | |
| *** jinty has quit IRC | 15:56 | |
| *** Aiste has joined #schooltool | 16:06 | |
| *** jinty has joined #schooltool | 16:07 | |
| *** tiredbones has quit IRC | 16:20 | |
| *** tiredbones has joined #schooltool | 16:20 | |
| *** Aiste_ has joined #schooltool | 16:37 | |
| *** Aiste has quit IRC | 16:38 | |
| *** Aiste_ has quit IRC | 17:05 | |
| *** vmx__ has joined #schooltool | 17:22 | |
| *** vmx_ has quit IRC | 17:23 | |
| *** ignas has quit IRC | 17:25 | |
| *** Aiste has joined #schooltool | 17:28 | |
| *** mgedmin has joined #schooltool | 17:28 | |
| * th1a yawns. | 17:30 | |
| *** ignas has joined #schooltool | 17:31 | |
| th1a | Is it 17:30 in Vilnius? | 17:31 |
| ignas | yes | 17:31 |
| ignas | hi :) | 17:31 |
| th1a | Hi ignas. | 17:31 |
| th1a | Everyone ready to go here? | 17:32 |
| th1a | Ping? | 17:33 |
| ignas | whom are you pinging ? | 17:34 |
| ignas | ping -t :) | 17:34 |
| ignas | ping -b i mean | 17:34 |
| th1a | Well, it is time to start the meeting, right? | 17:34 |
| th1a | srichter? Let's see... no faassen. | 17:35 |
| mgedmin | yes | 17:35 |
| alga | Unfortunately I'll have to leave soon | 17:35 |
| alga | blame the DST TZ shift | 17:35 |
| srichter | I am here | 17:35 |
| th1a | OK. This probably won't take long. | 17:35 |
| th1a | What's POV's status? Ready to work on SchoolTool soon? | 17:36 |
| alga | starting next week at best | 17:36 |
| alga | our deadline is still looming this Friday | 17:36 |
| th1a | Ah. I thought it was last Friday. | 17:36 |
| th1a | Did everyone read the big update I wrote last week. | 17:37 |
| th1a | http://www.schooltool.org/weblog/archive/2006/03/28/march-2006-project-update/ | 17:37 |
| ignas | th1a, still reading :/ | 17:37 |
| srichter | th1a: yeah, though for me nothing was really any news, but I am very happy about the direction | 17:38 |
| srichter | it was the right move | 17:38 |
| th1a | I'm not happy about moving more slowly. We just have to not move TOO slowly. | 17:38 |
| srichter | yeah, I agree we need to pick up speed | 17:39 |
| th1a | So one implication for POV in particular is that the first testers of attendance will be St. Ives. | 17:40 |
| srichter | I was more referring to using next year as a bets year and not risking full installations | 17:40 |
| th1a | srichter: Well, we're at a dead stop at the moment, so I agree. | 17:40 |
| tiredbones | srichter, what direction do you see? | 17:40 |
| th1a | srichter: beta not bets? | 17:40 |
| srichter | right | 17:40 |
| ignas | th1a, a question - what will happen to school*bell* in ubuntu/Debian ? | 17:41 |
| th1a | So after this iteration of attendance I'll have to get Miles from St. Ives talking directly to POV about what needs to be finished for his school. | 17:41 |
| srichter | tiredbones: I see no directions, this is Tom's job :-) I just enjoy working on what Tom tells me is important to work on. He he. | 17:41 |
| tiredbones | he he | 17:41 |
| srichter | th1a: btw, I did some work on SchoolTool last Monday and a little bit on Tuesday | 17:42 |
| th1a | ignas: Well, we'll have to implement the grand plan to derive SchoolBell from the SchoolTool source tree sometime between now and Breezy+1. | 17:42 |
| srichter | the quick progress I made with the UI indicates that the API is good | 17:42 |
| ignas | th1a, as many users are comming and asking for various fixes/directions while not really being aware that we are not going to do anything with SB for some time ... | 17:42 |
| mgedmin | th1a: breezy + 1 == dapper | 17:42 |
| mgedmin | I assume you meant dapper + 1 | 17:42 |
| th1a | Sorry. | 17:42 |
| th1a | Yes. | 17:42 |
| *** alga has quit IRC | 17:43 | |
| th1a | Well, we've all learned something about the open source development process, I guess. | 17:44 |
| th1a | We (Mark, Steve, me...) were all too optimistic about people coming along with their own SchoolBell fixes. | 17:44 |
| th1a | Although, realistically, you probably always get about 1 patch for every 25 complaints and requests, at best. | 17:45 |
| tiredbones | th1a, I think it's because of zope tech that slowed it down. | 17:45 |
| th1a | Maybe 1 per 100. | 17:45 |
| ignas | but they are very good with coming up with feature requests and bug reports :D | 17:45 |
| th1a | tiredbones: That's true, I'm afraid. | 17:45 |
| ignas | in triplicates most of the time | 17:45 |
| srichter | I just think that the crowd that SchoolBell is attracting is not the development crowd | 17:47 |
| th1a | ignas: Try not to let the SchoolBell situation get you down. | 17:47 |
| th1a | srichter: That is true as well. | 17:47 |
| srichter | specifically since SchoolBell does not integrate into CMF, Plone, CPS, Silva or whatnot | 17:47 |
| ignas | th1a, it is not leting me down, i just want to know - what should i say to someone who is requesting a fix that is not going to happen for 6 months | 17:47 |
| ignas | th1a, as i don't want to ignore users, that's all | 17:47 |
| srichter | ignas: tell them that; it's open source; they always have the option to pay you fix it | 17:48 |
| th1a | As we discussed last week, we couldn't make the moves we needed to with licensing, etc., to move into the center of the Python/Zope calendaring world. | 17:48 |
| srichter | in fact that would be my answer as a business man :-) | 17:48 |
| th1a | We just have to be honest about the fact that we're working on different things. | 17:49 |
| srichter | I agree | 17:49 |
| th1a | I mean, so many open source projects are completely abandoned. We're still around, so that's something. | 17:49 |
| srichter | yes, and we are producing something usable for at least 4-5 schools | 17:50 |
| tiredbones | th1a, tom seems very down. | 17:50 |
| th1a | :-) | 17:50 |
| srichter | plus all the other ones that are already using SchoolBell for smaller projects | 17:50 |
| srichter | I think in September we will really see the benefits of the current work | 17:51 |
| th1a | tiredbones: One thing about meeting online is that you can get out of bed 15 minutes before the meeting starts. But it is hard to be chipper when you do that. | 17:51 |
| ignas | th1a, is the "we will not work directly on schoolbell until dapper+1" fact written somewhere, os i could give the link to people who are asking about SB? | 17:51 |
| ignas | s/os/so | 17:51 |
| srichter | once people are using our stuff and we can turn around and create very customized reports using templates, adjust features as needed, it will be a joy to support users | 17:51 |
| *** vmx__ is now known as vmx | 17:51 | |
| th1a | srichter: Yes. Few people have seen the past six months' work. | 17:51 |
| srichter | also, SchoolTool is much more in our core focus, so support will come more natural | 17:52 |
| th1a | ignas: I'm working on the website this week, so I'll make sure that's as clear as possible. | 17:52 |
| th1a | OTOH, I don't want people to stop trying it out and reporting bugs, so I'm not sure what the result would be. | 17:53 |
| vmx | if schoolbell will be derived from schooltool, this information should be added too. so that the people know that it could be developed further, and it is not completely on hold | 17:53 |
| tiredbones | tech will not win out over a deliverable. | 17:53 |
| th1a | OK. I don't want to get too rambly here. | 17:54 |
| tiredbones | I thought the whole point of XP was get something before your customer. | 17:54 |
| th1a | tiredbones: Yes. | 17:55 |
| th1a | Actually, though, we are going to end up working more on the calendaring within SchoolTool in the next six months than I had been thinking. | 17:55 |
| th1a | One thing that has changed a bit is that two of the schools (HTH and SLA) place a high priority on students and parents viewing their homework, etc., through the web. | 17:56 |
| th1a | So for POV, between now and September, the focus will be: | 17:57 |
| th1a | * getting attendance ready for St. Ives. | 17:57 |
| th1a | * cleaning up calendaring for the above mentioned use | 17:58 |
| th1a | * probably some work on reports. | 17:58 |
| ignas | attendance is connected to calendaring too, as "attendance events" and timetabling are really closely related to calendaring, so yes i think we will have to do it properly sooner or later | 17:59 |
| th1a | Yes. | 17:59 |
| th1a | We'll probably need to work on the weekly calendar view and the printed calendars to make them more polished. | 17:59 |
| tiredbones | th1a, can that list be further broken down? | 17:59 |
| th1a | tiredbones: Presumably. I just made it up though. | 18:00 |
| th1a | That was more thinking out loud than revealing the next chapter in the master plan. | 18:00 |
| srichter | what would be the resources required to have a simple calendar/event API that we can hook into | 18:01 |
| *** jinty has quit IRC | 18:01 | |
| srichter | I need to create events eventually too, but honestly I am very afraid of the code | 18:01 |
| ignas | srichter, can you elaborate on that ? | 18:01 |
| th1a | Also, then, as next school year goes on, we'll start testing attendance in more schools, so there will be ongoing work and refinement through the year. | 18:01 |
| srichter | basically I just want to say: | 18:01 |
| srichter | >>>> ev = Event(...) | 18:02 |
| srichter | >>> cal.addEvent(ev) | 18:02 |
| srichter | maybe before that: | 18:02 |
| srichter | >>> cal = ICalendar(ISchoolToolApplication(None)) | 18:02 |
| srichter | I really do not want to have to worry about more | 18:02 |
| srichter | is that possible? | 18:03 |
| ignas | srichter, you should try that :) i think it works that way | 18:03 |
| mgedmin | srichter: yes | 18:03 |
| mgedmin | that's exactly what you do | 18:03 |
| srichter | cool | 18:03 |
| mgedmin | well, the Event class is named differently, IIRC | 18:03 |
| srichter | is that documented somewhere like that? | 18:03 |
| srichter | mgedmin: ok, I don't care about that bit. :-) | 18:03 |
| ignas | but i am afraid that you will have to provide the right datetime in UTC which is causing some problems at the moment | 18:03 |
| srichter | ok, no problem either | 18:03 |
| mgedmin | srichter: look at src/schooltool/app/booking.txt | 18:04 |
| srichter | as long as there is a document on how to add an event without knowing the entire package, then I am totally happy | 18:04 |
| th1a | I've assigned ignas the task of writing some more timezone-related documentation. | 18:04 |
| srichter | ok, will do | 18:04 |
| srichter | th1a: cool, that's great as well | 18:04 |
| th1a | So basically, at this point the calendar API doesn't handle the timezone correction itself, but whatever component is adding the even has to do it? | 18:05 |
| ignas | you have to deal with this only when you are converting user entered dates to datetime | 18:05 |
| mgedmin | th1a: the calendar API has an artificial constraint requiring all datetimes to be in UTC | 18:05 |
| mgedmin | so you have to do that | 18:05 |
| th1a | OK. | 18:06 |
| srichter | I think this constraint is not as bad as you make it sound | 18:06 |
| mgedmin | I didn't imply it was bad | 18:07 |
| ignas | if you are creating an abstract event on datetime.datetime.utcnow() - you only have to localize it to UTC | 18:07 |
| srichter | it is the same type of constraint as saying: all human-readable text must be unicode | 18:07 |
| mgedmin | I just wanted to say things would continue to work if it were removed | 18:07 |
| mgedmin | (unless there's something unexpected that I missed) | 18:07 |
| srichter | ok | 18:07 |
| ignas | srichter, you haven't seen the event grid on 04-02 (thew time you turn clocks) probably | 18:07 |
| mgedmin | (where by 'it' I meant the constraint) | 18:07 |
| mgedmin | yeah, DST transitions make hourly grids interesting | 18:08 |
| ignas | as well as recurring events | 18:08 |
| ignas | they start jumping | 18:08 |
| mgedmin | no they do not | 18:08 |
| mgedmin | that's the whole problem | 18:08 |
| mgedmin | ;) | 18:08 |
| ignas | yes they do :) | 18:08 |
| mgedmin | UTC does not have daylight savings | 18:08 |
| ignas | oh :) they look like they do jump to our users | 18:09 |
| mgedmin | so if you want 10 o'clock in your local time | 18:09 |
| mgedmin | when your local time jumps around | 18:09 |
| mgedmin | you're not going to get it | 18:09 |
| mgedmin | while we enforce storage in UTC | 18:09 |
| mgedmin | anyway, the back-end is solid | 18:10 |
| srichter | I think this is good; the view code or some adapter should handle the conversion | 18:10 |
| mgedmin | (unless you start thinking about all-day events interacting with various timezones) | 18:10 |
| srichter | for example, when America/New_york switches times, we go from EST to EDT | 18:10 |
| vmx | just a notice: at the moment i try to get allday events right. perhaps not the nicest solution (i've chatted with ignas and th1a about it), but a working one. i hope it'll be ready soon | 18:12 |
| th1a | vmx: We were bemoaning the lack of user contributions earlier, but we need to give you some credit. | 18:13 |
| * srichter notes that vmx is the first outside School* hacker :-) | 18:13 | |
| th1a | Pretty much. Except me. | 18:13 |
| th1a | And pcardune. | 18:13 |
| th1a | I guess there have been a few. | 18:13 |
| th1a | OK. Any other roadmap related questions? | 18:16 |
| th1a | I guess we can wrap up then. | 18:18 |
| th1a | Have a good week, folks. | 18:18 |
| * th1a bangs the virtual gavel. | 18:18 | |
| srichter | you too | 18:18 |
| vmx | if the meeting is over. i've a question. there's a comment in the source: | 18:21 |
| vmx | # XXX utc here is a bug, probably http://issues.schooltool.org/issue373 | 18:21 |
| vmx | but why wasn't it changed if it is a bug? | 18:21 |
| *** Aiste has quit IRC | 18:22 | |
| mgedmin | vmx: where in the source? | 18:22 |
| vmx | schooltool/app/browser/cal.py | 18:23 |
| vmx | approx: line 750 | 18:23 |
| vmx | i also think that start_dt = datetime.combine(start, time(tzinfo=utc)) is wrong, but why wasn't it changed to datetime.combine(start, time(tzinfo=self.timezone)) | 18:24 |
| vmx | i'm on the way on making some tests, just need to find some nice timezones to test with, first | 18:24 |
| mgedmin | http://source.schooltool.org/trac/browser/trunk/schooltool/src/schooltool/app/browser/cal.py#L711 | 18:25 |
| mgedmin | yes, that bit should not use UTC | 18:25 |
| *** jinty has joined #schooltool | 18:25 | |
| mgedmin | it wasn't changed because we did not have the time to do it yet | 18:26 |
| mgedmin | do it properly | 18:26 |
| *** th1a has quit IRC | 18:26 | |
| mgedmin | (write the test etc) | 18:26 |
| vmx | ah ok | 18:26 |
| mgedmin | ugh, getEvents uses dt.replace(tzinfo=self.timezone | 18:26 |
| mgedmin | another bug | 18:26 |
| vmx | where? | 18:26 |
| mgedmin | never ever use datetimeobj.replace(tzinfo=somethingelse) | 18:26 |
| mgedmin | it will not work properly | 18:27 |
| *** th1a has joined #schooltool | 18:27 | |
| ignas | with pytz | 18:27 |
| mgedmin | http://source.schooltool.org/trac/browser/trunk/schooltool/src/schooltool/app/browser/cal.py#L711 | 18:27 |
| *** Aiste has joined #schooltool | 18:28 | |
| ignas | date-util timezones will handle the "replace" semi properly, not 100% properly but like 99.967447916666671 % properly | 18:28 |
| vmx | ".replace()" is used quite often | 18:28 |
| ignas | but as we are using pytz | 18:29 |
| ignas | replace is never a good way to apply a timezone | 18:29 |
| ignas | you should use tzinfo.localize(dt) | 18:30 |
| vmx | i see "astimezone" very often in the source. what about that one? | 18:31 |
| mgedmin | it's good | 18:31 |
| mgedmin | the semantics is different | 18:31 |
| mgedmin | you use astimezone to convert, e.g. 14:30 UTC to 17:30 EEST | 18:31 |
| mgedmin | you use tz.localize to convert 14:30 "naive time" to 14:30 EEST | 18:32 |
| mgedmin | dt.replace() and datetime.combine() should raise a red flag | 18:32 |
| mgedmin | it is very easy to use them incorrectly | 18:32 |
| ignas | dt.replace() shoud be avoided when doing date arithmetic too | 18:33 |
| vmx | i use datetime.combine() for alldayevents, but perhpas tz.localize could be used | 18:33 |
| ignas | vmx, depends on why, where and how ... | 18:34 |
| vmx | although astimezone and all the others are used to often. there's an event.dtstarttz. that's (almost) all you need | 18:34 |
| *** faassen has joined #schooltool | 18:34 | |
| faassen | argh, sorry, I only remembered just now that the meeting was an hour ago. :( | 18:35 |
| vmx | ignas: we talked about the best way to handle all-day-events. i had again another idea | 18:36 |
| ignas | yes, i am listening | 18:36 |
| ignas | though, mgedimn advised just using timezoned datetime objects as arguments to the expand function | 18:37 |
| vmx | what about storing only the date in the database, and EventForDisplay sets dtstart of the event to 0:00 local time | 18:38 |
| vmx | that would be (almost) all | 18:38 |
| ignas | vmx, we must store only date, and why do we need dtstart 0:00 for allday events at all ? | 18:38 |
| ignas | dtstart with the time is there only for hysterical reasons :/ | 18:38 |
| *** pcardune has joined #schooltool | 18:39 | |
| vmx | sorry i ment you should set dtstarttz to 0:00 local time | 18:40 |
| vmx | ignas: yes but atm you can read very often things like "datetime.astimezone.date()" you just need to replace it with: | 18:40 |
| vmx | event.dtstarttz.date() at it'll work | 18:40 |
| vmx | you won't need to make a difference between alldayevents and normal one | 18:40 |
| *** pcardune has quit IRC | 18:40 | |
| vmx | datetime.astimezone.date() should be event.dtstart.astimezone.date() | 18:41 |
| vmx | i think it is ok to have no real difference between alldayevents and other ones if EventForDisplay was called | 18:42 |
| ignas | vmx, if i would not care about the interface for calendaring, i would do that, but we must keep the interface clean, what is the purpose of a datetime with 00:00 local time in an attribute for an allday event ? | 18:42 |
| ignas | EventForDisplay should be designed to cope with allday events not the other way around ... | 18:42 |
| *** pcardune has joined #schooltool | 18:42 | |
| pcardune | does anyone know if the schooltool.org server is down? I can't access the site | 18:43 |
| ignas | all day and normal events should provide a sane interface that enables implementing User interface, but should not be designed to work around incorrect behaviour of UI classes | 18:43 |
| ignas | that's why some minor bugs are taking more time to fix, we are trying to keep the whole thing maintainable and sane | 18:44 |
| jinty | pcardune: doesn't look like it from here | 18:44 |
| jinty | pcardune: but I am soon going to restart it. | 18:45 |
| vmx | ignas: then one would intruduce a new attribute and it will be fine? EventForDisplay cope with alldayevents. if you call it with an allday-event it will get a date and not a datetime. you will the convert it to datetime for much easier handling (and get event.dtstartz) | 18:46 |
| pcardune | jinty: ok | 18:46 |
| vmx | you will get much cleaner code this way | 18:46 |
| vmx | else you would always have problems with date vs. datetime | 18:47 |
| ignas | vmx, sorry, i can't visualize the change you have just proposed | 18:47 |
| ignas | introduce new attribute to what ? | 18:47 |
| vmx | ok :) | 18:47 |
| vmx | i'll start how i understood what you said | 18:48 |
| vmx | event.dtstart is wrong for alldayevents (as it is only a date and not a datetime) | 18:48 |
| vmx | i propose that dtstart is "abused" also for alldayevent dates | 18:49 |
| vmx | as you don't like it, one could also introduce a new attribute | 18:50 |
| vmx | which could then be named event.datestart. alldayevents would then have an empty dtstart, but a datestart | 18:50 |
| jinty | pcardune: should be back up | 18:51 |
| vmx | and i said that it doesn't make much sense introducing a new attribute, only because the name is wrong | 18:51 |
| jinty | pcardune: btw, whats up with the cando list at lists.schooltool.org? | 18:52 |
| jinty | pcardune: are you guys ever going to use it? | 18:52 |
| ignas | vmx, i am not proposing just plainly adding an attribute, this is not how interfaces are being *designed* | 18:55 |
| pcardune | jinty: we were going to use it, and I did use it a few times, but people seemed to despise the idea of having a mailing list, and nobody else ever used it | 18:55 |
| ignas | and IMHO your last sentence is completely 100% wrong | 18:56 |
| ignas | variables have names for a reason | 18:56 |
| pcardune | jinty: But I would still like to use it, and we will definitely need it in the future, so if it's not too much trouble to leave it around, I would appreciate that | 18:56 |
| vmx | ok, you're right | 18:56 |
| ignas | if there is a better name for a variable - you go and change all the instances of it, not put array of carrots into the variable named tuple_of_potatoes | 18:57 |
| jinty | pcardune: sure it's not a problem to leave it around, I only ask because there was only one post in the archives | 18:57 |
| vmx | ignas: ok you're really right. else the code will get very messy soon | 18:57 |
| pcardune | jinty: ok, thanks. | 18:57 |
| vmx | ignas: so a better name for dtstart would be start | 18:58 |
| vmx | as it was designed probalby no one thought about events without a time | 18:59 |
| mgedmin | yes | 18:59 |
| mgedmin | got it in one | 18:59 |
| vmx | of course start will ne UTC | 19:00 |
| vmx | what about an variable called "dtstartz". that would be the start but expanded to datetime if it isn't already | 19:00 |
| ignas | vmx, actually, i'd split EventFor Display into 2 different classes, one for allday events and another for normal events, and modify the UI code accordingly | 19:00 |
| vmx | or isn't it ok to have a "pseudo" time suddenly? | 19:00 |
| mgedmin | why do we need a datetime for displaying all-day events? | 19:00 |
| mgedmin | is it used anywhere? | 19:01 |
| vmx | mgedmin: atm it is used as the same code for all events is used | 19:01 |
| ignas | vmx, yes, that is my point - it is not ok to have a "pseudo" time | 19:01 |
| ignas | someone will use it as if it was normal time sooner or later ... | 19:02 |
| vmx | ignas: but it will be duplicated code | 19:02 |
| ignas | base classes are for such things as elimination of duplicate code, not "pseudo" time | 19:04 |
| vmx | or if's, what is even more ugly ;) | 19:05 |
| ignas | you put ifs first, then you see a pattern | 19:06 |
| ignas | then you refactor it | 19:06 |
| vmx | i just see the comment "We have date objects, but ICalendar.expand needs datetime objects" in the code | 19:06 |
| vmx | i think that's is the main problem, but that could be changed | 19:07 |
| vmx | as _getDays() doesn't really need datetime | 19:07 |
| vmx | i'll just take a look at the source again :) | 19:07 |
| vmx | a try to change it from scratch again | 19:08 |
| * jinty prays that when schooltool implements database packing that there is some kind of robust command line tool for this (In addition to a fancy TTW way) | 19:09 | |
| vmx | i've a question about the database behind everything. i haven't found the functions where the events really get stored and read out. where are they? | 19:10 |
| ignas | it's all ZODB magic | 19:10 |
| ignas | events inherit from Persistent | 19:10 |
| ignas | and are geting stored automagically when you add them to a calendar | 19:10 |
| ignas | while calendars get stored when you add them to persons/groups etc. | 19:11 |
| vmx | where would i e.g. define that event.start is sometimes date and the other times datetime? | 19:11 |
| ignas | you don't have to | 19:11 |
| vmx | so i have to have the right object time when the event gets added? | 19:14 |
| vmx | time=type | 19:14 |
| ignas | no | 19:14 |
| ignas | you can store bananas in there, ZODB handles everything | 19:15 |
| ignas | adding attributes is a bit different, you have to write evolution scripts that add these attributes to old instances | 19:16 |
| ignas | renaming attributes needs evolution scripts too | 19:16 |
| ignas | but if you will write a working patch that will pas mgedmin's code review process - we will write these ourselves | 19:16 |
| vmx | ok, that's a deal :) | 19:18 |
| vmx | i still don't understand how event.start will be date on alldayevents and datetime on normal ones? | 19:19 |
| th1a | jinty: How much did the database pack? | 19:19 |
| jinty | 400MB -> 90 MB | 19:20 |
| jinty | but that was still worse than th log file, which was at 800MB before i started rotating it;) | 19:20 |
| ignas | vmx, i'd probably split the class, and try to make sure no one ever gets allday events and simple events together unless he is using only their common interface ... | 19:21 |
| ignas | but i don't really have the time to design anything, or work on it at the moment | 19:22 |
| vmx | ignas: just to be sure i've understood everything. will there be 2 interfaces like ICalendarEvent and ICalnedarAllDayEvent? or 2 different implemnetations of the event interface? or something different? | 19:28 |
| ignas | I don't know now, sorry, when it comes to core classes i like discussing posible solutions wiht mgedmin or alga for some time on the whiteboard, before settling with one of the ideas, because there are a lot of variables to consider ... | 19:32 |
| ignas | the elegance of the solution, the elegance of the resulting implementation, evolution scripts etc. | 19:32 |
| ignas | and most of the time they have good ideas, or spot various shorcomings in my ideas ... | 19:33 |
| ignas | vmx, i'd just say - use your judgement, and do your best ... | 19:34 |
| vmx | ok. so there isn't really anything i can do atm? so i'll probably start to hack the look of the weekview a bit | 19:34 |
| ignas | if you will do a good job, we will apply the patch | 19:34 |
| vmx | i think i haven't enough background information to do it | 19:34 |
| vmx | and i'm not a good enough in oop | 19:35 |
| ignas | oh, by the way - even a less than perfect patch will be usefull, as we can gather only the usefull bits out of it ... | 19:35 |
| vmx | i could also write some tests, as i know some of the problems | 19:36 |
| ignas | vmx, i'd recomend http://www.amazon.com/gp/product/0201485672/103-3371354-6291814?v=glance&n=283155 to fix that | 19:36 |
| ignas | vmx, that would be nice too, a bug report with a failing test case is 100 times better than just a bug report | 19:36 |
| vmx | it'll get better soon as next term i'll have a course about software engeneering :) | 19:38 |
| vmx | thanks for the book recommandation | 19:38 |
| vmx | as the calendar development is on hold i assume there won't be much discussions about it | 19:41 |
| ignas | probably, unless i'll decide to fix some stuff on weekends (1 in 10 chance of that happening :/) | 19:42 |
| vmx | np, i can understand that. if there are different priorities, one can't do much about it | 19:43 |
| vmx | ok, i g2g. it was a nice chat, thanks for the time | 19:50 |
| *** Aiste has quit IRC | 19:51 | |
| *** jinty has quit IRC | 20:35 | |
| *** jinty has joined #schooltool | 20:38 | |
| *** faassen has quit IRC | 20:57 | |
| *** thisfred has quit IRC | 21:20 | |
| *** jinty has quit IRC | 21:52 | |
| *** ignas has quit IRC | 22:15 | |
| *** mgedmin has quit IRC | 23:10 | |
| *** flint has joined #schooltool | 23:57 | |
| flint | good afternoon paul... | 23:57 |
| pcardune | hi flint | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!