Re: [gtk-list] Re: GtkEtext overview and: GTK_WIDGET_SET_FLAGS inheritance?

>	The reason I had the View inherit from the Model was that I didn't
>want the user to be forced into two separate widgets for a simple text
>display.  I.e., I wanted the "view" to be equivalent to the current
>GtkText, which has both view and data.  I guess that is a mistake.

If you think about what you're actually trying to model, there really
*are* two separate entities. 

Note that in a full-blown MVC model, there would be controllers as
well as views; you've folded the V and the C together, which is OK as
long as you follow Havoc's recommendation of not doing:


You must do:


and then have a "signal handler" that is notifed by the model, and does:


>Then, my GtkEtextBuffer will override the GtkEditable's data-handling
>signals and functions (insert_text, delete_text, changed, plus add the
>necessary functions for changing the font and style of the text) and the
>GtkView will override the viewing functions (_realize, _expose, etc.) plus
>all the view-specific API functions, for things like setting the cursor
>blink rate and whether or not line numbers are displayed.

Thats pretty much it.

>	Does this make more sense?  Of course, it will be more difficult
>than using GtkText because now the user needs to create a GtkEtextBuffer
>*and* a GtkEtextView, and then "attach" that GtkEtextView to the
>GtkEtextBuffer...which is why I wanted the View to inherit from the

If you followed your original instinct, how would you attach multiple
Views to the Model ? If the original View was deleted, what happens to
all the other View's handle on the Model ? 

Thats why they (V, M, C) have to be peers. 

Anyway, Gamma et al. will hopefully change your life as it did for
many other programmers.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]