Murray Cumming wrote:
On Thu, 2007-07-26 at 21:55 -0500, Jonathon Jongsma wrote:On 7/26/07, Milosz Derezynski <internalerror gmail com> wrote:[snip]To preempt the obvious "yeah then why don't you come up with something" message: I would, in case I get support from the gtkmm devs. I'm not a C++ coder par excellence, nor am i entirely through with gtkmm myself (mostly, i guess but not entirely), and i don't think i can come up with something if all i'm going to hear will be "yeah, good idea, tell us when you're done". It should be clear to see that this is by no means a personal request by Jef or me, and not even one that should become concern of the entire gtkmm team because we brough it up, but simply because it needs to be done this or the other way anyway; you can't neglect a speed increase of 7500%. What's the gtkmm development team's take on this? Please don't feel prodded nor pushed into a speechless situation, but take this as a serious, real, and existing issue.Well, I certainly can't speak for the "gtkmm development team", since I don't really do all that much on gtkmm. But this sounds to me like something that could be really nice if implemented well. I haven't spent any time thinking about it though, so I don't have any ideas for an API.Yes, we always like patches.
I don't know much about the gtkmm internals, but I believe the problem is that the "row-changed" signal is emitted for every column, where the gtk+ function emits the signal only once. If that is indeed the problem, we could support batch updates by delaying this signal:
store->batch_start (); // Block the signal here. row[m_columns.number] = cmd.column_int(0); row[m_columns.datetime] = cmd.column_text(1); store->batch_end (); // Emit the signal here.If something like this is technically possible, we can keep the current gtkmm syntax and there is no need for vararg functions.