1 2012-07-08T00:05:50 *** spy
2 2012-07-08T00:12:41 *** spy
3 2012-07-08T00:32:34 *** RogerHaase
4 2012-07-08T00:44:23 *** spy
5 2012-07-08T01:14:26 *** dwcramer
6 2012-07-08T05:51:45 *** dwcramer
7 2012-07-08T08:00:00 *** jaiditya
8 2012-07-08T09:10:04 <CIA-54> Reimar Bauer <rb.proj AT googlemail DOT com> default * 612:8f2aa479f8cd extensions/data/plugin/parser/bbb_create.py: bbb: removed print statement
9 2012-07-08T10:53:57 *** mfandreas
10 2012-07-08T11:00:49 *** brickZA
11 2012-07-08T11:28:11 *** spy
12 2012-07-08T11:41:16 <dreimark> spy: reviewed
13 2012-07-08T12:25:45 <spy> dreimark: thank you, replied
14 2012-07-08T13:52:06 <dreimark> bbl
15 2012-07-08T13:52:14 <dreimark> spy: done
16 2012-07-08T13:56:33 *** brickZA
17 2012-07-08T13:57:58 *** brickZA
18 2012-07-08T14:24:49 <CIA-54> Thomas Waldmann <tw AT waldmann-edv DOT de> default * 1415:ac21bb448ba8 2.0/ (4 files in 3 dirs): implemented mongodb store, add pymongo to setup.py
19 2012-07-08T14:32:13 *** moin3
20 2012-07-08T14:32:22 *** moin3
21 2012-07-08T14:32:38 *** josep
22 2012-07-08T14:38:12 <ThomasWaldmann> moin
23 2012-07-08T15:57:05 <xiaq> moin
24 2012-07-08T15:57:43 <xiaq> i have some more ideas about the render-method (or whatever) stuff, after a little discussion with spy
25 2012-07-08T16:00:09 *** brickZA
26 2012-07-08T16:00:44 <xiaq> instead of render-method or meta-schema, use a fuzzy name "item-type" (or just "itemtype" to be consistent with "contenttype")
27 2012-07-08T16:02:45 <xiaq> it tells two things - the schema of metadata, how +view and +modify renders the ui (for itemtype=ticket, render a ticket editing page on +view and prohibit +modify. for itemtype=blog-post, render a bloggy ui for +view and +modify) - the polymorphism is inspired from spy's "modify_form_factory" (http://codereview.appspot.com/6356070/diff/1/MoinMoin/items/__init__.py)
28 2012-07-08T16:03:34 <xiaq> items of each "itemtype" is kept in a *separate whoosh indexer*.
29 2012-07-08T16:04:41 <xiaq> actually the separation of whoosh indexer by using "itemtype" is what i think makes most sense. whoosh assumes a homogenous structure, but with the introduction of ticket-specific and blogpost-specific metadata keys, this is no longer appropriate
30 2012-07-08T16:06:19 <xiaq> for the frontend side the itemtype only affects the behavior of +view, so +highlight, +raw, +download etc. will be still always available
31 2012-07-08T16:07:34 <xiaq> further we can make the mechanism more transparent by allowing "+view.ticket" "+view.blogpost" etc. to make the frontend behave as if itemtype=ticket or itemtype=blogpost. in that case, the indexer is *not* affected.
32 2012-07-08T16:17:07 <ThomasWaldmann> it is no problem if you do not provide all metadata keys
33 2012-07-08T16:17:20 <ThomasWaldmann> to whoosh
34 2012-07-08T16:18:09 <ThomasWaldmann> did you just play through all the different cases already present on the EP?
35 2012-07-08T16:22:20 <ThomasWaldmann> xiaq: ^
36 2012-07-08T16:37:59 <xiaq> ThomasWaldmann: yes whoosh doesn't need to know all the metadata keys, but we need such an index for all tickets (or an index for all blog posts, etc.) - sort all tickets according to priority, show all tickets with assigned_to unset, etc.
37 2012-07-08T16:38:24 <xiaq> a separate indexer for all tickets sounds appropriate doesn't it :)
38 2012-07-08T16:39:15 <xiaq> as for the list starting from line 110, let me enumerate those:
39 2012-07-08T16:39:36 *** mfandreas
40 2012-07-08T16:40:56 <xiaq> (before that let me say again that i'd like itemtype to affect the how +view behaves (ie. +view polymorphs according to itemtype. and contenttype too, that's another story which i'll go into a bit later)
41 2012-07-08T16:41:16 <xiaq> (and the good old +highlight, +raw, +download, etc. will always be available)
42 2012-07-08T16:43:58 <ThomasWaldmann> no, you don't necessarily need a separate index, you just need to know what document is a ticket, what a blog, etc.
43 2012-07-08T16:44:52 <ThomasWaldmann> we already have 2 different kinds of indexes, I'ld rather suggest not to multiply that by N if it can work in another way also
44 2012-07-08T16:45:07 <xiaq> hm
45 2012-07-08T16:45:11 <xiaq> http://packages.python.org/Whoosh/quickstart.html#the-index-and-schema-objects:
46 2012-07-08T16:45:19 <xiaq> To begin using Whoosh, you need an index object. The first time you create an index, you must define the index’s schema. The schema lists the fields in the index.
47 2012-07-08T16:46:09 <xiaq> different metadata keys => different (whoosh) schemas => separate indexes. reasonable?
48 2012-07-08T16:46:42 <ThomasWaldmann> schema keys = U(all key sets needed)
49 2012-07-08T16:47:53 <ThomasWaldmann> otherwise we have 2 (latest+all) * N (blog,tickets,wiki,...) + whatever bretonium comes up with
50 2012-07-08T16:48:31 <ThomasWaldmann> and every index that is kept open consumes quite some file handles
51 2012-07-08T16:48:59 <ThomasWaldmann> (that thing got a little better recently, but was an issue before that, even with what moin used back then)
52 2012-07-08T16:50:24 <xiaq> ThomasWaldmann: hm, but wouldn't be nice if we could keep the namespace of (say) ticket metadata schema and blogpost metadata schema separate - eg. both have some metadata key "foo" but with different types (and semantics)
53 2012-07-08T16:51:21 <xiaq> it makes it easier to plug things, when i work on tickets i don't need to worry about what spy call his blogpost meta keys since we're not messing up the same global namespace
54 2012-07-08T16:51:57 <ThomasWaldmann> well, nice on the one hand, but it would be confusing if you really did that
55 2012-07-08T16:52:42 <ThomasWaldmann> and also it is better for code reusage and handling of stuff is things are done the same way, if possible
56 2012-07-08T16:54:00 <ThomasWaldmann> (i mean confusing if using same name for different stuff)
57 2012-07-08T16:54:01 <xiaq> hm. let me get to indexing things a bit later, after some coding on that area. i'll go through the use case listing on http://etherpad.osuosl.org/moin-render-method now
58 2012-07-08T16:54:58 <xiaq> oh, there is another idea i haven't said
59 2012-07-08T16:57:20 <xiaq> hm... put that a bit later, i'm going though the use case listing:
60 2012-07-08T16:58:44 <xiaq> wiki-render: itemtype="default", contenttype=some wikish thing, (eg. text/x.moin.wiki)
61 2012-07-08T16:59:25 <xiaq> wiki-highlight: itemtype="default", contenttype=some wiki markup. and write this in the content
62 2012-07-08T16:59:31 <xiaq> {{{#!moin
63 2012-07-08T16:59:41 <xiaq> markup to highlight
64 2012-07-08T16:59:42 <xiaq> }}}
65 2012-07-08T17:00:01 <xiaq> wiki-raw: similiar, just leave out the #!moin
66 2012-07-08T17:01:01 <xiaq> wiki-download: itemtype="default", contenttype=some zippish thing - ie. make the default behavior of viewing a zip item downloading. it would be confusing if some zip items get downloaded on click, while some gets its content listed on click
67 2012-07-08T17:01:26 <ThomasWaldmann> wiki-highlight shall not only work for {{{...}}} one should just be able to directly highlight content
68 2012-07-08T17:03:28 <xiaq> ThomasWaldmann: just say +highlight in that case
69 2012-07-08T17:04:00 <xiaq> wiki-draft: i'm not sure if anyone wants some items to be rendered as draft by default. just create a +draft and have it work for all items.
70 2012-07-08T17:04:11 <xiaq> wiki-thumbnail: same thing as wiki-draft
71 2012-07-08T17:05:46 <xiaq> highlight, raw, download: keep itemtype="default" and take appropriate default actions based on contenttype (eg. default action for wikish thing is to render, default for zippish thing to download, default for something that looks like programming source is to highlight, etc.)
72 2012-07-08T17:06:54 <ThomasWaldmann> draft?
73 2012-07-08T17:07:20 <xiaq> ThomasWaldmann: yes, was perhaps added by spy?
74 2012-07-08T17:08:35 <ThomasWaldmann> maybe make some table and point me to it when finished and you made sure it is somehow consistent and covering all cases
75 2012-07-08T17:09:08 <xiaq> i admit that my solution for having a wiki item highlighted instead of rendered by default is a workaround - my idea is to have the item rendered when it looks wikish, highlighted when it looks programming-ish, but wiki markups are also (arguably) a type of programming language
76 2012-07-08T17:09:47 <xiaq> ThomasWaldmann: alright, i'll try to sort out my ideas
77 2012-07-08T17:16:56 <ThomasWaldmann> and i somehow would appreciate if default behaviour is somehow predictable
78 2012-07-08T17:17:29 <ThomasWaldmann> for example, triggering direct download for some stuff by default is maybe nothing we want (it could be an option though)
79 2012-07-08T17:18:09 <ThomasWaldmann> the problem if you only get a direkt download for some item is that you don't get the theme there then, so you can't choose any other navigation
80 2012-07-08T19:06:15 *** jaiditya
81 2012-07-08T20:23:57 <dreimark> re
82 2012-07-08T20:45:23 *** jaiditya
83 2012-07-08T20:45:44 *** spy
84 2012-07-08T20:47:16 *** jaiditya|2
85 2012-07-08T20:47:34 *** jaiditya|2
86 2012-07-08T20:56:08 <jaiditya> ThomasWaldmann: why we have history in views panel when we have it in links panel already ?
87 2012-07-08T20:56:21 <dreimark> jaiditya: one is per item
88 2012-07-08T20:56:26 <dreimark> the other global
89 2012-07-08T20:57:33 <dreimark> the question is how that functionality could be better separated
90 2012-07-08T21:02:07 <jaiditya> dreimark: actually I think its a bit confusing as heading views and links are not appropriate for global and specific panels
91 2012-07-08T21:09:45 <dreimark> jaiditya: yes, i have same feeling
92 2012-07-08T21:10:02 <dreimark> in the past the one for items was named info
93 2012-07-08T21:10:20 <dreimark> and the globale one was RecentChanges
94 2012-07-08T21:10:45 <dreimark> may be we should find a better name for the items info/history
95 2012-07-08T21:11:15 <dreimark> because it is also some different tool
96 2012-07-08T21:12:09 <dreimark> e.g. "revisions" or "revision control"
97 2012-07-08T21:16:23 <dreimark> or just short revs.
98 2012-07-08T21:16:23 <jaiditya> yeah
99 2012-07-08T21:16:54 <dreimark> i guess a to short one makes it difficult for non techies
100 2012-07-08T21:17:11 *** spy
101 2012-07-08T21:17:52 <dreimark> brb
102 2012-07-08T21:17:56 <jaiditya> btw I need your suggestion
103 2012-07-08T21:18:04 <jaiditya> https://dl.dropbox.com/u/43518659/visited-vs-nonvisited.jpg
104 2012-07-08T21:18:14 <jaiditya> https://dl.dropbox.com/u/43518659/new-home-view.jpg
105 2012-07-08T21:18:43 <jaiditya> which one is better black or non-black panel
106 2012-07-08T21:18:54 <jaiditya> ThomasWaldmann: ^^
107 2012-07-08T21:19:26 <jaiditya> a general opinion on whihc one looks good
108 2012-07-08T21:19:39 <jaiditya> which*
109 2012-07-08T21:21:14 <dreimark> I like the white one more, because of not too much intensity change which you have with black background
110 2012-07-08T21:21:29 <dreimark> the black one looks also good
111 2012-07-08T21:23:47 <jaiditya> thank you...I thought the same..now wid this look of home content is more dominating then panels
112 2012-07-08T21:25:55 * dreimark has to go to an other building checking a computer there
113 2012-07-08T21:25:58 <dreimark> brb
114 2012-07-08T21:50:56 *** RogerHaase
115 2012-07-08T22:08:26 <dreimark> re
116 2012-07-08T22:34:09 <jaiditya> dreimark: can you suggest something for this https://bitbucket.org/Jaiditya/moin-2.0/issue/27/foobar-theme-highlight-current-view-link#comment-1640944
117 2012-07-08T22:36:16 <dreimark> jaiditya: you could use an utf-8 arrow
118 2012-07-08T22:36:26 <dreimark> or >
119 2012-07-08T22:36:42 <dreimark> just something, that a user knows what he had selected
120 2012-07-08T22:38:23 <jaiditya> can you please look at the approach I have used...in the comment there
121 2012-07-08T22:48:56 * ThomasWaldmann found a camera + bag in the hotel room
122 2012-07-08T22:50:53 <ThomasWaldmann> jaiditya: i like the lighter one more, but the texture background is interfering with the font, you can't keep it like that
123 2012-07-08T22:52:26 <jaiditya> ThomasWaldmann: which font ?
124 2012-07-08T22:55:36 <ThomasWaldmann> all of it, the text, everywhere https://dl.dropbox.com/u/43518659/new-home-view.jpg
125 2012-07-08T22:58:19 <spy> ThomasWaldmann: Hi Thomas. How is you sprint?
126 2012-07-08T23:05:43 <spy> ThomasWaldmann: also want to hear your opinion on http://codereview.appspot.com/6356070
127 2012-07-08T23:08:10 *** RawChid
128 2012-07-08T23:15:23 <dreimark> jaiditya: that sounds that another request runs, is that true?
129 2012-07-08T23:15:41 <dreimark> otherwise i have no idea why it doesn't change color
130 2012-07-08T23:15:50 <dreimark> and I suggest no to do it by js
131 2012-07-08T23:16:09 <dreimark> if possible
132 2012-07-08T23:16:58 <jaiditya> ok. I'll see what I can do...
133 2012-07-08T23:46:39 *** dwcramer
134 2012-07-08T23:47:29 *** RawChid
135 2012-07-08T23:54:11 *** RogerHaase
136
