| *** dadeng has joined #schooltool | 00:05 | |
| *** dadeng has quit IRC | 00:28 | |
| *** alga has quit IRC | 00:49 | |
| *** th1a has joined #schooltool | 05:36 | |
| *** aks has joined #schooltool | 07:57 | |
| *** aks is now known as aks_afk | 09:46 | |
| *** aks_afk is now known as aks | 10:22 | |
| *** menesis has joined #schooltool | 10:33 | |
| *** alga has joined #schooltool | 11:29 | |
| *** menesis has quit IRC | 13:25 | |
| *** menesis has joined #schooltool | 14:18 | |
| *** aks has quit IRC | 14:25 | |
| *** jelkner has joined #schooltool | 15:43 | |
| *** asharma_ has joined #schooltool | 16:13 | |
| jelkner | Good morning, asharma_ | 16:15 |
|---|---|---|
| jelkner | good morning, asharma_! | 16:15 |
| jelkner | sorry for typing that twice | 16:15 |
| jelkner | but my xchat isn't working | 16:15 |
| asharma_ | Good morning jelkner | 16:15 |
| jelkner | and i don't see what i type | 16:15 |
| *** asharma_ has quit IRC | 16:21 | |
| *** asharma_ has joined #schooltool | 16:21 | |
| *** replaceafill has joined #schooltool | 16:24 | |
| th1a | Good morning replaceafill, aelkner, yvl, menesis. | 16:31 |
| replaceafill | good morning/afternoon | 16:32 |
| yvl | good morning! | 16:32 |
| aelkner | morning | 16:32 |
| th1a | replaceafill: How are we doing with the demo server? | 16:32 |
| replaceafill | th1a it's done, i had a chat with Chandara on Friday and gave him a new url | 16:32 |
| replaceafill | he wrote back yesterday | 16:33 |
| replaceafill | asking for a user manual | 16:33 |
| replaceafill | th1a i fwd you that one | 16:33 |
| menesis | hi | 16:33 |
| th1a | Hm... | 16:34 |
| replaceafill | also, last week i investigated about accordions and dialogs | 16:34 |
| th1a | I'll have to think about how we should approach that. | 16:34 |
| replaceafill | th1a i was thinking about checking your screenshots script | 16:34 |
| replaceafill | (for the manual) | 16:34 |
| th1a | Well, they have different links. | 16:35 |
| replaceafill | yes | 16:35 |
| th1a | We may need to give them something abbreviated for the customizations and require them to do the final version. | 16:35 |
| replaceafill | ah | 16:35 |
| th1a | Give them enough documentation to write the documentation. | 16:36 |
| replaceafill | like giving them only the right steps: first add some shifts, then school information, etc | 16:36 |
| th1a | Basically. | 16:36 |
| replaceafill | understood | 16:37 |
| replaceafill | on the jquery side, i also took a look at some spinner animations | 16:37 |
| replaceafill | now i'm not sure about if we should use plugins | 16:37 |
| th1a | I just think it is a packaging issue. | 16:38 |
| replaceafill | after our discussion last week about packaging them | 16:38 |
| th1a | We should ask menesis. | 16:38 |
| replaceafill | right | 16:38 |
| th1a | menesis: Any third party plugin for jquery should, technically, get its own package, right? | 16:38 |
| menesis | I think everything can be stuffed in one resources dir | 16:39 |
| replaceafill | menesis i use jstree as an example, which we just inserted as a resource directory | 16:39 |
| menesis | if there are more files than one .js (like jstree has) then a subdir is needed | 16:40 |
| th1a | So I'm being more pedantic than menesis? | 16:40 |
| menesis | what you mean by "its own package"? | 16:41 |
| th1a | A separate deb. | 16:41 |
| aelkner | th1a, we don't need to distribute debs of jquery source because we copied it into our own source | 16:43 |
| menesis | ideally, yes, but don't worry about that | 16:43 |
| th1a | OK. | 16:43 |
| menesis | just add plugins or libraries in the same place where others are | 16:43 |
| th1a | So... I guess we can do that. | 16:43 |
| menesis | I would like to use fanstatic framework to manage resources | 16:43 |
| th1a | And we can just pick a jquery menu plugin while we're at it. | 16:44 |
| menesis | there are packages already created for that http://www.fanstatic.org/en/latest/libraries.html | 16:44 |
| menesis | jstree and other plugins | 16:44 |
| menesis | then the used ones will have to be separate debs | 16:45 |
| th1a | OK. Makes sense. | 16:45 |
| th1a | ... | 16:45 |
| menesis | but for development included libraries in source are ok | 16:45 |
| th1a | That's what I was asking. | 16:45 |
| th1a | OK, back to the beginning. | 16:45 |
| replaceafill | cool, so we can use plugins | 16:45 |
| aelkner | wait, why is it different for development? can someone xplain that? | 16:46 |
| th1a | They DO have to be packaged separately. | 16:46 |
| th1a | Because of how Debian and Ubuntu work. | 16:46 |
| th1a | Libraries get separate packages. | 16:46 |
| aelkner | but if we copy a whole library into our source tree, doesn't that mean we don't need to distribute via packages | 16:47 |
| th1a | Also, we want to keep clean ownership over our shipped versions. | 16:47 |
| th1a | We COULD. | 16:47 |
| th1a | But it isn't how Debian and Ubuntu packaging works. | 16:47 |
| aelkner | can someone answer my question please? | 16:48 |
| menesis | if a library is packaged in Ubuntu separately, then we SHOULD use it. if it is not, we CAN include it | 16:48 |
| th1a | Include it in our release? | 16:48 |
| menesis | http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/schooltool/oneiric/view/head:/debian/patches/system-jquery.patch | 16:50 |
| menesis | for jquery, ubuntu source package has a patch to not install our included jquery, but use a system installed one | 16:51 |
| menesis | but jstree is included in python-schooltool.deb | 16:51 |
| th1a | OK... so we're ok with that, and maybe someday we'll switch to using or providing separate debs for jquery plugins we use? | 16:52 |
| th1a | Is this just because javascript scripts are considered kind of trivial? | 16:53 |
| menesis | maybe | 16:54 |
| th1a | OK. | 16:55 |
| menesis | javascript is a programming language like any other. whole applications can be written with it. | 16:55 |
| menesis | has nothing to do with javascript | 16:55 |
| th1a | Right, but coming from the background of web pages. | 16:55 |
| th1a | It just seems like they're being treated a little differently. | 16:56 |
| th1a | Anyhow... | 16:56 |
| menesis | for example firefox source code has many libraries included, and ./configure switches to use system libraries if available | 16:56 |
| th1a | Yes, but I'd imagine the debs don't come with those libraries. | 16:57 |
| th1a | Moving on... | 16:57 |
| replaceafill | my last comment on this | 16:57 |
| menesis | I don't think about schooltool debs now, why should you | 16:57 |
| replaceafill | i think we should take a look at plugins first, before doing things by ourselves | 16:58 |
| replaceafill | (just my opinion) | 16:58 |
| replaceafill | (and i'm talking jquery here) | 16:58 |
| aelkner | and can someone answer my question please! | 16:58 |
| menesis | of course use plugins | 16:58 |
| menesis | aelkner: what question, sorry? | 16:58 |
| th1a | Well, if we added 20 jquery plugins and then in October we discover we can't use them because the jquery gatekeeper for Debian/Ubuntu is an asshole, then it is a problem. | 16:59 |
| replaceafill | :D | 16:59 |
| aelkner | you can look back in the chat | 16:59 |
| aelkner | but i'll ask again: | 16:59 |
| th1a | aelkner: In general, libraries get separate packages in Debian/Ubuntu. | 16:59 |
| aelkner | why do we care about debs for jquery source when we copy it into our source? | 17:00 |
| th1a | That's why we have 100 or so packages that make up SchoolTool. | 17:00 |
| menesis | just add whatever plugins you want to src/schooltool/skin/resources | 17:00 |
| th1a | Zope was fragmented into 100 libraries, so we have to make 100 packages. | 17:00 |
| menesis | will see if we need to do anything else with them | 17:00 |
| aelkner | that's for zope, i get that | 17:00 |
| aelkner | but jquery source is copied into our source | 17:00 |
| th1a | Why don't we just copy zope's source into ours? | 17:01 |
| aelkner | not the same as dependency on zope packages | 17:01 |
| th1a | That would be much easier. | 17:01 |
| aelkner | i can't answer that ne | 17:01 |
| aelkner | one | 17:01 |
| th1a | Exactly. | 17:01 |
| menesis | aelkner: jquery is already packaged for Ubuntu (not by me) in libjs-jquery | 17:01 |
| aelkner | but i'm the one asking here, not answering :) | 17:01 |
| menesis | to avoid duplicate code we should use that package instead of our copy | 17:02 |
| menesis | but if there is no .deb, we can include javascript resources in schooltool source | 17:02 |
| aelkner | ah, so we don't want to copy jquery into our source anymore, is that it? | 17:02 |
| menesis | we do this now | 17:02 |
| th1a | It is just a question of how pedantic the Ubuntu/Debian gatekeepers are going to be. | 17:02 |
| menesis | with jstree, calwidget, maybe something else | 17:02 |
| th1a | OK. | 17:03 |
| th1a | So... | 17:03 |
| aelkner | but jquery itself is a deb, i see | 17:03 |
| th1a | Regardless, I don't want to go apeshit adding plugins. | 17:03 |
| th1a | So if there are a couple we want to use, great. | 17:03 |
| menesis | aelkner: there is a copy of jquery in source, but not in the deb | 17:03 |
| th1a | So I guess aelkner can just use a menu plugin. | 17:04 |
| menesis | of course | 17:04 |
| th1a | All right, where were we, replaceafill? | 17:05 |
| replaceafill | asking if we should use plugins :D | 17:05 |
| replaceafill | no seriously | 17:05 |
| aelkner | :) | 17:05 |
| replaceafill | i only wanted to point out that a plugin (even a crappy one) could be better than any jquery code i could write | 17:06 |
| aelkner | not what i would write :) | 17:06 |
| aelkner | only kidding | 17:06 |
| th1a | The menu one is the only one I felt we definitely needed. | 17:06 |
| replaceafill | and we at least should examine good plugins to see how they work | 17:06 |
| th1a | And that's the easiest to write. | 17:07 |
| replaceafill | and to me, in all this jquery topic the key part is finding ways to make the behaviour general enough | 17:07 |
| th1a | I want to get the most out of a small palette of widgets to start. | 17:07 |
| aelkner | well, it wasn't trivial, and i stil had unanswered issues, like screenX and screenY as I mentioned | 17:07 |
| replaceafill | for instance, what if activities tomorrow support a new action button | 17:07 |
| replaceafill | is it easy to include it in the contextmenu? | 17:08 |
| replaceafill | and stuff like that | 17:08 |
| yvl | sorry for a late reply, just sent an email on the topic | 17:08 |
| yvl | a short one | 17:08 |
| * replaceafill looks at his email | 17:08 | |
| th1a | I'm not sure that's an argument for using a plugin. | 17:08 |
| yvl | in summary - you can position with css pretty well | 17:09 |
| replaceafill | yvl right, that's what i like about jquery's cross platform support | 17:09 |
| yvl | well, absolute position should work pretty much in everywhere | 17:10 |
| yvl | unless I forgot something | 17:10 |
| *** alga has quit IRC | 17:10 | |
| aelkner | yvl, can you explain positioning with css please? | 17:11 |
| aelkner | for instance, in the gradebook case, the menu appears when the user clicks an activity title | 17:12 |
| aelkner | and it should appear right were the user just clicked | 17:12 |
| aelkner | so the positioning needs to be dynamic based on the click event location | 17:12 |
| aelkner | how would that be handled with css? | 17:12 |
| th1a | There are examples of CSS only menu implementations on the web. | 17:12 |
| yvl | if you looked at the html I sent | 17:13 |
| aelkner | yeah, but they involve having the menu appear with the event target | 17:13 |
| yvl | there are menus rendered for each item | 17:13 |
| aelkner | in other words, each activity title wold have the duplicate menu html with it | 17:13 |
| yvl | if you want to put them in dynamically | 17:13 |
| aelkner | then when the user hovers, it gets shown | 17:13 |
| yvl | that's one way | 17:13 |
| yvl | you can also inject HTML | 17:14 |
| yvl | if you want to | 17:14 |
| aelkner | using css? | 17:14 |
| yvl | using JS | 17:14 |
| aelkner | exactly | 17:14 |
| yvl | on click | 17:14 |
| aelkner | you were saying it can be handled with css | 17:14 |
| yvl | positioning | 17:14 |
| yvl | the position is inherited from the parent element | 17:14 |
| yvl | not from screenX | 17:15 |
| replaceafill | that's how contextmenu does it... | 17:15 |
| replaceafill | using absolute position for the css | 17:15 |
| replaceafill | and calculating with js | 17:15 |
| yvl | well, if you need to put it where the user clicked, it's one thing | 17:16 |
| yvl | as in - near mouse pointer | 17:16 |
| aelkner | i used abosulte posiotioning | 17:16 |
| aelkner | but that's ust so the element doesn't shove other elements aside | 17:16 |
| aelkner | you also need zindex to make sure it goes on top of the other elements i beleve | 17:17 |
| aelkner | but position: absolute does not position the element near where the user clicked | 17:17 |
| yvl | no it does not | 17:18 |
| yvl | oh | 17:18 |
| yvl | sorry | 17:18 |
| yvl | you are doing a pop-up context menu? | 17:18 |
| aelkner | yes | 17:18 |
| th1a | It isn't really. | 17:19 |
| th1a | There is a target. | 17:19 |
| aelkner | the menu's location is one spot only in the beginning of the body | 17:19 |
| aelkner | and it is hidden | 17:19 |
| th1a | It isn't a "right click anywhere" contextual menu. | 17:19 |
| aelkner | the javascipt event s in charge of making it appear and posiotioning it near the click | 17:19 |
| yvl | it isnt? | 17:19 |
| th1a | No. | 17:19 |
| aelkner | also, the links need to be calculted | 17:19 |
| aelkner | calculated | 17:20 |
| menesis | there are many examples on the web how to do menus or tooltips. I don't understand why you want to implement this yourself | 17:20 |
| yvl | then there's no need to check the mouse position | 17:20 |
| th1a | yvl: Yes. | 17:20 |
| yvl | if this would be "right click anywhere", then that would be another case | 17:20 |
| aelkner | did you guys look at my revision? | 17:20 |
| yvl | yes | 17:21 |
| th1a | Yes, the menu can always be in the same place. | 17:21 |
| aelkner | th1a, you don't mean that the user should see the menu in the same place regardless of where the activity is? | 17:21 |
| th1a | I mean, the user clicks a > and the menu pops up next to it. | 17:22 |
| aelkner | i thought this was a context menu? | 17:22 |
| th1a | It is in the context of the spreadsheet. We discussed this at great length. | 17:22 |
| aelkner | you are saying that the menu appears next to the > because it was there all along | 17:22 |
| aelkner | just hidden | 17:23 |
| yvl | why not? | 17:23 |
| th1a | It appears there because that is where the user would expect to see it. | 17:23 |
| aelkner | if that's the case then we need to duplicate the menu for each activity | 17:23 |
| yvl | actually - not necessarily | 17:23 |
| aelkner | that's a lot of html coming down the pipe | 17:23 |
| th1a | No it isn't. | 17:23 |
| * replaceafill sighs.... | 17:23 | |
| yvl | you can use the magic of JS to put it in HTML where you want | 17:23 |
| replaceafill | that's what i was saying before... | 17:23 |
| yvl | :) | 17:24 |
| aelkner | ah | 17:24 |
| yvl | IF | 17:24 |
| yvl | it is a lot | 17:24 |
| aelkner | i get it now, that's different | 17:24 |
| aelkner | i never considered moving the menu around in the DOM | 17:24 |
| aelkner | if that were the case, then position: absolute would do the trick | 17:25 |
| aelkner | because the element that it is next to would have the position | 17:25 |
| aelkner | do we want to move the html around in the DOM? | 17:25 |
| * yvl shrugs | 17:25 | |
| aelkner | it's doable, but it seems a bit hacky | 17:25 |
| yvl | personally I would just duplicate the menu | 17:25 |
| yvl | it's not that much | 17:26 |
| th1a | yvl: Yes. | 17:26 |
| aelkner | i should mention another related issue right there | 17:26 |
| aelkner | the way i coded it with the one dynamic menu | 17:26 |
| aelkner | all tests pass only because i didn't get rid of the (sort) link and | 17:27 |
| aelkner | javascript doesn't run in tests, so the activity link still did the old thing | 17:27 |
| aelkner | but if we do include the duplicated menu with each activity | 17:27 |
| aelkner | and then use css to hide it | 17:27 |
| aelkner | then the links would be there for the tests, right? | 17:28 |
| yvl | yes? | 17:28 |
| yvl | I mean - yes. | 17:28 |
| aelkner | even though they are hidden, they still would be clickable in testbrowser? | 17:29 |
| yvl | yes | 17:29 |
| th1a | That's a good reason not to get too tricky. | 17:29 |
| aelkner | well, that decides it then, duplicate menus | 17:29 |
| yvl | :) | 17:30 |
| aelkner | so i still need js to hide/unhide because: | 17:30 |
| aelkner | 1) th1a doesn't want menus to appear on hover | 17:30 |
| aelkner | 2) hover css only applies to the element one is hovering (am i right?) | 17:31 |
| th1a | I think css has onclick. | 17:31 |
| yvl | 2 - yes, but doesn't work on some older browsers | 17:31 |
| aelkner | can one make one element appear another is hovered? | 17:31 |
| aelkner | in css i mean | 17:32 |
| replaceafill | as usual, i'm lost now, what do you mean by "duplicate menus"? | 17:32 |
| aelkner | replaceafill, for each column, have the menu in the html | 17:32 |
| th1a | Just putting the menu code in a the top of each column. | 17:32 |
| aelkner | each column's menu would have the right links for that activity | 17:33 |
| aelkner | so tests would continue to work | 17:33 |
| th1a | Anyhow, a little js is not a problem. | 17:33 |
| th1a | Just keep this simple and straightforward though. | 17:33 |
| th1a | Or... we could just use a plugin. | 17:33 |
| yvl | :D | 17:34 |
| replaceafill | ... | 17:34 |
| aelkner | the important this is the decision to duplicate the menus and how that effects tests | 17:34 |
| th1a | Yes. | 17:34 |
| th1a | That is what I was going to say next. | 17:34 |
| th1a | Writing tests for the plugin might take longer than implementing menus ourselves. | 17:34 |
| replaceafill | welcome more html!!! | 17:34 |
| aelkner | and all i would need to change is globally replacing clicks of '(sort)' with clicks of 'Sort by' | 17:34 |
| replaceafill | let's bloat the output | 17:34 |
| aelkner | replaceafill, i'm with you, i thought we were trying to reduce the payload, not increase it | 17:35 |
| aelkner | but if yvl thinks it's small enough | 17:35 |
| yvl | I don't know | 17:35 |
| aelkner | it is only once per column | 17:35 |
| yvl | it depends on the implementation | 17:35 |
| aelkner | as opposed to once per cell | 17:35 |
| yvl | it does not look like a lot | 17:35 |
| th1a | It is small. | 17:36 |
| replaceafill | class="cell bla bla" didnt look like too much either | 17:36 |
| aelkner | <ul><li><a href="..."> | 17:36 |
| aelkner | that's about it | 17:36 |
| replaceafill | i hope i'm understanding this wrong, i'll wait to see the implementation too | 17:36 |
| yvl | replaceafill, what amount of payload do you expect to get out of this? | 17:37 |
| yvl | order-of-magnitude | 17:37 |
| yvl | and where is your pain level? ;) | 17:37 |
| aelkner | also, we already deliver the (sort) link in each column, so we wouldn't even be increasing in that case | 17:37 |
| th1a | replaceafill is flashing back to a per-cell issue. | 17:37 |
| aelkner | right :) | 17:37 |
| replaceafill | i'll stop commenting on this one :) | 17:38 |
| yvl | it is ok, replaceafill | 17:38 |
| yvl | don't think that I don't care about that issue | 17:38 |
| replaceafill | again, maybe i'm understanding it wrong | 17:38 |
| aelkner | replaceafill, as i was just saying, we already have two links for each column | 17:39 |
| yvl | I just thought that several hundred bytes are sacrificable in this case | 17:39 |
| replaceafill | :D | 17:39 |
| aelkner | we would be replacing them with a menu that has the two links | 17:39 |
| aelkner | with some >ul><li> around them | 17:39 |
| th1a | OK... MOVING ON. | 17:39 |
| th1a | replaceafill: Back to your jquery investigations... | 17:40 |
| replaceafill | :) | 17:40 |
| replaceafill | th1a i'd like a use case for the accordion/dialog story | 17:40 |
| th1a | Note that we may have to have these conversations daily during the UI sprint... | 17:40 |
| replaceafill | last week you talked about using accordions for contacts/sections, remember? | 17:40 |
| th1a | To put all the info on a person's page. | 17:41 |
| replaceafill | maybe i could code a small example now that i know how to use them | 17:41 |
| th1a | Sure. | 17:41 |
| replaceafill | *IN* schooltool (as you once said) :) | 17:41 |
| replaceafill | i'll start with some non-sense as usual and show it to you, to have feedback | 17:42 |
| th1a | OK. | 17:42 |
| replaceafill | that's it from me :) | 17:42 |
| replaceafill | (he said after one hour of discussion) :P | 17:42 |
| th1a | OK. | 17:42 |
| th1a | aelkner: Do you want to continue with your implementation or punt to a plug-in? | 17:43 |
| aelkner | the plugin won't work for us | 17:43 |
| th1a | OK. | 17:43 |
| replaceafill | :| | 17:43 |
| replaceafill | sorry | 17:43 |
| aelkner | correct me if i'm wrong, replaceafill, but it only woks with one menu | 17:43 |
| replaceafill | i said i wouldn't comment | 17:43 |
| replaceafill | :D | 17:43 |
| aelkner | please do | 17:43 |
| th1a | There are many jquery menu plugins floating around. | 17:43 |
| th1a | Including one that will be included in the next release of jquery-ui. | 17:44 |
| replaceafill | aelkner go with the multiple menu implementation | 17:44 |
| aelkner | why bother when it's easy to do with js and the zpl for repeating the menu as we agreed | 17:44 |
| aelkner | replaceafill, right | 17:44 |
| th1a | Yes, I'm ok with finishing what you started. | 17:44 |
| th1a | Particularly to avoid testing disasters. | 17:45 |
| aelkner | we solved the position problem with the duplicate menus | 17:45 |
| aelkner | but what about the colors? | 17:45 |
| aelkner | i mentioned that jquery had a nice image file for the background of each <li> | 17:46 |
| yvl | anything is better when pink! | 17:46 |
| aelkner | i just chose something light | 17:46 |
| aelkner | don't ask me to defend color choices | 17:46 |
| th1a | Well, we're going to be changing colors extensively soon anyhow. | 17:46 |
| aelkner | and when the scheme is decided, i won't have to :) | 17:47 |
| th1a | What we will have to do is get our CSS all coordinated so that we will be able to change colors across the whole application. | 17:47 |
| th1a | So we don't so much need colors as names of colors. | 17:47 |
| aelkner | we could use a task plan for the sprint | 17:47 |
| th1a | highlight1, etc. | 17:47 |
| th1a | I'm working on it. | 17:48 |
| aelkner | ah, ok, cool | 17:48 |
| aelkner | is it still starting a week from today? | 17:48 |
| th1a | Basically the spreadsheet will be a big checklist for each view. | 17:48 |
| th1a | That's the plan. | 17:48 |
| * yvl is ok with the plan | 17:49 | |
| yvl | just FYI | 17:49 |
| th1a | e.g.: text ok | colors ok | etc. | 17:49 |
| aelkner | how come yvl knows the plan and i don't? | 17:49 |
| th1a | The plan of starting next week. | 17:49 |
| * yvl pays attention at IRC weekly meetings, aelkner :P | 17:50 | |
| replaceafill | :)) | 17:50 |
| th1a | We'll also start with simple views so we can focus on process. | 17:50 |
| aelkner | i see conversations, but that's different than conclusions set down in documents | 17:50 |
| th1a | OK, so aelkner is going to keep working on menus and get back to me on that. | 17:51 |
| th1a | Thanks aelkner. | 17:51 |
| th1a | yvl? | 17:51 |
| yvl | ok... | 17:52 |
| yvl | I'm starting to remake the first few views in ST | 17:52 |
| yvl | Most of the underlying things are there | 17:52 |
| yvl | I think it's best to write convenience zcml directives as we go | 17:52 |
| yvl | I also need to make CSS for forms | 17:53 |
| yvl | don't expect that to be a lot of hassle | 17:53 |
| yvl | and I'll need to put some sort of "tutorial" on how to customize the new UI | 17:54 |
| th1a | Can we get some screenshots? | 17:54 |
| yvl | not yet, but once the first view is done - yes | 17:54 |
| aelkner | please use the developer list for sending email | 17:55 |
| yvl | of course | 17:55 |
| th1a | OK. We should be discussing this all week. | 17:55 |
| yvl | it will likely be calendar | 17:55 |
| * th1a would suggest not starting with the most complicated view. | 17:55 | |
| aelkner | yvl, are you pushing your branch on an ongoing basis? | 17:55 |
| aelkner | if so, we could begin to see what you are doing | 17:56 |
| aelkner | and be better prepared for the sprint | 17:56 |
| yvl | https://code.launchpad.net/~justas-pov/schooltool/flourish | 17:56 |
| aelkner | cool, thanks | 17:56 |
| yvl | not sure if this is useful at all now | 17:56 |
| th1a | OK, thanks, yvl. Let's move on. | 17:57 |
| th1a | menesis? | 17:57 |
| yvl | I am not decided about one thing, th1a | 17:57 |
| th1a | Go ahead, yvl. | 17:57 |
| yvl | on one hand, I'd like to implement the new UI as a separate skin | 17:57 |
| yvl | that means - almost duplicate views and almost duplicate templates | 17:58 |
| yvl | and everybody (like CanDo) can still use the old skin | 17:58 |
| yvl | on the other hand, it's duplicate code | 17:58 |
| yvl | if you had a lot of views and a lot of tests.... how would you proceed? | 17:59 |
| th1a | Backward compatibility is not a bad idea. | 17:59 |
| aelkner | safe thing about duplicate is that you can always get rid of old when it's more convenient | 17:59 |
| yvl | well ok then | 17:59 |
| th1a | Would the two versions be so entangled that it would be hard to get rid of the old ones later? | 17:59 |
| yvl | no | 18:00 |
| th1a | Duplication is ok with me then. | 18:00 |
| aelkner | that's two votes for duplication today :) | 18:00 |
| yvl | just that amount of code in the /browser folders could rise significantly | 18:00 |
| yvl | and people can get lost | 18:00 |
| * yvl is +0.1 for duplication this time ;) | 18:00 | |
| th1a | OK. | 18:01 |
| yvl | thanks for making this easy for me :) | 18:01 |
| th1a | Done now, yvl? | 18:01 |
| yvl | yes, please move on | 18:01 |
| menesis | ... | 18:01 |
| th1a | menesis? | 18:01 |
| aelkner | yvl, it should be easy, XP and all | 18:01 |
| yvl | :D | 18:01 |
| menesis | I have merged Alan's branches | 18:01 |
| aelkner | menesis, thanks | 18:02 |
| menesis | in gradebook, requirement_scoresystems and journal_data | 18:02 |
| menesis | and term_linkage in schooltool | 18:02 |
| aelkner | i should check all my branches briefly to confirm | 18:02 |
| menesis | also there is journal's remove_term_grading branch, will finish after the meeting | 18:03 |
| menesis | then, I split gradebook ftests in two layers | 18:03 |
| menesis | one with journal, one without | 18:03 |
| menesis | so there is a journal test dependency | 18:04 |
| aelkner | i should delete lp:~aelkner/schooltool.gradebook/custom_scoresystems as i ended up redoing in the branch you merged | 18:04 |
| menesis | but both paths are tested now | 18:04 |
| menesis | aelkner: yes, please | 18:04 |
| aelkner | done | 18:04 |
| menesis | to be honest I have left one ftest untouched, rml_student.txt, because it is large | 18:05 |
| menesis | and haven't looked at coverage | 18:05 |
| aelkner | menesis, https://code.launchpad.net/~aelkner/schooltool.lyceum.journal/remove_term_grading? | 18:06 |
| menesis | but mostly gradebook is tested without journal, and there are separate test to test just the journal integration | 18:06 |
| menesis | aelkner: not pushed yet, will do soon after the meeting | 18:07 |
| menesis | that's about the branches | 18:07 |
| menesis | then I did some cleanup work in lp:~menesis/schooltool/cleanup | 18:08 |
| menesis | removed setupdata | 18:08 |
| aelkner | this one is old: https://code.launchpad.net/~aelkner/schooltool.lyceum.journal/december_fixes | 18:08 |
| menesis | removed help | 18:08 |
| aelkner | should i delete it? | 18:08 |
| aelkner | btw, how does one visually see in the launchpad branch view if there are new revisions since last merge? | 18:09 |
| menesis | aelkner: yes, you can see it is Merged | 18:09 |
| menesis | then you can remove it | 18:10 |
| aelkner | ah, i see the date of the merge is later than the last revision | 18:10 |
| menesis | don't think you can easily see that on launchpad | 18:10 |
| aelkner | ok, deleted | 18:10 |
| th1a | OK, anything else, menesis? | 18:11 |
| menesis | ok, so I deleted SchoolTool Help, https://bugs.launchpad.net/bugs/789157 | 18:11 |
| menesis | is it OK? | 18:11 |
| th1a | Yes. | 18:12 |
| menesis | good | 18:12 |
| aelkner | ok, so all my branches are gone except the new popup one and the remove_term_grading | 18:13 |
| menesis | removing help, and also making API Docs/Introspector optional | 18:13 |
| aelkner | you will remove the second one when you finish pushing, right? | 18:13 |
| menesis | allowed me to remove some 5 zope dependencies | 18:13 |
| th1a | Cool. | 18:13 |
| menesis | aelkner: I cannot remove it, but it will show up as Merged, so not in the usual "All active branches" view | 18:14 |
| aelkner | ah, ok, just as well | 18:14 |
| menesis | before that I removed 5 more dependencies by including only the needed zcml, not all zope.app.zcmlfiles | 18:15 |
| aelkner | so i could have deactivated the branches i just deleted, true? | 18:15 |
| aelkner | oh, and sorry for interrupting your thread | 18:15 |
| menesis | and maybe can drop some more | 18:15 |
| menesis | will merge this cleanup to trunk so that less code is included and tested, maybe tests will get a little faster :) | 18:16 |
| th1a | Anything else? | 18:17 |
| menesis | aelkner: it may be useful for some time to leave the branches there, if bugs are linked to it, or you plan to continue | 18:17 |
| aelkner | how do i deactivate a branch? | 18:18 |
| menesis | you can click "Change branch details" in the actions menu on the right and change branch status | 18:18 |
| menesis | to Merged, Abandoned, or Development | 18:18 |
| aelkner | cool, thanks | 18:18 |
| menesis | but you can also delete the branch | 18:18 |
| menesis | many old branches no longer work | 18:19 |
| aelkner | true | 18:19 |
| *** fsufitch has joined #schooltool | 18:19 | |
| menesis | because I broke them with incorrect upgrade to 2a format | 18:19 |
| menesis | th1a: did some more things but nothing important | 18:20 |
| th1a | OK. Thanks menesis. | 18:20 |
| menesis | tried to help David, tested schooltool with ZTK 1.1 because jinty asked me if it is OK to use the latest zope.testbrowser, released a random zope package, fixed some mistakes in Debian packages, etc.. | 18:21 |
| th1a | Let's plan on meeting an hour early next week on Monday, assuming it will be an extra long meeting. | 18:21 |
| replaceafill | :| | 18:22 |
| * replaceafill is ok with it :) | 18:22 | |
| menesis | is it not too early for you in Americas? | 18:22 |
| th1a | And generally plan on meeting informally around this time every day the next two weeks. | 18:22 |
| replaceafill | 6:30 am here :P | 18:22 |
| aelkner | i'm fine with it | 18:22 |
| th1a | Ah... yes, no daylight savings time in El Salvador. | 18:23 |
| replaceafill | but it's ok | 18:23 |
| th1a | Well, can yvl and menesis plan on staying later? | 18:23 |
| yvl | it's ok with me | 18:23 |
| replaceafill | i don't mind | 18:23 |
| replaceafill | th1a, starting at 8:30 your time | 18:23 |
| menesis | I can | 18:23 |
| th1a | OK, let's start early. | 18:24 |
| menesis | I usually go home and hour from now | 18:24 |
| th1a | And plan on being available the regular meeting time as much as possible during the sprint. | 18:24 |
| yvl | sure | 18:24 |
| th1a | OK, thanks guys. Things are going to get busy, and fun. | 18:24 |
| yvl | it's going to be fun! | 18:24 |
| th1a | Have a great week! | 18:24 |
| * th1a drops the bag of gravel. | 18:25 | |
| replaceafill | thanks everybody | 18:25 |
| yvl | great week to you all! | 18:25 |
| aelkner | yes, looking forward to it | 18:25 |
| aelkner | great week everyone | 18:25 |
| replaceafill | yvl could you please comment on the pyquiz thread? i mean not now | 18:27 |
| replaceafill | but in a future email :) | 18:27 |
| * replaceafill doesn't think of it as urgent | 18:27 | |
| aelkner | replaceafill, could you attach me to the thread, i'm curious | 18:34 |
| replaceafill | aelkner it's on the dev list :/ | 18:37 |
| replaceafill | "Use of SchoolTool to authenticate users in pyquiz" | 18:37 |
| aelkner | ah :) | 18:40 |
| *** alga has joined #schooltool | 18:49 | |
| *** jelkner has quit IRC | 19:11 | |
| fsufitch | aelkner: ping | 19:34 |
| aelkner | fsufitch, hey | 19:39 |
| fsufitch | i got a question for you | 19:40 |
| aelkner | shoot | 19:40 |
| fsufitch | i was working on the whole "readonly" (actually @property) fields for CurrentCourseInfo | 19:40 |
| fsufitch | and there's a slight problem: the credits and description field are required as they are in schooltool.courseinfo.interfaces.ICourseInfo, but are *not* required in schooltool.course.interfaces.ICourse | 19:41 |
| fsufitch | is this intentional, or a mismatch? | 19:41 |
| aelkner | good point | 19:41 |
| aelkner | it's a case where schooltool core doesn't want to require those fields, but schooltool.courseinfo would | 19:42 |
| fsufitch | okay, so they need to stay required in courseinfo | 19:42 |
| fsufitch | got it :) | 19:42 |
| aelkner | you could check with dwelsh, but my first guess would be to say the interface matches his design | 19:43 |
| fsufitch | i tried calling him, but he didnt answer | 19:43 |
| aelkner | so you realize that you need setproperty | 19:43 |
| fsufitch | hmm yes | 19:44 |
| aelkner | because when the user sets the value in the form, you need to set the value in the corresponding course object | 19:44 |
| aelkner | ok, so you alread had that planned | 19:44 |
| fsufitch | yup | 19:44 |
| fsufitch | @property is fun to code :) | 19:44 |
| fsufitch | i also made an ICurrentCourseInfo -> ICourse adapter for convenience for these things | 19:44 |
| aelkner | yeah, i always like that feature in python | 19:44 |
| fsufitch | aelkner: so i just talked to dwelsh and he said to make everything but title and local course id optional, just like in schooltool | 19:50 |
| *** menesis has quit IRC | 19:51 | |
| fsufitch | brb, i need a bite to eat | 19:53 |
| aelkner | fsufitch, good input from dwelsh | 20:04 |
| fsufitch | it actually makes my work much easier :) | 20:05 |
| fsufitch | aelkner: this actually means i get to remove the tests for submitting an empty form, since the course_id and title will already be filled in anyway (because of the redirect) | 20:10 |
| th1a | aelkner: ayt? | 20:29 |
| aelkner | i'm here | 20:29 |
| th1a | Did you ever hack out deployed reportsheets for lehmann? | 20:29 |
| aelkner | way back when, i had to write code to remove his redundant deployed reportsheets | 20:30 |
| aelkner | but that code is gone now, not a part of schooltool | 20:30 |
| aelkner | why do you ask? | 20:30 |
| aelkner | th1a, i replied to your email | 20:31 |
| aelkner | speaking of hacking out deployed report sheets, we could use a warning when people try to deploy the same report sheet twice | 20:32 |
| *** menesis has joined #schooltool | 20:33 | |
| aelkner | i could add a bug for that, but i thought i'd chek with you here first | 20:33 |
| aelkner | the idea is, if the report sheet template __name__ which is included in the deployed __name__ | 20:33 |
| aelkner | is already present in the sections for the term, we could give a confirmation view saying that it is already deployed | 20:34 |
| aelkner | allowing the user to deploy the same template twice if they so desire | 20:34 |
| aelkner | there is a case where one might want to | 20:34 |
| aelkner | but having it happen without warning leads to what lehmann did | 20:34 |
| aelkner | i know that adding a removal feature at least takes away the need to hack the data | 20:35 |
| aelkner | actually, it's not remove, it's hide, right? | 20:35 |
| aelkner | but still, stopping the user from accidentally double-deploying would be a good feature | 20:36 |
| th1a | Don't you have a copy of the old code removal code? | 20:36 |
| aelkner | why would you be interested in that? | 20:36 |
| th1a | Because we have a user with the same problem. | 20:36 |
| th1a | And I'd like you to not lose code I pay you to write. | 20:36 |
| aelkner | and they can't wait for the hide feature i suppose | 20:36 |
| th1a | Well, they can wait longer if we just fix the db is kind of the point. | 20:37 |
| aelkner | let me tell you, that process was a pain | 20:37 |
| aelkner | i had to look over the data in a special trace to see which worksheets had scores filled in | 20:38 |
| aelkner | and then decide which one to delete (or ask lehman i think) | 20:38 |
| aelkner | then, hard-code the patch for that worksheet | 20:38 |
| th1a | So you'd just as soon fix the problem correctly. | 20:39 |
| aelkner | i probably still have that code around, but i'm just saying, it's not gong to work as is | 20:39 |
| th1a | This case is easier because there is just one we need to blow away. | 20:39 |
| aelkner | corretly, define please | 20:39 |
| th1a | So users can hide report sheets. | 20:39 |
| aelkner | if users can hide report sheets is correctly, then yes, it would be easier to just make that feature work | 20:40 |
| th1a | OK. That's fine. | 20:40 |
| aelkner | then get the fix to the user somehow (debs or sandbox) | 20:40 |
| aelkner | fsufitch, let's think about this a second | 20:42 |
| fsufitch | aelkner: wait what? | 20:43 |
| fsufitch | where did i come into this discussion? | 20:43 |
| aelkner | if the user is creating CurrentCourseInfo, then the add form will have the ICourse fields already filled in | 20:43 |
| fsufitch | oh, that | 20:43 |
| fsufitch | yes | 20:43 |
| aelkner | but they should be able to change them, too, or should they? | 20:43 |
| th1a | debs aelkner. We really don't want users using sandboxes. | 20:43 |
| aelkner | if they can wait for the deb pipeline, then debs would be best obviously | 20:44 |
| aelkner | fsufitch, i didn't think of that before, but is the CurrentCourseInfo form over-crowded with ICourse fields | 20:45 |
| aelkner | or is it convenient for the user to not have to call up the other ICourse edit form | 20:45 |
| fsufitch | no, it's only title, description, credits, and government_id | 20:46 |
| aelkner | i'm not sure what would be preferable | 20:46 |
| aelkner | so they stay on the form then? | 20:46 |
| fsufitch | i was going to make them hidden fields | 20:46 |
| aelkner | but that's what i'm asking | 20:46 |
| fsufitch | but i can make them show up and be editable, and propagate the changes to the Course | 20:46 |
| aelkner | right, if that is what dwelsh would prefer | 20:46 |
| aelkner | i'd ask him, because if he says to leave them off the form (being that they are redundant) | 20:47 |
| aelkner | then you have no reason to carry the fields at all hidden or otherwise | 20:47 |
| fsufitch | ok | 20:47 |
| fsufitch | and actually yes there is, because they're defined in the CourseInfo interface :) | 20:48 |
| fsufitch | and necessary in PublishedCourseInfo and CourseInfoRevision | 20:48 |
| aelkner | but don't try to talk him into either choice | 20:48 |
| aelkner | right, they are definitely necessary in those two cases | 20:48 |
| aelkner | come to think of it, dwelsh wold probably expect the fields to be there | 20:49 |
| aelkner | since they are there for the other two cases, why should it be different for CurrentCoureInfo? | 20:50 |
| fsufitch | i mean, they're *there* in the display form and such, but just not in the add/edit forms | 20:50 |
| aelkner | they should be in the add/edit form as well | 20:50 |
| fsufitch | or at least, that's how i was going to code it | 20:50 |
| aelkner | it just makes sense, i think | 20:51 |
| fsufitch | so they should be there, and they should change the original Course object | 20:51 |
| fsufitch | that makes sense actually | 20:51 |
| aelkner | right, exactly | 20:51 |
| fsufitch | okay | 20:51 |
| aelkner | why should the user have to think any differently about one versus the other | 20:51 |
| aelkner | so it's decided, great | 20:51 |
| fsufitch | ok | 20:53 |
| *** asharma_ has quit IRC | 22:04 | |
| *** fsufitch has quit IRC | 22:08 | |
| *** menesis has quit IRC | 23:58 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!