y.
-Original Message-
*Date*: Mon, 23 Dec 2019 13:23:20 +0100
*Subject*: Re: custom TreeModel
*Cc*: gtkmm-list@gnome.org <mailto:gtkmm-list@gnome.org>
*To*: danny <mailto:danny%20%3cdanny.van.el...@skynet.be%3e>>
*From*: Kjell Ahlstedt <mailto:kjell%20ahlstedt%20%3ckj
hi,
on one hand I genuinely feel that there is a real use case for this:
imagine a library that you've written, and you want to show its results
in a gtk treeview, but straight from your result data structure and not
by duplicating the nodes in the treeview itself. What if the input-
output schema
An alternative would be to add this in a new
gtkmm-documentation/examples/book/custom/custom_treemodel directory in
the gtkmm tutorial. And a description in a new section in the /Custom
Widgets/ chapter (which should then be renamed).
Isn't this kind of custom class that implements one or more
hello gtkmm,
so how do I continue with this? I feel that it would be really handy to
add an example such as the one below to the gtkmm demos subdir.
I was struggling with this myself some years ago for a gtk2 program
where the data were already established (and constantly changing)
outside the gui
type_slotDo(), nullptr }};
--
I'm not sure, though, if I really understand the purpose of virtual
bool Gtk::TreeModel::iter_parent_vfunc
(
this function finds a parent for the given child, right? but why would
that b
Your custom TreeModel can perhaps be added either to the gtkmm demo
programs or to the gtkmm tutorial at
https://gitlab.gnome.org/GNOME/gtkmm-documentation. Let's decide when
you have a working program.
Have you noticed that there is a custom TreeModel example at
https://gitlab.gnom
indeed! that seems to get me on my way! thanks!
if/when I get this working: would you be interested in adding this to
the gtkmm demo programs?
regards, D.
*
From: Kjell Ahlstedt
Have you declared your custom TreeModel something like
class MyTreeModel : public Glib
well, I was trying to come up with a good demo, because I have always
felt that people will like to fill a treeview directly from their own
data
it has been a while since I have worked woth gtkmm, so I adapted the
following from a working program against gtk-2:
the Gtk::Window* do_treeview_memor
Have you declared your custom TreeModel something like
class MyTreeModel : public Glib::Object, public Gtk::TreeModel
That's wrong. Glib::Object must be declared after the base interface(s):
class MyTreeModel : public Gtk::TreeModel, public Glib::Object
This restriction was introduced ab
please show the rest of the class declaration, including what/how it
inherits, and how you instantiate it.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
hello all,
can anyone tell me the list of methods to override in order to create a
custom TreeModel?
I currently have these:
virtual Gtk::TreeModelFlags get_flags_vfunc() const;
virtual int get_n_columns_vfunc() const;
virtual GType get_column_type_vfunc(int index) const;
virtual void
Sorry for the noise.
1) is for the Treeview to access the treemodel
2) is for the treemodel to access the data
eric jrdn2 wrote:
> Hi all,
> i'm building a treeview on a custom treemodel based on std::vector.
> My wish is to build it without knowing the number and the type of the
Hi all,
i'm building a treeview on a custom treemodel based on std::vector.
My wish is to build it without knowing the number and the type of the
treecolumns at build time.
I decided to come back to more fondamental widgets to do it, i.e.
implementing this with cellrenderers.
My question is
On 5/23/06, Tamer Mowafy <[EMAIL PROTECTED]> wrote:
I reused your tarball after adjusting configure.in so
configure can work with my version of gtkmm. It
compiled well and worked well. I then removed virtual
inheritance. This time it gave me the same runtime
warnings you mentioned. However my own
gt;
> I get the following output and nothing shows up in
> the treeview:
>
> $ ./src/testcustomtreemodel
> setting up Main
> setting up win
> Constructing vector container
> Adding item 1
> Adding item 2
> Adding item 3
> Adding item 4
> Ad
vector container
Adding item 1
Adding item 2
Adding item 3
Adding item 4
Adding item 5
Creating custom treemodel
(testcustomtreemodel:1068): glibmm-CRITICAL **:
Glib::Interface::Interface(const Glib::Interface_Class&): assertion
`gobject_ != 0' failed
creating tree view
(testcustom
--- Jonathon Jongsma <[EMAIL PROTECTED]>
wrote:
> In any case, i put
> a tarball up
> here:
>
http://download.gna.org/colorscheme/etc/customtreemodel-0.0.1.tar.gz
>
> If you get a chance to look at it that'd be great.
>
> Thanks,
> Jonner
>
Hi Jonathon
I have downloaded your tarball and gav
On 5/23/06, Murray Cumming <[EMAIL PROTECTED]> wrote:
> On 5/20/06, Tamer Mowafy <[EMAIL PROTECTED]> wrote:
> [ a bunch of interesting ideas about implementing a generic custom
> TreeModel]
>
>
> Thanks a lot for your input Tamer. You've given me a lot of go
> On 5/20/06, Tamer Mowafy <[EMAIL PROTECTED]> wrote:
> [ a bunch of interesting ideas about implementing a generic custom
> TreeModel]
>
>
> Thanks a lot for your input Tamer. You've given me a lot of good
> ideas. I'll try to experiment with some of
On 5/20/06, Tamer Mowafy <[EMAIL PROTECTED]> wrote:
[ a bunch of interesting ideas about implementing a generic custom TreeModel]
Thanks a lot for your input Tamer. You've given me a lot of good
ideas. I'll try to experiment with some of them and report back when
I've got
--- Jonathon Jongsma <[EMAIL PROTECTED]>
wrote:
> On 5/19/06, Tamer Mowafy [EMAIL PROTECTED] wrote:
> > Second you may consider declaring your template
> > parameters like this:
> >
> > template < class T, template < class U, class =
> > allocator > class TContainer>
> >
> > this makes your class
On 5/19/06, Tamer Mowafy <[EMAIL PROTECTED]> wrote:
first if the basic idea was to keep only one copy of
data around, you may think of using a reference to the
wrapped container.
>private:
> T m_container;
can be:
T& m_container;
this will allow two-way updates to be automatically
sensed on bot
Jonathon
I have enjoyed following the discussion about
introducing a generic TreeModel class. Using a
template class is a great idea for it sure would make
it easy to initialize the class with STL containers. I
have some few notes
first if the basic idea was to keep only one copy of
data around,
On Fri, 2006-05-19 at 13:40 -0500, Jonathon Jongsma wrote:
> So if I understand correctly, you have a ListModel and an underlying
> data container.The ListModel has the same number of elements as your
> underlying data store, but contains shared_ptrs to the elements of
> your data store instead of
On 5/19/06, Murray Cumming <[EMAIL PROTECTED]> wrote:
On Fri, 2006-05-19 at 12:05 -0400, Paul Davis wrote:
> libardour is the backend to multiple UIs (not all of them graphical). it
> is not allowed to have a dependency on the code used by any particular
> UI implementation. i.e. its not OK for t
On Fri, 2006-05-19 at 12:05 -0400, Paul Davis wrote:
> libardour is the backend to multiple UIs (not all of them graphical). it
> is not allowed to have a dependency on the code used by any particular
> UI implementation. i.e. its not OK for the curses implementation to have
> to link against GTK,
On Fri, 2006-05-19 at 17:59 +0200, Murray Cumming wrote:
> On Fri, 2006-05-19 at 10:41 -0400, Paul Davis wrote:
> > the one thing that is a little unfortunate about a custom treemodel
> > based on Gtk/Glib objects is that if you are strict about
> > Model/View/Controller prog
On Fri, 2006-05-19 at 10:41 -0400, Paul Davis wrote:
> the one thing that is a little unfortunate about a custom treemodel
> based on Gtk/Glib objects is that if you are strict about
> Model/View/Controller programming to the extent that you do not allow
> your Model implementation
On 5/19/06, Paul Davis <[EMAIL PROTECTED]> wrote:
the one thing that is a little unfortunate about a custom treemodel
based on Gtk/Glib objects is that if you are strict about
Model/View/Controller programming to the extent that you do not allow
your Model implementation to use View-relate
On 5/19/06, Andrew E. Makeev <[EMAIL PROTECTED]> wrote:
That is may way of creating custom models:
class CommonModel // class with common data handling and sorting
methods for my data-container
{...}
class DataListTreeModel
: public Glib::Object
, public Gtk::TreeModel
On 5/19/06, Paul Davis <[EMAIL PROTECTED]> wrote:
I agree with this whole heartedly. If we start making assumptions about
what gets passed to this class, it starts to lose some of its use.
Unless theres a very very good cause for doing so I'd recommend making
any assumptions.
I assume you mean
Jonathon Jongsma wrote:
> In fact i have a skeleton like this implemented to play around with,
> but I can't get it to instantiate. When I call the
> MyListModel::create() function, I keep getting errors like this:
>
> glibmm-CRITICAL **: Glib::Interface::Interface(const
> Glib::Interface_Class
s that are stored in the
container. For example, say you want a custom treemodel that uses
std::vector where rgb_t is defined as
struct rgb_t
{
int r, g, b
}
Do you want the model to have a single column of rgb_t objects, or do
you want three columns: an red column, a green column, and a b
the one thing that is a little unfortunate about a custom treemodel
based on Gtk/Glib objects is that if you are strict about
Model/View/Controller programming to the extent that you do not allow
your Model implementation to use View-related code (e.g GTK), its not
possible to use the treemodel
> So it seems that when I use virtual inheritance, the warnings go away.
Avoid introducing any new virtual inheritance. If the example doesn't do
it then you don't need to do it.
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
gt
lines are commented out. Any
>> > thoughts?
>>
>> Yes, I think I comment them out in Glom too.
>
> OK. Then maybe I'll just get rid of them in the example. Any objections?
No.
> So now the example runs without any warnings, and I've been working on
t;> Yes, I think I comment them out in Glom too.
>
> OK. Then maybe I'll just get rid of them in the example. Any objections?
No.
> So now the example runs without any warnings, and I've been working on
> ideas for a 'generic' custom treemodel. I'm thinki
necessary or not. But it seems to run fine
> and doesn't issue a warning when those lines are commented out. Any
> thoughts?
Yes, I think I comment them out in Glom too.
OK. Then maybe I'll just get rid of them in the example. Any objections?
So now the example runs witho
On Thu, 2006-05-18 at 18:55 -0500, Jonathon Jongsma wrote:
> OK, I think I get it now, more or less. I've just noticed, however
> that when I run the example from gtkmm CVS, I get the following
> warning:
>
> (lt-example:29959): GLib-GObject-WARNING **: cannot add interface type
> `GtkTreeModel'
On 5/17/06, Murray Cumming <[EMAIL PROTECTED]> wrote:
It's all to do with the fact that you don't have much control over when
the per-iter data is deallocated. You just get to say "everything I have
allocated before now is now invalid, so I'll release it and it's your own
dam fault if you try to
> On 5/17/06, Murray Cumming <[EMAIL PROTECTED]> wrote:
>> Maybe you should just store the Palette in the list model and use
>> cell_data_func callbacks to show it in the treeview.
>
> Hmm, that's an interesting idea. I'll look into that.
>
>>
>> I've done it in Glom, but the gtkmm example is sim
On 5/17/06, Murray Cumming <[EMAIL PROTECTED]> wrote:
Maybe you should just store the Palette in the list model and use
cell_data_func callbacks to show it in the treeview.
Hmm, that's an interesting idea. I'll look into that.
I've done it in Glom, but the gtkmm example is simpler.
I assu
On 5/17/06, Murray Cumming <[EMAIL PROTECTED]> wrote:
>> > even cooler if it actually derived from some STL abstract type,
>>
>> What kind of type do you mean exactly? Standard C++ containers are not
>> meant to be used as base classes. They do conform to standard
>> types/requirements, but I thi
>> > even cooler if it actually derived from some STL abstract type,
>>
>> What kind of type do you mean exactly? Standard C++ containers are not
>> meant to be used as base classes. They do conform to standard
>> types/requirements, but I think those are just concepts rather than
>> actual
>> clas
On Wed, 2006-05-17 at 14:06 +0200, Murray Cumming wrote:
> > On Wed, 2006-05-17 at 09:49 +0200, Murray Cumming wrote:
> >> [snip]
> >> > Actually, I wonder if it is possible that gtkmm provide custom model
> >> > implementation. Developer should just provide data container class
> >> > derived from
first.
I agree that this would be really cool. Since I'm about to start
figuring out how to implement my own custom TreeModel, I'll try to
keep this in mind. Maybe I can come up with something generic that we
can incorporate into gtkmm eventually.
Jonner
_
> On Wed, 2006-05-17 at 09:49 +0200, Murray Cumming wrote:
>> [snip]
>> > Actually, I wonder if it is possible that gtkmm provide custom model
>> > implementation. Developer should just provide data container class
>> > derived from some Gtk::virtual-base class and reimplement methods to
>> > get/
On Wed, 2006-05-17 at 09:49 +0200, Murray Cumming wrote:
> [snip]
> > Actually, I wonder if it is possible that gtkmm provide custom model
> > implementation. Developer should just provide data container class
> > derived from some Gtk::virtual-base class and reimplement methods to
> > get/set data
[snip]
> Actually, I wonder if it is possible that gtkmm provide custom model
> implementation. Developer should just provide data container class
> derived from some Gtk::virtual-base class and reimplement methods to
> get/set data from/to your container by given Gtk::TreeModelPath or
> Gtk::TreeI
Murray Cumming wrote:
After poking around a bit in my freshly built gtkmm, I noticed this:
gtkmm/examples/Makefile.am
# Doesn't build with GLIBMM_ENABLE_PROPERTIES unset:
#cellrenderercustom
Dunno if thats important or not though.
That's a different example.
There's a note in the Chang
> After poking around a bit in my freshly built gtkmm, I noticed this:
>
> gtkmm/examples/Makefile.am
> # Doesn't build with GLIBMM_ENABLE_PROPERTIES unset:
> #cellrenderercustom
>
> Dunno if thats important or not though.
That's a different example.
There's a note in the ChangeLog about that.
Palette inherit from Gtk::TreeModel (i.e.
implement a custom TreeModel). There is an example in gtkmm CVS that
shows how to implement a custom TreeModel, but unfortunately I haven't
had much luck deciphering it (especially the GlueItem stuff). And
besides the example, the documentation on i
t; and forth. So in order to display data directly from the Palette
> class, I'd need to have Palette inherit from Gtk::TreeModel (i.e.
> implement a custom TreeModel). There is an example in gtkmm CVS that
> shows how to implement a custom TreeModel, but unfortunately I haven't
don't need to copy / synchronize things back
and forth. So in order to display data directly from the Palette
class, I'd need to have Palette inherit from Gtk::TreeModel (i.e.
implement a custom TreeModel). There is an example in gtkmm CVS that
shows how to implement a custom TreeMo
54 matches
Mail list logo
