Re: gtkmm in MSYS2

[D. B.]

On Mon, Jan 23, 2017 at 1:48 PM, D. B. <db0...@gmail.com> wrote:

>
>> The second item was a really ugly oversized theme that I was not
>> able to change.  This is the one that made it useless for anything
>> that I wanted to do.  I did some hunting for a solution but the
>> only thing I was  able to find was that others had that problem
>> but there was no solution
>>
>
> That may be an issue, but more likely it's just your opinion on
> the default GTK+ 3 theme. And again, of course, there are solutions. You
> could have your application load in some CSS that overrides some properties
> to shrink padding on the elements you feel are too big, decrease font size,
> etc. It wouldn't be difficult.
>
>
Or, of course, just download another theme that you like more, and use
that. You can set it in your per-user GTK ini file, or even distribute your
application with calls that force that theme so that users would see the
same thing. You are in no way limited to the stock Adwaita theme.


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

Re: Glib::Dispatcher

[D. B.]

On Mon, Jan 23, 2017 at 12:00 PM, <gtkmm-list-requ...@gnome.org> wrote:

>
> Date: Mon, 23 Jan 2017 09:35:54 +0530
> From: Amit <ami...@skanray.com>
> To: gtkmm-list@gnome.org
> Subject: Re: gtkmm-list Digest, Vol 153, Issue 7 Gtkmm GUI fails to
> update
> Message-ID: <58858122.9000...@skanray.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
>
> Hi D. B .
>
> [...]
> *does it handle all calls to GTK++/mm functions?*
>
>   Pls Clarify  ...
>

I think I must've been thinking of something different. By reading
https://developer.gnome.org/gtkmm-tutorial/stable/sec-using-glib-dispatcher.html.en

it's hard to imagine any way to make non-threadsafe calls to GTK+ functions
using Dispatcher.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm-list Digest, Vol 153, Issue 9

[D. B.]

On Mon, Jan 23, 2017 at 12:00 PM, <gtkmm-list-requ...@gnome.org> wrote:

>
> Date: Mon, 23 Jan 2017 06:37:15 -0500
> From: Damon Register <damon.w.regis...@lmco.com>
> To: <gtkmm-list@gnome.org>
> Subject: Re: EXTERNAL: ANNOUNCE: gtkmm 3.89.3
> Message-ID: <a7f60730-3b52-b3a8-f0be-c03b603e5...@lmco.com>
> Content-Type: text/plain; charset="windows-1252"; format=flowed
>
> On 1/21/2017 8:12 AM, D. B. wrote:
> > I think whatever method you are using to obtain gtkmm is extremely
> suboptimal.
> I won't argue that.
>
> > Even in the GTK+2 branch, there's a 2.24 available of gtkmm.
> I could be wrong but it seems to me that the Windows side has
> always been behind the progress in the Linux world.  The only
> success that I ever got with gtkmm on Windows has been with
> a gtkmm 2.22 Windows installer found here:
> http://ftp.gnome.org/pub/gnome/binaries/win32/gtkmm/2.22/
> released about 6 years ago.  Since then I have never found anything
> that worked for me.  If there was a 2.24 installer for Windows,
> I never found it.
>

Official installers are not provided, but then neither are they for Linux
etc. It's expected that you'll build yourself or use a package-management
system - like MSYS2.


>
>  > Secondly, you should give a try to MSYS2, which provides
> > native Windows packages of gtkmm and many other useful libraries, and it
> tracks upstream releases
> I got excited for a moment about something new that might help
> but then after visiting the MSYS2 website I remembered that I tried
> this last year.
>
> > very quickly. I have had no (non-trivial or non-GTK-related!) problems
> building my current project
> > on both Debian and Windows for this reason.
> I wish I could say that was the case for me.  Last year I did get
> MSYS2 and was able to build a simple hello world project.  I ran
> into two problems and one made gtkmm3 on MSYS2 completely unusable.
>
> The first problem was
> GLib-GObject-WARNING **: attempt to override closure->va_marshal
> and I was not able to find a solution with Google or this list.
>

That wasn't really a problem, though. Things kept working. Or didn't they?
Besides, it has been fixed since then, since someone else had the idea of
reporting it on bugzilla, rather than giving up.


>
> The second item was a really ugly oversized theme that I was not
> able to change.  This is the one that made it useless for anything
> that I wanted to do.  I did some hunting for a solution but the
> only thing I was  able to find was that others had that problem
> but there was no solution
>

That may be an issue, but more likely it's just your opinion on the default
GTK+ 3 theme. And again, of course, there are solutions. You could have
your application load in some CSS that overrides some properties to shrink
padding on the elements you feel are too big, decrease font size, etc. It
wouldn't be difficult.

Given how both of these issues are respectively solved and easy to solve,
it would be worth trying again.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: EXTERNAL: ANNOUNCE: gtkmm 3.89.3

[D. B.]

On Sat, Jan 21, 2017 at 12:00 PM,  wrote:

> Date: Fri, 20 Jan 2017 15:27:49 -0500
> From: Damon Register 
> To: 
> Subject: Re: EXTERNAL: ANNOUNCE: gtkmm 3.89.3
> Message-ID: <69919c63-22ce-1d61-ada0-2c0fb6e8f...@lmco.com>
> Content-Type: text/plain; charset="utf-8"; format=flowed
>
> On 1/20/2017 7:45 AM, Murray Cumming wrote:
> > *** gtkmm
> >
> > gtkmm 3.89 wraps GTK+ 3.89. It will become gtkmm 4.0,
> > wrapping GTK+ 4.0. It is a version of the gtkmm-4.0 API.
> Wow, I have not been following the versions for a while.
> I am still stuck on gtkmm 2.22 because I have not been able to
> use anything more recent.  I am working on Windows and 2.22 is
> the only one that I could get to work.
>
> Thanks everyone for your work on this.  I guess it is time for
> me to take another shot at moving up.
>
> Damon Register
>

I think whatever method you are using to obtain gtkmm is extremely
suboptimal. Even in the GTK+2 branch, there's a 2.24 available of gtkmm.
Secondly, you should give a try to MSYS2, which provides native Windows
packages of gtkmm and many other useful libraries, and it tracks upstream
releases very quickly. I have had no (non-trivial or non-GTK-related!)
problems building my current project on both Debian and Windows for this
reason.

There may also be other methods, but this is the one I know, and I can
enthusiastically recommend it.

Keep in mind that (A) migrating from GTK+2 to GTK+3 may be non-trivial
depending on your program, and (B) GTK+4 may be the same again. Also, even
if you decide to move from 2 to 4 in one fell swoop, the migration guide
recommends that you first fixup your code so that it can build with 3, and
then start migrating to 4.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtkmm GUI fails to update

[D. B.]

On Fri, Jan 20, 2017 at 12:00 PM,  wrote:

> Date: Fri, 20 Jan 2017 12:25:48 +0530
> From: Amit 
> To: gtkmm-list@gnome.org
> Subject: Gtkmm GUI fails to update
>
> [...]
>

>   Window A has button called Dialogwindow A  which invoked a
> Dialogwindow and shows .
>
>   Window B has separate Thread which will update the data which need be
> be displayed on the windowB so here am
> using Dispatcher for displaying
>

Is the Dispatcher constructed in the same thread that initialised GTK+, and
does it handle all calls to GTK++/mm functions? AFAIK these are absolutely
required, otherwise all bets are off, and sporadic updating sounds like a
relatively lucky outcome. :D
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm compilation issue via jhbuild

[D. B.]

On Sun, Jan 1, 2017 at 12:00 PM,  wrote:

>
> Date: Sat, 31 Dec 2016 22:59:15 -0600
> From: Pavlo Solntsev 
> To: gtkmm-list@gnome.org
> Subject: Re: gtkmm compilation issue via jhbuild
> Message-ID: <1483246755.3065.8.ca...@meta.ua>
> Content-Type: text/plain; charset="UTF-8"
>
> 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.
>


Like those in many other languages, the mm libraries are *bindings* around
GLib, GTK+, and other C libraries. They make the libraries usable from
other languages.

In almost all cases, features should be added to the underlying C libs. In
most cases they can be automatically added to the bindings. A combination
of many clever tools written by binding authors and GObject introspection
mean that often, newly added functions/properties/signals can be
synchronised to the bindings automatically, with the only human
intervention being to run a script that does so.

Occasionally, a binding will add a small convenience feature, or wrapping a
C function/property/signal requires hand-written code, or etc. But usually,
if you want a new feature, you really want it in the wrapped libraries, not
the wrappers... as, I'm sure, do people who use the C libraries or prefer
to use other languages' bindings.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm compilation issue via jhbuild

[D. B.]

OP, I've created a Bugzilla for you:

https://bugzilla.gnome.org/show_bug.cgi?id=776658
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm compilation issue via jhbuild

[D. B.]

On Sat, Dec 31, 2016 at 12:00 PM,  wrote:

>
> Message: 1
> Date: Fri, 30 Dec 2016 13:36:20 +0100
> From: Kjell Ahlstedt 
> To: Pavlo Solntsev 
> Cc: gtkmm-list@gnome.org
> Subject: Re: gtkmm compilation issue via jhbuild
> Message-ID: <2f3d927f-77f6-02bd-ef5e-94f09a7b3...@bredband.net>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> jhbuild builds cairomm 1.15.1 from  a tarball, but gtkmm at present
> requires the latest cairomm from the git repository. See
> https://www.cairographics.org/cairomm/ for instructions how to get
> cairomm from git.
>
> Do you know that gtkmm and gtk+ are now unusually unstable? They will
> become gtkmm-4.0 and gtk+-4.0, which will not be ABI-compatible with
> gtkmm-3.0 and gtk+-3.0. If you want less unstable programs, you can
> build gtkmm-3 with jhbuild.
>
> Kjell
>

If you don't beat me to it, I'll see whether I know enough jhbuild to
resolve this for gtkmm 4 (now a.k.a. gtkmm) in its modulesets.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: GTKMM for Windows - Informations request

[D. B.]

>
> One question: does using MSYS2 to generate the binaries generate a
> dependency on Cygwin library (dll)? If yes, that does not fit the purpose
> of having a native Windows environment.


Of course it doesn't fit, and that's why it doesn't happen! MSYS2 also
provides mingw-w32 and -w64 shells with compilers that link directly
against the native runtimes (unless you told them otherwise, I guess)
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Time in Glibmm and libgdamm

[D. B.]

FYI, it looks like some kind of space character in your original email has
been changed to a question mark symbol throughout, which makes it hard to
read, at least here on GMail. Maybe you could reconfigure your email at the
sending side to avoid this. Hope this helps!
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: GTKMM for Windows - Informations request

[D. B.]

Personally I just installed MSYS2 and used its own precompled 32 and 64 bit
packages of GTK+/gtkmm/etc without problems. Then just keep running your
exe until you figure out all the DLLs that you need to distribute in the
same folder with it.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Fwd: gtkmm and glibmm DevHelp books do not work

[D. B.]

On Mon, Sep 19, 2016 at 8:29 PM, Phil Wolff  wrote:

> My system: Ubuntu 16.04, libgtkmm-3.0-doc 3.18.0-1, libglibmm-2.4-doc
> 2.46.3-1, devhelp 3.18.1. Docs are accessible via devhelp as expected.
>
> I note that the two links you specify were reported in 2011 and 2007…
>

For all I know, they're still applicable!

Should've said, though - I'm on Debian unstable, with gtkmm 3.21.6 and
glibmm 2.49.7.

Thanks for the data point anyway.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

gtkmm and glibmm DevHelp books do not work

[D. B.]

I noticed this in Builder, but it applies equally to DevHelp in the main
(which Builder just calls on).

Both the gtkmm and glibmm documentation sets are shown as options in
DevHelp, but they're unusable. DevHelp gives an "Error opening the
requested link" on the 1st try to open any document in either tree, and is
silent after that. Other docs work OK.

/usr/share/devhelp/books contains directories for both projects with
.devhelp2 files therein, which seem to point at the correct paths (albeit
via symlinks, but that makes no difference) - but neither are usable. I
tried changing the path to avoid the symlink, and it made no difference.
The files are present at the mentioned location and can be browsed using a
normal web browser, just not DevHelp.

Possibly relevant links...
https://bugs.launchpad.net/ubuntu/+source/gtkmm3.0/+bug/886705
https://bugs.archlinux.org/task/8022

Is this just for me? Any ideas on how to fix it, either way?

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

Re: gtkmm-list Digest, Vol 149, Issue 3

[D. B.]

On Sat, Sep 10, 2016 at 1:00 PM,  wrote:

>
> I need to add the following functions:
>
> virtual Gtk::SizeRequestMode get_request_mode_vfunc() const;
> virtual void get_preferred_width_vfunc(int& minimum_width, int&
> natural_width) const;
> virtual void get_preferred_height_for_width_vfunc(int width, int&
> minimum_height, int& natural_height) const;
> virtual void get_preferred_height_vfunc(int& minimum_height, int&
> natural_height) const;
> virtual void get_preferred_width_for_height_vfunc(int height, int&
> minimum_width, int& natural_width) const;
> virtual void on_size_allocate(Gtk::Allocation& allocation);
> virtual void on_map();
> virtual void on_unmap();
> virtual void on_realize();
> virtual void on_unrealize();
>
>
Do you really, though? It would seem easier to create your custom widget by
composition and let the existing Gtk::Button implementation handle all of
those, unless you absolutely need special behaviour.

I never understood the refrain 'prefer composition over inheritance' until
I started trying to inherit from libraries like this and realised how much
hassle it causes, which is often unnecessary unless you're fundamentally
changing the base class behaviour.

In my case, I wasn't, because I was just adding functionality to existing
widgets by wrapping - for which inheritance just caused my headaches - and
a phenomenal amount of unnecessary space overhead for all those new vtables
I never actually needed.

So now I just use composition to aggregate widgets together and add signals
to them.

Just my experience, YMMV.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm-list Digest, Vol 148, Issue 8

[D. B.]

Heh, it HAD been reported, but Bugzilla search didn't find a match as I was
writing up my title, probably because mine was too specific...

Here we go:
https://bugzilla.gnome.org/show_bug.cgi?id=769076
...and there are patches there, though I can't see any indication that a
fix has been committed yet, but it's definitely in the works.

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

Re: gtkmm-list Digest, Vol 148, Issue 8

[D. B.]

curse my keyboard. here's the missing bit

On Thu, Aug 25, 2016 at 2:42 PM, D. B. <db0...@gmail.com> wrote:

> Since AFAICT, somehow no one else had done it yet I've opened a bug
> report for this here:
>
>
https://bugzilla.gnome.org/show_bug.cgi?id=770392
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm-list Digest, Vol 148, Issue 8

[D. B.]

Since AFAICT, somehow no one else had done it yet I've opened a bug
report for this here:
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm-list Digest, Vol 148, Issue 8

[D. B.]

Although this isn't actually a gtkmm issue, or even a GTK+ one - rather
GLib/GObject as the message shows - did anyone ever figure out a reliable
explanation as to why it happens and how to prevent it?

-mwindows as I suggested is not working on my current example, oddly.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm-list Digest, Vol 148, Issue 8

[D. B.]

Btw, make sure you're using the mingw64 shell to compile, NOT the msys2
one! The latter should only be used for downloading/updating packages and
etc.


On Tue, Aug 16, 2016 at 1:05 PM, D. B. <db0...@gmail.com> wrote:

> I had this before. Based on research I think it might be caused by not
> compiling in GUI mode, i.e. with* -mwindows* switch etc.
>
> IIRC I could then start it from a cmd prompt - to ensure I'd see any
> stdout/err -  which wouldn't open the 2nd window like before, nor give the
> error
>
> Although I changed several things at the same time, so it could've been
> the others... but that was the only one that seemed relevant.
>
>
> On Tue, Aug 16, 2016 at 1:00 PM, <gtkmm-list-requ...@gnome.org> wrote:
>
>> Send gtkmm-list mailing list submissions to
>> gtkmm-list@gnome.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>> or, via email, send a message with subject or body 'help' to
>> gtkmm-list-requ...@gnome.org
>>
>> You can reach the person managing the list at
>> gtkmm-list-ow...@gnome.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of gtkmm-list digest..."
>>
>>
>> Today's Topics:
>>
>>1. gtkmm3 on msys2 gives "attempt to override
>>   closure->va_marshal" (Damon Register)
>>
>>
>> --
>>
>> Message: 1
>> Date: Mon, 15 Aug 2016 22:41:53 -0400
>> From: Damon Register <damonregis...@bellsouth.net>
>> To: Gtkmm Mailing List <gtkmm-list@gnome.org>
>> Subject: gtkmm3 on msys2 gives "attempt to override
>> closure->va_marshal"
>> Message-ID: <4107f574-d60a-b1e5-bbc7-b1a369946...@bellsouth.net>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> After being stuck in the gtkmm2 world for a few years, I decided to
>> finally try moving up to gtkmm3.  After a bit of searching on-line,
>> it seemed that it was either Visual Studio or msys2 if I want to make
>> Windows programs.  I followed the procedure that I found for msys2
>> and was even able to build a few "hello world" programs.  The only
>> problem I have is that I see this message on closing any of the
>> programs:
>>
>> GLib-GObject-WARNING **: attempt to override closure->va_marshal
>>
>> After some searching on this and a trip upstairs for some Excedrin,
>> I could only find a few mentions but no answers though I think one
>> suggested it might be a bug in this version of gtkmm.  Is there anyone
>> who knows about this problem and can help?
>>
>> I even tried a few tutorial examples such as the clock one, in case
>> my hello world code was missing something but they had the same
>> problem.
>>
>> Damon Register
>>
>>
>> --
>>
>> Subject: Digest Footer
>>
>> ___
>> gtkmm-list mailing list
>> gtkmm-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>>
>>
>> --
>>
>> End of gtkmm-list Digest, Vol 148, Issue 8
>> **
>>
>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm-list Digest, Vol 147, Issue 4

[D. B.]

Not to stand in the way of other users who might have valid logistical
barriers to that - but fwiw, I don't and would be very enthusiastically in
favour of requiring -std=c++14

The appeal of gtkmm to me is its cutting-edge adoption of modern C++
standards and recommended techniques, especially when compared to the
competition... who are only recently trying, and even slower in
broadcasting it. In contrast, gtkmm advertises it proudly. And this
leads to it having all the power of its much less readable bedrock BUT
while producing the most readable GUI code I've seen so far.

btw, for sake of pedantry, GCC 6 defaults to -std=gnu++14 which allows
non-standard extensions - none of which I can name, because I specifically
avoid such things!


On Thu, Jul 7, 2016 at 1:00 PM,  wrote:

> Message: 2
> Date: Thu, 07 Jul 2016 12:19:40 +0200
> From: Murray Cumming 
> To: gtkmm-list 
> Subject: C++14
> Message-ID: <1467886780.6740.6.ca...@murrayc.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Our current stable versions require C++11. Does anybody object to us
> requiring C++14 for the current unstable versions, which will become
> the next stable versions? GCC 6 uses C++14 by default.
>
> We don't need C++14 for anything urgently but it would be nice to have
> some little things such as decltype(auto) and std::make_unique().
>
> --
> Murray Cumming
> murr...@murrayc.com
> www.murrayc.com
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Accessing pair in Gtk::TreeModelColumn

[D. B.]

Given that TreeValueProxy uses a conversion operator returning a const
value of the template type, you simply need to tell the compiler to use
that conversion operator, so that it doesn't try to invoke .first on the
TreeValueProxy class itself.

You should be able to simplify the existing suggestions and avoid redundant
declarations by using a temporary and taking .first of that. I assume the
following are ultimately equivalent:

// cast to invoke specific conversion operator
auto str = static_cast< std::pair >(
row[columns.col] ).first;

// call copy ctor to make it deduce the right conversion
auto str = std::pair{ row[columns.col]
}.first;



On Fr, 2016-07-01 at 15:14 +0530, Kamalpreet Grewal wrote:
> > I am making a pair as data type of Gtk::TreeModelColumn.
> > Gtk::TreeModelColumn > col;
> >
> > At some places I wish to get only first string of this pair. So I did
> > something like row[columns.col].first to access it. But I get an
> > error.
> >
> > error: 'class Gtk::TreeValueProxy > Glib::ustring> >' has no member named 'first'
> >
> > I am accessing it just like one will do with another std::pair. How
> > can this be achieved?
>
> Try putting it in a pair first. For instance:
> std::pair thing = row[columns.col];
> auto str = thing.first;
>
> That might also work like this:
>
> const std::pair& thing =
> row[columns.col];
> const auto& str = thing.first;
>
> --
> Murray Cumming
> murr...@murrayc.com
> www.murrayc.com
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm-list Digest, Vol 146, Issue 12

[D. B.]

Hello,

I encountered the same thing when writing an internal library used to
collect some pre-main-program config from users. I couldn't just make this
concurrent with my main window (hidden until required) since it's reusable
code. As you've suggested, I just gave the initial config window its own
Application. This seems to work fine.

Of course, my main program has multiple windows, and that's OK, as long as
we have 1 window we can designate as primary to make it responsible for the
Application's lifetime.





On Fri, Jun 24, 2016 at 1:00 PM,  wrote:

> Send gtkmm-list mailing list submissions to
> gtkmm-list@gnome.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
> or, via email, send a message with subject or body 'help' to
> gtkmm-list-requ...@gnome.org
>
> You can reach the person managing the list at
> gtkmm-list-ow...@gnome.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gtkmm-list digest..."
>
>
> Today's Topics:
>
>1. Re: Gtk::Application - Switching between two Gtk::Window
>   (Kjell Ahlstedt)
>
>
> --
>
> Message: 1
> Date: Fri, 24 Jun 2016 11:41:45 +0200
> From: Kjell Ahlstedt 
> To: Tiago Matias 
> Cc: gtkmm-list@gnome.org
> Subject: Re: Gtk::Application - Switching between two Gtk::Window
> Message-ID: <576d0059.4050...@bredband.net>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> Terribly late reply. Don't know if you've found a solution.
> I tested with one of the example programs in the gtkmm tutorial. I
> created two identical windows, and called app->run() twice. The result was
>GLib-GIO-CRITICAL **: g_application_parse_command_line: assertion
> '!application->priv->options_parsed' failed
> and a segfault. I don't think Gtk::Application::run() is meant to be
> called more than once. A possible solution is to create two
> Gtk::Applications.
>
>auto app1 = Gtk::Application::create(argc, argv, "org.gtkmm.example");
>RadioButtons buttons1;
>app1->run(buttons1);
>
>auto app2 = Gtk::Application::create(argc, argv, "org.gtkmm.example");
>RadioButtons buttons2;
>return app2->run(buttons2);
>
> Kjell
>
> Den 2016-05-17 kl. 17:35, skrev Tiago Matias:
> > Before the line gtkmm_main->run (GuiWindow::Instance ()), I added the
> > the following line:
> >
> > gtkmm_main->add_window(GuiWindow::Instance ());
> >
> > This not have solved my problem.
> >
> > Best Regards,
> > Tiago Matias
> >
> >
> > On 05/17/2016 02:22 PM, Phil Wolff wrote:
> >> Be sure that your Gtk::Application calls add_window() on
> >> GuiWindow::Instance (). Gtk::Application can't properly handle any
> >> window it isn't aware of.
> >>
> >> On 2016/05/17 06:09, Tiago Matias wrote:
> >>> Hi,
> >>>
> >>>
> >>> I'm with a problem in a gtkmm application.
> >>>
> >>> I have a main file where a Gtk::Application runs a Gtk::Window. This
> >>> window loads some configurations when is showing a backgroud image.
> >>> In the final of the loading this window  calls the function hide()
> >>> ant the program returns to the main file program.
> >>>
> >>> Glib::RefPtr gtkmm_main =
> >>> Gtk::Application::create(argc, argv, "org.gtkmm.example");
> >>> gtkmm_main->run (IntroWindow::Instance());
> >>>
> >>>
> >>> After this, the Gtk::application runs other window:
> >>>
> >>> gtkmm_main->run (GuiWindow::Instance ());
> >>>
> >>> However, in this window, when i call the function hide(), the
> >>> program don't return to the main file program. If i don't run the
> >>> first window, the program returns. It seams that are some problem in
> >>> the switching of the windows. Can anyone help me.
> >>>
> >>> Best Regards,
> >>> Tiago Matias
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://mail.gnome.org/archives/gtkmm-list/attachments/20160624/70312802/attachment.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
> --
>
> End of gtkmm-list Digest, Vol 146, Issue 12
> ***
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Compiling and options

[D. B.]

Thanks, both! So it wasn't my other package causing it, at least :-) If
nothing else, it's news to me that people seemingly expect GCC 6 to hit
Debian testing soon... We'll see how well that works out.

For now, I'll keep hacking around their hack! Maybe add some grumblings to
their bugtracker later.

Thanks again







On Mon, Apr 18, 2016 at 6:57 PM, Murray Cumming  wrote:

> On Mon, 2016-04-18 at 17:37 +0100, Russel Winder wrote:
> > This appears to be just a Debian Sid thing, it does not happen with
> > Fedora Rawhide or OSX/MacPorts.
> >
> >
> > > > pkg-config glibmm-2.4 --cflags
> > -std=c++11 -I/usr/include/glibmm-2.4 -I/usr/lib/x86_64-linux-
> > gnu/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64
> > -linux-
> > gnu/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64
> > -linux-
> > gnu/sigc++-2.0/include
> >
> > > > pkg-config gtkmm-3.0 --cflags
> > -std=c++11 -pthread -I/usr/include/gtkmm-3.0 -I/usr/lib/x86_64-linux-
> > gnu/gtkmm-3.0/include -I/usr/include/atkmm-1.6 -I/usr/include/gtk-
> > 3.0/unix-print -I/usr/include/gdkmm-3.0 -I/usr/lib/x86_64-linux-
> > gnu/gdkmm-3.0/include -I/usr/include/giomm-2.4 -I/usr/lib/x86_64
> > -linux-
> > gnu/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib/x86_64-
> > linux-gnu/pangomm-1.4/include -I/usr/include/glibmm-2.4
> > -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/gtk-3.0
> > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0
> > -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include
> > -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/
> > -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz
> > -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
> > -I/usr/include/cairomm-1.0 -I/usr/lib/x86_64-linux-gnu/cairomm-
> > 1.0/include -I/usr/include/cairo -I/usr/include/pixman-1
> > -I/usr/include/freetype2 -I/usr/include/libpng16
> > -I/usr/include/sigc++-
> > 2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -I/usr/include/gdk
> > -
> > pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0
> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
>
> On debian, it's actually coming from the libsigc++ pkg-config file, as
> I think you'll find when you do this:
> $ pkg-config sigc++-2.0 --cflag
>
> They have done this against our wishes:
> https://bugzilla.gnome.org/show_bug.cgi?id=755750#c13
>
> This is very much a distro-specific problem that you should complain to
> your distro about. Sorry. I am annoyed with them, not with you. Thanks
> for letting me know.
>
>
> --
> Murray Cumming
> murr...@murrayc.com
> www.murrayc.com
>
>
>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Compiling and options

[D. B.]

Hi Murray,

Thanks for the fast explanation! Makes sense. And of course, I'll try these
out later and let you know.

This might just be the usual problem of me being really forgetful - I
just remembered I'm querying another package at the same time (as my
current makefile only manages 1 set of options for all object files). I'll
double-check and get back to you. I expect you're completely correct, of
course, and PEBKAC. Or at least, the other package isn't as careful to
preserve users' chosen settings as gtkmm thankfully is - another example of
its excellent quality. :-)

Cheers





On Mon, Apr 18, 2016 at 2:06 PM, Murray Cumming <murr...@murrayc.com> wrote:

> On Mon, 2016-04-18 at 13:51 +0100, D. B. wrote:
> > Russel: Just reorder arguments in your makefile such that your own
> > compiler options come after pkg-config's ones. Any later value for a
> > given option overrides the earlier one.
> >
> > Murray: I had to do exactly this to use -std=c++14 on Debian testing,
> > so yes, it does happen 'in the wild'.
>
> I can't find any such patch for the debian packages via this system:
> https://sources.debian.net/patches/gtkmm3.0/
> https://sources.debian.net/patches/glibmm2.4/
>
> Please show us the output of these commands, so we can see exactly
> where this -std=c++11 is coming from:
>
> $ pkg-config glibmm-2.4 --cflags
> $ pkg-config gtkmm-3.0 --cflags
>
> >  Do you mean that 'plain' gtkmm does not enforce any -std?
>
> Indeed. It does not, for this very reason.
>
> >  I thought C++11 was required for gtkmm, but do you normally require
> > users to add that manually in their own place?
>
> Yes. Adding it as CFLAG from pkg-config would cause this very problem.
>
> --
> Murray Cumming
> murr...@murrayc.com
> www.murrayc.com
>
>
>
>
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list