Re: Proposed GtkTreeView API change
- From: Tim Janik <timj gtk org>
- To: Jonathan Blandford <jrb redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: Proposed GtkTreeView API change
- Date: Mon, 10 Sep 2001 21:05:23 +0200 (CEST)
On 10 Sep 2001, Jonathan Blandford wrote:
> Currently GtkTreeView has a "range_changed" signal on it that is
> supposed to let the view know when a series of rows change. It was
> added when signals were slower, and sizing of rows was different.
signals haven't gotten any faster recently, the speed optimizations
are still outstanding.
> Unfortunately, since then row sizing has changed such that you need to
> walk the range anyway, and you emit a bunch of signals per row (a
> "property_notify" per column). Additionally, none of the models emit
> it, and the TreeView doesn't support it. Changing GtkTreeModelSort to
> support it will be a nightmare. All this leads me to believe that we
> need to change it to be just "changed" (or maybe "row_changed"). I'd
> like to do this, though it will break anyone's code who's using this or
> writing their own model. Comments??
i'd be in favour of this, and i doubt there are lots of third-party models
out there currently. also, signals _will_ get faster, so the number of
emissions should become a smaller concern.
what's the exact matter with ::property_notify you mention though (or do
you mean GObject::notify)? once you change more than one property per
object, you might want to free/thaw notify first.
>
> Thanks,
> -Jonathan
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]