*** povbot has joined #zope3-dev | 00:37 | |
*** jinty has quit IRC | 00:44 | |
*** sashav has quit IRC | 00:50 | |
*** zbir has quit IRC | 00:59 | |
*** projekt01 has left #zope3-dev | 01:08 | |
*** tanghus has joined #zope3-dev | 01:09 | |
*** TresEquis has quit IRC | 01:20 | |
*** benji has quit IRC | 01:39 | |
*** zbir has joined #zope3-dev | 01:55 | |
*** tarek has quit IRC | 02:01 | |
*** niemeyer has quit IRC | 02:19 | |
*** RaFromBRC is now known as RaFromBRC|away | 02:34 | |
*** RaFromBRC|away is now known as RaFromBRC | 02:55 | |
*** pcardune has joined #zope3-dev | 03:08 | |
*** taveren has joined #zope3-dev | 03:36 | |
*** dunny has quit IRC | 03:45 | |
*** dunny has joined #zope3-dev | 04:32 | |
*** TrevorP has quit IRC | 05:06 | |
*** natea has joined #zope3-dev | 05:06 | |
*** TrevorP has joined #zope3-dev | 05:11 | |
*** zbir has joined #zope3-dev | 05:17 | |
*** TrevorP has quit IRC | 05:20 | |
*** TrevorP has joined #zope3-dev | 05:21 | |
*** TrevorP has quit IRC | 05:22 | |
*** tristil has joined #zope3-dev | 05:22 | |
*** srichter has quit IRC | 05:23 | |
*** stub has joined #zope3-dev | 05:26 | |
*** TrevorP has joined #zope3-dev | 05:31 | |
*** RaFromBRC has quit IRC | 06:03 | |
*** rockyburt has quit IRC | 06:38 | |
*** MiUlEr has joined #zope3-dev | 06:48 | |
*** MiUlEr is now known as MiUlErlog | 07:18 | |
*** taveren has left #zope3-dev | 07:28 | |
*** sm has quit IRC | 08:02 | |
*** sashav has joined #zope3-dev | 08:13 | |
*** srichter has joined #zope3-dev | 08:16 | |
*** zopePloneConsult has joined #zope3-dev | 08:19 | |
*** eins has joined #zope3-dev | 08:21 | |
eins | hi | 08:21 |
---|---|---|
*** sashav has quit IRC | 08:26 | |
*** WebMaven has quit IRC | 08:50 | |
*** srichter has quit IRC | 08:50 | |
*** Theuni has joined #zope3-dev | 09:02 | |
*** strichter has joined #zope3-dev | 09:03 | |
*** zagy has joined #zope3-dev | 09:04 | |
*** Aiste has quit IRC | 09:07 | |
*** Aiste has joined #zope3-dev | 09:10 | |
*** hdima has joined #zope3-dev | 09:13 | |
*** Aiste has quit IRC | 09:13 | |
*** Aiste has joined #zope3-dev | 09:14 | |
*** _srichter has joined #zope3-dev | 09:17 | |
*** strichter has quit IRC | 09:18 | |
*** povbot has joined #zope3-dev | 09:36 | |
*** _srichter has quit IRC | 09:37 | |
*** romanofski has joined #zope3-dev | 09:41 | |
romanofski | moin | 09:42 |
eins | hi romanofski :) | 09:47 |
* romanofski waves to eins | 09:48 | |
*** j-w has joined #zope3-dev | 09:49 | |
*** Theuni has quit IRC | 09:53 | |
*** Theuni has joined #zope3-dev | 09:58 | |
*** tarek has joined #zope3-dev | 09:59 | |
*** zagy has quit IRC | 10:02 | |
*** zagy has joined #zope3-dev | 10:02 | |
*** strichter has joined #zope3-dev | 10:03 | |
*** tarek has quit IRC | 10:03 | |
*** sashav has joined #zope3-dev | 10:06 | |
*** tristil has quit IRC | 10:14 | |
*** MJ has quit IRC | 10:17 | |
*** dunny has quit IRC | 10:19 | |
*** stub has quit IRC | 10:19 | |
*** strichter has quit IRC | 10:34 | |
*** dunny has joined #zope3-dev | 10:48 | |
*** dunny has quit IRC | 10:51 | |
*** dunny has joined #zope3-dev | 10:51 | |
*** romanofski has quit IRC | 11:19 | |
*** romanofski has joined #zope3-dev | 11:19 | |
*** srichter has joined #zope3-dev | 11:24 | |
*** MJ has joined #zope3-dev | 11:34 | |
*** Theuni has quit IRC | 11:36 | |
*** Theuni has joined #zope3-dev | 11:37 | |
*** ChanServ sets mode: +o srichter | 11:40 | |
*** stub has joined #zope3-dev | 11:42 | |
*** Theuni has quit IRC | 12:11 | |
*** jinty has joined #zope3-dev | 12:13 | |
*** Theuni has joined #zope3-dev | 12:14 | |
*** alga has joined #zope3-dev | 12:22 | |
*** Aiste has quit IRC | 12:28 | |
*** dunny has quit IRC | 12:31 | |
*** d2m has quit IRC | 12:38 | |
*** d2m has joined #zope3-dev | 12:39 | |
*** dunny has joined #zope3-dev | 12:46 | |
*** J1m_ has joined #zope3-dev | 12:49 | |
*** mkerrin has joined #zope3-dev | 12:49 | |
*** mgedmin has joined #zope3-dev | 12:58 | |
*** ignas has joined #zope3-dev | 13:02 | |
*** Aiste has joined #zope3-dev | 13:07 | |
*** M1 has joined #zope3-dev | 13:07 | |
*** MJ has quit IRC | 13:08 | |
*** M1 is now known as MJ | 13:08 | |
*** rockyburt has joined #zope3-dev | 13:10 | |
eins | how do I get interfaces that are provided by some class? | 13:14 |
srichter | from zope.interface import providedBy | 13:16 |
srichter | providedBy(obj_instance) | 13:16 |
srichter | but usually this is not a sensible query | 13:16 |
srichter | better: | 13:16 |
srichter | IMyInterface.providedBy(obj) | 13:17 |
eins | well I don't have IMyInterface there, I want to get it | 13:17 |
srichter | but how do you know to get it from this list? | 13:18 |
eins | providedBy() I need all interfaces that are provided | 13:19 |
eins | I need all interfaces that are provided | 13:19 |
srichter | what for? | 13:20 |
srichter | I have never needed this other than for APIDOC | 13:20 |
*** sashav has quit IRC | 13:20 | |
*** alga has quit IRC | 13:21 | |
*** alga has joined #zope3-dev | 13:22 | |
eins | just playing around. trying to get all attribute names from all interfaces that are provided by a class | 13:22 |
srichter | ah ok | 13:22 |
srichter | this is similar to the APIDOC case then | 13:22 |
eins | yup | 13:22 |
srichter | note that in real life you almost never want that, since you want control over what things you display | 13:23 |
eins | providedBy(object).__dict__['declared'] works but looks pretty ugly | 13:23 |
srichter | so you are usually working in the mode of addressing one interface at a time | 13:23 |
srichter | it should work without the __dict__ bit | 13:23 |
eins | not, it doesnt: TypeError: unsubscriptable object | 13:24 |
eins | :) | 13:24 |
eins | I thought so too.. | 13:24 |
srichter | mmh, ok | 13:24 |
srichter | let me check that | 13:24 |
srichter | ok, so providedBy returns a declaration | 13:27 |
srichter | a declaration extends specification | 13:28 |
srichter | and specification has a get() method | 13:28 |
srichter | I knew there was something. :-) | 13:28 |
srichter | providedBy(obj).get('myAttr') | 13:28 |
*** J1m_ has quit IRC | 13:29 | |
eins | thanks srichter ;) | 13:32 |
*** MiUlErlog has quit IRC | 13:34 | |
eins | specification even has interfaces() which is good: | 13:34 |
eins | providedBy(object).interfaces() | 13:34 |
eins | :) | 13:34 |
eins | now I have what I needed. thanks again srichter ;) | 13:35 |
srichter | you are welcome | 13:39 |
*** Aiste has quit IRC | 13:55 | |
*** dunny has quit IRC | 14:01 | |
srichter | mkerrin: do you think you'll finish the WebDAV stuff for the next release? | 14:24 |
mkerrin | srichter: unlikely - I have very little time at the moment. I really want to get back to it though. | 14:35 |
mkerrin | BTW - I am involved in a project that ported the PrimaGIS plone mapping product to Zope3, as a side project to get it to run under CPS via Five - you may be interested in knowing. | 14:37 |
*** jinty has quit IRC | 14:38 | |
*** jinty has joined #zope3-dev | 14:38 | |
*** Aiste has joined #zope3-dev | 14:42 | |
*** andres has joined #zope3-dev | 14:45 | |
srichter | mkerrin: very cool! | 14:51 |
mkerrin | srichter: hopefully I can get around to making a more formal announced next week instead a random remark on IRC | 14:56 |
*** Aiste has quit IRC | 14:57 | |
d2m | how would i override the loading of zope.app.basicskin/rotterdam in zope/app/configure.zcml (which is loaded from site.zcml) ? | 15:01 |
srichter | mkerrin: he he; I just checked it out; it's pretty cool | 15:03 |
srichter | (the Zope 2 version that is) | 15:04 |
srichter | d2m: what do you try to accomplish? | 15:04 |
d2m | the skins are loaded by default, even when i want toi use my own skin, they get loaded (and are available throuf directives) | 15:05 |
d2m | i figured that i would need to patch zope/app/configure.zcml and browser.zcml (which is not what i want) | 15:06 |
d2m | srichter: in short, i do not want the skins to be available TTW | 15:08 |
srichter | ok | 15:10 |
srichter | you have to modify z.a.configure.zcml | 15:11 |
srichter | an alternative is to rewrite the site.zcml and *not* load zope/app/configure.zcml and build your own | 15:11 |
srichter | Schooltool is doing this | 15:11 |
efge | mkerrin: not z3 related, but you know there's a CPSGeo product? | 15:11 |
d2m | ok, i'll look there - thanks | 15:12 |
srichter | one big added benefit to the latter approach has the advantage that you can be more selective | 15:12 |
srichter | for example SchoolTool (including its not so small configuration leads in less than 2 secs on my computer in comparison to 4.4 secs for all of Zope 3 (without dev mode) | 15:12 |
efge | mkerrin: janguenot would like to discuss geo products with you, he tells me he'll email you or will find you on irc (too busy now :)) | 15:13 |
*** zbir has quit IRC | 15:22 | |
mkerrin | efge: np - I am just going out for some food now - but I will be happy to talk about any of the GEO related stuff | 15:28 |
*** niemeyer has joined #zope3-dev | 15:29 | |
*** faassen has joined #zope3-dev | 15:48 | |
*** sashav has joined #zope3-dev | 15:57 | |
*** benji has joined #zope3-dev | 15:59 | |
srichter | benji: how open are you guys to zc.table improvements? | 16:04 |
srichter | I have two things in mind: | 16:04 |
benji | quite open, srichter | 16:04 |
srichter | Have base CSS classes for all tags by default | 16:04 |
srichter | this would cover a *lot* of occasions for subclassing | 16:04 |
srichter | the second would be macro-based column cell rendering | 16:05 |
benji | I think default CSS classes would be good; perhaps with a common prefix | 16:05 |
srichter | I have some fairly complex columns and typing the stuff in Python is getting old quickly | 16:05 |
srichter | benji: right | 16:05 |
srichter | just something that you can change easily too | 16:05 |
benji | I don't quite get what you're saying about the macro-based cell rendering though | 16:06 |
srichter | like: formatter:tableClass = 'myclass' | 16:06 |
benji | (and it's been a while csince I looked at the code) | 16:06 |
srichter | benji: I have cells that are more than simple values or fields | 16:06 |
benji | right | 16:06 |
benji | and you're making your own column for them? | 16:06 |
srichter | they have links and display several things make decisions about icons etc | 16:06 |
srichter | yes | 16:06 |
srichter | but writing all this HTML in Python is getting old very quickly | 16:07 |
srichter | Thus I propose (as a base class not default) a formatter that contains a template that contains ZPT macros | 16:07 |
benji | so, a new column type that has a template it uses to format the cells, makes sense to me | 16:08 |
srichter | a special column (MacroColumn or PTColumn) will then use one of the macros in the template to render its cell value | 16:08 |
srichter | but I do not want to write a template for each and every column | 16:08 |
benji | why would it "use one of the macros in the template", and not just juse the whole template? | 16:08 |
srichter | then you have template proliferation :-) | 16:08 |
benji | disk space is cheap :) | 16:09 |
srichter | that's not the reason | 16:09 |
srichter | it's my sanity :-) | 16:09 |
benji | hah | 16:09 |
srichter | I think macros are usually perfect for small HTML snippets | 16:09 |
srichter | and I would have all column macros in one template together | 16:09 |
benji | I still don't like the idea of munging all the cell formatter PTs in one file and using macros to pull them out, but that shouldn't stop you fom doing it, that particular column can be private to you | 16:10 |
srichter | right | 16:10 |
benji | the beauty of componentization :) | 16:10 |
srichter | it would certainly be an addition instead of a replacement or extension | 16:10 |
srichter | :-) | 16:10 |
srichter | (I just would prefer also not maintaining the code in a separate project ;-) | 16:11 |
srichter | ok, I will make those changes | 16:12 |
*** gumpa has joined #zope3-dev | 16:12 | |
srichter | probably will take me while though | 16:13 |
srichter | but overall, I love zc.table; it's a lot of fun working with it | 16:13 |
srichter | benji: btw, how do you handle table widths? | 16:13 |
srichter | I mean column widths? | 16:13 |
benji | normally we don't force a width | 16:14 |
srichter | mmh, ok, I definitely need this | 16:14 |
benji | we then make things not wrap if neccesary, and also use an abbreviator to make long strings shorter | 16:15 |
srichter | well, I have to fulfill a specific design, so I do not have that choice :-( | 16:17 |
srichter | mmh, ok | 16:18 |
srichter | maybe I'll use the suggested hack from the README | 16:18 |
benji | ok | 16:19 |
*** zbir has joined #zope3-dev | 16:23 | |
*** tonico has quit IRC | 16:34 | |
*** hdima has quit IRC | 17:11 | |
*** andres has quit IRC | 17:16 | |
*** eins has quit IRC | 17:22 | |
*** natea has joined #zope3-dev | 17:34 | |
*** natea has joined #zope3-dev | 17:38 | |
*** sashav has quit IRC | 17:50 | |
*** stub has quit IRC | 17:54 | |
*** sawdog has joined #zope3-dev | 18:01 | |
*** sm has joined #zope3-dev | 18:05 | |
*** alga has quit IRC | 18:09 | |
*** j-w has quit IRC | 18:12 | |
*** baldtrol has joined #zope3-dev | 18:18 | |
baldtrol | i posted a sorta-related question to zope3-users mailing list a moment ago, but a fresh question has sprung to mind, and i thought it might be better brought up here... if i create an EditForm derivative with formlib, is it possible to present it through a viewlet? basically i'd like to build a user portal that allows a user to modify multiple sets of data associated to their profile from a single "dashboard" type interface. | 18:21 |
*** zopePloneConsult has left #zope3-dev | 18:22 | |
*** sm has quit IRC | 18:22 | |
*** sm has joined #zope3-dev | 18:22 | |
srichter | baldtrol: absolutely | 18:22 |
srichter | just make the edit form also comply to the viewlet API | 18:23 |
baldtrol | srichter: i figured ;) would you just make the "render" method a call to __call__? | 18:23 |
baldtrol | the render method on the viewlet, i mean | 18:23 |
srichter | they both share the update/render pattern | 18:23 |
srichter | no, just do not implement __call__ | 18:23 |
srichter | it is not required b any API | 18:23 |
srichter | well, that's not true | 18:23 |
srichter | it is required for a standalone edit form, but not if used in a viewlet | 18:24 |
baldtrol | hmm... ok. i had always assumed that __call__ was kinda magiced behind the scenes when you gave it a template | 18:24 |
srichter | nope | 18:24 |
philiKON | srichter, got a sec? | 18:24 |
srichter | all that __call__ usually does is: self.template() | 18:24 |
srichter | all that __call__ usually does is: return self.template() | 18:24 |
srichter | philiKON: not really, but shoot | 18:24 |
baldtrol | right, right. | 18:24 |
philiKON | srichter, ok, i'll make it short. two things: | 18:25 |
philiKON | 1. zope.app.locales contains a) translations for the 'zope' domain, b) some i18n tools | 18:25 |
philiKON | i think the i18n tools (extractor) should move to zope.i18n | 18:25 |
srichter | right | 18:25 |
philiKON | with the translations, i'm not sure | 18:25 |
philiKON | zope.formlib has introduced its own translation domain | 18:25 |
srichter | ok to the i18n tools moving | 18:25 |
srichter | I wonder why it was not there... | 18:25 |
philiKON | should translations be kept centrally or in the individual packages? | 18:25 |
philiKON | srichter, because we were lazy ;) | 18:26 |
srichter | well, honestly I am now at a point where I would like each package maintain its own translation | 18:26 |
srichter | this has two drawbacks: | 18:26 |
srichter | (1) you need to fix the translation utility to accept multiple files for the same domain | 18:26 |
srichter | (2) Will cause duplications in translations (lot's of them too, probably) | 18:27 |
srichter | I think leaving them in zope.app for now and stating that they are app server specific is the sanest thing to do | 18:27 |
*** rockyburt has quit IRC | 18:27 | |
srichter | I am really torn here | 18:27 |
srichter | since the issue runs even deeper | 18:28 |
*** rockyburt has joined #zope3-dev | 18:28 | |
philiKON | yep | 18:28 |
philiKON | ad (1): | 18:28 |
srichter | when I write a custom application, I often want to control the translations | 18:28 |
philiKON | each zope.* package could maintain its own domain | 18:28 |
philiKON | that would solve the multiple files thing | 18:28 |
srichter | now, I am using formlib in an applications and part of the messages are in the zope domain and some in my custom one | 18:28 |
philiKON | ad (2): yep :( | 18:28 |
srichter | that really sucks | 18:28 |
philiKON | yes | 18:29 |
philiKON | a central domain is easier in lots of ways | 18:29 |
philiKON | i wonder how plone does it for the gazillion products they have | 18:29 |
srichter | me too | 18:29 |
srichter | rockyburt: ???? (see above) | 18:29 |
rockyburt | hm? | 18:30 |
rockyburt | asking about domains? | 18:30 |
philiKON | rockyburt, yes | 18:30 |
rockyburt | to be quite frank i do very little i18n | 18:30 |
philiKON | rockyburt, does archetypes have its own i18n domain? | 18:30 |
rockyburt | oh, lemme check | 18:30 |
srichter | philiKON: I think the best would be to start treating domains more abstractly | 18:30 |
srichter | philiKON: so when I have my custom project, I collect all messages from formlib and translate them myself | 18:31 |
rockyburt | it looks like archetypes uses the plone i18n domain | 18:31 |
philiKON | i see | 18:31 |
srichter | I could use the standard zope PO files as a translation memory | 18:31 |
rockyburt | at least the couple .pt's i just checked have i18n:domain="plone" | 18:31 |
rockyburt | in archetypes | 18:31 |
srichter | btw, KBabel now supports translation memories! | 18:32 |
philiKON | perhaps for now it would be best to move the extractor tool etc. to zope.i18n and zope.app.locales to zope.translations perhaps? | 18:33 |
srichter | I would leave the POs in zope.app | 18:34 |
srichter | they are app server specific | 18:34 |
philiKON | except that they aren't :) | 18:34 |
philiKON | translations for stuff in zope.* should be accessible too | 18:35 |
philiKON | perhaps we should postpone this issue | 18:35 |
srichter | yep | 18:35 |
srichter | this needs some really hard thinking | 18:35 |
philiKON | but we'll have to deal with it at some point | 18:35 |
srichter | (darn, and I thought this subject was done with) | 18:36 |
philiKON | same as with the ISite thing | 18:36 |
srichter | ahat about ISite? | 18:36 |
philiKON | well, it needs to move somewhere | 18:36 |
philiKON | but j1m doesn't want it in zope.component | 18:36 |
srichter | I would put it in zope.local or zope.localcomponent | 18:37 |
philiKON | that would work. i suggested zope.site. | 18:37 |
srichter | even zope.site would be ok | 18:37 |
srichter | :-) | 18:37 |
*** pcardune has quit IRC | 18:40 | |
philiKON | srichter, another suggestion | 18:46 |
philiKON | zope.formlib.page.Page feels misplaced | 18:46 |
philiKON | i'd like to move it to zope.publisher.browser.BrowserPage | 18:46 |
srichter | +1 | 18:47 |
srichter | it should also have an abstract __call__ method | 18:47 |
baldtrol | +.0005 (it'd be +1, but i multiplied it by how much my vote should really count ;) ) | 18:48 |
srichter | philiKON: formlib itself needs serious cleanup as well | 18:49 |
philiKON | haha | 18:49 |
philiKON | yeah @ cleanup | 18:49 |
srichter | philiKON: the test coverage and documentation must be improved | 18:49 |
srichter | philiKON: also, it violates naming conventions left and right | 18:49 |
philiKON | dunno what you mean by "abstract __call__", but it *does* have a __call__ that raises NotImplementedError, i think | 18:49 |
philiKON | ah, you're right | 18:50 |
srichter | (I am very bumped that I did not have a closer look before it was added to the core) | 18:50 |
philiKON | it doesn't provide a __call__ | 18:50 |
srichter | philiKON: __call__ right | 18:50 |
philiKON | so, it should provide a __call__ that raises NotImplementedError | 18:50 |
philiKON | :) | 18:50 |
srichter | yep | 18:51 |
*** tonico has joined #zope3-dev | 19:12 | |
*** srichter has quit IRC | 19:13 | |
*** MJ has quit IRC | 19:22 | |
*** jinty has quit IRC | 19:45 | |
*** MJ has joined #zope3-dev | 19:50 | |
*** rockyburt has quit IRC | 19:53 | |
*** rockyburt has joined #zope3-dev | 19:54 | |
*** srichter has joined #zope3-dev | 20:00 | |
*** ChanServ sets mode: +o srichter | 20:00 | |
*** alga has joined #zope3-dev | 20:13 | |
*** sm has quit IRC | 20:20 | |
*** faassen has quit IRC | 20:22 | |
*** sm has joined #zope3-dev | 20:22 | |
*** ignas has quit IRC | 20:28 | |
*** efge has quit IRC | 20:37 | |
*** zbir has quit IRC | 21:07 | |
*** zbir has joined #zope3-dev | 21:13 | |
sawdog | hey zack | 21:16 |
baldtrol | srichter: i've managed to place a form in a viewlet (which wasn't terribly difficult, as you indicated ;) ), but i still run into the problem where the form render seems to re-render the whole zmi inside of itself. if i, in tal, get to where i can do a tal:content="python: viewlet.template" it shows that it's using the template i assigned it in the zcml, but my template in no way re-renders the zmi. it's, as a matter of fact (to make sure i wasn't doin | 21:26 |
baldtrol | i tried creating an adapter for my own named template and assigning that named template to template = namedtemplate.NamedTemplate('mytemplate') in my form class, but it threw an error :\ | 21:27 |
*** tristil has joined #zope3-dev | 21:42 | |
*** sashav has joined #zope3-dev | 21:42 | |
*** alga has quit IRC | 21:55 | |
*** deo has joined #zope3-dev | 22:03 | |
*** rockyburt is now known as rockyburt|away | 22:03 | |
*** mexiKON has joined #zope3-dev | 22:09 | |
*** jinty has joined #zope3-dev | 22:18 | |
*** mgedmin has quit IRC | 22:18 | |
*** philiKON has quit IRC | 22:19 | |
srichter | baldtrol: of course you cannot just use the entire default template | 22:27 |
srichter | you have to use the macro that only displays the form | 22:27 |
*** whit is now known as whit|out | 22:56 | |
baldtrol | srichter: i thought, from looking at it, that that's what the subpageform.pt would do, if i associated it. the way it reads, the only macro it's implementing is form. | 23:02 |
baldtrol | (sorry for the delay... work duties ;) ) | 23:02 |
*** kamalgill has joined #zope3-dev | 23:10 | |
baldtrol | kamalgill: thanks again man :) | 23:10 |
*** rockyburt|away has quit IRC | 23:10 | |
kamalgill | baldtrol: sorry? thx for? | 23:11 |
kamalgill | oh, got it | 23:11 |
baldtrol | <-- pete from thig (sorry) | 23:11 |
kamalgill | right, now i understand :) | 23:11 |
kamalgill | you're welcome--looking forward to meeting you in SF | 23:12 |
baldtrol | yessir, quite. | 23:12 |
kamalgill | btw, anyone here know the latest status of the new zope3.org? | 23:14 |
kamalgill | anyone working on zope3.org? | 23:15 |
kamalgill | anyone else here think we could use a kick-ass zope3.org site? | 23:16 |
*** mcdonc has joined #zope3-dev | 23:16 | |
baldtrol | that last one i can say yes to ;) | 23:16 |
*** tanghus has quit IRC | 23:17 | |
kamalgill | baldtrol: fantastic. | 23:17 |
kamalgill | anyone else? | 23:17 |
*** tristil has quit IRC | 23:17 | |
*** tanghus has joined #zope3-dev | 23:18 | |
kamalgill | i'd like to volunteer to help with the new zope3.org site, but i'm not sure whom to contact to get this going | 23:20 |
benji | someone is working on it kamalgill, let me see if the svn.zope.org checkins show who... | 23:20 |
kamalgill | benji: thx | 23:20 |
benji | user name: oestermeier | 23:21 |
benji | the code is in /zope3org/trunk | 23:21 |
kamalgill | k | 23:21 |
kamalgill | is that Uwe Oestermeier? | 23:22 |
benji | I would assume so :) | 23:22 |
baldtrol | later on everyone | 23:23 |
*** baldtrol has left #zope3-dev | 23:23 | |
*** jinty has quit IRC | 23:26 | |
*** benji has quit IRC | 23:32 | |
*** whit|out is now known as whit | 23:33 | |
*** mkerrin has quit IRC | 23:41 | |
*** tanghus_ has joined #zope3-dev | 23:48 | |
*** sawdog has left #zope3-dev | 23:52 | |
*** J1m_ has joined #zope3-dev | 23:56 | |
*** Aiste has joined #zope3-dev | 23:57 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!