Re: How to unblock bugfix, pipeline failed with unrelated error in gtk

[Pavlo Solntsev via gtkmm-list]

gtkmm team, 

A Docker image can be built with a specific version of gtk. After that,
this image can be used to execute CI job. It will be a pretty quick
build. glib folks use this approach to build against multiple distors. 

The good thing about this approach is that all needed dependencies
explicitely included into the Docker's image. 

The negative side of this approach is that docker images should be
manually built and uploaded. But, scipts can help.



On Wed, 2022-02-16 at 21:17 +0100, Kjell Ahlstedt via gtkmm-list wrote:
> Den 2022-02-16 kl. 15:02, skrev Baldvin Kovacs via gtkmm-list:
>  
> >  
> > Hello, 
> > 
> > I'm trying to send a merge request of a bugfix in gtkmm, but the
> > build pipeline fails with an unrelated error in (or at least it
> > seems so, the error is pasted to the bottom of this email).
> > 
> > What's the usual way to go about this? Should I notify owners of
> > Gtk? By what channels? Or is it on me to track it down, get that
> > fixed first, before I can propose my Gtkmm fix to be considered?
> > 
> > Thanks,
> > Baldvin
> > 
> > FAILED:
> > subprojects/gtk/examples/application3/exampleapp3_resources.h 
> >  /usr/bin/glib-compile-resources
> > ../subprojects/gtk/examples/application3/exampleapp.gresource.xml -
> > -sourcedir ../subprojects/gtk/examples/application3/. --sourcedir
> > ../subprojects/gtk/examples/application3 --internal --generate --
> > target
> > subprojects/gtk/examples/application3/exampleapp3_resources.h
> > ../subprojects/gtk/examples/application3/exampleapp.gresource.xml:
> > Failed to close file descriptor for child process (Operation not
> > permitted).
> > 
> The latest gtkmm commits require gtk4 >=4.6.0, but that's not
> available from the distro that the CI uses.
> Dependency gtk4 found: NO found 4.4.1 but need: '>= 4.6.0'
> 
> Gtk is then built as a subproject of gtkmm. The latest patch on gtk's
> main branch is used. Today gtk folks have added patches that make
> their own CI pipeline fail. For the time being, just accept that the
> latest gtk patches don't work. The gtk folks will find out, and fix
> it themselves.
> 
> Hopefully that latest version of some distro will soon include gtk
> 4.6.0. Then it won't be built as a subproject.
> 
> Kjell
>  
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Does anyone know how to update the www.gtkmm.org website?

[Pavlo Solntsev via gtkmm-list]

Hi, 

just would like to add my two cents here. We can create a Wiki page as
we did here:
https://gitlab.gnome.org/GNOME/libgda/-/wikis/home

So it will be updated with every succesful CI run. If gtkmm.org is too
old but gitlab source is "more" up to date, it would make sence to
redirect gtkmm.org ot the GitLab wiki. 

I am not sure if it applicable or doable but may work. 

Thanks, 

-PS

On Sun, 2022-01-16 at 19:18 +0100, Kjell Ahlstedt via gtkmm-list wrote:
> The www.gtkmm.org website has not been updated for a long time. There
> are a number of gtkmm issues about obsolete information. I don't know
> how to update the website. The source code is stored at
> https://gitlab.gnome.org/GNOME/gnomemm-website. I've made a few
> updates to the source code, and used GitLab's CI and Pages to have a
> partially updated version published at
> https://gnome.pages.gitlab.gnome.org/gnomemm-website. That's not good
> enough. No one will find it there. Who has permission to update
> www.gtkmm.org?
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Deriving from GObject in C++

[Pavlo Solntsev via gtkmm-list]

If your program logic has been already written in C++ you can write GUI
using GTKMM. Or even scripting language. Do not use GTK, unless you
know what you are doing. If you need to make a derived widget from the
existing one => gtkmm is your friend. If you want to create a widget
from scratch that is a different story. Try to keep GUI separated from
the business logic you aeady have. Will save you a lot of time in the
future. 
 


On Tue, 2020-05-26 at 08:59 +, gnu wrote:
> I want to make a GUI app and have only little past experience with
> gtk
> and gtkmm. The program is actually finished apart from a GUI and is
> written in C++. I thought about deriving from GObject using C++ and
> create a bunch of custom classes and widgets (not only overriding
> existing methods but defining new ones), that can then be used in the
> wider glib/gtk world through GIR introspection. This would
> comfortably
> open the door to using some scripting languages for the GUI part - at
> least that's my fantasy.
> 
> But is this even possible and what would be the recommended way to do
> so?
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: mmification of gspell

[Pavlo Solntsev via gtkmm-list]

> 
> The lack of constness
> and limitations on callbacks are unfortunate, and some of the style
> strikes me as odd, but that's a great effort/start nonetheless and
> hopefully goes on.

The last comment is dated 6 months ago. I assume, it is not active
project and can serve as a good starting point. BTW, is it possible to
replace libsigc++ with boost.signals2? I don't want to say we should,
but just wandering. 


> 
> 
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: mmification of gspell

[Pavlo Solntsev via gtkmm-list]

Check this project https://gitlab.com/mnauw/cppgir 

Worth checking upfront.

On Wed, 2020-04-15 at 18:19 +0200, Emmanuel Gil Peyrot wrote:
> On Wed, Apr 15, 2020 at 04:53:21PM +0200, Kjell Ahlstedt wrote:
> > On 2020-04-15 01:51, Emmanuel Gil Peyrot wrote:
> > > Hi,
> > > 
> > > In Inkscape[1] I’ve been trying to replace[2] both GtkSpell and
> > > aspell
> > > with gspell[3], but I couldn’t find any gspellmm library.
> > > 
> > > I’ve been looking through your mm libraries to see how to
> > > generate it,
> > > but it seems you write almost all of the code, instead of
> > > generating it
> > > from gobject-introspection like in other languages, is there any
> > > reason
> > > for that?
> > I don't know for sure, but I think gobject-introspection did not
> > exist when
> > glibmm and friends were first created. Then no one has taken the
> > time to
> > learn gobject-introspection and to convert everything. I think
> > there once
> > was an attempt to generate glibmm from gobject-introspection, but
> > it was not
> > finished.
> 
> Thanks, do you have a link to this unfinished attempt?  It might make
> future maintainance much less costly than doing everything manually,
> especially with the changing APIs surrounding GTK 4.
> 
> > > I’d be interested in creating such a library if no one else
> > > already has
> > > something, do you have any pointer for where to start from?  The
> > > API
> > > surface is small enough I could do it from scratch, but it would
> > > most
> > > likely integrate better taking your advices. :)
> > > 
> > > Thanks!
> > > 
> > > [1] https://inkscape.org/
> > > [2] https://gitlab.com/inkscape/inkscape/-/merge_requests/1756
> > > [3] https://wiki.gnome.org/Projects/gspell
> > > 
> > > 
> > There are some instructions in the gtkmm tutorial, appendix G: 
> > https://developer.gnome.org/gtkmm-tutorial/stable/chapter-wrapping-c-libraries.html.en
> > .
> > It's not completely up-to-date. It assumes that you will build with
> > Autotools. I suppose you prefer Meson.
> 
> Of course I do. ^^
> 
> > mm-common contains the skeletonmm directory with files you can
> > start with.
> > The skeletonmm project contains files for building with Meson. If
> > you decide
> > to use it, I recommend that you clone mm-common from the git repo
> > with the
> > latest commits.
> 
> Thanks, I’ll have a look at this method. :)
> 
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: mm-common and mm-common-get

[Pavlo Solntsev via gtkmm-list]

ok, not it is clear. All versions I checked were <1.0. To build against
mm-common-1.0 under CI we need to clone git repo. As soon as all
distributors switch to the new version, the one from the distro repo
will be used.

Thanks

On Fri, 2020-03-27 at 15:33 +0100, Kjell Ahlstedt wrote:
> mm-common-get is new in mm-common 1.0.0, released 2019-10-29. Which
> version of mm-common have you got?
> 
> On 2020-03-26 19:35, Pavlo Solntsev via gtkmm-list wrote:
> > Hi,
> > 
> > Working on meson, I found that mm-common-get is not available in
> > debian:sid(https://packages.debian.org/sid/all/mm-common/filelist),
> > ubuntu:devel(
> > https://packages.ubuntu.com/focal/all/mm-common/filelist) 
> > and 
> > fedora(
> > https://fedora.pkgs.org/31/fedora-armhfp/mm-common-0.9.12-4.fc31.noarch.rpm.html
> > )
> > 
> > I am trying to use a  docker image and the image has no mm-common-
> > get.
> > Meson aborts because it can't find the script. Are you aware about
> > this? I file a bug report to debian. May be they know something. 
> > 

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

mm-common and mm-common-get

[Pavlo Solntsev via gtkmm-list]

Hi,

Working on meson, I found that mm-common-get is not available in
debian:sid(https://packages.debian.org/sid/all/mm-common/filelist),
ubuntu:devel(https://packages.ubuntu.com/focal/all/mm-common/filelist) 
and 
fedora(
https://fedora.pkgs.org/31/fedora-armhfp/mm-common-0.9.12-4.fc31.noarch.rpm.html
)

I am trying to use a  docker image and the image has no mm-common-get.
Meson aborts because it can't find the script. Are you aware about
this? I file a bug report to debian. May be they know something. 

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Meson and Autotools, or only Meson?

[Pavlo Solntsev via gtkmm-list]

On Thu, 2020-03-26 at 08:55 +0100, Kjell Ahlstedt wrote:
> On 2020-03-26 03:06, Pavlo Solntsev wrote:
> > On Wed, 2020-03-25 at 18:49 +0100, Kjell Ahlstedt via gtkmm-list
> > wrote:
> > > These *mm packages can now be built either with Meson or with
> > > Autotools:
> > > 
> > > mm-common
> > > libsigc++-2.0, libsigc++-3.0
> > > glibmm-2.4, glibmm-2.66
> > > pangomm-1.4, pangomm-2.44
> > > (gtkmm-documentation-3,) gtkmm-documentation-4
> > > I've put gtkmm-documentation-3 in parentheses because there is no
> > > released tarball with Meson support, it's only in the git repo.
> > 
> > How about ninja dist?
> > https://mesonbuild.com/Creating-releases.html
> > 
> 
> Yes, what about ninja dist? What do you mean? It should work with the
> listed packages. Have you found that it doesn't? Or is your question
> a way of saying that I should have used ninja dist instead of
> make distcheck in recent releases?
> 
What I am trying to say is that meson together with ninja allows
tarball generation. I am not sure about the archive format. Also, for
upstream API reference, we can make a wiki page at gitlab to see the
resent successful comment. It can be done using CI. Any tarball from
the successful commit can be added to the wiki page with possibility to
download it. This is definitely a big picture. The first step would be
to establish two build systems as a transition stage, then add CI, and
start exploring other options as I described.


> Kjell

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: ***UNCHECKED*** Meson and Autotools, or only Meson?

[Pavlo Solntsev via gtkmm-list]

On Wed, 2020-03-25 at 18:49 +0100, Kjell Ahlstedt via gtkmm-list wrote:
> These *mm packages can now be built either with Meson or with
> Autotools:
> 
> mm-common
> libsigc++-2.0, libsigc++-3.0
> glibmm-2.4, glibmm-2.66
> pangomm-1.4, pangomm-2.44
> (gtkmm-documentation-3,) gtkmm-documentation-4
> I've put gtkmm-documentation-3 in parentheses because there is no
> released tarball with Meson support, it's only in the git repo.

How about ninja dist?
https://mesonbuild.com/Creating-releases.html

> 
> Some underlying C packages, such as glib and gtk4, have dropped
> Autotools support. Shall we do the same, where possible?
> 
Make sure meson works in parallel with autotools and eventually drop
the support. 

> I think at least one released tarball must contain both Meson support
> and Autotools support before Autotools support can be dropped, or
> else https://gitlab.gnome.org/GNOME/gnome-build-meta/ will have
> problems. Correct me, if I'm wrong here.
> 
> At the moment all of the listed packages use Meson when they are
> built with jhbuild, but only mm-common does so when it's built with
> gnome-build-meta.
> 
> Regards
> Kjell
> 
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Help proposal for libgdamm

[Pavlo Solntsev via gtkmm-list]

Hi,

Just would like to follow up on our previous conversation. The libgda
master CI was broken and finally got fixed recently. All test and
compilation should be ok. I tried to compile libgdamm and do see some
issues due to last-two-years activity in libgda. It may be a good idea
to setup a CI for libgdamm. I will try to play with that. Let me know
if you have a specific plan to move forward. 

Best,
-Pavlo.

On Thu, 2020-01-23 at 16:20 +0100, murr...@murrayc.com wrote:
> Your help would be much appreciated. Actually, I had difficulty even
> building libgda.
> 
> On 23 Jan 2020 15:25, Pavlo Solntsev via gtkmm-list <
> gtkmm-list@gnome.org> wrote:
> > Hi,
> > 
> > I saw some recent activities in libgdamm repo. However, I checked
> > and
> > it looks like the library can't be compiled because of changes in
> > libgda code. Would it be be possible to open issues for work that
> > needs
> > to be done? I can help with porting some code. For now, I am
> > cleaning
> > documentation for lilbgda and found that some API introduced in the
> > dev
> > version (6.0) can be obsolete. Technically, this is not obsolete,
> > since
> > we didn't have a stable version yet. For instance, a lot of DDL
> > operations were moved to the new GdaDB... module and having
> > redundant
> > API is not the best approach. Anyway, I would like to coordinate
> > work
> > on libgdamm if possible. Thanks.
> > 
> > 
> > ___
> > gtkmm-list mailing list
> > gtkmm-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtkmm-list
> > 
> 
> 

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Help proposal for libgdamm

[Pavlo Solntsev via gtkmm-list]

See below a simple script I use on debian testing to build everything
in libgda under jhbuild. If you see an issue related to libxml2 or
libxslt see https://gitlab.gnome.org/GNOME/jhbuild/merge_requests/53
I avoid this by building with ignored system dependencies:

or just under jhbuild shell, manually

We build in the "build" directory. I assume, it doesn't exist.

If you want to build only libgda, the simple
$ mkdir build
$ cd build
$ meson
$ ninja
$ ninja install

should work. In the current master libgda is compiled with -Werror. 
What error do you see?

#!/bin/bash -x

GLADE_BASE=$HOME/jhbuild/install/share/glade
GLADE_CATALOG_DIR=$GLADE_BASE/catalogs
GLADE_PIXMAPS_DIR=$GLADE_BASE/pixmaps

mkdir build && cd build
meson --prefix=$HOME/jhbuild/install \
--libdir=lib \
-Denable-debug=true \
-Denable-ldap=true \
-Dwith-ui=true \
-Dgtk_doc=true \
-Dexperimental=true \
-Denable-tools=true \
-Dglade-catalog-dir=$GLADE_CATALOG_DIR \
-Dglade-pixmap-dir=$GLADE_PIXMAPS_DIR \

ninja
# end of script


On Thu, 2020-01-23 at 16:20 +0100, murr...@murrayc.com wrote:
> Your help would be much appreciated. Actually, I had difficulty even
> building libgda.
> 
> On 23 Jan 2020 15:25, Pavlo Solntsev via gtkmm-list <
> gtkmm-list@gnome.org> wrote:
> > Hi,
> > 
> > I saw some recent activities in libgdamm repo. However, I checked
> > and
> > it looks like the library can't be compiled because of changes in
> > libgda code. Would it be be possible to open issues for work that
> > needs
> > to be done? I can help with porting some code. For now, I am
> > cleaning
> > documentation for lilbgda and found that some API introduced in the
> > dev
> > version (6.0) can be obsolete. Technically, this is not obsolete,
> > since
> > we didn't have a stable version yet. For instance, a lot of DDL
> > operations were moved to the new GdaDB... module and having
> > redundant
> > API is not the best approach. Anyway, I would like to coordinate
> > work
> > on libgdamm if possible. Thanks.
> > 
> > 
> > ___
> > gtkmm-list mailing list
> > gtkmm-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtkmm-list
> > 
> 
> 

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Help proposal for libgdamm

[Pavlo Solntsev via gtkmm-list]

Hi,

I saw some recent activities in libgdamm repo. However, I checked and
it looks like the library can't be compiled because of changes in
libgda code. Would it be be possible to open issues for work that needs
to be done? I can help with porting some code. For now, I am cleaning
documentation for lilbgda and found that some API introduced in the dev
version (6.0) can be obsolete. Technically, this is not obsolete, since
we didn't have a stable version yet. For instance, a lot of DDL
operations were moved to the new GdaDB... module and having redundant
API is not the best approach. Anyway, I would like to coordinate work
on libgdamm if possible. Thanks.


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

libgdamm: Project status

[Pavlo Solntsev via gtkmm-list]

Hi,

I work on libgda project but use C++ code in my project where I need to
communicate to SQL server. I see that libgdamm is not so active for a
long time. I am interested in libgdamm project since it meets my
personal goals. For now, I am building my own wrap library around
libgda classes using only methods I need. Looks good so far. However,
as to me, it is a repeating work. I could use libgdamm classes and
extend them according to my needs. I have no access to the GNOME repo
and can't commit directly to bring libgdamm to the libgda:master. 

I know, Murray Cumming is in charge of it now. I don't see much
activities and wonder if the project still alive. 

Thanks.
-Pavlo



___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

building pangomm

[Pavlo Solntsev via gtkmm-list]

Hi,

I am not sure if this post should go here but since it is mm module

I decided to reorganize my jhbuild framework and have to compile gtkmm.
As a dependency, I have to compile pangomm-1.4 and got an error here.
What caught my attention is the version of glibmm-2.4 == 2.62.0 and
library needed 2.64. In the meson file 

if not is_msvc
  glibmm_generate_extra_defs_dep = cpp_compiler.find_library(
'glibmm_generate_extra_defs-2.64',
  )

  executable('generate_extra_defs', 'generate_defs_pango.cc',
dependencies: [pangomm_build_dep, glibmm_generate_extra_defs_dep],
install: false,
  )
endif

Why do we list library name explicitly? Is it mistake or I have to use
some special tweak here?

I am building gtkmm-3 with default jhbuild config.

Thanks.


Found pkg-config: /usr/bin/pkg-config (0.29)
Run-time dependency pangocairo found: YES 1.45.0
Run-time dependency glibmm-2.4 found: YES 2.62.0
Run-time dependency cairomm-1.0 found: YES 1.13.1
Program mm-common-get found: YES
(/home/pavlo/Projects/GNOME/install/bin/mm-common-get)
Program m4 found: YES (/usr/bin/m4)
Program perl found: YES (/usr/bin/perl)
Program doxygen found: YES (/usr/bin/doxygen)
Program dot found: YES (/usr/bin/dot)
Program xsltproc found: YES (/usr/bin/xsltproc)
Compiler for C++ supports arguments -pedantic: YES 
Compiler for C++ supports arguments -Wall: YES 
Compiler for C++ supports arguments -Wextra: YES 
Compiler for C++ supports arguments -Wformat-security: YES 
Compiler for C++ supports arguments -Wsuggest-override: YES 
Compiler for C++ supports arguments -Wshadow: YES 
Compiler for C++ supports arguments -Wno-long-long -Wlong-long: YES 
Compiler for C++ supports arguments -Werror: YES 
Compiler for C++ supports arguments -DG_DISABLE_DEPRECATED: YES 
Compiler for C++ supports arguments -DPANGO_DISABLE_DEPRECATED: YES 
Compiler for C++ supports arguments -DGLIBMM_DISABLE_DEPRECATED: YES 
Compiler for C++ supports arguments -DSIGCXX_DISABLE_DEPRECATED: YES 
WARNING: Consider using the builtin warning_level option instead of
adding warning flags by hand.
WARNING: Consider using the builtin warning_level option instead of
adding warning flags by hand.

tools/extra_defs_gen/meson.build:7:2: ERROR: C++ library
'glibmm_generate_extra_defs-2.64' not found

*** Error during phase configure of pangomm-1.4: ## Error 

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: What shall be the version number of the next mm-common release?

[Pavlo Solntsev via gtkmm-list]

My two cents. Is it going to be a stable release? If so, lets omit
leading zero, e.g. 1.0.0 for the upcoming version. All unstable version
will be incremented using the second and the third number. 

Thanks.


On Sat, 2019-10-26 at 15:37 +0200, Kjell Ahlstedt via gtkmm-list wrote:
> mm-common in the git repo now supports Meson in several ways.
> 
> mm-common itself can be built with Meson.
> It supports other modules that are built with Meson (so far only
> pangomm's master branch).
> The skeletonmm directory shows the start of a module which will be
> built with Meson.
> It's time to make a new release of mm-common, but I don't understand
> how mm-common releases are numbered. It seems the minor version
> number ('y' in x.y.z) is not used for differentiating between stable
> and unstable releases.
> 
> The latest release is 0.9.12. Shall the next release be 0.10.0? If
> not, what shall it be? Does anyone know?
> 
> Kjell AHlstedt
> 
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Debugging widgets

[Pavlo Solntsev via gtkmm-list]

Thanks Daniel for the tip.
I tried gtk_init() but it looks like it is not enough for mm version.
Instead, I called Gtk::Application::run() and it works. The code is
follow:

auto app = Gtk::Application::create("mytest");
Gtk::Box box;
app->run();
BOOST_TEST(box.get_homogeneous() == false);

I also substituted Gtk::Box with my custom widget and everything seems
works just fine.

Thanks.

-Pavlo


On Wed, 2019-09-18 at 20:48 +0100, Daniel Boles wrote:
> sounds like you just never initialised gtk via an application or
> gtk_init()
> 
> 
> On Wed, 18 Sep 2019, 20:45 Pavlo Solntsev via gtkmm-list, <
> gtkmm-list@gnome.org> wrote:
> > Hi, 
> > 
> > I am trying to understand how to debug a widget. I am trying to do
> > something like this. This is just a test.
> > 
> > Gtk::Box box;
> > BOOST_TEST(box.get_homogeneous() == true);
> > 
> > I get the following error:
> > 
> > (process:25274): Gtk-CRITICAL **: 14:36:20.149:
> > _gtk_css_lookup_resolve: assertion '(((__extension__ ({
> > GTypeInstance
> > *__inst = (GTypeInstance*) ((provider)); GType __t =
> > ((_gtk_style_provider_private_get_type ())); gboolean __r; if
> > (!__inst)
> > __r = (0); else if (__inst->g_class && __inst->g_class->g_type ==
> > __t)
> > __r = (!(0)); else __r = g_type_check_instance_is_a (__inst, __t);
> > __r;
> > }' failed
> > 
> > (process:25274): GLib-GObject-CRITICAL **: 14:36:20.149:
> > g_object_set_data_full: assertion 'G_IS_OBJECT (object)' failed
> > 
> > (process:25274): Gtk-ERROR **: 14:36:20.149: ../../checkout/gtk+-
> > 3/gtk/gtkstylecontext.c:348:gtk_style_context_init: Can't create a
> > GtkStyleContext without a display connection
> > 
> > Since Gtk::Box is not a top level widget is has no CSS styles
> > associated with it. What would be the best practice to add CSS
> > styles
> > (ctor?) and eventually, how to debug a widget? I assume, we don't
> > need
> > to call any show() methods. 
> > 
> > Thanks.
> > -Pavlo
> > 
> > ___
> > gtkmm-list mailing list
> > gtkmm-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtkmm-list

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Debugging widgets

[Pavlo Solntsev via gtkmm-list]

Hi, 

I am trying to understand how to debug a widget. I am trying to do
something like this. This is just a test.

Gtk::Box box;
BOOST_TEST(box.get_homogeneous() == true);

I get the following error:

(process:25274): Gtk-CRITICAL **: 14:36:20.149:
_gtk_css_lookup_resolve: assertion '(((__extension__ ({ GTypeInstance
*__inst = (GTypeInstance*) ((provider)); GType __t =
((_gtk_style_provider_private_get_type ())); gboolean __r; if (!__inst)
__r = (0); else if (__inst->g_class && __inst->g_class->g_type == __t)
__r = (!(0)); else __r = g_type_check_instance_is_a (__inst, __t); __r;
}' failed

(process:25274): GLib-GObject-CRITICAL **: 14:36:20.149:
g_object_set_data_full: assertion 'G_IS_OBJECT (object)' failed

(process:25274): Gtk-ERROR **: 14:36:20.149: ../../checkout/gtk+-
3/gtk/gtkstylecontext.c:348:gtk_style_context_init: Can't create a
GtkStyleContext without a display connection

Since Gtk::Box is not a top level widget is has no CSS styles
associated with it. What would be the best practice to add CSS styles
(ctor?) and eventually, how to debug a widget? I assume, we don't need
to call any show() methods. 

Thanks.
-Pavlo

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Getting GValue* from Glib::Value

[Pavlo Solntsev via gtkmm-list]

Thanks for the update. 

On Sat, 2019-04-27 at 09:35 +0200, Kjell Ahlstedt wrote:
> I have fixed Glib::Checksum, DateTime and TimeZone in the master
> branch. These classes are now wrapped as _CLASS_BOXEDTYPE, which
> means they get Glib::Value specializations. I've also added TODO
> comments in the glibmm-2-60 branch. Hopefully, I remember to fix it
> there when glibmm 2.62.0 is released. That fix will not be identical
> to the one in the master branch. The master branch fix contains a
> (very small) change in the API (a changed default value in a method
> that very few users of glibmm will call directly from their own
> code).
> On 2019-04-25 14:24, Pavlo Solntsev via gtkmm-list wrote:
> > Glib maintainer also wants no change in the implementation of
> > GDateTime. I like your strategy. Thanks.
> > 
> > 
> > On Thu, 2019-04-25 at 13:55 +0200, Kjell Ahlstedt wrote:
> > > Don't change GDateTime in glib because of Glib::Value<>.
> > > Many boxed types get Glib::Value specializations almost
> > > automatically. Those that are wrapped as _CLASS_OPAQUE_COPYABLE
> > > don't. GDateTime is one of them. I'll either add the Glib::Value
> > > specialization manually to glibmm/datetime.h or make a more
> > > general
> > > fix in the _CLASS_OPAQUE_COPYABLE m4 macro.
> > > For the time being I can fix something in the master branch. A
> > > fix in
> > > the glibmm-2.4 ABI series has to wait until glibmm 2.62.0.
> > > However I
> > > fix it, the fix will include added API and/or ABI.
> > > On 2019-04-24 18:06, Pavlo Solntsev via gtkmm-list wrote:
> >  

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Getting GValue* from Glib::Value

[Pavlo Solntsev via gtkmm-list]

Glib maintainer also wants no change in the implementation of
GDateTime. I like your strategy. Thanks.


On Thu, 2019-04-25 at 13:55 +0200, Kjell Ahlstedt wrote:
> Don't change GDateTime in glib because of Glib::Value<>.
> Many boxed types get Glib::Value specializations almost
> automatically. Those that are wrapped as _CLASS_OPAQUE_COPYABLE
> don't. GDateTime is one of them. I'll either add the Glib::Value
> specialization manually to glibmm/datetime.h or make a more general
> fix in the _CLASS_OPAQUE_COPYABLE m4 macro.
> For the time being I can fix something in the master branch. A fix in
> the glibmm-2.4 ABI series has to wait until glibmm 2.62.0. However I
> fix it, the fix will include added API and/or ABI.
> On 2019-04-24 18:06, Pavlo Solntsev via gtkmm-list wrote:
> > Thank you Kjell.
> > 
> > It works. Basically, the code you provided should be added to the
> > header (glibmm/value.h). Currently, GDateTime is not GObject-based. 
> > If
> > we switch GDateTime to GObject the situation will be simpler for
> > mm.
> > For my problem, I will use code in my app. Does it make sense to
> > add it
> > to the master (glibmm)? Or it is better change GDateTime
> > implementation. 
> > 
> > Thanks.
> > 
> > 
> > On Wed, 2019-04-24 at 14:45 +0200, Kjell Ahlstedt wrote:
> > > The description of Glib::ValueBase says
> > >  * Glib::Value<> is specialized for almost any type used within
> > > the
> > > glibmm and gtkmm libraries.
> > >  *
> > >  * - Basic types like int, char, bool,
> > > etc., also void*.
> > >  * - Glib::ustring and std::string.
> > >  * - Pointers to classes derived from Glib::Object.
> > >  * - Glib::RefPtr<> pointer types, which are assumed to be
> > > Glib::Object pointers.
> > >  * - All flags and enum types used within the gtkmm libraries.
> > >  *
> > >  * If a type doesn't fit into any of these categories, then a
> > > generic
> > >  * implementation for custom types will be used. 
> > > "Almost any type" does not include Glib::DateTime, unfortunately.
> > > And
> > > "All flags and enum types" is not quite right. There are some
> > > enum
> > > types, especailly in glibmm, without a Glib::Value
> > > specialization.
> > > I think this Glib::Value specialization will
> > > work:
> > > namespace Glib
> > > {
> > > template <>
> > > class Value : public ValueBase_Boxed
> > > {
> > > public:
> > >   using CppType = Glib::DateTime;
> > >   using CType = GDateTime*;
> > > 
> > >   static GType value_type() { return G_TYPE_DATE_TIME; }
> > > 
> > >   void set(const CppType& data) { set_boxed(data.gobj()); }
> > >   CppType get() const { return
> > > CppType(static_cast(get_boxed()), true); }
> > > };
> > > } // namespace Glib
> > > 

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Getting GValue* from Glib::Value

[Pavlo Solntsev via gtkmm-list]

Thank you Kjell.

It works. Basically, the code you provided should be added to the
header (glibmm/value.h). Currently, GDateTime is not GObject-based. If
we switch GDateTime to GObject the situation will be simpler for mm.
For my problem, I will use code in my app. Does it make sense to add it
to the master (glibmm)? Or it is better change GDateTime
implementation. 

Thanks.


On Wed, 2019-04-24 at 14:45 +0200, Kjell Ahlstedt wrote:
> The description of Glib::ValueBase says
>  * Glib::Value<> is specialized for almost any type used within the
> glibmm and gtkmm libraries.
>  *
>  * - Basic types like int, char, bool,
> etc., also void*.
>  * - Glib::ustring and std::string.
>  * - Pointers to classes derived from Glib::Object.
>  * - Glib::RefPtr<> pointer types, which are assumed to be
> Glib::Object pointers.
>  * - All flags and enum types used within the gtkmm libraries.
>  *
>  * If a type doesn't fit into any of these categories, then a generic
>  * implementation for custom types will be used. 
> "Almost any type" does not include Glib::DateTime, unfortunately. And
> "All flags and enum types" is not quite right. There are some enum
> types, especailly in glibmm, without a Glib::Value specialization.
> I think this Glib::Value specialization will work:
> namespace Glib
> {
> template <>
> class Value : public ValueBase_Boxed
> {
> public:
>   using CppType = Glib::DateTime;
>   using CType = GDateTime*;
> 
>   static GType value_type() { return G_TYPE_DATE_TIME; }
> 
>   void set(const CppType& data) { set_boxed(data.gobj()); }
>   CppType get() const { return
> CppType(static_cast(get_boxed()), true); }
> };
> } // namespace Glib
> 
> On 2019-04-23 15:01, p.sun@gmail.com wrote:
> > Thanks, Kjell. I missed that gobj() returns a pointer to gobject_.
> > However, the returned type is not a pure C gtype. Let me illustrate
> > this by example:
> > 
> > ```
> >   Glib::Value data;
> > 
> >   data.init(data.value_type());
> > 
> >   const GValue *val = data.gobj();
> >   std::cout << "val type is " << G_VALUE_TYPE_NAME(val) <<
> > std::endl;
> > 
> >   GValue *val2 = g_new0(GValue, 1);
> >   g_value_init(val2, G_TYPE_DATE_TIME);
> >   std::cout << "val2 type is " << G_VALUE_TYPE_NAME(val2) <<
> > std::endl;
> > 
> > ```
> > In stdout I see
> > 
> > ```
> > val type is glibmm__CustomBoxed_N4Glib8DateTimeE
> > val2 type is GDateTime
> > ```
> > 
> > I know that GDateTime is a boxed type and Glib::Value registers it
> > own
> > type. If I use built-in type, e.g. int, I see the same type for C++
> > and
> > C parts. Basically, my question should be refined and tailed to the
> > conversion of C++ gtype (boxed equivalent) to the C-like gtype. 
> > 
> > Thanks.

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Getting GValue* from Glib::Value

[Pavlo Solntsev via gtkmm-list]

Thanks, Kjell. I missed that gobj() returns a pointer to gobject_.
However, the returned type is not a pure C gtype. Let me illustrate
this by example:

```
  Glib::Value data;

  data.init(data.value_type());

  const GValue *val = data.gobj();
  std::cout << "val type is " << G_VALUE_TYPE_NAME(val) << std::endl;

  GValue *val2 = g_new0(GValue, 1);
  g_value_init(val2, G_TYPE_DATE_TIME);
  std::cout << "val2 type is " << G_VALUE_TYPE_NAME(val2) << std::endl;

```
In stdout I see

```
val type is glibmm__CustomBoxed_N4Glib8DateTimeE
val2 type is GDateTime
```

I know that GDateTime is a boxed type and Glib::Value registers it own
type. If I use built-in type, e.g. int, I see the same type for C++ and
C parts. Basically, my question should be refined and tailed to the
conversion of C++ gtype (boxed equivalent) to the C-like gtype. 

Thanks.


On Tue, 2019-04-23 at 10:46 +0200, Kjell Ahlstedt wrote:
> What's wrong with Glib::ValueBase::gobj()? It returns a pointer to
> gobject_. What else do you want? How should your proposed
> Glib::ValueBase::get_gvalue() differ from Glib::ValueBase::gobj()?
> On 2019-04-23 06:14, Pavlo Solntsev via gtkmm-list wrote:
> > Hi, 
> > 
> > I have 
> > 
> > Glib::Value data;
> > data.init(Glib::Value::value_type());
> > 
> > How can I get pure C GValue*? I need it to use with the C API.
> > data.gobj() returns C++ based type, which is not acceptable by C
> > API. I
> > see protected gobject_ in the base class. Does it make sense to
> > have an
> > API, e.g.  const GValue* Glib::ValueBase::get_gvalue() to fetch
> > thepointer for underlying GValue? 
> > 
> > Any other suggestion? 
> > Thanks.
> > 

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Getting GValue* from Glib::Value

[Pavlo Solntsev via gtkmm-list]

Hi, 

I have 

Glib::Value data;
data.init(Glib::Value::value_type());

How can I get pure C GValue*? I need it to use with the C API.
data.gobj() returns C++ based type, which is not acceptable by C API. I
see protected gobject_ in the base class. Does it make sense to have an
API, e.g.  const GValue* Glib::ValueBase::get_gvalue() to fetch thepointer for 
underlying GValue? 

Any other suggestion? 
Thanks.

-- 
- Pavlo Solntsev
-
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Sent from Evolution on GNU/Debian 


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: How to use Glib::Value?

[Pavlo Solntsev via gtkmm-list]

Thanks for the clarification. I didn't check the implementation of
Glib::Value 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 Column {
> > Glib::Value data
> > 
> > public:
> > Column(){
> > data.init(data.get_value_type());
> > }
> > Column(const T ):Column(){
> > data.set(val);
> > }
> > 
> > void set_value(const T ){
> > data.set(val);
> > }
> > 
> > T get_value(void){
> > return data.get();
> > }
> > 
> > };
> > 
> > Usage is very convenient:
> > Column 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::init(...) method.
> > 
> > Just a suggestion. I can prepare MR if the idea is valuable.
> > 
> > Thanks.
> > 

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: How to use Glib::Value?

[Pavlo Solntsev via gtkmm-list]

Thank you for clarification.

This is what I did for my code. 

template
class Column {
Glib::Value data

public:
Column(){
data.init(data.get_value_type());
}
Column(const T ):Column(){
data.set(val);
}

void set_value(const T ){
data.set(val);
}

T get_value(void){
return data.get();
}

};

Usage is very convenient:
Column 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::init(...) method.

Just a suggestion. I can prepare MR if the idea is valuable.

Thanks.



On Tue, 2019-03-05 at 19:28 +0100, Kjell Ahlstedt wrote:
> init() is a method in Glib::ValueBase, base class of all
> Glib::Value<> specializations. The documentation says
> init() is not implemented as constructor, to avoid the necessity
> to implement a forward constructor in each derived class.
> There are many subclasses of Glib::ValueBase. Most of these
> subclasses (perhaps even all of them) has just compiler-generated
> constructors. I suppose someone found it tedious to write
> constructors with a call to init() in all those subclasses. It's not
> obvious to me that it was a wise decision not to do that.
> On 2019-03-05 14:37, Pavlo Solntsev via gtkmm-list wrote:
> > Thanks, that works. Out of curiosity, why not to call init() in the
> > constructor? 
> > 
> > 
> > On Tue, 2019-03-05 at 11:00 +0100, Kjell Ahlstedt wrote:
> > > Replace
> > >data.init(G_TYPE_DATE_TIME);
> > > by
> > >data.init(data.value_type());
> > > or
> > >data.init(Glib::Value::value_type());
> > > You don't store a GDateTime, you store a Glib::DateTime. That's
> > > not
> > > the same thing.
> > > This is not well described in the documentation, but there is an
> > > example at
> > > https://gitlab.gnome.org/GNOME/glibmm/blob/master/tests/glibmm_value/main.cc
> > > On 2019-03-04 14:05, Pavlo Solntsev via gtkmm-list wrote:
> > > > Hi,
> > > > 
> > > > Have this code 
> > > > ```
> > > > Glib::Value datai;
> > > > datai.init(G_TYPE_INT);
> > > > datai.set(8);
> > > > std::cout << "Value = " << datai.get() << std::endl;
> > > > ```
> > > > I see in stdout:
> > > > Value = 8
> > > > 
> > > > Works good. Now I would like to use another type:
> > > > Glib::DateTime
> > > > ```
> > > > Glib::Value data;
> > > > 
> > > > data.init(G_TYPE_DATE_TIME);
> > > > Glib::DateTime ctime = Glib::DateTime::create_now_utc();
> > > > data.set(ctime);
> > > > ```
> > > > 
> > > > This compiles ok, but generates 
> > > > Program received signal SIGSEGV, Segmentation fault.
> > > > 0x77b2405c in Glib::DateTime::operator= (this=0x0,
> > > > src=...)
> > > > at
> > > > ___ gtkmm-list
> > > > mailing list gtkmm-list@gnome.org 
> > > > https://mail.gnome.org/mailman/listinfo/gtkmm-list
> > > > /home/pavlo/jhbuild/checkout/glibmm-
> > > > 2.4/glib/glibmm/datetime.cc:89
> > > > 89if(gobject_)
> > > > 
> >  

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: How to use Glib::Value?

[Pavlo Solntsev via gtkmm-list]

Thanks, that works. Out of curiosity, why not to call init() in the
constructor? 


On Tue, 2019-03-05 at 11:00 +0100, Kjell Ahlstedt wrote:
> Replace
>data.init(G_TYPE_DATE_TIME);
> by
>data.init(data.value_type());
> or
>data.init(Glib::Value::value_type());
> You don't store a GDateTime, you store a Glib::DateTime. That's not
> the same thing.
> This is not well described in the documentation, but there is an
> example at
> https://gitlab.gnome.org/GNOME/glibmm/blob/master/tests/glibmm_value/main.cc
> On 2019-03-04 14:05, Pavlo Solntsev via gtkmm-list wrote:
> > Hi,
> > 
> > Have this code 
> > ```
> > Glib::Value datai;
> > datai.init(G_TYPE_INT);
> > datai.set(8);
> > std::cout << "Value = " << datai.get() << std::endl;
> > ```
> > I see in stdout:
> > Value = 8
> > 
> > Works good. Now I would like to use another type: Glib::DateTime
> > ```
> > Glib::Value data;
> > 
> > data.init(G_TYPE_DATE_TIME);
> > Glib::DateTime ctime = Glib::DateTime::create_now_utc();
> > data.set(ctime);
> > ```
> > 
> > This compiles ok, but generates 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x77b2405c in Glib::DateTime::operator= (this=0x0, src=...)
> > at
> > /home/pavlo/jhbuild/checkout/glibmm-2.4/glib/glibmm/datetime.cc:89
> > 89if(gobject_)
> > 

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

How to use Glib::Value?

[Pavlo Solntsev via gtkmm-list]

Hi,

Have this code 
```
Glib::Value datai;
datai.init(G_TYPE_INT);
datai.set(8);
std::cout << "Value = " << datai.get() << std::endl;
```
I see in stdout:
Value = 8

Works good. Now I would like to use another type: Glib::DateTime
```
Glib::Value data;

data.init(G_TYPE_DATE_TIME);
Glib::DateTime ctime = Glib::DateTime::create_now_utc();
data.set(ctime);
```

This compiles ok, but generates 
Program received signal SIGSEGV, Segmentation fault.
0x77b2405c in Glib::DateTime::operator= (this=0x0, src=...) at
/home/pavlo/jhbuild/checkout/glibmm-2.4/glib/glibmm/datetime.cc:89
89if(gobject_)

Part from dbg:
```
26Glib::Value data;
(gdb) 
28data.init(G_TYPE_DATE_TIME);
(gdb) p data
$1 = { = { = {gobject_ =
{g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0,
v_int64 = 0, 
v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0},
{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64
= 0, 
v_float = 0, v_double = 0, v_pointer = 0x0, }, static custom_type_ = }
(gdb) n
29Glib::DateTime ctime = Glib::DateTime::create_now_utc();
(gdb) p data
$2 = { = { = {gobject_ =
{g_type = 93824992400576, data = {{v_int = 0, v_uint = 0, v_long = 0,
v_ulong = 0, 
v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0,
v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0,
v_int64 = 0, 
v_uint64 = 0, v_float = 0, v_double = 0, v_pointer =
0x0, }, static custom_type_ = }
(gdb) n
30data.set(ctime);
(gdb) p data
$3 = { = { = {gobject_ =
{g_type = 93824992400576, data = {{v_int = 0, v_uint = 0, v_long = 0,
v_ulong = 0, 
v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0,
v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0,
v_int64 = 0, 
v_uint64 = 0, v_float = 0, v_double = 0, v_pointer =
0x0, }, static custom_type_ = }
(gdb) p ctime
$4 = {gobject_ = 0x5557c4a0}
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x77b2405c in Glib::DateTime::operator= (this=0x0, src=...) at
/home/pavlo/jhbuild/checkout/glibmm-2.4/glib/glibmm/datetime.cc:89
89if(gobject_)
(gdb) 
```

Could you please help me to understand how to use Glib::Value with
types such as Glib::DateTime?

Thanks.


-- 
- Pavlo Solntsev
-
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Sent from Evolution on GNU/Debian 


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: libgdamm development

[Pavlo Solntsev via gtkmm-list]

Thanks, for clarification. I may play with local modulsets. 



On Tue, 2018-09-11 at 15:36 +0200, Kjell Ahlstedt wrote:
> I have not worked with libgdamm, but when looking at some files in
> the GitLab repository, I can see that they are out of date and/or
> inconsistent.
> jhbuild's gnome-world.modules file says that libgdamm's master branch
> depends on gtkmm-3 (and thus indirectly on glibmm-2.4). This does not
> fit with configure.ac, which says that libgdamm-6.0 depends
> on glibmm-2.56. That's an obsolete name of the new ABI, which is now
> called glibmm-2.58, and which is compatible with gtkmm-4.
> It looks like the libgdamm-5-0 branch is the one to use in
> combination with glibmm-2.4 and gtkmm-3.
> I suppose that if you want to work with the libgdamm's master branch,
> you have to use the latest versions, i.e. the master branches, also
> from gtkmm and the modules it depends on. But that's not what
> 'jhbuild build libgdamm' will give you.
> /Kjell
> On 2018-09-11 05:38, Pavlo Solntsev via gtkmm-list wrote:
> > Hi, 
> > I am trying to compile libgdamm using jhbuild. Everything was
> > compiled
> > successfully but not libgdamm.  It looks like it needs very "fresh"
> > version of glibmm: 
> > 
> > return Glib::make_refptr_for_instance(
> > dynamic_cast (Glib::wrap_auto
> > ((GObject*)(object),
> > take_copy)) );
> > 
> > Could you please share your experience with libgdamm compilation? I
> > was
> > thinking to port some new work in libgda but it is really
> > frustrating
> > if I can't even compile it. Is it really necessary to pull recent
> > glimmand gtkmm-4? 
> > 
> > Thanks.
> > 
> > 
>  

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

libgdamm development

[Pavlo Solntsev via gtkmm-list]

Hi, 
I am trying to compile libgdamm using jhbuild. Everything was compiled
successfully but not libgdamm.  It looks like it needs very "fresh"
version of glibmm: 

return Glib::make_refptr_for_instance(
dynamic_cast (Glib::wrap_auto ((GObject*)(object),
take_copy)) );

Could you please share your experience with libgdamm compilation? I was
thinking to port some new work in libgda but it is really frustrating
if I can't even compile it. Is it really necessary to pull recent glimmand 
gtkmm-4? 

Thanks.


-- 
 

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: glibmm versions

[Pavlo Solntsev via gtkmm-list]

Thank you for clarification. 

gtkmm for libgdamm is optional, to compile libgda-ui module and other
useful tools. There is a separate package libgda-uimm which contains
some GUI widgets for libgda. Actually, very useful widgets. But libgda-
uimm is very old and should be updated. I am contributing to the libgda
and usually build all available modules from the source libgda.
Therefore, I need dev files not just from gtk but also from gladeui.
Some code was modified to use the recent API from libgdamm and thus the
current libgdamm depends on recent API version. For now, I use C code
directly from c++ app. Will play on side with jhbuild moduleset files.

Thanks,


On Sun, 2018-07-29 at 13:04 +0200, Kjell Ahlstedt wrote:
> The gtk+ team are working on a new gtk+-4.0 ABI, parallel-installable 
> with gtk+-3.0. The corresponding gtkmm ABI is gtkmm-4.0.
> The glib team don't plan for a new glib ABI. It will still be glib-
> 2.0. But there will be a new glibmm ABI, parallel-installable with
> glibmm-2.4. Unfortunately the name of this new glibmm ABI has not yet
> settled. It will depend on which glib-2.0 release it will be based
> on, and that depends on when the gtk+-4.0 and gtkmm-4.0 ABI will
> become stable. That has caused the confusion with different
> preliminary names of the new glibmm ABI. It would perhaps have been
> better to use an obviously preliminary name, like for example glibmm-
> 2X, until both the ABI and its name become stable. Then the ABI name
> would change just once.
> It looks to me as if he jhbuild moduleset for libgdamm ought to be
> updated. Probably you need a libgdamm entry, downloading the master
> branch, and depending on gtkmm (i.e. the new gtkmm-4.0), then a
> libgdamm-5 entry, downloading another branch (libgdamm-5-0?), and
> depending on gtkmm-3.
> How come libgdamm depend on gtkmm according to the jhbuild moduleset,
> but gtkmm is now mentioned in configure.ac?
> On 2018-07-26 20:43, p.sun@gmail.com wrote:
> > Thank you, Kjell.
> > 
> > Situation with API/ABI version is really confusing. Is there any
> > rule
> > you follow when you make a release? Say, new version of glibmm is
> > issued after new version of glib. 
> > 
> > From jhbuild moduleset only libgdamm needs glibmm-2.58 (a la
> > master).
> > Downgrade doesn't work since API for glibmm was changed between 2.4
> > and
> > 2.56. It looks like only one solution here is to create a local
> > module
> > set file and build all dependencies around master. 
> > 
> > Thanks.
> > 
> > 
> > On Thu, 2018-07-26 at 10:40 +0200, Kjell Ahlstedt wrote:
> > > glibmm-2.56 was once the tentative ABI-name of a series of new
> > > ABI-
> > > breaking releases of glibmm. Now the still tentative ABI-name is
> > > glibmm-2.58. It's very confusing. I've tried to explain in a
> > > jhbuild
> > > bug.
> > > https://bugzilla.gnome.org/show_bug.cgi?id=792047#c6
> > > https://bugzilla.gnome.org/show_bug.cgi?id=792047#c11
> > > You shall probably change the requirement in libgdamm to glibmm-
> > > 2.58
> > > > = 2.57.1
> > > 
> > > Kjell
> > > On 2018-07-26 07:21, Pavlo Solntsev via gtkmm-list wrote:
> > > > Hi,
> > > > Could you please clarify the following. I am trying to compile
> > > > libgdamm. It requires glibmm-2.56 >= 2.45.31. What does it
> > > > mean?
> > > > There
> > > > is a branch 2.56 which corresponds to glibmm-2.4. How to get
> > > > glibmm-
> > > > 2.56? master corresponds to glibmm-2.58. I already filed bug
> > > > against
> > > > jhbuild but I am ready to compile glibmm manually. 
> > > > 
> > > > Thanks.
> > > > 
> > > > 
> > > > 
> > > > configure: error: Package requirements (glibmm-2.56 >= 2.45.31
> > > > libgda-
> > > > 6.0 >= 5.0.2) were not met:
> > > > 
> > > > No package 'glibmm-2.56' found
> > > > 
> > > 
> > >  
>  
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: glibmm versions

[Pavlo Solntsev via gtkmm-list]

Thank you, Kjell.

Situation with API/ABI version is really confusing. Is there any rule
you follow when you make a release? Say, new version of glibmm is
issued after new version of glib. 

>From jhbuild moduleset only libgdamm needs glibmm-2.58 (a la master).
Downgrade doesn't work since API for glibmm was changed between 2.4 and
2.56. It looks like only one solution here is to create a local module
set file and build all dependencies around master. 

Thanks.


On Thu, 2018-07-26 at 10:40 +0200, Kjell Ahlstedt wrote:
> glibmm-2.56 was once the tentative ABI-name of a series of new ABI-
> breaking releases of glibmm. Now the still tentative ABI-name is
> glibmm-2.58. It's very confusing. I've tried to explain in a jhbuild
> bug.
> https://bugzilla.gnome.org/show_bug.cgi?id=792047#c6
> https://bugzilla.gnome.org/show_bug.cgi?id=792047#c11
> You shall probably change the requirement in libgdamm to glibmm-2.58
> >= 2.57.1
> Kjell
> On 2018-07-26 07:21, Pavlo Solntsev via gtkmm-list wrote:
> > Hi,
> > Could you please clarify the following. I am trying to compile
> > libgdamm. It requires glibmm-2.56 >= 2.45.31. What does it mean?
> > There
> > is a branch 2.56 which corresponds to glibmm-2.4. How to get
> > glibmm-
> > 2.56? master corresponds to glibmm-2.58. I already filed bug
> > against
> > jhbuild but I am ready to compile glibmm manually. 
> > 
> > Thanks.
> > 
> > 
> > 
> > configure: error: Package requirements (glibmm-2.56 >= 2.45.31
> > libgda-
> > 6.0 >= 5.0.2) were not met:
> > 
> > No package 'glibmm-2.56' found
> > 
>  
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

glibmm versions

[Pavlo Solntsev via gtkmm-list]

Hi,
Could you please clarify the following. I am trying to compile
libgdamm. It requires glibmm-2.56 >= 2.45.31. What does it mean? There
is a branch 2.56 which corresponds to glibmm-2.4. How to get glibmm-
2.56? master corresponds to glibmm-2.58. I already filed bug against
jhbuild but I am ready to compile glibmm manually. 

Thanks.



configure: error: Package requirements (glibmm-2.56 >= 2.45.31 libgda-
6.0 >= 5.0.2) were not met:

No package 'glibmm-2.56' found
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: c++ source generation from C code

[Pavlo Solntsev via gtkmm-list]

Thanks.

It works. 

On Thu, 2018-07-12 at 13:16 +0200, Kjell Ahlstedt wrote:
> On 2018-07-12 05:43, Pavlo Solntsev via gtkmm-list wrote:
> > Hi,
> > 
> > As I mentioned before, libgda was significantly modified and as
> > results, libgdamm is broken. I was trying to fix this. Overall, I
> > was
> > very close to the final solution but it looks like the generated
> > c++
> > code contains statement like:
> > 
> > using GdaHandlerBooleanClass = struct _GdaHandlerBooleanClass;
> > 
> > and it causes compilation error:
> > conflicting declaration...
> > 
> > previous declaration as ‘typedef struct GdaHandlerBinClass
> > GdaHandlerBinClass’
> >  G_DECLARE_FINAL_TYPE (GdaHandlerBin, gda_handler_bin, GDA,
> > HANDLER_BIN, GObject)
> >^
> > /home/pavlo/jhbuild/install/include/glib-
> > 2.0/gobject/gtype.h:1399:54:
> > note: in definition of macro ‘G_DECLARE_FINAL_TYPE’
> >typedef struct { ParentName##Class parent_class; }
> > ModuleObjName##Class;   \
> >   ^
> > 
> > Could you please give me a hint to the solution, if any? I suspect
> > it
> > is a m4 macro issue, that should be modified. 
> > 
> > On other matter. Do you accept merge requests to gitlab?
> > 
> > Thanks.
> > 
>  Try _STRUCT_NOT_HIDDEN, like in e.g. https://gitlab.gnome.org/GNOME/
> gtkmm/blob/master/gtk/src/filechoosernative.hg line 109:
> 
> class FileChooserNative : public NativeDialog, public FileChooser
> {
>   _CLASS_GOBJECT(FileChooserNative, GtkFileChooserNative,
> GTK_FILE_CHOOSER_NATIVE, NativeDialog, GtkNativeDialog)
>   _IMPLEMENTS_INTERFACE(FileChooser)
>   _STRUCT_NOT_HIDDEN
>   ..
> 
> Whether merge requests are accepted for libgdamm, I don't know. I
> have not worked with libgdamm.
> 
> /Kjell
> 
> 
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

c++ source generation from C code

[Pavlo Solntsev via gtkmm-list]

Hi,

As I mentioned before, libgda was significantly modified and as
results, libgdamm is broken. I was trying to fix this. Overall, I was
very close to the final solution but it looks like the generated c++
code contains statement like:

using GdaHandlerBooleanClass = struct _GdaHandlerBooleanClass;

and it causes compilation error:
conflicting declaration...

previous declaration as ‘typedef struct GdaHandlerBinClass
GdaHandlerBinClass’
 G_DECLARE_FINAL_TYPE (GdaHandlerBin, gda_handler_bin, GDA,
HANDLER_BIN, GObject)
   ^
/home/pavlo/jhbuild/install/include/glib-2.0/gobject/gtype.h:1399:54:
note: in definition of macro ‘G_DECLARE_FINAL_TYPE’
   typedef struct { ParentName##Class parent_class; }
ModuleObjName##Class;   \
  ^

Could you please give me a hint to the solution, if any? I suspect it
is a m4 macro issue, that should be modified. 

On other matter. Do you accept merge requests to gitlab?

Thanks.

-- 
- Pavlo Solntsev
-
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Sent from Evolution on GNU/Debian 

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Looking for support

[Pavlo Solntsev]

Dear Kjell.

Patches I submitted to libgda were not even reviewed. The project is
dead. I understand that my involvement into GNOME dev community is very
low to justify writing permissions. Therefore, I forked libgda to
gitlab.gnome.org. I patches don't got to upstream I will push them to
my copy and leave to to community to use the forked version or stay
with the original one. 


On Thu, 2018-03-08 at 10:57 +0100, Kjell Ahlstedt wrote:
> At https://wiki.gnome.org/AccountsTeam/NewAccounts it's said:
> > We do request that applicants have submitted a reasonable number of
> > patches to an existing maintainer, or bugzilla reports before they
> > request direct commit access. 
> 
> You supplied one patch to https://bugzilla.gnome.org/show_bug.cgi?id=
> 793778, but that's probably not enough for you to get commit
> permission to the git repository. Have you supplied other accepted
> patches? If so, ask the person(s) that reviewed and accepted your
> patches.
> Kjell
> Den 2018-03-05 kl. 21:24, skrev Pavlo Solntsev:
> > Dear friends.
> > 
> > I am interested in libgda/libgdamm projects. It looks like, the
> > activity of  the libgda project is very slow. I am interested in
> > libgda
> > project and see some room for improvements. I want to help with
> > this
> > project. As part of this process, I submitted a request to have
> > write
> > access to the GNOME repo. The administrator is asking for a vouch.
> > Is
> > there anyone who can support me in this case?
> > 
> > Please note my e-mail change. 
> > 
> > Thanks for help.
> > 
> > 
>  
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Looking for support

[Pavlo Solntsev]

Dear friends.

I am interested in libgda/libgdamm projects. It looks like, the
activity of  the libgda project is very slow. I am interested in libgda
project and see some room for improvements. I want to help with this
project. As part of this process, I submitted a request to have write
access to the GNOME repo. The administrator is asking for a vouch. Is
there anyone who can support me in this case?

Please note my e-mail change. 

Thanks for help.


-- 
- Pavlo Solntsev
-
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Sent from Evolution on GNU/Debian 

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: get/set wrap methods.

[Pavlo Solntsev]

By mistake I made the bug visible to llibgdamm developers only. I added
your email and other email. You should be able to it. It looks like only
libgdamm developer can change visibility of the bug. If you still have
problem - let me know and I will resubmit as a new one.

-Pavlo Solntsev
-

*Please avoid sending me Word or PowerPoint attachments.See
http://www.gnu.org/philosophy/no-word-attachments.html
<http://www.gnu.org/philosophy/no-word-attachments.html>*

On Sat, Feb 24, 2018 at 3:05 AM, Kjell Ahlstedt <kjellahlst...@gmail.com>
wrote:

> When I try to open your bug report, I only get the message
>
> You are not authorized to access bug #793778.
>
> Kjell
>
> Den 2018-02-24 kl. 05:06, skrev Pavlo Solntsev:
>
> Just submitted a patch for a macro to generate setter for char* member in
> consistent way. Please review.
> https://bugzilla.gnome.org/show_bug.cgi?id=793778
>
>
> -Pavlo Solntsev
> 
> -
>
> *Please avoid sending me Word or PowerPoint attachments. See
> http://www.gnu.org/philosophy/no-word-attachments.html
> <http://www.gnu.org/philosophy/no-word-attachments.html>*
>
> On Fri, Feb 23, 2018 at 10:12 AM, Pavlo Solntsev <pavlo.solnt...@gmail.com
> > wrote:
>
>> Perfect! Now I understand the methodology to implement setter for a
>> structure. Do you think it would make sense to have a macro for this?  Say,
>> _MEMBER_SET_CHAR.
>>
>> -Pavlo Solntsev
>> 
>> -
>>
>>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: get/set wrap methods.

[Pavlo Solntsev]

Just submitted a patch for a macro to generate setter for char* member in
consistent way. Please review.
https://bugzilla.gnome.org/show_bug.cgi?id=793778


-Pavlo Solntsev
-

*Please avoid sending me Word or PowerPoint attachments.See
http://www.gnu.org/philosophy/no-word-attachments.html
<http://www.gnu.org/philosophy/no-word-attachments.html>*

On Fri, Feb 23, 2018 at 10:12 AM, Pavlo Solntsev <pavlo.solnt...@gmail.com>
wrote:

> Perfect! Now I understand the methodology to implement setter for a
> structure. Do you think it would make sense to have a macro for this?  Say,
> _MEMBER_SET_CHAR.
>
> -Pavlo Solntsev
> 
> -
>
> *Please avoid sending me Word or PowerPoint attachments.See
> http://www.gnu.org/philosophy/no-word-attachments.html
> <http://www.gnu.org/philosophy/no-word-attachments.html>*
>
> On Fri, Feb 23, 2018 at 9:43 AM, Kjell Ahlstedt <kjellahlst...@gmail.com>
> wrote:
>
>> Den 2018-02-23 kl. 15:36, skrev Pavlo Solntsev:
>>
>> >>>  Your concern is justified. The Glib::ustring must be returned by
>> value. The _MEMBER_GET should be
>> It is interesting. getter must return by value
>>
>> >>> Your _MEMBER_SET macro doesn't seem to fit the generated code that
>> you show. I would think that
>> >>>  _MEMBER_SET(name, name, const Glib::ustring&, gchar*)
>>
>> from https://github.com/GNOME/glibmm/blob/master/tools/m4/member.m4
>> My understanding that the generated type will be const T& if T is
>> provided to the macros.
>>
>> dnl Creates accessors for simple types:
>>
>> define(`_MEMBER_SET',`dnl
>>
>> ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_START ')dnl
>>
>> void set_$1(const $3`'& value);
>>
>> ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_END ')dnl
>>
>> _PUSH(SECTION_CC)
>>
>> ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_START ')dnl
>>
>> void __CPPNAME__::set_$1(const $3`'& value)
>>
>> {
>>
>> gobj()->$2 = _CONVERT($3,$4,`value');
>>
>> }
>>
>> ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_END ')dnl
>>
>>
>> _POP()')
>>
>>
>>
>>
>> Sorry, I was wrong. _MEMBER_SET(name, name, Glib::ustring, gchar*)
>> does generate the code you showed.
>>
>> >> would generate that code. In this case a reference is OK, but it looks
>> like the generated code can cause a memory leak. Who owns the duplicated
>> string? Who deallocates it? What if gobj()->name contains a pointer to a
>> string when set_name() is called?
>>
>>
>> Basically once again, return by value. What would be the correct wrap for
>> the simple struct? Wrap struct and manually wrap set/get method?
>>
>> I will investigate how private members are stored and how they related to
>> the original C struct. Thanks
>>
>> In Glib::OptionEntry, _MEMBER_SET is not used for strings. Those methods
>> are hand-coded to avoid a memory leak. Example:
>>
>> void OptionEntry::set_long_name(const Glib::ustring& value)
>> {
>>   if (gobject_->long_name)
>>   {
>> g_free((gchar*)(gobject_->long_name));
>> gobject_->long_name = nullptr;
>>   }
>>
>>   gobj()->long_name = (value).c_str() ? g_strdup((value).c_str()) :
>> nullptr;
>> }
>>
>>
>> Don't ask me why value.c_str() is tested for nullptr. I don't understand.
>> I don't think it can ever be a nullptr. And even if it is, g_strdup() can
>> handle that.
>>
>>
>>
>> -Pavlo Solntsev
>>
>>
>>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: get/set wrap methods.

[Pavlo Solntsev]

Perfect! Now I understand the methodology to implement setter for a
structure. Do you think it would make sense to have a macro for this?  Say,
_MEMBER_SET_CHAR.

-Pavlo Solntsev
-

*Please avoid sending me Word or PowerPoint attachments.See
http://www.gnu.org/philosophy/no-word-attachments.html
<http://www.gnu.org/philosophy/no-word-attachments.html>*

On Fri, Feb 23, 2018 at 9:43 AM, Kjell Ahlstedt <kjellahlst...@gmail.com>
wrote:

> Den 2018-02-23 kl. 15:36, skrev Pavlo Solntsev:
>
> >>>  Your concern is justified. The Glib::ustring must be returned by
> value. The _MEMBER_GET should be
> It is interesting. getter must return by value
>
> >>> Your _MEMBER_SET macro doesn't seem to fit the generated code that you
> show. I would think that
> >>>  _MEMBER_SET(name, name, const Glib::ustring&, gchar*)
>
> from https://github.com/GNOME/glibmm/blob/master/tools/m4/member.m4
> My understanding that the generated type will be const T& if T is provided
> to the macros.
>
> dnl Creates accessors for simple types:
>
> define(`_MEMBER_SET',`dnl
>
> ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_START ')dnl
>
> void set_$1(const $3`'& value);
>
> ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_END ')dnl
>
> _PUSH(SECTION_CC)
>
> ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_START ')dnl
>
> void __CPPNAME__::set_$1(const $3`'& value)
>
> {
>
> gobj()->$2 = _CONVERT($3,$4,`value');
>
> }
>
> ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_END ')dnl
>
>
> _POP()')
>
>
>
>
> Sorry, I was wrong. _MEMBER_SET(name, name, Glib::ustring, gchar*)
> does generate the code you showed.
>
> >> would generate that code. In this case a reference is OK, but it looks
> like the generated code can cause a memory leak. Who owns the duplicated
> string? Who deallocates it? What if gobj()->name contains a pointer to a
> string when set_name() is called?
>
>
> Basically once again, return by value. What would be the correct wrap for
> the simple struct? Wrap struct and manually wrap set/get method?
>
> I will investigate how private members are stored and how they related to
> the original C struct. Thanks
>
> In Glib::OptionEntry, _MEMBER_SET is not used for strings. Those methods
> are hand-coded to avoid a memory leak. Example:
>
> void OptionEntry::set_long_name(const Glib::ustring& value)
> {
>   if (gobject_->long_name)
>   {
> g_free((gchar*)(gobject_->long_name));
> gobject_->long_name = nullptr;
>   }
>
>   gobj()->long_name = (value).c_str() ? g_strdup((value).c_str()) :
> nullptr;
> }
>
>
> Don't ask me why value.c_str() is tested for nullptr. I don't understand.
> I don't think it can ever be a nullptr. And even if it is, g_strdup() can
> handle that.
>
>
>
> -Pavlo Solntsev
>
>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: get/set wrap methods.

[Pavlo Solntsev]

Daniel,

now it is clear. I didn't and still don't understand exactly how internal
data members are represented in the generated class (I have no access to my
code now) but the situation I have by returning a reference is clear. BTW
does it make sense to think about shared_ptr as returned value for getter?

-Pavlo Solntsev
-

*Please avoid sending me Word or PowerPoint attachments.See
http://www.gnu.org/philosophy/no-word-attachments.html
<http://www.gnu.org/philosophy/no-word-attachments.html>*

On Fri, Feb 23, 2018 at 8:42 AM, Daniel Boles <dboles@gmail.com> wrote:

> > Basically, this is glibmm limitation for now.
>
> I can see no way that this is any fault or limitation of glibmm's. It is
> rather a simple fact of any language supporting reference semantics: You
> can't (safely, usefully) have a reference of a given type unless you have
> an instance of that type, with at least the same lifetime as that of the
> reference.
>
> You have a char* but want to return a Glib::ustring&; these are not
> compatible facts. So, the Glib::ustring must be created whenever requested,
> and returned by value. If you want to return a Glib::ustring&, keep a
> Glib::ustring somewhere, and use a reference to that.
>
>
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: get/set wrap methods.

[Pavlo Solntsev]

Daniel,
now it is clear. Basically, this is glibmm limitation for now.

-Pavlo Solntsev
-

*Please avoid sending me Word or PowerPoint attachments.See
http://www.gnu.org/philosophy/no-word-attachments.html
<http://www.gnu.org/philosophy/no-word-attachments.html>*

On Fri, Feb 23, 2018 at 8:25 AM, Daniel Boles <dboles@gmail.com> wrote:

> You might think you need that, but you can't do it, because there is
> nothing permanent to reference, only a temporary created by the conversion
> to ustring.
>
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: get/set wrap methods.

[Pavlo Solntsev]

>>>  Your concern is justified. The Glib::ustring must be returned by
value. The _MEMBER_GET should be
It is interesting. getter must return by value

>>> Your _MEMBER_SET macro doesn't seem to fit the generated code that you
show. I would think that
>>>  _MEMBER_SET(name, name, const Glib::ustring&, gchar*)

from https://github.com/GNOME/glibmm/blob/master/tools/m4/member.m4
My understanding that the generated type will be const T& if T is provided
to the macros.

dnl Creates accessors for simple types:
define(`_MEMBER_SET',`dnl
ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_START ')dnl
void set_$1(const $3`'& value);
ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_END ')dnl
_PUSH(SECTION_CC)
ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_START ')dnl
void __CPPNAME__::set_$1(const $3`'& value)
{
gobj()->$2 = _CONVERT($3,$4,`value');
}
ifelse(`$5',`deprecated',`_DEPRECATE_IFDEF_END ')dnl
_POP()')



>> would generate that code. In this case a reference is OK, but it looks
like the generated code can cause a memory leak. Who owns the duplicated
string? Who deallocates it? What if gobj()->name contains a pointer to a
string when set_name() is called?


Basically once again, return by value. What would be the correct wrap for
the simple struct? Wrap struct and manually wrap set/get method?

I will investigate how private members are stored and how they related to
the original C struct. Thanks



-Pavlo Solntsev
-

*Please avoid sending me Word or PowerPoint attachments.See
http://www.gnu.org/philosophy/no-word-attachments.html
<http://www.gnu.org/philosophy/no-word-attachments.html>*

On Fri, Feb 23, 2018 at 4:02 AM, Kjell Ahlstedt <kjellahlst...@gmail.com>
wrote:

> Your concern is justified. The Glib::ustring must be returned by value.
> The _MEMBER_GET should be
>
>   _MEMBER_GET(name, name, Glib::ustring, const gchar*)
> Your _MEMBER_SET macro doesn't seem to fit the generated code that you
> show. I would think that
>   _MEMBER_SET(name, name, const Glib::ustring&, gchar*)
> would generate that code. In this case a reference is OK, but it looks
> like the generated code can cause a memory leak. Who owns the duplicated
> string? Who deallocates it? What if gobj()->name contains a pointer to a
> string when set_name() is called?
>
> Kjell
>
>
> Den 2018-02-22 kl. 20:56, skrev Pavlo Solntsev:
>
> Thanks for comments.  My macroses:
>
>   _MEMBER_GET(name,name,const Glib::ustring&,const gchar*)
>   _MEMBER_SET(name,name,Glib::ustring,gchar*)
>
> the generated code :
> const Glib::ustring& DsnInfo::get_name() const
> {
>   return Glib::convert_const_gchar_ptr_to_ustring(gobj()->name); // This
> is my concern. it looks like we return ref for temp object
> }
>
> void DsnInfo::set_name(const Glib::ustring& value)
> {
>   gobj()->name = g_strdup((value).c_str());
> }
>
> Thanks.
>
> -Pavlo Solntsev
> 
> -
>
> *Please avoid sending me Word or PowerPoint attachments. See
> http://www.gnu.org/philosophy/no-word-attachments.html
> <http://www.gnu.org/philosophy/no-word-attachments.html>*
>
> On Thu, Feb 22, 2018 at 12:34 PM, Daniel Boles <dboles@gmail.com>
> wrote:
>
>> On 22 February 2018 at 18:32, Daniel Boles <dboles@gmail.com> wrote:
>>
>>> also, I don't see how RefPtr is relevant to the given example struct;
>>> it's only for Glib::Object instances, i.e. things that themselves wrap
>>> GObjects, as RefPtr is implemented via GObject refcounts.
>>>
>>
>> ...in the currently stable glibmm, at least. Beyond that, in the next
>> release, it'll be an std::shared_ptr, layering a different layer of
>> refcounting over GObject's own.
>>
>> but the point stands: what would a RefPtr to a char* or any other simple
>> property type even mean? They should just be returned by value, not by
>> reference.
>>
>>
>> ___
>> gtkmm-list mailing list
>> gtkmm-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>>
>>
>
>
> ___
> gtkmm-list mailing 
> listgtkmm-list@gnome.orghttps://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: get/set wrap methods.

[Pavlo Solntsev]

Yes, I did. because my goal is to get
const T& get_name()const
method. I need to return a reference.


-Pavlo Solntsev
-

*Please avoid sending me Word or PowerPoint attachments.See
http://www.gnu.org/philosophy/no-word-attachments.html
<http://www.gnu.org/philosophy/no-word-attachments.html>*

On Fri, Feb 23, 2018 at 3:40 AM, Daniel Boles <dboles@gmail.com> wrote:

> On 22 February 2018 at 19:56, Pavlo Solntsev <pavlo.solnt...@gmail.com>
> wrote:
>
>> Thanks for comments.  My macroses:
>>
>>   _MEMBER_GET(name,name,const Glib::ustring&,const gchar*)
>>   _MEMBER_SET(name,name,Glib::ustring,gchar*)
>>
>> the generated code :
>> const Glib::ustring& DsnInfo::get_name() const
>> {
>>   return Glib::convert_const_gchar_ptr_to_ustring(gobj()->name); // This
>> is my concern. it looks like we return ref for temp object
>> }
>>
>
>
> Of course it returns that. You just told it to! Look at the 2nd parameter
> of your _MEMBER_GET() declaration.
>
>
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: get/set wrap methods.

[Pavlo Solntsev]

Thanks for comments.  My macroses:

  _MEMBER_GET(name,name,const Glib::ustring&,const gchar*)
  _MEMBER_SET(name,name,Glib::ustring,gchar*)

the generated code :
const Glib::ustring& DsnInfo::get_name() const
{
  return Glib::convert_const_gchar_ptr_to_ustring(gobj()->name); // This is
my concern. it looks like we return ref for temp object
}

void DsnInfo::set_name(const Glib::ustring& value)
{
  gobj()->name = g_strdup((value).c_str());
}

Thanks.

-Pavlo Solntsev
-

*Please avoid sending me Word or PowerPoint attachments.See
http://www.gnu.org/philosophy/no-word-attachments.html
<http://www.gnu.org/philosophy/no-word-attachments.html>*

On Thu, Feb 22, 2018 at 12:34 PM, Daniel Boles <dboles@gmail.com> wrote:

> On 22 February 2018 at 18:32, Daniel Boles <dboles@gmail.com> wrote:
>
>> also, I don't see how RefPtr is relevant to the given example struct;
>> it's only for Glib::Object instances, i.e. things that themselves wrap
>> GObjects, as RefPtr is implemented via GObject refcounts.
>>
>
> ...in the currently stable glibmm, at least. Beyond that, in the next
> release, it'll be an std::shared_ptr, layering a different layer of
> refcounting over GObject's own.
>
> but the point stands: what would a RefPtr to a char* or any other simple
> property type even mean? They should just be returned by value, not by
> reference.
>
>
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

get/set wrap methods.

[Pavlo Solntsev]

I am trying to wrap a simple structure from libgda package. I followed some
examples and documentation and was able to implement all get/set methods
via _MEMBER_GET macros. The generated code looks exactly as I would expect
for c++ get/set:

const T& get_some()const;
void set_some(const T&);

My question about getter. It looks like I return a reference for the
temporary created object, which is not good. Do you think getter should
return Glib::RefPtr<>? It is a little uncommon for c++ in my opinion. Does
it cause any performance degradation by creating a RefPtr object and
returning it?

As an example, we may consider a simple struct:
struct Person {
char *fname;
char *lname;
};

Thanks,

-Pavlo Solntsev
-

*Please avoid sending me Word or PowerPoint attachments.See
http://www.gnu.org/philosophy/no-word-attachments.html
<http://www.gnu.org/philosophy/no-word-attachments.html>*
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: prepare_create_table wrapping - part2

[Pavlo Solntsev]

Dear Kjell.

There is no open bug. I should probably explain how it started. I have
personal interests in using libgdamm. I found that simple process of
creating tables was missed in libgdamm. However, in libgda those
methods were available. I had two options: 1) make my own version of
methods to create a table or 2) help community and add those methods to
libgdamm. Initial problem with implementation was with understanding
how implementation (wrapping) works. Sorry, but not a lot of
documentation available. I naturally expected different behavior of
_CLASS_GENERIC methods and _WRAP_METHOD. In the process I learn
information that wasn't clearly available to me: class in class
wrapping. Wrapping non GObject based classes etc. To all that, I didn't
know internal policy in *mm projects. Does it make sense to write
classes in the mm module? How to wrap correctly C style struct to C++
class, or leave it as a struct. After I spent some time, played with
code, bugged you (sorry for that) I have already answers for majority
of the listed above questions but some of them still unclear. 

I will file a bug report for missing
Gda::ServerOperation::prepare_create_table()
Gda::ServerOperation::perform_create_table()
methods to track all changes. 

And I agree with you comments. 

Best,

On Sun, 2017-05-14 at 19:28 +0200, Kjell Ahlstedt wrote:
> This discussion is perhaps more suitable for a bug report. But if
> you 
> had started with a libgdamm bug, I would not have found it. Anyway,
> here 
> are some comments.
> 
> _WRAP_METHOD and many other _WRAP_* macros can only be used in a
> class 
> with a _CLASS_* macro. In this patch it looks like 
> ServerOperationCreateTableArg is not included within another class.
> It 
> ought to be possible to use one of the _CLASS_* macros, perhaps 
> _CLASS_OPAQUE_COPYABLE.
> 
> cnc.operator->()->gobj()? Why not just cnc->gobj()?
> 
> Don't ServerOperationCreateTableArg's copy constructors leak memory? 
> They assign to _parent several times.
> 
> 
> Den 2017-05-13 kl. 18:42, skrev Pavlo Solntsev:
> > Dear Kjell.
> > 
> > Thank you so much for pointing on that. I have successfully
> > compiled
> > libgdamm. Could you please take a look for CreateTableArg class
> > implementation. Is it something we can stay with? I found that
> > _WRAP_METHOD doesn't work in this case.
> >    
> > Thanks.
> > 
> > 
> > On Sat, 2017-05-13 at 09:53 +0200, Kjell Ahlstedt wrote:
> > > You have misspelt CreateTableArgTraits in some places
> > > (CreateTableArgTriats), but not everywhere.
> > > 
> > > You can remove the CONVERSION()s to Glib::RefPtr > > ServerOperationCreateTableArg> and
> > > Glib::RefPtr. I suppose they are
> > > not
> > > used, and therefore make no harm.
> > > 
> > > There may be other errors, I haven't studied your code in detail.
> > > 
> > > 
> > > -- 
> > 
> > - Pavlo Solntsev
> > 
> 
> 
-- 
- Pavlo Solntsev
-
Sent from Evolution on GNU/Debian  id="-x-evo-
selection-start-marker">


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: prepare_create_table wrapping - part2

[Pavlo Solntsev]

ok, good to know. I will try to build a class inside ServerOperation. What
I found, traits class needs a copy constructor for CppType method. I don't
see a simple way to overcome this just by using:
typedef GdaServerOperationCreateTableArg CreateTableArg

and traits class.

Probably a full class should be built. Thanks.


-Pavlo Solntsev


On Fri, May 12, 2017 at 6:32 AM, Kjell Ahlstedt <kjellahlst...@gmail.com>
wrote:

> I don't think it's possible to use _CLASS_GENERIC or any of the other
> _CLASS_* macros in a class within another class.
>
> Den 2017-05-11 kl. 15:21, skrev Pavlo Solntsev:
>
> Dear Kjell.
>
> My initial idea was to wrap struct GdaServerOperationCreateTableArg as a
> class inside the Gda::ServerOperatio. It should look like:
> Gda::ServerOperation::CreateTableArg. To do so I used _CLASS_GENERIC
> macros. I wasn't successful. It may be implemented manually, but in that
> case, it will not be wrap. I see not option now how to transform C-style
> struct to C++ class. I am talking about struct to class conversion because
> in C API there are a set of functions that can logically be wrapped as
> methods for C++ class. However, simple macros will not give enough
> flexibility for expansion the class. Do you think it is a good idea to
> write a class from scratch (without using macroses) based on C API? I may
> try this route but I want to make sure it is not against *mm rules of
> porting.
>
> I will play with your suggestion.
>
> Thanks,
>
> -Pavlo Solntsev
>
>
>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: prepare_create_table wrapping - part2

[Pavlo Solntsev]

Dear Kjell.

My initial idea was to wrap struct GdaServerOperationCreateTableArg as a
class inside the Gda::ServerOperatio. It should look like:
Gda::ServerOperation::CreateTableArg. To do so I used _CLASS_GENERIC
macros. I wasn't successful. It may be implemented manually, but in that
case, it will not be wrap. I see not option now how to transform C-style
struct to C++ class. I am talking about struct to class conversion because
in C API there are a set of functions that can logically be wrapped as
methods for C++ class. However, simple macros will not give enough
flexibility for expansion the class. Do you think it is a good idea to
write a class from scratch (without using macroses) based on C API? I may
try this route but I want to make sure it is not against *mm rules of
porting.

I will play with your suggestion.

Thanks,

-Pavlo Solntsev


On Thu, May 11, 2017 at 6:20 AM, Kjell Ahlstedt <kjellahlst...@gmail.com>
wrote:

> Glib::ListHandler uses a type traits class. It's a second template
> argument with a default value. The default type traits class is not
> suitable for your case, even though it might be considered the most
> elementary case: Convert a std::vector<T*> to GList with T* elements.
>
> First decide if you will use GdaServerOperationCreateTableArg pointers
> directly in libgdamm, or if you want to to wrap them in a 
> Gda::ServerOperationCreateTableArg
> class. Then make a type traits class suitable for either std::vector<
> GdaServerOperationCreateTableArg*> or std::vector ServerOperationCreateTableArg>. You can find some examples of type traits
> classes in glibmm/gio/src/resolver.ccg, gtkmm/gtk/src/iconview.hg,
> gtkmm/gtk/src/papersize.hg.
>
> RefPtr is not useful here. It contains a pointer to a C++ object with
> reference() and unreference() methods.
> Den 2017-05-09 kl. 21:19, skrev Pavlo Solntsev:
>
> Dear Kjell.
>
> I tried your suggestions and some problems are gone. However, I see
> some type conversion issue. It looks like
> _GdaServerOperationCreateTableArg type is not visible. I tried using
> RefPtr instead of plain pointers - same effect. I attached g++ output
> and patch. Thanks for any comments.
>
>
>
>
> On Tue, 2017-05-09 at 19:05 +0200, Kjell Ahlstedt wrote:
>
> Den 2017-05-09 kl. 05:18, skrev Pavlo Solntsev:
>
> hi,
> I found some mistakes in my code and fixed them. However, I can't
> figure out where is the problem. I included new patch for my
> changes as
> well as log from the compiler. Could someone take a look?
> Thanks.
>
>
>
> The description of gda_server_operation_prepare_create_table() says
> that
> the "arguments" parameter is a list of
> GdaServerOperationCreateTableArg,
> but if you look at the code in gda-server-operation.c, you'll see
> that
> it's really a list of GdaServerOperationCreateTableArg*, i.e. a list
> of
> pointers. GdaServerOperationCreateTableArg is defined in
> gda-server-operation.c, hidden from your code. You must use a
> std::vector<GdaServerOperationCreateTableArg*>.
>
>
>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: prepare_create_table wrapping - part2

[Pavlo Solntsev]

Dear Kjell.

I tried your suggestions and some problems are gone. However, I see
some type conversion issue. It looks like
_GdaServerOperationCreateTableArg type is not visible. I tried using
RefPtr instead of plain pointers - same effect. I attached g++ output
and patch. Thanks for any comments. 




On Tue, 2017-05-09 at 19:05 +0200, Kjell Ahlstedt wrote:
> Den 2017-05-09 kl. 05:18, skrev Pavlo Solntsev:
> > hi,
> > I found some mistakes in my code and fixed them. However, I can't
> > figure out where is the problem. I included new patch for my
> > changes as
> > well as log from the compiler. Could someone take a look?
> > Thanks.
> > 
> > 
> 
> The description of gda_server_operation_prepare_create_table() says
> that 
> the "arguments" parameter is a list of
> GdaServerOperationCreateTableArg, 
> but if you look at the code in gda-server-operation.c, you'll see
> that 
> it's really a list of GdaServerOperationCreateTableArg*, i.e. a list
> of 
> pointers. GdaServerOperationCreateTableArg is defined in 
> gda-server-operation.c, hidden from your code. You must use a 
> std::vector<GdaServerOperationCreateTableArg*>.
> 
-- 
- Pavlo Solntsev
-
Sent from Evolution on GNU/Debian  id="-x-evo-
selection-start-marker">

diff --git a/libgda/src/serveroperation.ccg b/libgda/src/serveroperation.ccg
index 7062331..7f34bd6 100644
--- a/libgda/src/serveroperation.ccg
+++ b/libgda/src/serveroperation.ccg
@@ -77,6 +77,25 @@ void ServerOperation::set_value_at_as_value(const Glib::ustring& path, const Gli
 ::Glib::Error::throw_exception(gerror);
 }
 
+static Glib::RefPtr prepare_create_table(
+Glib::RefPtr , 
+const Glib::ustring _name,
+std::vector<GdaServerOperationCreateTableArg* > )
+{
+GError* gerror = 0;
+Glib::RefPtr op =
+Glib::wrap(gda_server_operation_prepare_create_table(
+cnc.operator->()->gobj(), 
+table_name.c_str(),
+Glib::ListHandler::vector_to_list(arguments).data(),
+)
+);   
+
+  if(gerror) ::Glib::Error::throw_exception(gerror);
+
+  return op;
+}
+
 } /* namespace Gda */
 
 } /* namespace Gnome */
diff --git a/libgda/src/serveroperation.hg b/libgda/src/serveroperation.hg
index 079651d..286bbbf 100644
--- a/libgda/src/serveroperation.hg
+++ b/libgda/src/serveroperation.hg
@@ -62,12 +62,17 @@ public:
   _WRAP_ENUM(Type, GdaServerOperationType, NO_GTYPE)
 
   // These are from gda-easy but they fit in here best
-  static Glib::RefPtr prepare_create_database(const Glib::ustring& provider,
+   static Glib::RefPtr prepare_create_database(const Glib::ustring& provider,
const Glib::ustring& db_name);
 
-  static Glib::RefPtr prepare_drop_database(const Glib::ustring& provider,
+   static Glib::RefPtr prepare_drop_database(const Glib::ustring& provider,
  const Glib::ustring& db_name);
 
+   static Glib::RefPtr prepare_create_table(
+   Glib::RefPtr , 
+   const Glib::ustring _name,
+   std::vector );
+
   _WRAP_METHOD(void perform_create_table(), gda_server_operation_perform_create_table, errthrow)
   _WRAP_METHOD(void perform_drop_database(const Glib::ustring& provider), gda_server_operation_perform_drop_database, errthrow)
   _WRAP_METHOD(void perform_create_database(const Glib::ustring& provider), gda_server_operation_perform_create_database, errthrow)
diff --git a/tools/m4/convert_libgdamm.m4 b/tools/m4/convert_libgdamm.m4
index 255f651..529015e 100644
--- a/tools/m4/convert_libgdamm.m4
+++ b/tools/m4/convert_libgdamm.m4
@@ -45,6 +45,8 @@ _CONVERSION(`GdaServerProvider*',`Glib::RefPtr',`Glib::wrap($3)'
 _CONVERSION(`GdaServerProvider*',`Glib::RefPtr',`Glib::wrap($3)')
 _CONVERSION(`GdaServerOperation*',`Glib::RefPtr',`Glib::wrap($3)')
 _CONVERSION(`GdaServerOperation*',`Glib::RefPtr',`Glib::wrap($3)')
+_CONVERSION(`GdaServerOperationCreateTableArg*',`Glib::RefPtr',`Glib::wrap($3)')
+_CONVERSION(`GdaServerOperationCreateTableArg*',`Glib::RefPtr',`Glib::wrap($3)')
 _CONVERSION(`GdaDataHandler*',`Glib::RefPtr',`Glib::wrap($3)')
 _CONVERSION(`GdaSqlParser*',`Glib::RefPtr',`Glib::wrap($3)')
 _CONVERSION(`GdaSqlParser*',`Glib::RefPtr',`Glib::wrap($3)')
In file included from /home/pavlo/jhbuild/install/include/glibmm-2.54/glibmm/object.h:35:0,
 from /home/pavlo/jhbuild/install/include/glibmm-2.54/glibmm/binding.h:22,
 from /home/pavlo/jhbuild/install/include/glibmm-2.54/glibmm.h:91,
 from /home/pavlo/jhbuild/checkout/libgdamm/libgda/libgdamm/serveroperation.cc:4:
/home/pavlo/jhbuild/install/include/glibmm-2.54/glibmm/containerhandle_shared.h: In instantiation of ‘struct Glib::Container_Helpers:

prepare_create_table wrapping - part2

[Pavlo Solntsev]

hi,
I found some mistakes in my code and fixed them. However, I can't
figure out where is the problem. I included new patch for my changes as
well as log from the compiler. Could someone take a look?
Thanks.


-- 
- Pavlo Solntsev
-
Sent from Evolution on GNU/Debian  id="-x-evo-
selection-start-marker">

diff --git a/libgda/src/serveroperation.ccg b/libgda/src/serveroperation.ccg
index 7062331..c2b35ff 100644
--- a/libgda/src/serveroperation.ccg
+++ b/libgda/src/serveroperation.ccg
@@ -77,6 +77,24 @@ void ServerOperation::set_value_at_as_value(const Glib::ustring& path, const Gli
 ::Glib::Error::throw_exception(gerror);
 }
 
+static Glib::RefPtr prepare_create_table(Glib::RefPtr , 
+  const Glib::ustring _name,
+  std::vector )
+{
+GError* gerror = 0;
+Glib::RefPtr op =
+Glib::wrap(gda_server_operation_prepare_create_table(
+cnc.operator->()->gobj(), 
+table_name.c_str(),
+Glib::ListHandler::vector_to_list(arguments).data(),
+)
+);   
+
+  if(gerror) ::Glib::Error::throw_exception(gerror);
+
+  return op;
+}
+
 } /* namespace Gda */
 
 } /* namespace Gnome */
diff --git a/libgda/src/serveroperation.hg b/libgda/src/serveroperation.hg
index 079651d..fce01e8 100644
--- a/libgda/src/serveroperation.hg
+++ b/libgda/src/serveroperation.hg
@@ -68,6 +68,11 @@ public:
   static Glib::RefPtr prepare_drop_database(const Glib::ustring& provider,
  const Glib::ustring& db_name);
 
+  
+   static Glib::RefPtr prepare_create_table(Glib::RefPtr , 
+ const Glib::ustring _name,
+ std::vector );
+
   _WRAP_METHOD(void perform_create_table(), gda_server_operation_perform_create_table, errthrow)
   _WRAP_METHOD(void perform_drop_database(const Glib::ustring& provider), gda_server_operation_perform_drop_database, errthrow)
   _WRAP_METHOD(void perform_create_database(const Glib::ustring& provider), gda_server_operation_perform_create_database, errthrow)
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H   -I.. -I/home/pavlo/jhbuild/checkout/libgdamm/libgda -I../.. -DG_LOG_DOMAIN=\"libgdamm\" -DLIBGDAMM_BUILD=1 -pthread -I/home/pavlo/jhbuild/install/include/glibmm-2.54 -I/home/pavlo/jhbuild/install/lib/glibmm-2.54/include -I/home/pavlo/jhbuild/install/include/sigc++-3.0 -I/home/pavlo/jhbuild/install/lib/sigc++-3.0/include -I/home/pavlo/jhbuild/install/include/libgda-6.0 -I/home/pavlo/jhbuild/install/include/libgda-6.0/libgda -I/home/pavlo/jhbuild/install/include/glib-2.0 -I/home/pavlo/jhbuild/install/lib/glib-2.0/include -I/usr/include/libxml2  -Wall -g -O2 -MT serveroperation.lo -MD -MP -MF .deps/serveroperation.Tpo -c -o serveroperation.lo /home/pavlo/jhbuild/checkout/libgdamm/libgda/libgdamm/serveroperation.cc
libtool: compile:  g++ -DHAVE_CONFIG_H -I.. -I/home/pavlo/jhbuild/checkout/libgdamm/libgda -I../.. -DG_LOG_DOMAIN=\"libgdamm\" -DLIBGDAMM_BUILD=1 -pthread -I/home/pavlo/jhbuild/install/include/glibmm-2.54 -I/home/pavlo/jhbuild/install/lib/glibmm-2.54/include -I/home/pavlo/jhbuild/install/include/sigc++-3.0 -I/home/pavlo/jhbuild/install/lib/sigc++-3.0/include -I/home/pavlo/jhbuild/install/include/libgda-6.0 -I/home/pavlo/jhbuild/install/include/libgda-6.0/libgda -I/home/pavlo/jhbuild/install/include/glib-2.0 -I/home/pavlo/jhbuild/install/lib/glib-2.0/include -I/usr/include/libxml2 -Wall -g -O2 -MT serveroperation.lo -MD -MP -MF .deps/serveroperation.Tpo -c /home/pavlo/jhbuild/checkout/libgdamm/libgda/libgdamm/serveroperation.cc  -fPIC -DPIC -o .libs/serveroperation.o
In file included from /home/pavlo/jhbuild/install/include/glibmm-2.54/glibmm.h:142:0,
 from /home/pavlo/jhbuild/checkout/libgdamm/libgda/libgdamm/serveroperation.cc:4:
/home/pavlo/jhbuild/install/include/glibmm-2.54/glibmm/vectorutils.h: In instantiation of ‘Glib::Container_Helpers::GListKeeper::~GListKeeper() [with Tr = Glib::Container_Helpers::TypeTraits<_GdaServerOperationCreateTableArg>]’:
/home/pavlo/jhbuild/checkout/libgdamm/libgda/libgdamm/serveroperation.cc:98:94:   required from here
/home/pavlo/jhbuild/install/include/glibmm-2.54/glibmm/vectorutils.h:859:28: error: invalid use of incomplete type ‘using CTypeNonConst = using CTypeNonConst = struct _GdaServerOperationCreateTableArg {aka struct _GdaServerOperationCreateTableArg}’
 Tr::release_c_type(static_cast(node->data));
^~
In file included from /home/pavlo/jhbuild/install/include/libgda-6.0/libgda/gda-server-provider.h:30:0,
 from /home/pavlo/jhbuild/checkout/libgdamm/libgda/libg

prepare_create_table implementation issue

[Pavlo Solntsev]

Hi,

I am trying to wrap gda_server_operation_prepare_create_table(). The
patch still doesn't work and I need some expert check and adjustment.
Could you please take a look at your convenience? 

Thanks.

-- 
- Pavlo Solntsev
-
Sent from Evolution on GNU/Debian  id="-x-evo-
selection-start-marker">

diff --git a/libgda/src/serveroperation.ccg b/libgda/src/serveroperation.ccg
index 7062331..e15f6c0 100644
--- a/libgda/src/serveroperation.ccg
+++ b/libgda/src/serveroperation.ccg
@@ -77,6 +77,25 @@ void ServerOperation::set_value_at_as_value(const Glib::ustring& path, const Gli
 ::Glib::Error::throw_exception(gerror);
 }
 
+
+typedef GdaServerOperationCreateTableArg CreateTableArg;
+
+static Glib::RefPtr prepare_create_table(Glib::RefPtr , 
+  const Glib::ustring _name,
+  std::vector )
+{
+  GError* gerror = 0;
+  Glib::RefPtr op =
+Glib::wrap(gda_server_operation_prepare_create_table(cnc.operator->()->gobj(), 
+ table_name.c_str(),
+   Glib::SListHandler::vector_to_slist(arguments).data()),
+   );   
+
+  if(gerror) ::Glib::Error::throw_exception(gerror);
+
+  return op;
+}
+
 } /* namespace Gda */
 
 } /* namespace Gnome */
diff --git a/libgda/src/serveroperation.hg b/libgda/src/serveroperation.hg
index 079651d..af9f8a0 100644
--- a/libgda/src/serveroperation.hg
+++ b/libgda/src/serveroperation.hg
@@ -68,6 +68,12 @@ public:
   static Glib::RefPtr prepare_drop_database(const Glib::ustring& provider,
  const Glib::ustring& db_name);
 
+   typedef GdaServerOperationCreateTableArg CreateTableArg;
+  
+   static Glib::RefPtr prepare_create_table(Glib::RefPtr , 
+ const Glib::ustring _name,
+ std::vector );
+
   _WRAP_METHOD(void perform_create_table(), gda_server_operation_perform_create_table, errthrow)
   _WRAP_METHOD(void perform_drop_database(const Glib::ustring& provider), gda_server_operation_perform_drop_database, errthrow)
   _WRAP_METHOD(void perform_create_database(const Glib::ustring& provider), gda_server_operation_perform_create_database, errthrow)
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: libgdamm compilation

[Pavlo Solntsev]

I finally compiled libgdamm - master branch. Uh. All branches glib,
glibmm, libgda, and libgdamm are master's. libgda didn't go without --
disable-crypto. I compiled against libssl-dev-1.1.0e-1  , whichis default in 
debian testing. 

Sorry, Murray, for taking your time. Your comments and suggestions were
very useful. 

Best,
 

On Fri, 2017-04-28 at 08:26 +0200, Murray Cumming wrote:
> On Thu, 2017-04-27 at 23:53 -0500, Pavlo Solntsev wrote:
> > Murray,
> > 
> > It looks like I was confused by the version labeling. I was able to
> > compile libgda (upstream version) but without libcrypto support. I
> > filed a bug for that. I am trying to compile libgdamm using jhbuild
> > but
> >  always receive:
> > configure: error: Package requirements (glibmm-2.54 >= 2.45.31
> > libgda-
> > 6.0 >= 5.0.2) were not met:
> > 
> > No package 'glibmm-2.54' found
> > 
> > I just found that default branch is not master.
> 
> I don't know what default would mean here. The git master branch of
> libgdamm (the libgdamm-6.0 API) builds with the master branch of
> libgda
> (the libgda-6.0 API) and the master branch of glibmm (the glibmm-2.54
> API).
> 
> At least, it's meant to.
> 
> Maybe you are sometimes talking about distro package versions
> (Debian,
> Ubuntu, Fedora?) and sometimes about building from git.
> 
-- 
- Pavlo Solntsev
-
Sent from Evolution on GNU/Debian  id="-x-evo-
selection-start-marker">

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: libgdamm compilation

[Pavlo Solntsev]

Murray,

It looks like I was confused by the version labeling. I was able to
compile libgda (upstream version) but without libcrypto support. I
filed a bug for that. I am trying to compile libgdamm using jhbuild but
 always receive:
configure: error: Package requirements (glibmm-2.54 >= 2.45.31 libgda-
6.0 >= 5.0.2) were not met:

No package 'glibmm-2.54' found

I just found that default branch is not master. Thus, I can't get the
recent version. I am working on this case and will let you know if I
have any problem.

Thanks.



On Thu, 2017-04-27 at 22:24 +0200, Murray Cumming wrote:
> On Thu, 2017-04-27 at 14:08 -0500, Pavlo Solntsev wrote:
> > Thanks. 
> > 
> > For me it is confused to see one version in the file name and
> > another
> > inside. 
> 
> I'm sorry. I don't understand. What change are you suggesting? Maybe
> a
> patch would make that clearer. Thanks.
> 
> 
> Murray Cumming
> murr...@murrayc.com
> www.murrayc.com
> 
-- 
- Pavlo Solntsev
-
Sent from Evolution on GNU/Debian  id="-x-evo-
selection-start-marker">


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: libgdamm compilation

[Pavlo Solntsev]

Thanks. 

For me it is confused to see one version in the file name and another
inside. 

On Thu, 2017-04-27 at 20:37 +0200, Murray Cumming wrote:
> On Thu, 2017-04-27 at 07:58 -0500, Pavlo Solntsev wrote:
> > Hi,
> > 
> > Why do we have libgda-6.0 >= 5.0.2 in configure.ac? I haven't seen
> > the
> > corresponding branch in libgda.
> 
> libgda's git master is libgda-6.0:
> https://git.gnome.org/browse/libgda/tree/libgda-6.0.pc.in
> 
> >  Or maybe I missed something. 
> > The recent package is libgda-5.0 therefore it looks like a typo for
> > me.
> 
> 
-- 
- Pavlo Solntsev
-
Sent from Evolution on GNU/Debian  id="-x-evo-
selection-start-marker">


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

libgdamm compilation

[Pavlo Solntsev]

Hi,

Why do we have libgda-6.0 >= 5.0.2 in configure.ac? I haven't seen the
corresponding branch in libgda. Or maybe I missed something. 
The recent package is libgda-5.0 therefore it looks like a typo for me.

Thanks.



-- 
- Pavlo Solntsev
-
Sent from Evolution on GNU/Debian  id="-x-evo-
selection-start-marker">

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

perform_create_table wrapper

[Pavlo Solntsev]

Hello,

Still trying to get around libgdamm. I found that
gda_server_operation_perform_create_table() has no wrapper. Is there
any reason for that? I made a simple patch to implement this. I may try
to help more if it is useful. Let me know. 

BTW, what distro is more appropriate for GNOME? I am using Debian
testing but it looks like my packages are not new enough. I used to use
Ubuntu, but it was so buggy about 3-4 years ago. I don't want to make a
lot of discussion from this topic just want to get an idea about what
people use. 

Thanks. 



-- 
- Pavlo Solntsev
-
Sent from Evolution on GNU/Debian  id="-x-evo-
selection-start-marker">
From d65b598c4b5969736a376be9c7c23f4dacd47764 Mon Sep 17 00:00:00 2001
From: Pavlo Solntsev <pavlo.solnt...@gmail.com>
Date: Tue, 25 Apr 2017 22:26:12 -0500
Subject: [PATCH] perform_create_table was wrapped

---
 libgda/src/serveroperation.ccg | 11 +++
 libgda/src/serveroperation.hg  |  1 +
 2 files changed, 12 insertions(+)

diff --git a/libgda/src/serveroperation.ccg b/libgda/src/serveroperation.ccg
index 968ac0e..ca40b52 100644
--- a/libgda/src/serveroperation.ccg
+++ b/libgda/src/serveroperation.ccg
@@ -98,6 +98,17 @@ void ServerOperation::set_value_at_as_value(const Glib::ustring& path, const Gli
 ::Glib::Error::throw_exception(gerror);
 }
 
+bool ServerOperation::perform_create_table()
+{
+GError *error = 0;
+bool res;
+res = gda_server_operation_perform_create_table(gobj(),);
+if(error) ::Glib::Error::throw_exception(error);
+
+return res;
+}
+
+
 } /* namespace Gda */
 
 } /* namespace Gnome */
diff --git a/libgda/src/serveroperation.hg b/libgda/src/serveroperation.hg
index ef12fd0..d1eb8ee 100644
--- a/libgda/src/serveroperation.hg
+++ b/libgda/src/serveroperation.hg
@@ -67,6 +67,7 @@ public:
   static Glib::RefPtr prepare_drop_database(const Glib::ustring& provider,
  const Glib::ustring& db_name);
 
+  bool perform_create_table();
   bool perform_drop_database(const Glib::ustring& provider);
   bool perform_create_database(const Glib::ustring& provider);
 
-- 
2.11.0

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: libgdamm in Debian

[Pavlo Solntsev]

Dear Aitor.

I have made a package for debian. Could you please take a look and
provide comments and suggestions, if any? I was able to build only with
--enable-maintainer-mode flag. I am planning to move forward and upload
it to the debian repo. If anyone has any suggestions feel free to
share.

all files are here:
https://drive.google.com/drive/folders/0B8fjSLiFRX_PZWFnbUVfMTcxYTA?usp
=sharing
 
Best,



On Tue, 2017-04-11 at 23:33 +0200, aitor_czr wrote:
> Hi Pavlo,
> On 04/11/2017 02:00 PM, Pavlo Solntsev <pavlo.solnt...@gmail.com>
> wrote:
> 
> > Murray,
> > 
> > It looks like you were a maintainer of libgdamm package in debian.
> > This
> > package in not a part of debian anymore. Could you please clarify
> > why
> > packed was removed from debian? Thanks.
>  
> Indeed, i can't find any packaging of libgdamm in debian.
> 
> I have some experience packaging for debian. Maybe, i can help on
> that.
> 
> Cheers,
> 
>   Aitor.
> 
> 
> 
-- 
- Pavlo Solntsev
-
Sent from Evolution on GNU/Debian  id="-x-evo-
selection-start-marker">

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm-list Digest, Vol 156, Issue 11

[Pavlo Solntsev]

Dear Aitor.
I already built a Debian package. I was thinking to become a Debian
developer. I can provide you my build for your comments.


-Pavlo Solntsev
Sent from Linux based mobile OS.

On Apr 11, 2017 4:33 PM, "aitor_czr" <aitor_...@gnuinos.org> wrote:

Hi Pavlo,
On 04/11/2017 02:00 PM, Pavlo Solntsev <pavlo.solnt...@gmail.com>
<pavlo.solnt...@gmail.com> wrote:

Murray,

It looks like you were a maintainer of libgdamm package in debian. This
package in not a part of debian anymore. Could you please clarify why
packed was removed from debian? Thanks.


Indeed, i can't find any packaging of libgdamm in debian.

I have some experience packaging for debian. Maybe, i can help on that.

Cheers,

  Aitor.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

libgdamm in debian

[Pavlo Solntsev]

Murray,

It looks like you were a maintainer of libgdamm package in debian. This
package in not a part of debian anymore. Could you please clarify why
packed was removed from debian? Thanks.




-Pavlo Solntsev
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

C++ binding of C struct

[Pavlo Solntsev]

Hi,

I tried to send this email before but wasn't sure about success. 

I saw we have some C struct in libgdamm/glibmm code. In the source file
(libgdamm) I saw a comment that C struct should be wrapped. Do we have
a plan how to wrap C struct into C++ style? Could you provide
reference, if any? One of such objects is GdaMetaDBObject. Technically,
it might not be necessary because this object should not be modified
(based on explanation for the object). I would expect that function
Gnome::Gda::MetaStruct::complement(...) should return const
GdaMetaDBObject*.  


Thanks.

-- 
- Pavlo Solntsev
-
Sent from Evolution on GNU/Debian  id="-x-evo-
selection-start-marker">

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

struct binding

[Pavlo Solntsev]

Hi,

Do we have an established method for binding C struct. I see some stuct
in libgdamm and glibmm that where left as they are. For example,
GdaMetaDbObject (libgdamm). What is the status, if any, of this
project.

-- 
- Pavlo Solntsev
-
Sent from Evolution on GNU/Debian  id="-x-evo-
selection-start-marker">


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

wrapping structure

[Pavlo Solntsev]

Hi,
What is the strategy to wrap C struct in mm versions? I Found that in
libgdamm some struct's are totally C like. There is a comment there,
that struct's should be wrapped. Do you have any idea how to approach
this case? 

Thanks.
-Pavlo.

-- 
- Pavlo Solntsev
-
Sent from Evolution on GNU/Debian  id="-x-evo-
selection-start-marker">


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm-doc patch

[Pavlo Solntsev]

Thanks, Kjell.

I didn't realized this. 

On Tue, 2017-02-21 at 13:02 +0100, Kjell Ahlstedt wrote:
> The programs in https://git.gnome.org/browse/gtkmm-documentation/tree
> /examples, the master branch, are updated for gtkmm-4, the new API-
> and ABI-breaking coming release of gtkmm. In gtkmm-4 show_all() and
> show_all_children() have been removed. They are not needed because
> property_visible() has default value true. In gtkmm-3 the default
> value is false.
> If you want to see example programs for gtkmm-3, look at the gtkmm-3-
> 22 branch,
> https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/a
> ctionbar/examplewindow.cc?h=gtkmm-3-22
> 
> Den 2017-02-20 kl. 20:59, skrev Pavlo Solntsev:
> > Small correction.
> > 
> > Please review.
> > 
> > 
>  
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

gtkmm-doc patch

[Pavlo Solntsev]

Small correction.

Please review.

diff --git a/examples/book/actionbar/examplewindow.cc b/examples/book/actionbar/examplewindow.cc
index 1206edb..4f3ae40 100644
--- a/examples/book/actionbar/examplewindow.cc
+++ b/examples/book/actionbar/examplewindow.cc
@@ -54,6 +54,7 @@ ExampleWindow::ExampleWindow()
   m_box.pack_start(m_face_image, Gtk::PACK_EXPAND_WIDGET);
   m_box.pack_end(m_action_bar, Gtk::PACK_SHRINK);
   add(m_box);
+  show_all_children();
 }
 
 ExampleWindow::~ExampleWindow()
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::CellRendererCombo how to

[Pavlo Solntsev]

Thank you so much, Phil.

I didn't realized I have to insert ListStore model as value for each
row. Also, a little bit confusing was part render->property_editable()
= true. I see logic here now, but it wasn't clear. 

Surprisingly, I wasn't able to locate this example on the web site.

Thanks again.

-Pavlo.


On Fri, 2017-02-10 at 06:43 -0800, Phil Wolff wrote:
> https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/t
> reeview/combo_renderer
> 
> 
> On 02/10/2017 06:17 AM, p_solnt...@meta.ua wrote:
> > Hi,
> > 
> > Could you please provide a simple example how to use
> > Gtk::CellRendererCombo in Gtk::TreeView?
> > 
> > What I have for now is two column Gtk::TreeView. In first column
> > (each
> > raw) I need ComboBox.
> > 
> > I have the following class for ComboModel. Is it necessary to have
> > m_id
> > member?
> > 
> > class ModelColumnsRender : public Gtk::TreeModelColumnRecord
> > {
> > public:
> > 
> >    ModelColumnsRender()
> >  { add(m_name); }
> > 
> >    Gtk::TreeModelColumn m_name;
> > }m_columnsrender;
> > 
> > Using m_columnsrender I can create a Gtk::ListTree model and
> > populate it.
> > 
> > For TreeView itself, I also have the similar class as mentioned
> > above:
> > 
> > class ModelColumns : public Gtk::TreeModelColumnRecord
> > {
> > public:
> > 
> >    ModelColumns()
> >  { add(m_name); add(m_amount) }
> > 
> >    Gtk::TreeModelColumn m_name;
> >    Gtk::TreeModelColumn m_amount;
> > 
> > }m_columns;
> > 
> > I can also create a ListStore model using m_columns.
> > 
> > Now I do the following:
> > // Create a column
> > auto render = Gtk::manage(new Gtk::CellRenderCombo);
> > auto pCol = Gtk::manage(new Gtk::TreeViewColumn("Animals"));
> > 
> > pCol->pack_start(*render, true);
> > treeview->append_column(*pCol);
> > treeview->append_column("Amount",m_columns.m_amount);
> > 
> > How can I add a model to my render? I tried
> > 
> > render->property_model() = refListStoreModelForCombo;
> > 
> > But no effect.
> > 
> > Where should I define the model for CellRenderCombo? inside of
> > ModelColumns class if so, how can I populate it?
> > 
> > Thanks.
> > 
> > -Pavlo
> > 
> > 
> > 
> > 
> > 
> > __
> > Жіноча нижня білизна від Anabel Arto
> > http://go.meta.ua/anabel_lingery_ua
> > 
> > ___
> > gtkmm-list mailing list
> > gtkmm-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtkmm-list
> 
> 
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm compilation issue via jhbuild

[Pavlo Solntsev]

Thank you, D.B.

Could someone, please, explain briefly the overall model for
glib/gtkmm/libgdamm feature implementation? I mean, if I want to
introduce some features, I can provide a patch. It is clear. But where
should I implement my changes: gtk+gtkmm or there is a mechanism to add
features directly to gtkmm avoiding gtk. It will help me better
understand methodology of the aforementioned libraries.

Thanks.

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

gtkmm compilation issue via jhbuild

[Pavlo Solntsev]

Hi,
I was trying to compile gtkmm via jhbuild. All modules were ok, except
gtkmm. I got this massage:

/home/pavlo/jhbuild/checkout/gtkmm/gdk/gdkmm/cursor.cc: In member
function ‘Cairo::RefPtr
Gdk::Cursor::get_surface(double&, double&)’:
/home/pavlo/jhbuild/checkout/gtkmm/gdk/gdkmm/cursor.cc:178:10: error:
‘make_refptr_for_instance’ is not a member of ‘Cairo’
   return ::Cairo::make_refptr_for_instance< ::Cairo::Surface>(new
::Cairo::Surface(gdk_cursor_get_surface(gobj(), &(x_hot), &(y_hot)),
true /* take reference */));
  ^~
/home/pavlo/jhbuild/checkout/gtkmm/gdk/gdkmm/cursor.cc:178:61: error:
expected primary-expression before ‘>’ token
   return ::Cairo::make_refptr_for_instance< ::Cairo::Surface>(new
::Cairo::Surface(gdk_cursor_get_surface(gobj(), &(x_hot), &(y_hot)),
true /* take reference */));
 ^
Makefile:625: recipe for target 'cursor.lo' failed

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Time in Glibmm and libgdamm

[Pavlo Solntsev]

Hi, (my first email didn't go well)

My question about Glibmm and libgdamm. I code only in c++. I faced this
problem when I wanted to save Date and Time into SQL database using
libgdamm. SQL by itself provides two types: DATE and TYPE. They are
good match for Glib::Date class, which already exist, and Glib::Time,
which doesn't exist. 

I can use GdaTime via std::time_t but this is ugly way for OO. Some
other libraries including boost provide class to handle time.

Could please explain me, why we have this situation with Time? It is so
ambiguous and confusing. I will be glad to help with implementation of
Glib::Time class. 
I would like a solution where Glib::Time and Glib::Date classes are
parent classes for Glib::DataTime. It will allow to manipulate DATATIME
type in SQL. 

Thanks.

From documentation:

typedef gint32  GTime;
Simply a replacement for time_t. It has been deprecated since it is not
equivalent to time_t on 64-bit platforms with a 64-bit time_t.
Unrelated to GTimer.
Note that GTime is defined to always be a 32-bit integer, unlike time_t
which may be 64-bit on some systems. Therefore, GTime will overflow in
the year 2038, and you cannot use the address of a GTime variable as
argument to the UNIX time() function.


Some time related classes found in Glib and Gnome::Gda namespace
1) Glib::Date
2) Glib::DateTime
3) Glib::TimeVal
4) Gnome::Gda::Timestemp ( or GdaTimestamp)
5) Gnome::Gda::Time ( or GdaTime)

Another unrelated topic. Since libgda will be developed by itself, it
would be clearer to have all class in Gda namespace. For back
compatibility, we may typedef Gda namespace to Gnome::Gda. 


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Storring value in treeview

[Pavlo Solntsev]

Hi,
Simple example:
class myclass {
enum MyType {
None = 0,
Firsttype ,
Secondtype
};
}

I have a class member that returns MyType. Let's call it get_type (). 
Some code exame:
void myfunc (sometype obj)
{
Gtk::TreeModel::Row row =*(m_refTreeView-> get_selected ());
row[m_columns.m_type] = obj.get_type ();
// checking code
std::cout << "1typ is " << obj.get_type () << std::endl;
std::cout << "2typ is " << row [m_columns.m_type]  << std::endl;
}
m_columns.m_type is MyType type.
I don't understand,  why I see different outputs. In the first case I have the 
correct value 1 or 2, while in thesecond one I see a random value 86363773. 

I have many columns and have no problems with them. 
Could you please clarify what I missed. Let me know if you need more 
information.
-Pavlo.
Thanks.___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list