Just FWIW, can we agree on one meaning of "transactional"?
For me, the fact that the model shouldn't have to know about the number of
views showing it has nothing to do with transactionality:
> there may be multiple views on the model, and when changing the model, one
> should not be required to k
As a somewhat related topic (this thread seems to not be nailed on a very
specific topic yet and this still fits in i think), a changeset+commit API
(in the truer sense; not what was proposed with just saying "all nodes below
this one have changed") would be _very_ welcome for gtkmm, because right
As a somewhat related topic (this thread seems to not be nailed on a very
specific topic yet and this still fits in i think), a changeset+commit API
(in the truer sense; not what was proposed with just saying "all nodes below
this one have changed") would be _very_ welcome for gtkmm, because right
On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
> On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
>
> > The model itself is the source. The view is just a viewer for it. The
> > source itself doesn't change. The content of the source changes. The
> > view, being an observer of the m
On Sun, 2007-06-24 at 15:19 +0200, Kristian Rietveld wrote:
> I think a much better solution would be to be able to group a bunch of
> changes together in a kind of "atomic changeset" which is then emitted
> with a single signal.
I agree with this and am in need of this kind of things too.
I'll
On Thu, 2007-08-02 at 15:48 -0400, Behdad Esfahbod wrote:
> 4. Like 3, but also go ahead and change PangoScript uses to
> GUnicodeScript in public Pango API (and internally too). This doesn't
> have the C++ problem because PangoScript and GUnicodeScript will be the
> same thing as far as the co
On 8/4/07, Benjamin Berg <[EMAIL PROTECTED]> wrote:
> If you already use a style, you can also use
>
> widget "*red_widget*" style "red_style"
>
> instead. And then you just need to set the name on the button and none
> of its children. As the label will also be affected with the above line
> (beca
