| kamstrup | mhr3: that crash you pointed out in the tree-index branch is nasty... | 08:25 |
|---|---|---|
| mhr3 | kamstrup, which one? | 08:26 |
| mhr3 | clear or the other one? | 08:26 |
| kamstrup | the priv->reader_* being unset one | 08:26 |
| mhr3 | ah | 08:26 |
| kamstrup | the only way I can find to fix it is to include the reader fields in a gobject property | 08:26 |
| mhr3 | yea, i immediately didn't like the constructor after seeing the magic after g_object_new | 08:26 |
| kamstrup | and I don't want 3 props because that'll introduce all sorts of odd corner casesw | 08:27 |
| kamstrup | so ideally one prop | 08:27 |
| mhr3 | right, so make a construct (write only) gobject property and use set_data on it | 08:27 |
| kamstrup | but I don't want to have a public struct to hold that data either | 08:27 |
| kamstrup | setdata() - how'd you mean? | 08:28 |
| kamstrup | I was thinking just a construct only prop, that we hide in GI | 08:28 |
| mhr3 | standard g_object_set_data | 08:28 |
| kamstrup | set with what data? | 08:28 |
| kamstrup | :-) | 08:28 |
| mhr3 | and use it to hide the three props | 08:28 |
| mhr3 | or well... pass along | 08:29 |
| kamstrup | sorry, I don't how that can work | 08:29 |
| mhr3 | ok, here we go | 08:29 |
| kamstrup | we can't call set_data() until after we have the object instantiated and construct() called | 08:29 |
| mhr3 | ..index_new { var dummy = object_new(G_TYPE_OBJECT); dummy.set_data("reader-...", ...); ...; var index = object_new(TYPE_TREE_INDEX, "dummy", dummy, ...); } | 08:30 |
| mhr3 | i could have used enter :) | 08:31 |
| kamstrup | ah - you want to call set_data() on the *model* :-) | 08:31 |
| mhr3 | no, no, just some dummy | 08:31 |
| mhr3 | but model could work as well, actually | 08:31 |
| kamstrup | ah | 08:31 |
| kamstrup | I'd just go with a gpointer[3]... | 08:32 |
| mhr3 | also a way | 08:32 |
| kamstrup | ugly no matter what :-) | 08:32 |
| mhr3 | right :) | 08:32 |
| mhr3 | kamstrup, but making it a real prop would ease subclassing | 08:33 |
| kamstrup | mhr3: yeah, that's a good point | 08:34 |
| kamstrup | mhr3: since I have a DeeScanIndex lined up already | 08:34 |
| mhr3 | and HashIndex has the same problem i guess | 08:34 |
| kamstrup | indeed | 08:34 |
| mhr3 | kamstrup, btw i think the *_reader methods will need (skip) annotation, they won't be usable from python nor vala | 08:50 |
| kamstrup | I think I already tested them working in Python | 08:51 |
| mhr3 | no way | 08:51 |
| mhr3 | how did you pass the column in? | 08:51 |
| kamstrup | mhr3: but I think I'll refactor that part anyway | 08:51 |
| kamstrup | mhr3: just 0 I believe | 08:52 |
| kamstrup | probably working by chance because it's 32 bit... | 08:52 |
| === MacSlow is now known as MacSlow|lunch | ||
| === nuthinking_ is now known as nuthinking | ||
| === yofel_ is now known as yofel | ||
| davidcalle | kamstrup, mhr3 ping | 13:56 |
| mhr3 | hey davidcalle | 13:57 |
| davidcalle | mhr3, when is libunity API supposed to break? | 13:57 |
| mhr3 | when we're done with all the changes, we dont want multiple breaks | 13:58 |
| davidcalle | Ok | 13:59 |
| === MacSlow|lunch is now known as MacSlow | ||
| kamstrup | davidcalle: yeah, stuff is slowly starting to trickle into bzr as we speak | 14:22 |
| kamstrup | but as mhr3 said we aim for *one* break early in the cycle | 14:23 |
| kamstrup | and it'll only be a small break, so I don't expect any major refactoring needed | 14:23 |
| mhr3 | hmmm | 14:23 |
| mhr3 | :) | 14:23 |
| davidcalle | kamstrup, mhr3, I'm ok with refactoring as long as it means features :) | 14:24 |
| kamstrup | davidcalle: there will be features, faster methods, and an API designed to minimize the number of potential client side bugs | 14:25 |
| mhr3 | kamstrup, while we're at that do you any way to do the filtering/sorting of results from multiple scopes | 14:25 |
| kamstrup | so I hope you'll love it :-) | 14:25 |
| mhr3 | kamstrup, davidcalle can explain, although i think you've talked about it | 14:26 |
| kamstrup | mhr3: njpatel did all that, and I never really looked at it :-) | 14:26 |
| davidcalle | kamstrup, I'm sure I will. | 14:27 |
| davidcalle | kamstrup, I'm looking for a way to sort results from multiple scopes. I was thinking of something like mutliple scopes talking to the same dee model, and dee doing the sorting. | 14:28 |
| davidcalle | Use case being : someone wants to add a scope to the file lens (like a new datasource for games) and want the results to integrate nicely the existing game results. | 14:29 |
| Andy80 | hi all | 14:30 |
| davidcalle | the application lens* | 14:30 |
| kamstrup | davidcalle: right - there are a few subtleties here | 14:30 |
| kamstrup | davidcalle: I think it is very important that the results view don't "jump around" as slower results trickle in | 14:30 |
| kamstrup | of course, the one doing the merging could be clever enough to avoid that | 14:31 |
| davidcalle | kamstrup, I used to think the same thing, but I'm not so sure. | 14:31 |
| kamstrup | hehe, I am :-) | 14:32 |
| kamstrup | ok, there may be lenses that are special in this regard | 14:32 |
| kamstrup | but lenses like files and apps can not have that behaviour imho | 14:32 |
| davidcalle | kamstrup, I mean, either we have non-sorted results from multiple sources, either we have slow results from multiple sources. | 14:33 |
| kamstrup | fx a "Quake3 game servers lens" that lists servers sorted according to some clever combination of latency and #users ... :-) | 14:33 |
| kamstrup | So I guess the problems start when you want to merge results from a scope into an already populated category in the lens | 14:34 |
| davidcalle | kamstrup, indeed. With scopes with different latency. I have stuff appearing at top or bottom in an unreliable way. | 14:40 |
| davidcalle | btw, there is a bug I need to file: In a category : results from scope A appear, results from scope B appear, results from scope A jump after results from B. | 14:44 |
| davidcalle | But I believe it's related, somehow, to the way Unity loads icons. If I disable online thumbnail fetching for scope A, it doesn't happen. | 14:45 |
| Andy80 | anyone of you can tell me which one is the right XChat branch in Launchpad? There are many... I've prepared a very small fix and I don't know which one to branch from and which one to push into... I tried yesterday but probably I pushed to the wrong one and I got a lot of diff errors. Please note that my "fix" is only related to Ubuntu and must not be included in the upstream version of it. Thanks | 15:04 |
| Andy80 | and another question: which one is the preferred "mono" font to use in Ubuntu: "Ubuntu Mono" or "Monospace" ? thanks | 15:16 |
| davidcalle | Andy80, Ubuntu Mono is now default in Gnome Terminal. | 15:32 |
| Andy80 | davidcalle: my intention was modifing XChat to have the same font as default, to maintain the same UI experience, and I already modified the proper file... but now I've found another branch that already has "Monospace 9" as default font.... so I don't know what to do exactly :) | 15:36 |
| davidcalle | Andy80, you could ask Sladen in #ubuntu-design , he is the one dealing with the Ubuntu font integration. | 15:39 |
| Andy80 | davidcalle: ok, I ask him, thank you :) | 15:40 |
| davidcalle | Andy80, yw :) | 15:40 |
| === davidcalle_ is now known as davidcalle | ||
| API | dbarth, one question, is lamalex on holidays? | 17:15 |
| API | btw, hi | 17:15 |
| API | ;) | 17:15 |
| gema | API: Thanksgiving in the US, I'd say lamalex is probably off today :) | 17:53 |
| API | gema, well also asking because I was looking lamalex some days ago | 17:56 |
| API | but it is true that today is a bad day | 17:56 |
| API | to look after him ;) | 17:56 |
| API | gema, thanks, I forgot that USA turkey-related party ;) | 17:57 |
| gema | API: yep, almost time for turkey here in the uk too! | 17:57 |
| gema | API: where are you from out of curiosity? | 17:59 |
| API | gema, Spain, I didn't know about that uk Thanksgiving, I thought that it was just USA and Canada celebration | 18:05 |
| gema | API: I meant Christmas , we don't do thanksgiving, I am also from Spain, encantada :D | 18:05 |
| API | gema, ah ok | 18:06 |
| === JanC_ is now known as JanC | ||
| === seiflotfy is now known as HuNannyYumYum | ||
| === HuNannyYumYum is now known as seiflotfy | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!