| *** admp has joined #schooltool | 00:34 | |
| *** tvon has quit IRC | 01:03 | |
| *** tvon has joined #schooltool | 01:03 | |
| *** admp has quit IRC | 02:15 | |
| *** tvon has quit IRC | 07:32 | |
| *** tvon has joined #schooltool | 07:37 | |
| *** povbot` has joined #schooltool | 09:18 | |
| *** povbot has quit IRC | 09:18 | |
| *** dman13_ has quit IRC | 10:50 | |
| *** Ricey_ has quit IRC | 10:50 | |
| *** munkee has quit IRC | 10:50 | |
| *** srichter has quit IRC | 10:50 | |
| *** srichter has joined #schooltool | 10:51 | |
| *** povbot has joined #schooltool | 10:51 | |
| *** orwell.freenode.net sets mode: +n | 10:51 | |
| *** povbot has joined #schooltool | 10:54 | |
| *** povbot has joined #schooltool | 10:57 | |
| *** tvon has joined #schooltool | 10:57 | |
| *** dman13 has joined #schooltool | 11:01 | |
| *** povbot has joined #schooltool | 11:05 | |
| *** auxesis_ has quit IRC | 11:30 | |
| *** auxesis has joined #schooltool | 11:32 | |
| *** Ricey has joined #schooltool | 11:55 | |
| *** jinty has joined #schooltool | 12:13 | |
| *** gintas has joined #schooltool | 12:19 | |
| *** admp_ has joined #schooltool | 13:11 | |
| *** admp_ has left #schooltool | 13:11 | |
| *** bskahan has joined #schooltool | 13:20 | |
| povbot | /svn/commits: * gintas committed revision 4586: | 13:31 |
|---|---|---|
| povbot | /svn/commits: Mention gettext in README.txt, wording fix (to be backported). | 13:31 |
| povbot | /svn/commits: * gintas committed revision 4587: | 13:31 |
| povbot | /svn/commits: Cosmetic fix. | 13:31 |
| povbot | /svn/commits: * gintas committed revision 4588: | 13:32 |
| povbot | /svn/commits: Mention gettext in README (should be backported). | 13:32 |
| povbot | /svn/commits: * gintas committed revision 4589: | 13:34 |
| povbot | /svn/commits: Backported revision 4588. | 13:34 |
| povbot | /svn/commits: * gintas committed revision 4590: | 13:35 |
| povbot | /svn/commits: Backported revision 4586. | 13:35 |
| *** bskahan has quit IRC | 13:39 | |
| *** povbot has joined #schooltool | 13:47 | |
| povbot | /svn/commits: * gintas committed revision 4591: | 13:47 |
| *** srichter has joined #schooltool | 13:47 | |
| povbot | /svn/commits: Backported revisions 4580, 4581, 4584. | 13:47 |
| *** tvon has joined #schooltool | 13:48 | |
| povbot | /svn/commits: * gintas committed revision 4592: | 13:48 |
| povbot | /svn/commits: Backported revision 4582. | 13:48 |
| *** Ricey has quit IRC | 13:49 | |
| *** dman13 has quit IRC | 13:49 | |
| *** jinty has quit IRC | 13:49 | |
| *** auxesis has quit IRC | 13:49 | |
| *** auxesis has joined #schooltool | 13:49 | |
| *** jinty has joined #schooltool | 13:49 | |
| *** jinty has quit IRC | 13:54 | |
| *** tvon has quit IRC | 13:54 | |
| *** gintas has quit IRC | 13:54 | |
| *** munkee has quit IRC | 13:54 | |
| *** auxesis has quit IRC | 13:54 | |
| *** Ricey has joined #schooltool | 13:54 | |
| *** dman13 has joined #schooltool | 13:54 | |
| *** jinty has joined #schooltool | 13:54 | |
| *** auxesis has joined #schooltool | 13:54 | |
| *** tvon has joined #schooltool | 13:54 | |
| *** gintas has joined #schooltool | 13:54 | |
| *** munkee has joined #schooltool | 13:54 | |
| *** jinty has quit IRC | 13:55 | |
| *** dman13 has quit IRC | 13:55 | |
| *** munkee has quit IRC | 13:55 | |
| *** gintas has quit IRC | 13:55 | |
| *** tvon has quit IRC | 13:55 | |
| *** auxesis has quit IRC | 13:55 | |
| *** dman13 has joined #schooltool | 13:56 | |
| *** jinty has joined #schooltool | 13:56 | |
| *** auxesis has joined #schooltool | 13:56 | |
| *** tvon has joined #schooltool | 13:56 | |
| *** gintas has joined #schooltool | 13:56 | |
| *** munkee has joined #schooltool | 13:56 | |
| povbot | /svn/commits: * jinty committed revision 4593: | 14:10 |
| povbot | /svn/commits: Create a small i18nextract.py for schoolbell. | 14:10 |
| povbot | /svn/commits: * jinty committed revision 4594: | 14:11 |
| povbot | /svn/commits: Use local i18nextract.py rather than the Zope3 one. | 14:11 |
| jinty | hoi gintas: could you commit some translations for me? | 14:28 |
| jinty | otherwise I had a good look at the packaging work you did, it all looks good. | 14:30 |
| *** ignas has joined #schooltool | 14:32 | |
| povbot | /svn/commits: * gintas committed revision 4595: | 14:46 |
| povbot | /svn/commits: Allow access to items() if we allow access to keys() and values(). | 14:46 |
| *** bskahan has joined #schooltool | 15:18 | |
| *** bskahan has quit IRC | 15:24 | |
| *** mgedmin has joined #schooltool | 15:27 | |
| *** ignas has quit IRC | 15:28 | |
| *** ignas_ has joined #schooltool | 15:28 | |
| *** bskahan has joined #schooltool | 15:32 | |
| *** jinty has quit IRC | 15:36 | |
| *** th1a has joined #schooltool | 15:47 | |
| th1a | Jennifer is taking a nap, so I'm at POV for another hour or so. | 15:48 |
| srichter | ok, I am here | 15:51 |
| srichter | we could start now | 15:52 |
| th1a | We could, but this would be 40 minutes early, right? | 15:52 |
| srichter | yes, who is not here? | 15:52 |
| povbot | /svn/commits: * gintas committed revision 4596: | 15:53 |
| povbot | /svn/commits: Removed unused imports. | 15:53 |
| * tvon yawns | 15:57 | |
| srichter | bskahan: are you already here? | 15:57 |
| povbot | /svn/commits: * gintas committed revision 4597: | 15:58 |
| povbot | /svn/commits: Fixed a i18n deprecation warning. This is already fixed in trunk. | 15:58 |
| povbot | /svn/commits: * tvon committed revision 4598: | 15:58 |
| povbot | /svn/commits: unused import | 15:58 |
| bskahan | hello | 16:03 |
| povbot | /svn/commits: * gintas committed revision 4599: | 16:03 |
| povbot | /svn/commits: Removed svn:externals tag from schooltool release branch. I know that it is smart, trendy and politically correct to have it there but it gets in the way a lot and slows me down. | 16:03 |
| srichter | th1a: if you can collect all the POV developers, I think everyone is here now | 16:04 |
| gintas | I'm here | 16:04 |
| * mgedmin too | 16:04 | |
| tvon | ignas_, mgedmin: ping | 16:04 |
| th1a | OK. | 16:04 |
| srichter | someone needs to poke alga | 16:04 |
| gintas | he's on holiday | 16:05 |
| povbot | /svn/commits: * gintas committed revision 4600: | 16:05 |
| srichter | ah, ok; unpoke alga | 16:05 |
| povbot | /svn/commits: Removed svn:externals tag from SchoolBell release branch. I know that it is smart, trendy and politically correct to have it there but it gets in the way a lot and slows me down. | 16:05 |
| th1a | I hope everyone saw the Lithuanian discus thrower take the world championship yesterday with a dramatic 70 meter toss on the last throw of the competition. | 16:05 |
| gintas | I didn't | 16:06 |
| * bskahan wonders if that was on ESPN2 | 16:06 | |
| th1a | Probably. | 16:06 |
| srichter | oh, my dad told me the world chamionship is going on, but I could not find the US coverage | 16:06 |
| th1a | OK. Thanks to gintas for going through the bug tracker. | 16:06 |
| * bskahan agrees | 16:07 | |
| gintas | heh | 16:07 |
| * srichter claps (he knows how painful it is) | 16:07 | |
| gintas | I don't get notifications about my own changes, so I always am a bit surprised that people notice | 16:07 |
| th1a | I was thinking that one of Etria's stories covered issue 240, but now I'm thinking that it actually didn't. | 16:07 |
| th1a | That is, we hid actions that the user can't undertake, but didn't hide object he can't see? | 16:08 |
| bskahan | right | 16:08 |
| th1a | OK. That'll have to wait 'til later then. | 16:09 |
| th1a | I'm going to see if issue 318 is fixed. | 16:09 |
| bskahan | thanks | 16:10 |
| th1a | What else needs to be checked/fixed? | 16:11 |
| bskahan | issue325 | 16:11 |
| * mgedmin roots for 319 | 16:11 | |
| bskahan | gintas pointed out that it needs a generation for upgrades | 16:11 |
| bskahan | I'll do that today | 16:12 |
| gintas | ok | 16:12 |
| bskahan | other than the need for a generation is everyone ok with r4579? | 16:13 |
| bskahan | it means that all new containers will have to be explicitly restricted | 16:13 |
| th1a | OK. 318 fixed. | 16:13 |
| tvon | bskahan: arent containers returned by __iter__ or something along those lines? | 16:14 |
| tvon | bskahan: meaning, I don't think they need to be explicitly named | 16:14 |
| gintas | bskahan, I think you could do it by 'exclusion' rather than 'inclusion' | 16:14 |
| gintas | that is, restrict all containers except public ones | 16:15 |
| bskahan | gintas: ok, good point | 16:15 |
| th1a | mgedmin: I'm not sure that we need to spend much time on 319 right now, if nothing is actually broken, because it looks like the next thing you guys are going to do is resolve the SB/ST clashes once and for all. | 16:15 |
| gintas | th1a, I sure hope we do | 16:16 |
| bskahan | tvon: not sure I follow | 16:16 |
| th1a | We need to explicitly test upgrades from the previous version at some point prior to release. | 16:16 |
| gintas | right | 16:16 |
| th1a | i.e., someone has to be responsible for testing upgrades. | 16:16 |
| * bskahan nods | 16:16 | |
| gintas | would that be me? | 16:16 |
| th1a | Perhaps the release manager :-) | 16:16 |
| tvon | bskahan: I think you can iter over the containers in an app, so you don't need to name the containers you are restricting | 16:16 |
| srichter | maybe we can automate this | 16:16 |
| srichter | what we really need to test for is data integrity | 16:17 |
| bskahan | having sample data will make testing upgrades easier | 16:17 |
| th1a | In case you were wondering if the POV guys talk to each other a lot during these meetings, so far, the answer is 'no.' | 16:17 |
| srichter | I think this could be done using an old data.fs with test data and run it on the new version | 16:17 |
| bskahan | heh | 16:17 |
| srichter | and then check whether all object loaded and all screens work | 16:17 |
| th1a | srichter: Yes, in the long run this should definitely be automated. | 16:18 |
| th1a | Upgrades are a constant issue in this kind of apps. | 16:18 |
| th1a | There were Blackboard upgrades that were legendary clusterfucks. | 16:19 |
| bskahan | ideally it could be hooked up to run the ftests set, upgrade, then run the ftests again | 16:19 |
| srichter | something like that | 16:19 |
| srichter | I think this could be even setup as a buildbot | 16:19 |
| th1a | Well, I'll add upgrade testing to the things to discuss on Wednesday. | 16:19 |
| mgedmin | if someone creates a data.fs with extensive sample data for a specific version of schooltool/bell, and wants to add it to svn somewhere, +5 for that idea | 16:20 |
| srichter | that would be the first step, yes, +1 from me too | 16:20 |
| th1a | Well, I think we're also going to discuss more serious sample data generation on Wednesday, too. | 16:21 |
| th1a | We'd better get back to issues with the current release. | 16:21 |
| gintas | I'm worried about John Baillie's problem | 16:21 |
| gintas | it sounds like a serious bug | 16:21 |
| th1a | Philipp sent a bug with pdf generation to the list. | 16:21 |
| gintas | I know, that shouldn't be too bad | 16:22 |
| gintas | looks like there's a security declaration missing somewhere in schooltool | 16:22 |
| gintas | but Baillie's is trickier | 16:22 |
| gintas | I think it's caused by events shared from several calendars | 16:22 |
| gintas | (a design decision that I now regret a lot) | 16:23 |
| bskahan | gintas: have you been able to recreate that bug? | 16:24 |
| th1a | gintas: How do you know what's causing John's bug? | 16:24 |
| bskahan | he's not upgrading, as far as I understand. He's using a new data.fs so we should be able to get the same error | 16:25 |
| gintas | I think I had experienced the same problem some time ago | 16:25 |
| mgedmin | what are you talking about? is there an issue in the tracker? | 16:25 |
| bskahan | mgedmin: its a mail to the list | 16:25 |
| bskahan | from 2005.08.05 | 16:26 |
| th1a | I think he might not really have deleted Data.fs. | 16:26 |
| gintas | hmm, it looks like he sent his reply to me personally | 16:26 |
| th1a | Ah. Could you forward it? | 16:26 |
| gintas | sure | 16:26 |
| mgedmin | Message-ID: <42F4125F.90607@stmarys-school.org> ? | 16:27 |
| bskahan | mgedmin: Subject: [schooltool] School Bell on K12LTSP-EL | 16:28 |
| bskahan | yeah, that's it | 16:28 |
| *** Aiste has joined #schooltool | 16:29 | |
| th1a | Can anyone replicate that? | 16:30 |
| * mgedmin running svn up on his school* sandboxes | 16:30 | |
| * mgedmin thinks it will take a while | 16:30 | |
| gintas | ouch | 16:33 |
| gintas | looks like I found another bug on the way | 16:33 |
| th1a | Yipes, the event add form seems broken on Safari. | 16:34 |
| th1a | Given that I have no submit button... | 16:34 |
| bskahan | gintas: did you get a traceback in the overlay portlet? | 16:37 |
| gintas | yeah | 16:37 |
| bskahan | same here | 16:37 |
| tvon | where? | 16:37 |
| gintas | line 199 of overlay.py is wrong | 16:37 |
| gintas | I think there should be an attribute access, not a getitem | 16:38 |
| gintas | I smell a unit test gap | 16:38 |
| gintas | OK, I'll try the same thing with the release branch | 16:39 |
| gintas | hopefully we don't have such a bug there | 16:39 |
| gintas | anyway, we don't have to settle this during the meeting | 16:40 |
| gintas | I'll fix it | 16:40 |
| th1a | I'm trying to upload a screenshot of the form in Safari, but iPhoto decided to stop working. | 16:40 |
| bskahan | th1a: email it to me? | 16:41 |
| tvon | mgedmin: did you do anything when schooltool when you were playing with javascript unit tests? | 16:41 |
| bskahan | please | 16:41 |
| * tvon tries to figure out when main.py calls app.setSiteManager | 16:42 | |
| mgedmin | tvon, as far as I know schooltool has no unit tests for javascript | 16:42 |
| mgedmin | (I hope I understood your question) | 16:42 |
| * mgedmin suggests entering all known bugs to the issue tracker, if they are not already there | 16:43 | |
| gintas | ok, we do have the same problem in the release branch | 16:45 |
| gintas | I'll add an issue | 16:45 |
| * mgedmin doesn't know which problem gintas is talking about, and is feeling generally lost and confused | 16:45 | |
| gintas | the one that causes the traceback | 16:47 |
| tvon | mgedmin: reading back, my question made no sense | 16:47 |
| gintas | http://issues.schooltool.org/issue328 | 16:47 |
| * mgedmin thinks gintas is making fun of him | 16:48 | |
| tvon | woah | 16:48 |
| tvon | gintas: you get that when submitting the overlay selection form? | 16:48 |
| mgedmin | the release branch breaks 'svn co $URL $DIR && cd $DIR && make test ftest' | 16:48 |
| mgedmin | which exactly version of Zope 3 does it depend on? | 16:49 |
| gintas | tvon, yes | 16:49 |
| tvon | odd, I dont | 16:49 |
| mgedmin | (a URL that I could check out would be best) | 16:49 |
| th1a | OK, I need to speak to the POV people offline for a second before I go. | 16:50 |
| bskahan | tvon: happens here on svn trunk | 16:50 |
| tvon | is this new? | 16:50 |
| bskahan | tvon: its from r4418 I would guess | 16:51 |
| tvon | well 199 is indeed wrong, I don't get the error though | 16:52 |
| th1a | OK, we're back. | 16:52 |
| * mgedmin is sitting here twiddling his thumbs, waiting for an answer | 16:53 | |
| gintas | mgedmin, I removed the externals because they were a huge pain the ass | 16:53 |
| mgedmin | gintas, thanks a lot | 16:53 |
| gintas | pain in the ass | 16:53 |
| tvon | er, "line 199 in browser.overlay" | 16:53 |
| mgedmin | gintas, so gimme the url already! | 16:53 |
| th1a | Philipp just added an issue for his pdf bug as issue 330. | 16:53 |
| th1a | Who can take care of that. | 16:53 |
| th1a | ? | 16:53 |
| gintas | you want Zope 3 trunk rev 37654 | 16:53 |
| tvon | bskahan: as a user or manager? | 16:54 |
| gintas | th1a, I think I'll take care of it | 16:54 |
| bskahan | tvon: user | 16:54 |
| mgedmin | gintas, not the 3.1 branch? | 16:54 |
| gintas | mgedmin, no | 16:54 |
| mgedmin | what's happening with 3.1 by the way? | 16:54 |
| gintas | but they differ very little | 16:54 |
| mgedmin | how do they differ and why don't we want 3.1? | 16:54 |
| srichter | gintas: why do we want this particular revision? | 16:54 |
| srichter | we should really rely on the 3.1 branch for the release | 16:54 |
| th1a | There is no reason to think the 3.1 branch wouldn't work, right? | 16:55 |
| srichter | its a recipe for disaster to rely on this particular revision | 16:55 |
| gintas | why? | 16:55 |
| srichter | because you can never rely on bug fixes on the 3.1 branch | 16:55 |
| srichter | btw, the trunk uses the 3.1 branch and all tests pass | 16:55 |
| gintas | as I said, they're almost the same at the moment | 16:56 |
| th1a | OK. I'm going to pack up. I'll be back on Wednesday. | 16:56 |
| mgedmin | I'll go with the branch then | 16:56 |
| mgedmin | th1a, see you later! | 16:56 |
| th1a | Bye. | 16:56 |
| srichter | I made a bunch of fixes on the 3.1 branch that the SchoolBell (and later SchoolTool) trunk relies on | 16:57 |
| *** th1a has quit IRC | 16:57 | |
| gintas | srichter, are they pertinent to SB 1.2? | 16:58 |
| gintas | I branched before the trunk was bound to 3.1 | 16:58 |
| srichter | no, not to the release I think | 16:58 |
| srichter | right | 16:58 |
| srichter | so it might be ok | 16:58 |
| gintas | I don't really mind switching | 16:59 |
| srichter | I guess we will just do another release when we notice some 3.1 bug/security fix is needed | 16:59 |
| tvon | is anyone slated (in the z3 world) to make debian packages for 3.1? | 17:01 |
| *** FarcePest has joined #schooltool | 17:01 | |
| gintas | there's zope3-lib 3.0.91 in breezy | 17:02 |
| bskahan | tvon: there's an ubuntu goal | 17:02 |
| srichter | well, there is a commitment by a group of Zope Debian packagers | 17:02 |
| gintas | I suppose that this will become 3.1 eventually | 17:02 |
| *** jinty has joined #schooltool | 17:02 | |
| gintas | hi jinty | 17:02 |
| gintas | you wanted me to commit some translations, right? | 17:02 |
| *** dman13 has quit IRC | 17:03 | |
| jinty | yep | 17:05 |
| jinty | they are in debian bugs http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=317897 | 17:06 |
| jinty | 317899 | 17:06 |
| jinty | 319589 | 17:06 |
| *** SteveA has joined #schooltool | 17:06 | |
| jinty | would do it myself, but... | 17:07 |
| povbot | /svn/commits: * jinty committed revision 4601: | 17:08 |
| povbot | /svn/commits: Extract translations in setup.py rather than using Zope3/utilities/i18nextract.py. | 17:08 |
| povbot | /svn/commits: * jinty committed revision 4602: | 17:13 |
| povbot | /svn/commits: oops! | 17:13 |
| tvon | browser.overlay:199 isn't wrong | 17:13 |
| povbot | /svn/commits: * jinty committed revision 4603: | 17:17 |
| povbot | /svn/commits: Make building Zope3 conditional on there being a Zope3 directory. It should now be possible to delete the Zope3 external in schoolbell and only have zope on the python path. | 17:17 |
| tvon | nice | 17:17 |
| *** bska|mobile has joined #schooltool | 17:26 | |
| *** bskahan has quit IRC | 17:30 | |
| jinty | aaargh! | 17:32 |
| povbot | /svn/commits: * gintas committed revision 4604: | 17:32 |
| povbot | /svn/commits: Forced some rm's to avoid error messages in output when files don't exist. | 17:32 |
| gintas | tvon, sorry for the rushed conclusion | 17:33 |
| gintas | I'll try and look around using pdb | 17:33 |
| tvon | gintas: np, problem is related | 17:33 |
| tvon | gintas: bskahan and I figured it out over jabber | 17:33 |
| gintas | oh | 17:33 |
| gintas | will you fix it today? | 17:34 |
| tvon | yeah | 17:34 |
| gintas | excellent | 17:34 |
| srichter | a UI detail I just noticed is that the active action should be highlighted | 17:36 |
| tvon | srichter: yeah | 17:36 |
| bska|mobile | afk a bit | 17:37 |
| *** bska|mobile has quit IRC | 17:37 | |
| gintas | by the way, issue 329 (event add form broken on Safari) should really be fixed | 17:41 |
| tvon | lets see if konq reproduces it... | 17:41 |
| tvon | ... | 17:42 |
| tvon | kde apps take forever to fire up in gnome | 17:42 |
| srichter | because they have to lead all the libs | 17:42 |
| tvon | and start all sorts of lil daemon thingies | 17:43 |
| srichter | I suggest running KDE; much nicer anyways ;-) | 17:43 |
| tvon | aha! I knew there was something different about you | 17:43 |
| tvon | oh wow, we have the page footer in ther footer of the event add form here | 17:43 |
| * srichter is probably one of the langest KDE users; since 0.9 ... | 17:44 | |
| * mgedmin considers starting a GNOME vs KDE flame war for a moment, then drops the idea | 17:44 | |
| tvon | hehe | 17:44 |
| srichter | he he | 17:46 |
| tvon | my first linux desktop was kde 1.x.. I think on RH 5 | 17:48 |
| tvon | not counting fvwm in the school labs... that was solaris anyways | 17:49 |
| povbot | /svn/commits: * gintas committed revision 4605: | 17:57 |
| povbot | /svn/commits: Added Vietnamese translation. | 17:57 |
| srichter | mgedmin: why is the schooltool skin set with a traversal hook? | 18:02 |
| srichter | wouldn't it be better to just make the ST/SB skin the default one? | 18:03 |
| povbot | /svn/commits: * gintas committed revision 4606: | 18:03 |
| povbot | /svn/commits: Added Vietnamese debconf translation for SchoolTool. | 18:03 |
| mgedmin | srichter, we have a (probably ill-considered) use case when the user adds a SchoolToolApplication from the ZMI in a random Zope folder | 18:05 |
| srichter | so, in those cases the ST will not be set as defualt skin | 18:05 |
| mgedmin | in those cases we need the traversal hook | 18:06 |
| srichter | and the user has to either manually add it or specify it in the URL | 18:06 |
| mgedmin | I do not understand what you're saying | 18:06 |
| srichter | but this effectively turns off the skin the user wants to use | 18:06 |
| srichter | well, I think the traversal hook is bad for two reasons: | 18:07 |
| srichter | (1) it basically ignores the user's desires to have a certain skin | 18:07 |
| srichter | (2) it prohibits the user to use a different skin for ST/SB | 18:08 |
| srichter | and for my use case: | 18:08 |
| srichter | (3) the ST/SB skin is not activated outside of the ST/SB instance, which is bad, if you want to integrate other objects (such as the error utility) in the app | 18:09 |
| srichter | my problem, I think, can be solved by making the SB/ST skin the default skin in the standalone server | 18:10 |
| srichter | (and for the ftests of course) | 18:10 |
| mgedmin | I disagree on all three counts :) | 18:10 |
| srichter | mgedmin: over; thoughts? | 18:10 |
| srichter | he he | 18:11 |
| mgedmin | I do not think that the ability to have different skins is important at this point for ST | 18:11 |
| mgedmin | I think that having the user specify ++skin++whatever in URLs is an ugly wart | 18:11 |
| gintas | jinty, I applied the translations | 18:11 |
| srichter | of course, I never said to use ++skin++ | 18:11 |
| mgedmin | I think that Zope 3 plumbing such as error utilities is an internal plumbing detail that does not matter for a typical ST user | 18:12 |
| srichter | so we use the defaultSkin directive | 18:12 |
| srichter | mgedmin: well, it matters in developer mode | 18:12 |
| mgedmin | besides, if an ST instance is a site, then the error utility within it will be skinned with the ST skin | 18:12 |
| srichter | I mean, the error reporting works great on the standalone server | 18:12 |
| srichter | but I cannot test this, because in the ftests I don't have a standalone server and thus the skin is not chosen | 18:13 |
| mgedmin | eh? | 18:13 |
| mgedmin | are you talking about ST's custom error pages? | 18:13 |
| mgedmin | or the standard zope 3 error reporting utility? | 18:13 |
| mgedmin | I believe ST's custom skinned error pages are functionally tested | 18:14 |
| srichter | error reporting utility | 18:14 |
| mgedmin | ok | 18:14 |
| mgedmin | two things | 18:14 |
| srichter | I basically registered two menu items in schoolbell_actions | 18:15 |
| mgedmin | 1. I think it is wrong if my adding of a ST instance in a folder suddenly changes the skin of a utility that is not within the ST instance | 18:15 |
| tvon | Note that some of these issues will be less of a problem once we get moved to pagelets and finish the long-running UI work | 18:15 |
| tvon | I think... | 18:15 |
| srichter | in the standalone server they show up, because the SchoolBell app is the root site | 18:15 |
| mgedmin | 2. you can add an ST instance, make it a site, then go to /my_st/++etc++site/...utility in a ftest | 18:16 |
| mgedmin | how important is the "add ST as an object in a random Zope 3 instance" use case? | 18:16 |
| mgedmin | I'd like to drop it if I can get away with it | 18:16 |
| mgedmin | however then we'll have to somehow rework our ftests | 18:17 |
| srichter | I think it is dead0unimportant | 18:17 |
| srichter | I think it is dead-unimportant | 18:17 |
| mgedmin | Jim talked about some improvements for the Z3 test runner | 18:17 |
| mgedmin | that would let us use different ftesting.zcml's for different packages | 18:17 |
| srichter | yes, it can definitely be done with the new level support | 18:17 |
| mgedmin | in that case we could have a zcml that corresponds to our standalone server | 18:17 |
| srichter | yep | 18:17 |
| mgedmin | drop the traversal subscriber and use defaultSkin | 18:18 |
| srichter | right | 18:19 |
| srichter | mgedmin: on a totally different topic, we should move all ftests to testbrowser ASAP ;-) | 18:20 |
| gintas | hmm, I remembered just now that we did not touch the SB/ST split at all during the meeting | 18:21 |
| povbot | /svn/commits: * gintas committed revision 4607: | 18:22 |
| povbot | /svn/commits: Cosmetic fixes. | 18:22 |
| srichter | gintas: yep :-( | 18:23 |
| srichter | mgedmin: gintas: do you guys have time/want to discusss it now? | 18:23 |
| gintas | I could spare some time, dunno about mgedmin | 18:24 |
| * mgedmin is packing a bunch of zope data.fs'es to free up some disk space on a server | 18:24 | |
| mgedmin | I can multitask | 18:24 |
| srichter | ok | 18:24 |
| mgedmin | my original vision was to have schoolbell.app and schooltool completely separate | 18:24 |
| mgedmin | two different apps assembled from shared components | 18:25 |
| mgedmin | the vision proved to be too utopic | 18:25 |
| gintas | that's why we call these things visions | 18:25 |
| gintas | ;) | 18:25 |
| mgedmin | thus now we have the strange tangle | 18:25 |
| srichter | yep | 18:25 |
| mgedmin | full of inheritance and duplication | 18:25 |
| *** SteveA has quit IRC | 18:25 | |
| srichter | so I would suggest making SchoolBell a specific instance of SchoolTool | 18:25 |
| mgedmin | I'm not certain how merging ST/SB would make things simpler | 18:26 |
| mgedmin | how do you remove the unnecessary things? | 18:26 |
| srichter | they are shared then | 18:26 |
| tvon | So instead of ST being SB with extra bits bolted on, SB would be ST with less bits added? | 18:26 |
| srichter | yes | 18:26 |
| srichter | basically you take the feature-richer app and just don't provide all the features | 18:27 |
| gintas | the conversion could be very messy | 18:27 |
| mgedmin | I do not understand | 18:27 |
| srichter | and basically apply a different skin | 18:27 |
| gintas | right now we use layers to override all kinds of stuff | 18:27 |
| mgedmin | how exactly do you "not provide all the features"? | 18:27 |
| srichter | for example: | 18:27 |
| mgedmin | hide views in a skin? | 18:27 |
| srichter | don't even register superfluous views | 18:28 |
| srichter | but for example: | 18:28 |
| srichter | ST has levels | 18:28 |
| srichter | SB does not | 18:28 |
| srichter | so, we have the levels in a special package called "levels" | 18:29 |
| srichter | in SB we simply do not distribute this package | 18:29 |
| srichter | and nothing will happen | 18:29 |
| srichter | the only obstacle here is that we need to make the SB/ST app initialization more flexible | 18:29 |
| srichter | by creating those sub-containers (persons, groups, ...) with adapters (factories) | 18:30 |
| srichter | if we make sufficient use of the CA, then I think we can very effectively merge the two | 18:31 |
| gintas | still sounds like a lot of trouble to me | 18:31 |
| srichter | (I never said it would be easy) | 18:31 |
| srichter | but it is definitely worth it | 18:32 |
| mgedmin | how is it different from what we have now? | 18:32 |
| srichter | the current situation is just insane! | 18:32 |
| srichter | a lot less code duplication | 18:32 |
| gintas | where in particular would you see big wins in reducing redundancy? | 18:33 |
| gintas | backend? views? initialization routines? | 18:33 |
| srichter | everywhere | 18:34 |
| srichter | all accross the board | 18:34 |
| srichter | (less for views, because there are specifics for each app, which is understandable) | 18:34 |
| mgedmin | so you want to have one source tree | 18:34 |
| mgedmin | and a bunch of zpkg config files | 18:34 |
| srichter | yes | 18:34 |
| srichter | yes | 18:34 |
| mgedmin | and then produce ST by taking everything, and produce SB by taking a subset of Python packages | 18:35 |
| srichter | and in src/schooltool a package called "sbapp" that contains only some of the specific view stuff | 18:35 |
| srichter | yes | 18:35 |
| srichter | it's basically the difference between distributing zope.component versus Zope 3, the app | 18:36 |
| srichter | or simple Zope 3 app and zwiki, including everything | 18:36 |
| srichter | here is an example of the worst case code duplication that will drive a third party developer insane: | 18:36 |
| srichter | what is the difference between sb.app.interfaces.IPerson and st.interfaces.IPerson? | 18:37 |
| mgedmin | extra attributes, IIRC | 18:37 |
| gintas | one is a subset of another | 18:37 |
| srichter | One single ITimetabled inherited interface! | 18:37 |
| mgedmin | sb's persons have no timetables | 18:37 |
| mgedmin | so if you do not include the timetabling package in SB, what happens with IPerson? | 18:38 |
| mgedmin | does it have an attribute for storing timetables that never can be used? | 18:38 |
| srichter | would be one solution | 18:38 |
| mgedmin | what about absence tracking, or grades, or other things? | 18:38 |
| mgedmin | (once we add them) | 18:38 |
| mgedmin | SB won't have any of those things, ST will | 18:38 |
| srichter | another would be to make this part of the implementation | 18:39 |
| srichter | right, they are simply disabled | 18:39 |
| mgedmin | how do you disable an attribute? | 18:39 |
| srichter | they should not be attributes in the first place | 18:39 |
| mgedmin | what should they be then? | 18:39 |
| mgedmin | annotations? adapters? | 18:39 |
| srichter | attributes should only describe the core data that is independent of the environemnt | 18:39 |
| srichter | yes, adapters that use annotations | 18:40 |
| srichter | that is the Zope 3 way to do it and it will allow us to make our objects as feature-rich or feature-poor as we need them | 18:40 |
| gintas | well, I don't want to rewrite SchoolTool a third time | 18:41 |
| srichter | this can be done very gradually over the next months | 18:41 |
| srichter | I can always ask Tom whether he let's me do it | 18:41 |
| srichter | if you are burned out ;-) | 18:42 |
| mgedmin | I would be very happy if ST and SB were two applications combined with ZCML from a single soup of components | 18:42 |
| mgedmin | but I am not yet convinced your way is feasible | 18:43 |
| srichter | btw, the st.level is a good example on how I extended ST without touching anything else; except the one palce I could not avoid | 18:43 |
| srichter | mgedmin: good to have your support | 18:44 |
| mgedmin | (I've yet to take a look at it) | 18:44 |
| srichter | mgedmin: that's the reason I really wanted to check with you | 18:44 |
| gintas | srichter, I'm not against the idea | 18:44 |
| gintas | I just don't have a clear picture of how it could be executed | 18:44 |
| gintas | by the way, during the coming 6 months I will be available on a very limited basis (if at all), so should you decide to carry out the idea, I probably won't be able to contribute much | 18:45 |
| srichter | I could spend the next day or two demonstrating how it should be done on a couple of examples | 18:45 |
| gintas | so you needn't listen to me ;) | 18:45 |
| srichter | :-) | 18:46 |
| srichter | mgedmin: do you have concrete examples of where it all might not be feasible? | 18:47 |
| mgedmin | everywhere ;) | 18:48 |
| srichter | mgedmin: do you think that ST is well-tested? | 18:49 |
| mgedmin | yes | 18:49 |
| srichter | so if I poke around, but get all tests to pass, it will work? | 18:49 |
| mgedmin | (hopefully) | 18:49 |
| mgedmin | in theory | 18:49 |
| srichter | ok | 18:49 |
| srichter | I am going to start a branch and try a couple of things | 18:50 |
| srichter | 1. Remove the ITimetabled from Person, Group, Resource | 18:50 |
| gintas | if you turn everything upside down, and then turn all tests upside down, I wouldn't be very confident in the results even if all the tests passed | 18:50 |
| srichter | 2. Remove sb.IAdaptableToSchoolBellApplication from ICourseContainer, ICourseContained... | 18:51 |
| mgedmin | in theory you could refactor everything and then get unmodified functional tests passing | 18:51 |
| mgedmin | (2): yay! | 18:51 |
| gintas | IAdaptableToSchoolBellApplication is a wart IMHO | 18:51 |
| mgedmin | IAdaptableTo....Application was a mistake | 18:51 |
| srichter | mgedmin: right, that is the goal | 18:51 |
| srichter | as long as I get all ftests passing, it should mean the app works | 18:52 |
| gintas | I'm not sure I trust the coverage of functional tests | 18:52 |
| mgedmin | srichter, would you have a single skin for both ST and SB? | 18:52 |
| srichter | yes | 18:52 |
| mgedmin | with different contents depending on which packages were included? | 18:52 |
| srichter | but that might be debatable | 18:52 |
| srichter | I think a SB skin that derives from ST skin might be cleaner | 18:52 |
| mgedmin | ok | 18:53 |
| srichter | yes, that would be the noblest goal | 18:53 |
| srichter | (to not have a second skin and manage everything with ZCML and package inclusion) | 18:53 |
| mgedmin | by the way, due to our (ill-considered?) choice to support SB/ST as a Zope 3 content object | 18:53 |
| mgedmin | we could not have implemented your scheme | 18:54 |
| mgedmin | because somebody might want to add both ST and SB as content objects | 18:54 |
| srichter | which scheme? | 18:54 |
| mgedmin | in a single zope 3 instance | 18:54 |
| mgedmin | so ST and SB have to be zcml-compatible now | 18:54 |
| srichter | mmh, good point | 18:54 |
| mgedmin | (your scheme to make ST and SB differ in ZCML and the set of python packages) | 18:54 |
| mgedmin | that's one of the reasons we had different sets of parallel object interfaces, skins, etc | 18:55 |
| srichter | yes, that would be a true issue, which I think can be overcome (but it might make it much, much harder to do) | 18:55 |
| mgedmin | btw I think a lot of page template duplication could be avoided with pagelets | 18:55 |
| srichter | right, no question about that | 18:55 |
| srichter | ok, I would claim that noone would run SB and ST on the same instance | 18:56 |
| srichter | if we think that is a good assumption, we should be safe | 18:56 |
| mgedmin | if we drop "SB/ST as a Z3 content object" use case, we're good anyway | 18:56 |
| srichter | yes | 18:57 |
| srichter | ok, I'll assume we drop that requirement | 18:57 |
| tvon | then couldn't we have the extra bits in schooltool setup via events? so it's basically just determined by an extra zcml include? | 18:57 |
| srichter | events are one way to provide extra functionality | 18:57 |
| srichter | adapters are another | 18:58 |
| tvon | so the terms package would add the terms container, courses adds course container.. | 18:58 |
| tvon | ah | 18:58 |
| srichter | yes | 18:58 |
| srichter | in fact now that you mention it, I really like the event idea for instantiation the ST/SB app | 18:58 |
| srichter | it is better than having custom subscribers, named adapters or named utilities | 18:59 |
| tvon | one thing to consider (maybe), what happens when someone has a SB instance and they later go add the ST zcml includes" | 18:59 |
| tvon | s/"/? | 18:59 |
| srichter | tvon: well, you cannot do this right now either, so let's not add additional use cases at this point | 19:00 |
| * tvon nods | 19:00 | |
| srichter | (though I have an answer for you: generation scripts) | 19:00 |
| tvon | ah | 19:01 |
| tvon | assuming they want their SB turned into a ST and they didn't just screw the pooch | 19:02 |
| tvon | but, later | 19:02 |
| povbot | /svn/commits: * srichter committed revision 4608: | 19:04 |
| povbot | /svn/commits: Create a branch to work on some refactorings to demonstrate that we can merge schooltool and schoolbell. | 19:04 |
| povbot | /svn/commits: * srichter committed revision 4609: | 19:05 |
| povbot | /svn/commits: Make a copy of schoolbell. | 19:05 |
| povbot | /svn/commits: * srichter committed revision 4610: | 19:05 |
| povbot | /svn/commits: Make a copy of schooltool. | 19:05 |
| mgedmin | I'll write up my thoughts about ST/SB reorganization and send them to the mailing list | 19:10 |
| srichter | great | 19:10 |
| tvon | maybe hackish, but sbapp could have a boolean property "isSchoolTool" or "isSchoolBell" that event subscribers could check | 19:11 |
| * mgedmin would REALLY like to avoid that | 19:11 | |
| srichter | yep, nothing like that should exist | 19:11 |
| povbot | /svn/commits: * gintas committed revision 4611: | 19:12 |
| povbot | /svn/commits: Marked an ugly hack with an XXX. | 19:12 |
| tvon | heh, okay | 19:12 |
| srichter | the entire point of the merge would be that there is no difference at all between the two | 19:13 |
| srichter | just configuration makes them look/behave otherwsie | 19:14 |
| povbot | /svn/commits: * srichter committed revision 4612: | 19:15 |
| povbot | /svn/commits: Corrected linkage. | 19:15 |
| mgedmin | "there is no difference" is not achievable, period | 19:16 |
| mgedmin | "minimizing differences" is a possible goal | 19:16 |
| mgedmin | uh, probably we're talking about the same thing but using different words ;) | 19:16 |
| srichter | :-) I think we are. | 19:17 |
| tvon | I see it as code reuse.. there would be no need for SchoolToolApplication() or duplicate adapters (one adapting to ischoolbellapp and another to ischooltoolapp) | 19:17 |
| srichter | I meant explicitely the objects should be not difference; but difference will occur due to different config and different view registrations | 19:17 |
| tvon | same classes, different instances? | 19:18 |
| tvon | nm | 19:18 |
| srichter | well, that's the same :-) | 19:18 |
| srichter | there will be only an ISchoolToolApplication interface | 19:19 |
| tvon | wouldn't there be only one SchoolToolApplication? | 19:19 |
| srichter | well, most will have one isntance yes | 19:19 |
| tvon | one of them has more containers due to them being added after the object is created? or are we still going to have two different class definitions? | 19:20 |
| srichter | no, one class definition | 19:20 |
| tvon | okay, cool | 19:20 |
| srichter | mgedmin: an organizational question: of course we want to have a lot less stuff in app.py, so we put goup/groupcontainer into separate modules | 19:22 |
| srichter | should we make those packages or modules? | 19:22 |
| srichter | I think they should be packages, even if very small, so that we can distribute them more easily | 19:22 |
| mgedmin | it depends | 19:22 |
| mgedmin | e.g. if they have their own modular zcml, then they should be packages | 19:22 |
| mgedmin | I general I try to avoid circular dependencies | 19:23 |
| srichter | mmh, how do we decide this? | 19:23 |
| mgedmin | and it might be difficult in this case -- person views know about groups, for example, and group views know about persons | 19:23 |
| *** gintas has quit IRC | 19:25 | |
| srichter | mgedmin: was the adaptation to ISchoolBellApplication really needed for something? Or is it totally replaced by the getSchoolBellApplication function? | 19:32 |
| mgedmin | let me see... in a couple of views we had the need to get the application itself when context was something different (e.g. a person container) | 19:41 |
| mgedmin | so we introduced the interface and adaptation, as a flexible mechanism to get the app object without hardcoding object relationships all over the place | 19:42 |
| mgedmin | later we found out it wasn't enough | 19:42 |
| mgedmin | we needed the app for some contexts that had no adapters | 19:42 |
| mgedmin | so we changed getSchoolXXXApplication to get the app from the site instead | 19:42 |
| srichter | ok, cool | 19:42 |
| srichter | that's what I thought | 19:43 |
| mgedmin | but did not find the time to rip out old adapters etc | 19:43 |
| srichter | (btw, I don't think this was a bad move) | 19:43 |
| povbot | /svn/commits: * jinty committed revision 4613: | 19:52 |
| povbot | /svn/commits: Work around a subtle bug in zope.configuration.config and synchronize from schooltool setup.py. | 19:52 |
| srichter | I think we will need to develop a layer for the rest views as well | 20:09 |
| povbot | /svn/commits: * srichter committed revision 4614: | 20:19 |
| povbot | /svn/commits: Removed IAdaptableToSchoolBellApplication interface. | 20:19 |
| srichter | okay, step (2) is done | 20:49 |
| povbot | /svn/commits: * srichter committed revision 4615: | 20:50 |
| povbot | /svn/commits: No more IAdaptableToSchoolBellApplication interface. Yipee. | 20:50 |
| *** bskahan has joined #schooltool | 20:53 | |
| povbot | /svn/commits: * jinty committed revision 4616: | 20:54 |
| povbot | /svn/commits: Sync changes from schoolbell setup.py and Makefile. You should now be able to delete the Zope3 external from schooltool. However, using a 3.1 tarball distribution WILL NOT WORK as it does not contain zope.app.wfmc | 20:54 |
| srichter | argh, what are those overlaid_calendars in IPerson? | 20:57 |
| srichter | argh, what are those `overlaid_calendars` in *Person*? | 20:58 |
| srichter | they are not documented in any interface that Person implements | 20:58 |
| mgedmin | let me check | 21:00 |
| tvon | OverlaidCalendarsProperty? | 21:00 |
| tvon | er.. | 21:00 |
| srichter | why is it not in any interface? | 21:00 |
| srichter | also, why does it use an underscore? | 21:00 |
| mgedmin | schoolbell.app.interfaces.IReadPerson | 21:00 |
| mgedmin | overlaid_calendars = Attribute("""Additional calendars to overlay. ...""") | 21:00 |
| srichter | ok, I see | 21:02 |
| srichter | mmh, the security on ITimetabled is strange | 21:09 |
| srichter | all objects' ITimetabled interface is publically allowed, except for Person, where you require schoolbell.viewCalendar | 21:10 |
| srichter | that does not make sense | 21:10 |
| bskahan | tvon: tried the calendar widget from trunk on safari | 21:46 |
| tvon | bskahan: does it work? | 21:47 |
| bskahan | works mostly here | 21:47 |
| tvon | heh, mostly? | 21:47 |
| bskahan | maybe tom has the version without the css fix | 21:47 |
| bskahan | it works, except its slightly off position (not far off), after it hides, there's shmutz left from the border | 21:48 |
| tvon | rm, okay | 21:49 |
| bskahan | the shmutz is a serious issue, the positioning is not | 21:49 |
| tvon | is it a rendering issue? | 21:49 |
| bskahan | yeah | 21:49 |
| tvon | eg, a safari redraw issue? | 21:49 |
| bskahan | right | 21:49 |
| tvon | suck | 21:49 |
| bskahan | but it doesn't seem like safari can't handle dynamic forms | 21:49 |
| bskahan | so I'm not sure where to start looking for a way to fix that | 21:50 |
| *** ignas_ has quit IRC | 22:12 | |
| *** mgedmin has quit IRC | 22:14 | |
| *** bskahan has quit IRC | 22:55 | |
| *** jonesiebo has joined #schooltool | 23:07 | |
| *** jonesiebo has left #schooltool | 23:11 | |
| *** bskahan has joined #schooltool | 23:14 | |
| *** jonesieboy has joined #schooltool | 23:21 | |
| *** jonesieboy has left #schooltool | 23:24 | |
| *** jonesieboy has joined #schooltool | 23:24 | |
| *** jonesieboy has quit IRC | 23:25 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!