Re: How to use Glib::Value?

[p sun fun gmail com]

Thanks for the clarification. I didn't check the implementation of
Glib::Value<T> class when proposed the idea. I checked and I see that
default constructor can be defined and init() call can be done there. I
will try to submit MR to the master and we can discuss further.

On Sat, 2019-03-09 at 13:04 +0100, Kjell Ahlstedt wrote:
> Right now we're maintaining two parallel-installable versions of
> glibmm, 
> the stable glibmm-2.4 ABI series with the latest release glibmm
> 2.58.0 
> (git branch glibmm-2-58), and the new and very unstable glibmm-2.60
> ABI 
> with the latest release 2.59.1 (git branch master).
>
> In the master branch we can change both API and ABI until the first 
> stable release of gtk-4 and gtkmm-4.
> In the glibmm-2-58 branch the usual restrictions apply: No API or
> ABI 
> must be changed or removed. New API and ABI can be added only when
> (if) 
> we release a glibmm 2.60.x version in the glibmm-2.4 ABI series.
>
> Yes, I know these API and ABI version numbers are confusing. It's
> just 
> the way it is right now in glibmm.
> It means that in the master branch you can suggest just about
> anything 
> you like. In the glibmm-2-58 branch we can't do very much, basically
> fix 
> obvious bugs and improve documentation. If there will be a glibmm-2-
> 60 
> branch, branched from glibmm-2-58, API and ABI can be added there,
> but 
> not changed or removed.
>
> You're welcome to write one or two MRs if you like. An MR for the
> master 
> branch is probably the easiest one. In the master branch there is no 
> requirement that all code that uses glibmm must continue to work
> without 
> modification and without recompilation.
>
> I don't understand the point of renaming the present Glib::Value
> classes 
> to Glib::Value_t and then write new Glib::Value classes that use 
> Glib::Value_t. In the master branch Glib::Value_t seems unnecessary.
> All 
> code can be put in modified Glib::Value classes. In glibmm-2-60 it
> would 
> not be allowed, if the new Glib::Value classes break ABI or API,
> which 
> they probably will.
>
> On 2019-03-08 14:35, Pavlo Solntsev via gtkmm-list wrote:
> > Thank you for clarification.
> >
> > This is what I did for my code.
> >
> > template<class T>
> > class Column {
> >     Glib::Value<T> data
> >
> > public:
> >     Column(){
> >             data.init(data.get_value_type());
> >     }
> >     Column(const T &val):Column(){
> >             data.set(val);
> >     }
> >
> >     void set_value(const T &val){
> >             data.set(val);
> >     }
> >
> >     T get_value(void){
> >             return data.get();
> >     }
> >
> > };
> >
> > Usage is very convenient:
> > Column<Glib::ustring> mColumn;
> >
> > mColumn.get(); // get value
> > mColumn.set("New string"); // Set value
> >
> > This is just a general idea and some parts are missed. Do you think
> > the
> > similar code can be incorporated to Glib::Value? For example. If we
> > rename the current class Glib::Value to Glib::Value_t and remove
> > from
> > the public API, we can define a new class Glib::Value which will
> > include Glib::Value_t in the way I showed above. This will remove
> > extra
> > step such as call Glib::Value<T>::init(...) method.
> >
> > Just a suggestion. I can prepare MR if the idea is valuable.
> >
> > Thanks.