Re: Why no gtkmm equivalent for gtk_list_store_set?
- From: "Jonathon Jongsma" <jonathon jongsma gmail com>
- To: "Milosz Derezynski" <internalerror gmail com>
- Cc: Jef Driesen <jefdriesen hotmail com>, gtkmm-list gnome org
- Subject: Re: Why no gtkmm equivalent for gtk_list_store_set?
- Date: Thu, 26 Jul 2007 21:55:49 -0500
On 7/26/07, Milosz Derezynski <internalerror gmail com> wrote:
> First off I've been thinking on how to do it best with gtkmm for a while too
> because the increase is -indeed- tremendous and by no means negligable. The
> difference _IS_ tremendous by all standards. Even if the figures presented
> here should be somewhat off because of other workload on the box or
> whatever, it is extreme.
>
> The problem i guess is that vararg functions are sort of a
> no-no-uhmm-yeah-only-if-you-really-have-to with C++;
> everything needs to be statically typed and predefined to guarantee comile
> time safety.
>
>
> While no one will hear a complaint about _this_ from me, the
> ListStore/TreeStore situations need to be fixed; there needs to be an API
> that allows atomic setting of entire rows.
>
> 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.
>
> --Milosz
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.
--
jonner
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]