Re: color of gtk widget
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 > (because of the trailing *). I didn't know you could have trailing stars, that's useful, thanks. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How to deprecate PangoScript?
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 compiler is concerned. The gobject type name > for PangoScript changes though as we should make pango_script_get_type() > to just return g_unicode_script_get_type(). Right? As far as I can tell, option four won't cause insurmountable problems for language bindings. And given that it appears to be a clean solution from a C point of view, I think it's the winner. I take it that pango_script_iter_* won't be changed apart from pango_script_iter_get_range for which PangoScript is replaced by GUnicodeScript? -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
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 give some real world examples of how GtkTreeView and GtkTreeModel are being used today already: In Tinymail while headers are being downloaded I need to "prepend" those to a GtkTreeModel (during download, not while all are downloaded as that is not what people nowadays want from an E-mail client: they want to start using things 'as they get received'). Same for notify events (Push E-mail if you prefer the buzzword name): these are events that "happen" and "can happen in any thread or anywhere"). Such an even, for example in case the user used another E-mail client to move 80,000 E-mails, will cause 80,000 row insertions to happen. Although this number sounds "large", in fact .. it's small. Some people have over 300,000 items in their E-mail folders (talk to one of those Ubuntu bugzilla maintainers, who made a IMAP folder for each Ubuntu product on his IMAP server: he has thousands of folders and some folders have ten or hundred thousands of items in it. And this ain't "rare", really). Note that this is the guy being responsible for Ubuntu Mobile, and would like to use this as test on his Mobile device (imo this should be perfectly possible on a device that has 50MB of RAM). Or look at Rhythmbox or Banshee: some people have over half a million songs. A customer once asked me to make an analysis to port a software jukebox on Windows to GNOME. With the software it was a possible use-case or "event to support" to "suddenly" receive 300,000 new songs and have 700,000 old songs removed. The people in the bar, the listeners, don't want the software to stop playing. The guy at the bar does not want the software to change the sorting order or settings when this remotely invoked event happens. I know I'm using a lot of words. I'm just really trying to make it clear that unsetting the model and setting a new model is not a practical method and that it's wrong from a Model View Controller perspective: 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 model in the MVC paradigm, should adapt to the changes. It should not require a sudden set and unset of its model. Finally, Kris, if you need any assistance with this: you know where to find me and you know that I'm interested in helping with this if necessary. > All connected views/models could then process the > full changeset in one pass. (Possibly this could also add/remove ranges > of nodes, etc). Thanks for your hard work on GtkTreeView and Model! Make it rock! -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
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 model in the MVC paradigm, should adapt
> > to the changes. It should not require a sudden set and unset of its
> > model.
>
> I'm a big user of MVC. Although on some level I agree with you, I would
> ask what the difference is between:
>
> void gtk_treeview_freeze (GtkTreeView* tv) {
> /* store model in tv, then unset */
> }
> void gtk_treeview_thaw (GtkTreeView* tv) {
> /* reset model in tv */
> }
Owk .. it's a bit lengthy and there are a lot of "personal opinions
about MVC" embedded in this one:
Well I'm in favour of having a strict separation between code that views
data (the view), and code that represents the data (the model).
If you require that "using the model" is to be adapted or adjusted to
certain limitations, you are requiring that the model's code becomes
specific for the view. Let me explain:
Let's take the example with a person and a view for a person:
Person p = new Person ();
PersonView v1 = new PersonView ();
v1.Model = p;
I have another PersonView open on (another) screen (whether it's another
computer or another process or another whatever is irrelevant for now):
PersonView v2 = new PersonView ();
v2.Model = p;
Imagine I'm working at the p's town administration and I change person
p's name. Let's say we did this in v1.
We'll assume a simple system where each person has one instance in this
global system or where each system gets notified by triggers on the
remote database (quite Utopical, I know. But it's irrelevant. You can
also imagine one computer, one application with two PersonView instances
being visible at the same time, showing the same model -- the same
person instance, as we got the instance from a factory and the instance
is, indeed, the exact same instance --).
In v1's instance (image on_name_textbox_changed indeed happens) :
public class PersonView
{
public Person Model;
private void on_name_textbox_changed (TextBox o, ...) {
this.Model.Name = o.Text;
}
}
Note that maybe some people want to do this with a separate Controller
type, in which case we're in the exact same situation.
Now if we'd require that you always now refresh v1 and v2's model before
either v1 OR v2 (not "AND", because v1 can indeed update itself in the
on_name_textbox_changed method, but since PersonView should rather
observer its Model, we usually don't do this --but it can, I know--) ...
... how will v2 get itself updated in time?
It can't, because the view requires getting updated by having it set its
model each time it needs an update.
Now this is a simple example. Whether model is a list of rows, a tree of
things, a bear, a person, a traffic light (which is a typical example),
a remote control for a television ...
Whether the model is a list of 800,000 E-mails. Whether its 300,000 song
titles, ...
Doesn't matter for the MVC theory. You can always have a v1 and a v2
showing the same model instance.
When v1 causes a change to its model, and v2 shares the same instance as
model with v1, v2 should update itself instantly. Because both v1 and v2
observe the model.
Now the "update" (which gets called by the notify of the observable
model) of PersonView can of course do this internally (resetting its
model, resetting its state, doing this or doing that). That's just an
implementation detail.
In case of GtkTreeView this would mean that GtkTreeView would have to
implement this implementation detail. Not the application developer.
In GtkTreeView's case, if the changes are big .. its right now only
practical (else the performance is very weak, yadi yada) if you unset
the model and reset the model. But that's broken as illustrated in the
example above.
> and just calling gtk_treeview_set_model (NULL) and
> gtk_treeview_set_model (NOTNULL).
>
> there are additional issues: freeze/thaw semantics require use of a
> counter, so that, for example, if 3 nested contexts call "freeze", only
> the 3rd subsequent call to "thaw" actually unfreezes. contrast this to
> the simplicity of code in which only the top level sets+unsets the
> model, and all lower levels act on the model regardless of whether its
> connected to a view or not.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
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
now, setting row data looks like this (snippet from our code):
--snip--
void
Playlist_V::put_track_at_iter (Track const& track,
Gtk::TreeModel::iterator & iter)
{
(*iter)[m_track_cr.track] = track;
(*iter)[m_track_cr.uid] = track.bmpx_track_id;
(*iter)[m_track_cr.localUid] = m_localUid;
(*iter)[m_track_cr.searchKey] = track.title ? track.title.get() :
std::string();
(*iter)[m_track_cr.playTrack] = track.active.get();
--snip--
And yes, this is exactly how it looks like: The row is accessed for each of
those lines, and each uses a separate call to list_store_set() internally.
Yes, it i disastrous to performance. One guy on the gtkmm-devel list
recently made a benchmark and found that the gtkmm way of doing this is
approximately 75 times (not 75% -- 75 times) slower than the C Gtk+ method.
Now without going to deep into C++, let's just say that with the way gtkmm
at least works, if not to be sane C++ altogether, it's not possible to have
a C-like TreeModel API in gtkmm, and that's where the changesets come in.
I've been already thinking of a transactional system for TreeModel, and i
have some ideas, but nothing that could be put to code right now.
_However_, a native API for this in C TreeModel (perhaps an additional
interface to TreeModel? "GtkTreeModelTransactional"?) would make this task
very simple because then it could be normally wrapped without needing
gtkmm-specific API.
Kris if you are really on to having a TreeModelTransactional Iface, please
just say "yeah", and i'll also start working on something (deadchip in
#gtk+, btw). This would be a major help for the other discussed problems
here, as well as for this one.
-- Milosz
On 6/24/07, Kristian Rietveld <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jun 19, 2007 at 12:45:09PM +0100, Peter Clifton wrote:
> > This seems to break the MVC abstraction - if the model changes
> > drastically, I need to know which tree-views are connected so I can
> > disconnect them? Bad!
> >
> > We need some new API I guess - which signals any connected views that
> > the data it has cached about the model should be invalidated, and that
> > the model may be changing without emitting signals.
> >
> > Once the model is updated, a further signal will inform the view that it
> > can keep cached state again.
>
> In practise this won't be all that different compared to setting a new
> model on the tree view, except that with a signal it will be initiated
> from the model. After the model emits the "I am finished changing
> everything" signal, the tree view will have to rebuild its internal
> rbtree by iterating over the full model again (any other model that is
> connected to this model will have to rebuild its internal state tree
> too), since it has no clue what has changed. This will probably also
> involve unreferencing all nodes when the model emits "invalidate" and
> re-reference the new nodes after the mass changing, and remembering
> selection and expansion state during the mass-changing (this information
> is kept in the internal rbtree too), etc.
>
> 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. All connected views/models could then process the
> full changeset in one pass. (Possibly this could also add/remove ranges
> of nodes, etc).
>
>
> regards,
>
> -kris.
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
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
now, setting row data looks like this (snippet from our code):
--snip--
void
Playlist_V::put_track_at_iter (Track const& track,
Gtk::TreeModel::iterator & iter)
{
(*iter)[m_track_cr.track] = track;
(*iter)[m_track_cr.uid] = track.bmpx_track_id ;
(*iter)[m_track_cr.localUid] = m_localUid;
(*iter)[m_track_cr.searchKey] = track.title ? track.title.get() :
std::string();
(*iter)[m_track_cr.playTrack] = track.active.get();
--snip--
And yes, this is exactly how it looks like: The row is accessed for each of
those lines, and each uses a separate call to list_store_set() internally.
Yes, it i disastrous to performance. One guy on the gtkmm-devel list
recently made a benchmark and found that the gtkmm way of doing this is
approximately 75 times (not 75% -- 75 times) slower than the C Gtk+ method.
Now without going to deep into C++, let's just say that with the way gtkmm
at least works, if not to be sane C++ altogether, it's not possible to have
a C-like TreeModel API in gtkmm, and that's where the changesets come in.
I've been already thinking of a transactional system for TreeModel, and i
have some ideas, but nothing that could be put to code right now.
_However_, a native API for this in C TreeModel (perhaps an additional
interface to TreeModel? "GtkTreeModelTransactional"?) would make this task
very simple because then it could be normally wrapped without needing
gtkmm-specific API.
Kris if you are really on to having a TreeModelTransactional Iface, please
just say "yeah", and i'll also start working on something (deadchip in
#gtk+, btw). This would be a major help for the other discussed problems
here, as well as for this one.
-- Milosz
On 6/24/07, Kristian Rietveld <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jun 19, 2007 at 12:45:09PM +0100, Peter Clifton wrote:
> > This seems to break the MVC abstraction - if the model changes
> > drastically, I need to know which tree-views are connected so I can
> > disconnect them? Bad!
> >
> > We need some new API I guess - which signals any connected views that
> > the data it has cached about the model should be invalidated, and that
> > the model may be changing without emitting signals.
> >
> > Once the model is updated, a further signal will inform the view that it
> > can keep cached state again.
>
> In practise this won't be all that different compared to setting a new
> model on the tree view, except that with a signal it will be initiated
> from the model. After the model emits the "I am finished changing
> everything" signal, the tree view will have to rebuild its internal
> rbtree by iterating over the full model again (any other model that is
> connected to this model will have to rebuild its internal state tree
> too), since it has no clue what has changed. This will probably also
> involve unreferencing all nodes when the model emits "invalidate" and
> re-reference the new nodes after the mass changing, and remembering
> selection and expansion state during the mass-changing (this information
> is kept in the internal rbtree too), etc.
>
> 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. All connected views/models could then process the
> full changeset in one pass. (Possibly this could also add/remove ranges
> of nodes, etc).
>
>
> regards,
>
> -kris.
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
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 know about the number of views. excellent
> point, end of story for me. it ought to be "transactional".
I think the most sensible meaning is the one we e.g. know from SQL and which
Kris mentioned: One atomic changeset which can be "committed" to the model
in one run. (It can probably not be rolled back, or if it would be possible,
then it'd be quite expensive, but that's not really the point anyway).
As for the model-should-be-view-ignorant issues, they have nothing to do
with transactions, but are just as valid concerns of course.
--Milosz
On 8/5/07, Paul Davis <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-08-05 at 00:25 +0200, Philip Van Hoof wrote:
> > 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 model in the MVC paradigm, should
> adapt
> > > > to the changes. It should not require a sudden set and unset of its
> > > > model.
> > >
> > > I'm a big user of MVC. Although on some level I agree with you, I
> would
> > > ask what the difference is between:
> > >
> > > void gtk_treeview_freeze (GtkTreeView* tv) {
> > > /* store model in tv, then unset */
> > > }
> > > void gtk_treeview_thaw (GtkTreeView* tv) {
> > > /* reset model in tv */
> > > }
> >
> > Owk .. it's a bit lengthy and there are a lot of "personal opinions
> > about MVC" embedded in this one:
>
> it didn't need to be so lengthy :) thats why i noted that i use MVC a
> *lot* myself. the key point you raise is one that i had forgotten: there
> may be multiple views on the model, and when changing the model, one
> should not be required to know about the number of views. excellent
> point, end of story for me. it ought to be "transactional".
>
> --p
>
>
>
> ___
> gtk-list mailing list
> [EMAIL PROTECTED]
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
